gerade auf Heise gefunden: https://www.heise.de/newsticker/meldung/Avast-veroeffentlicht-Maschinencode-Decompiler-als-Open-Source-3923397.html Frohes Fest
:
Verschoben durch Admin
Beitrag #5250850 wurde von einem Moderator gelöscht.
Online Test Methode ist offline... Try Out Decompilation In Your Browser Unfortunately, the web version of the decompilation service is currently disabled due to extremely high load on our servers.
Stephan schrieb: > Nur 32Bit ? naja der ist ja nicht nur für PCs gedacht. Der kann ja auch > PIC und ARM. Und hast du schonmal ausprobiert was da rauskommt?
brauch bestimmt noch eine weile bis er auf IDA-Pro+Hex-Rays Niveau ist - damit lassen sich aus eigener Erfahrung auch komplizierte Funktionen aus EXEn extrahieren und funktionsfähig rekompilieren die verwendung von LLVM-IR als Zwischensprache gefällt mir
Bert3 schrieb: > aus eigener Erfahrung auch komplizierte Funktionen aus > EXEn extrahieren und funktionsfähig rekompilieren Das ist doch gar kein use-case für einen Decompiler. Bzw. ist es kein Maß für die Qualität eines Dekompilers. Die Qualität misst sich alleine an der Menschenlesbarkeit des produzierten Codes. Assembly in funtional äquivalentes komplett unleserliches C umzuwandeln, ist ziemlich trivial.
Beitrag #5251325 wurde von einem Moderator gelöscht.
>Das ist doch gar kein use-case für einen Decompiler. >Bzw. ist es kein Maß für die Qualität eines Dekompilers. bei komplexeren Analysen ist die kompilierbarkeit einfach ein weiteres Hilfsmittel um weiter zu kommen - und es gibt nach meinem Wissen gar keinen anderen Dekompiler der es überhaupt so weit schafft >Die Qualität misst sich alleine an der Menschenlesbarkeit des >produzierten Codes. da es kaum nutzbare Dekompiler gibt würde ich die Messlatte weniger hoch ansetzen - man bekommt ja trotzdem einfacheren(oder teilweise auch nur viel weniger) Code den man anschauen muss >Assembly in funtional äquivalentes komplett unleserliches C umzuwandeln, >ist ziemlich trivial. die Hex-Rays Ergebnisse sehen schon etwas besser als aus "unleserliches" C - auf jeden Fall um Welten besser als Seitenweise Assembler zu analysieren um am Ende 20 Zeilen Code draus zu machen
einer hat sich die Mühe gemacht - trivial Beispiele da durch zu jagen: https://www.heise.de/forum/heise-online/News-Kommentare/Avast-veroeffentlicht-Maschinencode-Decompiler-als-Open-Source/Einige-Beispiele/posting-31565332/show/
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?
:
Bearbeitet durch User
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.
Bert3 schrieb: > einer hat sich die Mühe gemacht - trivial Beispiele da durch zu > jagen: > > https://www.heise.de/forum/heise-online/News-Komme... Das ist noch verbesserungsfähig, sieht aber schon deutlich besser aus, als ich erwartet hätte. Allerdings ist nicht angegeben, wie es kompiliert wurde. Ohne Optimierung ist das Dekompilieren wahrscheinlich sehr viel einfacher, als mit Optimierung.
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.
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.
Thomas W. schrieb: > Quellen sind mit git geholt und alles nach Anleitung auf > der github-Seite übersetzt. Besorge dir ein vernünftiges und aktuelles System. Auf Debian Sid funktioniert die Übersetzung einwandfrei.
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".
Thomas W. schrieb: > Unter einem 32 oder 64 Bit Betriebssystem? 64 Bit > Das Problem scheint mit meinem 32 Bit Betriebssystem zusammenzuhängen, > mal sehen ob ich das auf die Schnelle gefixt bekomme (libelf). Wenn ein Compilerprozess mehr als 3GB braucht, dann kann das auch zu einem Problem führen.
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).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.