Binär in Source Übersetzer

[Tobias2013]

Hallo, bin neue hier.

Ich habe vor kurzem im TV zusehen könne, wie jemand compilierten Code wieder zurück in sein Source-Format übersetzen konnte (also die Syntax, wie man das Programm schreibt),
wohl mit der Option unterschiedliche Ansichten (welche unterschiedliche Syntaxstrukturen bilden) um nach etwas probieren den Sourcecode wiederherzustellen.

Mich würde interessieren wie diese Programm heißen und ob solche Programme/Übersetzer direkt in Debian 7 enthalten sind bzw. im Paket der Programmierertools?

Beste Grüße,
Tobias

[peschmae]

Das nennt sich decompiler und funktioniert im Normalfall nur mässig gut, denn bei kompilieren gehen jede Menge Informationen verloren (Variablennamen, Schleifen werden geunrollt, Sachen geinlined, etc) - hier gibts ein paar Programme die sowas versuchen. Was hingegen immer möglich ist ist desassemblieren - das Ergebnis davon sind dann allerdings assembler-Instruktionen.

Einigermassen gut funktionieren kann das dekompilieren bei Sachen die nur Bytecode für irgend eine VM erzeugen wo noch viel Information drin ist (Java, Python, etc).

Viel einfacher ist auf Debian allerdings ein apt-get source $paketname, damit erhält man nämlich den originalen Quellcode und kein Gematsche

MfG Peschmä

[Cae]

Deassemblieren geht z.B. mit objdump. Beispiel:

Code: Alles auswählen

$ echo 'int main(void) { int a = 0x23, b = 0x34, c; c = a + b; return c; }' | gcc -Wall -W -O0 -xc - -o out
$ objdump -d out | awk '/<main>/{f=1}f{if(""==$0)exit;print}'
00000000004004ac <main>:
  4004ac:	55                   	push   %rbp
  4004ad:	48 89 e5             	mov    %rsp,%rbp
  4004b0:	c7 45 fc 23 00 00 00 	movl   $0x23,-0x4(%rbp)
  4004b7:	c7 45 f8 34 00 00 00 	movl   $0x34,-0x8(%rbp)
  4004be:	8b 45 f8             	mov    -0x8(%rbp),%eax
  4004c1:	8b 55 fc             	mov    -0x4(%rbp),%edx
  4004c4:	01 d0                	add    %edx,%eax
  4004c6:	89 45 f4             	mov    %eax,-0xc(%rbp)
  4004c9:	8b 45 f4             	mov    -0xc(%rbp),%eax
  4004cc:	5d                   	pop    %rbp
  4004cd:	c3                   	retq   
  4004ce:	90                   	nop
  4004cf:	90                   	nop
$ echo 'int main(void) { int a = 0x23, b = 0x34, c; c = a + b; return c; }' | gcc -Wall -W -O2 -xc - -o out
$ objdump -d out | awk '/<main>/{f=1}f{if(""==$0)exit;print}'
00000000004003a0 <main>:
  4003a0:	b8 57 00 00 00       	mov    $0x57,%eax
  4003a5:	c3                   	retq   
  4003a6:	90                   	nop
  4003a7:	90                   	nop
$ 

Mit abgeschalteten Optimierungen (-O0, minus Otto Null) erkennt man noch relativ viel vom Quellcode, z.B. die Werte 0x23, 0x34, das add. Mit eingeschalteten Optimierungen (-O2) wird diese Logik schon beim Kompilieren berechnet und taucht gar nicht in der Binary auf. Entsprechend wird nur das berechnete Ergebnis 0x57 nach %eax geschoben und main() per retq beendet.

Man sieht also, schon beim "einfachen" Disassemblieren kann/wird es Detailverluste geben, das gilt erst recht fuer komplexeres Decompilen. Man braucht ziemlich tiefes Verstaendnis fuer das Geschehen, um zu verstehen, was da passiert. Ansonsten hat peschmae schon alles relevante zum Thema geschrieben...

Gruss Cae

[wanne]

Hatte da auch schon gesucht und nichts gefunden, das es schaft komplexere Programme ohen debugging information (-g im gcc) so zu decompilieren, dass sie sich danach wieder compilieren lassen.

[Tobias2013]

Cool, danke für Eure schnellen Infos,
das hilft mir richtig weiter

Werde mich mal mit "objdump" auseinandersetzen.

Beste Grüße,
Tobias

[Tobias2013]

Hab jetzt ein wenig in der Richtung recherchiert und für alle die es interessiert:

Die von mir in diesem Threat gesuchte Methode heißt in der Fachwelt (Wissenschaft): "Reverse Engineering".
Bücher dazu gibt's u.a. auf amazon (zu teilweise stattlichen Preisen).

Beste Grüße und danke nochmal für die Starthilfe,
Tobias

[r4pt0r]

Beim disassemblieren erhält man aber nicht den ursprünglichen quellcode, da der sicherlich in einer Hochsprache geschrieben wurde. Man erhält nur den reinen Assemblercode der vom Compiler ausgespuckt wurde, und kann so zumindest die Funktionsweise der Software analysieren (i.e. es geht erst richtig mit der Arbeit los!). Je mehr man darüber weiß was die Software machen soll desto "leichter" wird es bei der Analyse.
Professionelle Disassembler (bzw der einzige?) wie IDAPro (ältere Version gibts kostenlos zum download) helfen ungemein, da z.b. flowcharts dargestellt werden können und referenzen leichter zu verfolgen sind. Zudem kann man variablen, Tabellen etc benennen und so alles besser lesbar machen.

Ich "zerlege" selber Software von Motorsteuergeräten zwecks programmieren selbiger zur Leistungssteigerung. Ohne flowcharts wäre das teilweise fast unmöglich (zumindest extrem umständlich) da die Software oft in dutzende Subroutinen verzweigt um dann in wenigen Ausgangsroutinen zu enden die dann letztendlich die finalen Werte (z.b. Zündzeitpunkt) ergeben. Das von Hand auseinander zu fummeln und verketten würde das ganze noch weiter verkomplizieren. Auch das direkte aufrufen/anzeigen referenzierter Funktionen und Tabellen hilft ungemein den Code etwas besser zu "lesen".
Je mehr Datenfelder/Kennfelder man kennt, desto einfacher wird es neu gefundene Tabellen zuzuordnen auf die in bestimmten Routinen zugegriffen wird. Oft hilft aber nur Try&Error am lebenden Objekt mit extremen Werten um zu probieren ob eine neu gefundene Routine wirklich das macht was man vermutet... Also egal was da im TV gezeigt wurde, man jagt nicht einfach nur einen fetzen Software durch eine andere Software und hinterher hat man eine hübsche Textdatei in der sauber der komplette Programmcode in verständlicher Form steht. Man muss vieles auch per Blackboxing ausprobieren und sollte ein tiefes Verständnis von den Aufgaben der Software haben damit man mit dem Ergebnis was anfangen kann...

Das reine Durchkommentieren/benennen der bekannten Kennfelder und Routinen einer "neuen" Motorsoftware (von der selben Steuergerätegeneration!) um zumindest die bekannten Teile "lesbar" zu machen, dauert schon gute 50h. Also nix für zwischendurch...


PS: Assemblerwissen sollte man grundlegend auch mitbringen (zumindest grundlegend), wobei ich mich selber nicht als fähig bezeichne in Assembler zu Programmieren. Lesen kann ichs trotzdem mittlerweile recht gut Liegt evtl auch daran dass Motorsoftware hauptsächlich Rechenoperationen und rumschieben von Sensorwerten und Berechnungsergebnissen von einem Register ins andere beinhaltet. Da hat man nicht so viel komplexität...

[Tobias2013]

Professionelle Disassembler (bzw der einzige?) wie IDAPro (ältere Version gibts kostenlos zum download) helfen ungemein, da z.b. flowcharts dargestellt werden können und referenzen leichter zu verfolgen sind. Zudem kann man variablen, Tabellen etc benennen und so alles besser lesbar machen.

OK, dann werde ich mir mal IDApro ansehen. Klingt zumindest sinnvoll. Gibt es denn keine vergleichbare Alternative hierfür im open source Bereich?

Oft hilft aber nur Try&Error am lebenden Objekt mit extremen Werten um zu probieren ob eine neu gefundene Routine wirklich das macht was man vermutet... Also egal was da im TV gezeigt wurde, man jagt nicht einfach nur einen fetzen Software durch eine andere Software und hinterher hat man eine hübsche Textdatei in der sauber der komplette Programmcode in verständlicher Form steht. Man muss vieles auch per Blackboxing ausprobieren und sollte ein tiefes Verständnis von den Aufgaben der Software haben damit man mit dem Ergebnis was anfangen kann...

Das war ein Bericht zu digitalen Schädlingen und an einer Stelle hat ein Analyst von Kaspersky am Monitor ein wenig erklärt. An einer Stelle konnte er direkt ein wenig Syntax wiederherstellen, der Rest drum herum war allerdings noch Salat.

PS: Assemblerwissen sollte man grundlegend auch mitbringen (zumindest grundlegend), wobei ich mich selber nicht als fähig bezeichne in Assembler zu Programmieren. Lesen kann ichs trotzdem mittlerweile recht gut Liegt evtl auch daran dass Motorsoftware hauptsächlich Rechenoperationen und rumschieben von Sensorwerten und Berechnungsergebnissen von einem Register ins andere beinhaltet. Da hat man nicht so viel komplexität...

Also kann man zusammenfassen, das man insgesamt gut mit verschiedenen Hochsprachen vertraut sein sollte und den Grundlagen von Assembler.

Danke für die Tipps r4pt0r

[r4pt0r]

OK, dann werde ich mir mal IDApro ansehen. Klingt zumindest sinnvoll. Gibt es denn keine vergleichbare Alternative hierfür im open source Bereich?

Leider neien - aber mit der älteren/eingeschränkten freien Version kann man schonmal einiges anstellen. Exotischere Prozessorarchitekturen sind dann eben z.b. nicht verfügbar...

Das war ein Bericht zu digitalen Schädlingen und an einer Stelle hat ein Analyst von Kaspersky am Monitor ein wenig erklärt. An einer Stelle konnte er direkt ein wenig Syntax wiederherstellen, der Rest drum herum war allerdings noch Salat.

Also kann man zusammenfassen, das man insgesamt gut mit verschiedenen Hochsprachen vertraut sein sollte und den Grundlagen von Assembler.

Danke für die Tipps r4pt0r

Mit "etwas" Übung/Wissen kann man sicherlich auch aus dem Stil des Assemblercodes herauslesen in welcher Hochsprache das Programm geschrieben wurde und/oder welcher Compiler genutzt wurde. Da gibt es so diverse eigenheiten...
Wenns nur darum geht die Funktionsweise zu analysieren oder funktionen zu modifizieren/ändern/hinzufügen reichen entsprechend mehr oder weniger fortgeschrittene Assembler-Kenntnisse. Vieles kommt aber beim anschauen des Codes wenn man einen Teil nicht versteht und sich damit beschäftigt von selbst (oder von Google/Lxquick/duckduckgo... )
Bei mir waren die letzten exkursionen in assembler schon gut 10 Jahre her - habe dann die Geschichte mit der Motorsoftware zum Anlass genommen mich wieder reinzulesen und mir zum auffrischen das Buch "Assemblerprogrammierung" von wikibooks.org zumindest teilweise zu Gemüte geführt [1]. In Bezug auf IDA Pro ist das Buch von Chris Eagle / No Starch Press absolute Referenz [2]. Das ganze kombiniert mit der Entwickler-/Befehlsreferenz des Prozessors für den die betreffende Software geschrieben wurde, und man hat schonmal ganz brauchbares Handwerkszeug um zu verstehen was los ist, auch wenn man nur nachschlägt über was man im Code stolpert... Die Referenz des Prozessors zumindest zu überfliegen macht vorab aber auf jeden Fall sinn, gerade wenns um Register und deren Nutzung geht.



[1] http://de.wikibooks.org/wiki/Assembler- ... rozessoren
[2] http://nostarch.com/idapro.htm