mikrocontroller.net

Forum: PC-Programmierung Kostenloser Quellenoffene Decompiler


Autor: Stephan (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
gerade auf Heise gefunden:

https://www.heise.de/newsticker/meldung/Avast-vero...

Frohes Fest

: Verschoben durch Admin
Beitrag #5250850 wurde von einem Moderator gelöscht.
Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kaj (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Kann nur 32 Bit, damit praktisch uninteressant.

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur 32Bit ? naja der ist ja nicht nur für PCs gedacht. Der kann ja auch 
PIC und ARM.

Autor: Der Andere (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ma Win (mawin_offiziell)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Bert3 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>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

Autor: Bert3 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
einer hat sich die Mühe gemacht - trivial Beispiele da durch zu jagen:

https://www.heise.de/forum/heise-online/News-Komme...

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ma Win (mawin_offiziell)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ma Win (mawin_offiziell)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Ma Win (mawin_offiziell)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.