Disassembler gibt's die noch

[p80286]

Vor vielen Jahren, als Programme noch klein waren und Betriebssysteme noch mit 3 Buchstaben benannt wurden, gab es einige Disassembler die für kleines Geld recht ordentliche Leistung boten. Mit rudimentären Assembler-Kenntnissen, konnte man da einigen Programmen ganz gut über die Schulter schauen.

Gibt's so etwas auch heute noch oder ist man da ohne intime Kenntnisse des Prozessors, und der verschiedenen Spezialbefehlssätze vollkommen aufgeschmissen?

Gruß
K-H

[BUG]

Heute bist du vermutlich mit einem Debugger besser dran. Oder anders: jeder Debugger hat einen Disassambler dabei und während der Ausführung hineingucken ist bei den heutigen Code-Größen angenehmer.

Der Gold-Standard ist IDA Pro, OllyDbg ist unter Windows beliebt und von radare hab ich positives gehört.

[nuclearping]

X64DBG wäre noch erwähnenswert. Nicht vom Namen abschrecken lassen, er kann auch 32bit. :P

[mensch72]

Heute ist es die hohe Kunst, wie gut man virtualisiert ohne das es "bemerkt" wird.
Wenn dann noch ein echter echter Bus und CPU Trace von der virtuellen Umgebung möglichst in Echtzeit aufgezeichnet wird, dann kann ich anschließend beliebig oft und beliebig schnell (von Einzelschritt bis das was die Hardware hergibt) mich durch den Code arbeiten. Früher reichte oft das parsen der (D)OS Interrupts und man wusste was passiert.

Heute analysiert man zuerst die verwendeten PE-Loader(gepackt, verschlüsselt,...) und dann die verwendeten Compiler&Frameworks (.NET, Java, MFC, MCL, FMX,...) und hat dann hoffentlich in seinem Analysetool schon die passenden Plugins. Echt gute kommerzielle (kleine) Sachen in ASM oder einfachem Plain"C" gibt es heute quasi kaum noch.
(eigentlich nur bei bösem Zeug nehmen sich die Schöpfer noch die Zeit so ganz tief in die ASM Trickkiste zu greifen)

Gegen Spezialhardware mit dualported RAM oder Analysetools auf Hardwarebene kann fast kein Debugschutz bestehen. Solange die Sache in Quasi Echtzeit einer simulierten 1,5GHz Dualcore CPU läuft(real dann eben nötig Quadcore besser 4GHz) und sich aufzeichnen lässt, ist es nur eine Frage des Aufwandes es für ein bestimmtes Ziel zu analysieren.

[jaenicke]

Es gibt ja auch Dekompiler wie DeDe oder IDA, die aus Delphianwendungen gut kommentierten Assemblercode produzieren.

[Zacherl]

Ist halt die Frage, was du genau machen willst.

Für professionelle Anwendung kommt wohl ausschließlich IDA in Frage. Dafür gibt es optional von HexRays auch noch einen Decompiler, der das Assembly in C Code übersetzt. Ist aber recht teuer der Spaß.

Um mal eben reinzuschnuppern reichen OllyDbg oder x64dbg voll und ganz aus. Decompiler kenne ich dafür allerdings nicht. Kommt dann auf den Compiler deines Targets an, ob sehr viel gebrauch von neueren (spezial-)Instructions gemacht wird, oder nicht.

[himitsu]

Bedenke auch, daß frühe reine EXE nur 100 KB hatte und jetzt eine Delphi-EXE mit nur einer TForm mit TButton und dem EventCode

Delphi-Quellcode:

Beep;

schon gefühlte 80 MB sind ... da muß du gleich mal viel, viel, sehr viel mehr Assemblercode überblicken, bevor du den Beep überhaupt findest. :stupid:

[p80286]

Zitat:

Zitat von Zacherl (Beitrag 1324452)

Ist halt die Frage, was du genau machen willst.

Gute Frage, in den meisten Fällen schauen mit welchen Werten ein Programm arbeitet. Oder wie ein Zugriff realisiert wird, der "offizell" gar nicht geht. Aber das aus reiner Neugierde!

Zitat:

Zitat von himitsu (Beitrag 1324477)

Bedenke auch, daß frühe reine EXE nur 100 KB hatte und jetzt eine Delphi-EXE mit nur einer TForm mit TButton und dem EventCode

Delphi-Quellcode:

Beep;

schon gefühlte 80 MB sind ... da muß du gleich mal viel, viel, sehr viel mehr Assemblercode überblicken, bevor du den Beep überhaupt findest. :stupid:

Das ist, was mich abschreckt mein letzter (DISASM hieß er glaube ich) hat mir da eine enorme Menge an Arbeit abgenommen.

Zitat:

Zitat von mensch72 (Beitrag 1324430)

Früher reichte oft das parsen der (D)OS Interrupts und man wusste was passiert.

Auf der Stufe bin ich hängen geblieben.

Zitat:

Zitat von jaenicke (Beitrag 1324431)

Es gibt ja auch Dekompiler wie DeDe oder IDA, die aus Delphianwendungen gut kommentierten Assemblercode produzieren.

So richtig erschließt sich mir nicht der Unterschied zwischen Disassembler und Decompiler, aber auf den ersten Blick scheint IDA mir gut in den Kram zu passen.

Vielen Dank! mal schauen ob ich da noch durchsteige.

K-H

[Neutral General]

Zitat:

Zitat von p80286 (Beitrag 1324497)

Zitat:

Zitat von Zacherl (Beitrag 1324452)

Ist halt die Frage, was du genau machen willst.

Gute Frage, in den meisten Fällen schauen mit welchen Werten ein Programm arbeitet. Oder wie ein Zugriff realisiert wird, der "offizell" gar nicht geht. Aber das aus reiner Neugierde!

Verstehe nicht so genau was du da erreichen willst. Kannst du mal ein Beispiel nennen?
Habe das Gefühl, dass das heute nicht mehr relevant ist.

Zitat:

Zitat von p80286 (Beitrag 1324497)

So richtig erschließt sich mir nicht der Unterschied zwischen Disassembler und Decompiler, aber auf den ersten Blick scheint IDA mir gut in den Kram zu passen.

Disassembler: Maschinencode => Assemblercode
Decompiler: Maschinencode/Assemblercode => (Pseudo-)Hochsprache

[jaenicke]

Wobei der Unterschied zwischen reinem Disassembler und Decompiler fließend ist.

DeDe kann zum Beispiel keine Hochsprachenquelltexte erzeugen, bereitet den Assemblerquelltext aber auf und extrahiert Events aus Formularen einzeln usw., so dass die Struktur wieder ähnlich der des ursprünglichen Delphiprogramms ist.

[p80286]

Zitat:

Zitat von Neutral General (Beitrag 1324499)

Zitat:

Zitat von p80286 (Beitrag 1324497)

Zitat:

Zitat von Zacherl (Beitrag 1324452)

Ist halt die Frage, was du genau machen willst.

Gute Frage, in den meisten Fällen schauen mit welchen Werten ein Programm arbeitet. Oder wie ein Zugriff realisiert wird, der "offizell" gar nicht geht. Aber das aus reiner Neugierde!

Verstehe nicht so genau was du da erreichen willst. Kannst du mal ein Beispiel nennen?
Habe das Gefühl, dass das heute nicht mehr relevant ist.

Könnte sein. Letzt ist mir ein Programm über den Weg gelaufen, das die Komandozeilenparameter teilweise nur casesensitive bzw. gar nicht akzeptiert hat. Da dann "mal" nachzuschauen was er so treibt wäre schon ganz schön.

Gruß
K-H

[Neutral General]

War das zufällig ein altes CAD-Programm?

[mensch72]

..."Habe das Gefühl, dass das heute nicht mehr relevant ist."...

Sowas ist heute wie früher oft nur relevant, wenn man Sachen wissen will, die man nicht für Geld kaufen kann.


Gute (böse) Beispiele sind Analysen für Programme, welche offline irgendwelche symetrische Verschlüsselungen benutzen. Der Key ist als irgendwo "im System/Programm"... da ist es oft nur eine Frage des Aufwandes an diesen heran zukommen.
Ansonsten können es auch Algos oder Funktionsaufrufe sein, welche einen Interessieren. Gerne benutzt, um in eigentlich revisionssicherer Software doch Eingaben oder Änderungen nachträglich durchzuführen, welche nicht im TransaktionsLog erscheinen oder dort wieder verschwinden.


Schnödes Kopierschutz umgehen sehe ich nicht als lohnendes Ziel, denn da kann man für Geld es ja kaufen und kommt eigentlich immer billiger wie bei Gegenrechnung der zu investierenden Zeit.

[Neutral General]

Zitat:

Zitat von mensch72 (Beitrag 1324552)

..."Habe das Gefühl, dass das heute nicht mehr relevant ist."...

Sowas ist heute wie früher oft nur relevat, wenn man Sachen wissen will, die man nicht für Geld kaufen kann.

Ich meinte damit auch nicht dass solche Programme generell nicht mehr relevant sind.
Ich hatte nur das Gefühl (oder so habe ich es verstanden), dass p80286 sich quasi Programmier-"Tipps"/Tricks aus dem Assemblercode anderer Programme holen will.
Und das lohnt heutzutage in meinen Augen nicht mehr. Wenn es um Reverse Engineering von Algorithmen, Cracking o.ä. geht dann geht es ohne solche Programme natürlich auch heute nicht.

Wegen der Sache mit dem Kopierschutz umgehen: Wenn der Hersteller des Programms sich nicht beide Beine rausgerissen hat für seinen Kopierschutz/Lizenzabfrage dann lohnt das für jmd mit etwas Erfahrung in diesem Bereich auf jeden Fall - Vorausgesetzt natürlich es geht nicht um ein 50€ Programm. Aber bei Software die mehrere hundert oder tausend Euro kostet ist man dann am Ende doch billiger dran wenn man die Software innerhalb von ein paar Tagen crackt. (Das soll jetzt keine Motivation und erst recht kein Aufruf sein so etwas zu tun!).

[jaenicke]

Zitat:

Zitat von Neutral General (Beitrag 1324554)

Wegen der Sache mit dem Kopierschutz umgehen: Wenn der Hersteller des Programms sich nicht beide Beine rausgerissen hat

Beispiel bei XE2... da reichte es an der richtigen Stelle zwei Bytes zu ändern, dann dachte Delphi es sei aktiviert, wenn man eine gültige Seriennummer eingegeben hatte... ;-)
Da hatte ich spaßeshalber mal etwas herumprobiert. ;-)