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.