Kostenloser Quellenoffene Decompiler

Ich habe es mir aus gegebenem Anlass mal angesehen, weil ich zwei 
Windows dlls (beide ca. 8 MByte groß) habe die ich bisher mit der 
letzten Free-IDA-Pro Version händisch analysiert habe, und mal mit dem 
Ergebnis des RetDec vergleichen wollte.

Ergebnis von RetDec bei beiden dlls nach der nach Installation auf einer 
Win7 32 Bit VM (triviale Testprogramme lassen sich hinreichend 
decompilieren):
LLVM ERROR: Could not acquire a cryptographic context: Unknown error 
(0x8)
Error: Decompilation to LLVM IR failed

Vermutung da schlägt eine Windows Funktion fehl.

Also Debian VM mit Jessie hergenommen. Lässt sich nicht kompilieren weil 
Cmake zu alt, also erstmal dist-upgrade auf Stretch durchgeführt. 
Kompiliert bis:
demangler.dir/stgrammars/borlanddll.cpp.o
cclplus: out of memory

Und das mit 4 GByte RAM.

Hat das schon mal jemand an einem reellem Projekt erfolgreich einsetzen 
können? Bzw. unter Linux compiliert?

Thomas W. schrieb:
> Bzw. unter Linux compiliert?

Ja, kein Problem. Das Kompilieren des Demangler-Pakets braucht bei mir
in Spitze etwa 380 MB. Baust du vielleicht mutlithreaded (mit make
-j<n>) und hast viele Cores in deinem Prozessor? Dann steigt der RAM-
Verbrauch natürlich auf ein Vielfaches an.

Yalu X. schrieb:

> Ja, kein Problem. Das Kompilieren des Demangler-Pakets braucht bei mir
> in Spitze etwa 380 MB. Baust du vielleicht mutlithreaded (mit make
> -j<n>) und hast viele Cores in deinem Prozessor? Dann steigt der RAM-
> Verbrauch natürlich auf ein Vielfaches an.

Nichts dergleichen, keine besonderen Einstellungen. Linux läuft bei mir 
in einer VMware VM mit einem Prozessor / einem Core. Speicherbedarf von 
cc1plus steigt beim Übersetzen bis auf knapp 3 GByte an bis es dann 
abbricht.

Übrigens funktioniert der Build nur, wenn man es mit 'git clone' holt. 
Lädt man es sich als .zip bei github runter, schlägt es fehl.

Ma W. schrieb:
> Thomas W. schrieb:
>> cc1plus steigt beim Übersetzen bis auf knapp 3 GByte an bis es dann
>> abbricht.
>
> Du hast halt zu wenig RAM.
> Ist doch offensichtlich.

Nö, neue VM mit Ubuntu 17.10 erzeugt mit ebenfalls gleichen 
Hardwareeinstellungen (4 GB Ram), und zumindest wird der Teil bei dem 
der Übersetzungslauf bisher abgebrochen hat problemlos durchlaufen.
Jetzt erhalte ich aber einen weiteren Übersetzungsfehler in filemap.c 
aus yaracpp. Quellen sind mit git geholt und alles nach Anleitung auf 
der github-Seite übersetzt.

Ma W. schrieb:

> Besorge dir ein vernünftiges und aktuelles System.
> Auf Debian Sid funktioniert die Übersetzung einwandfrei.

Unter einem 32 oder 64 Bit Betriebssystem?
Das Problem scheint mit meinem 32 Bit Betriebssystem zusammenzuhängen, 
mal sehen ob ich das auf die Schnelle gefixt bekomme (libelf).

Die Systemvoraussetzungen sagen zumindest nichts von "nur 64 Bit".

Ok, unter einem 32 Bit Betriebssystem ist es wohl nicht sinnvoll zu 
verwenden.
Übersetzt habe ich es mit meiner Änderung jetzt bekommen, beim 
Dekompilieren geht dem Programm jedoch der Speicher aus (bad_alloc 
exception).

Thomas W. schrieb:
> beim
> Dekompilieren geht dem Programm jedoch der Speicher aus (bad_alloc
> exception).

https://github.com/avast-tl/retdec/issues/13

Bei mir unter Windows hat er sich für eine DLL mit 3,7MB (mit 
Debug-Daten) 38GB Speicher genommen.

Endlich mal wieder eine Rechtfertigung dafür, dass ich meinem PC 64GB 
RAM gegönnt habe. :)

Markus K. schrieb:

> https://github.com/avast-tl/retdec/issues/13
>
> Bei mir unter Windows hat er sich für eine DLL mit 3,7MB (mit
> Debug-Daten) 38GB Speicher genommen.
>
> Endlich mal wieder eine Rechtfertigung dafür, dass ich meinem PC 64GB
> RAM gegönnt habe. :)

Ich merke es auch gerade. Ich habe jetzt eine 64 Bit VM mit 12 GB RAM 
erstellt, was aber zum Dekompilieren noch nicht reicht. Mein Host hat 
aber nur 16 GB, müsste ich erst nachlegen.

Wie lange hat das Dekompilieren deiner DLL denn gedauert? Bei meiner DLL 
benötigt es ca. 7 Stunden zur Analyse. Beim Generieren des Codes aus der 
LLVM IR bricht es bei mir dann wegen Speichermangel ab, wobei der 
Schritt ja eigentlich der einfachste von allen sein dürfte.

Thomas W. schrieb:

> Wie lange hat das Dekompilieren deiner DLL denn gedauert? Bei meiner DLL
> benötigt es ca. 7 Stunden zur Analyse.

Ich bin nicht dabei geblieben und er schließt ja das 
decompile.sh-Fenster mit der Dauer hinterher wieder. Von den 
Zeitstempeln her würde ich sagen, dass es 2h gedauert hat (die .c-Datei 
ist 2h jünger als die .dsm)


Momentan bin ich aber noch nicht so zufrieden. Insbesondere kann ich 
keine vernünftig Dokumentation finden. Bin ich blind?

Markus K. schrieb:

> Momentan bin ich aber noch nicht so zufrieden. Insbesondere kann ich
> keine vernünftig Dokumentation finden. Bin ich blind?

Ich hätte auch gerne eine grobe Übersicht über die Funktionsweisen und 
Module. Eine Übersicht über die Funktionsweise bekommt man aber in den 
diversen Veröffentlichungen dir hier verlinkt sind(die Ph.D. Thesis von 
2015 passt imho noch recht gut):

https://retdec.com/publications/

Ich konnte meine dll mittlerweile durch die bei github vermerkte 
Änderung von ulimit dekompilieren. Das Ergebnis überzeugt mich jedoch 
überhaupt nicht, bzw. bei Funktionen mit kryptografischen Algorithmen 
ist das Ergebnis schlechter verständlich als z.B. die 
Assembler+grafische Darstellung in IDA Pro (Free).