Decompiler

[wanne]

Hi, gibt's irgend was, das stabiel läuft und aus binarys C-Code macht. Konkret geht es mir darum das dann wider für ne andere Architektur zu compilieren. => Ob der Code schön aussieht ist wurst. Ob er effizent eigentlich auch.
So schwer dürfte das doch eigentlich nicht sein. Kann ja einfach die befehle nacheinander abarbeiten. Das einzige was etwas schwieriger ist ist zu erkennen wo's einen Methodenaufruf gibt.

[Natureshadow]

Das einzige was etwas schwieriger ist ist zu erkennen wo's einen Methodenaufruf gibt.

??

[rendegast]

Du könntest den Quellcode für andere Architektur übersetzen.
Wenn Du den Quellcode nicht hast, ihn einfordern.
Wenn Du ihn nicht bekommst, ist es wohl proprietär und Decompilieren verboten.

[Liffi]

Boomerang[1] kann dir evtl. helfen.

Aber: Neben dem guten Argument, dass es nicht erlaubt sein könnte: C Code ist nicht immer so portabel wie er sein könnte. Je größer das Programm, je mehr Abhängigkeiten desto größer ist die Wahrscheinlichkeit, dass jemand was archtikturabhängiges reingemacht hat.

[1]http://boomerang.sourceforge.net/

[Cae]

Du kannst aus einer gestripten Binary nicht eindeutig auf den Quellcode schliessen. Deassemblieren ist immer moeglich, z.B. (sinnvollerweise) per gdb oder objdump -d (aus binuntils). Natuerlich mag's auch Tools geben, die sich ueberlegen, welchen C-Code diesen Assembler-Output erzeugt haben koennte, aber wie soll man erkennen, ob's nun eine for(i=0;i<=1;i++)-Schleife ist oder einfach duplizierter Code oder ein Makro?

Gruss Cae

[wanne]

Du kannst aus einer gestripten Binary nicht eindeutig auf den Quellcode schliessen.

Mir schon klar deswegen habe ich ja auch gesagt, dass ich einen C-Code haben will und sogar gesagt dass ich an den relativ wenig ansprüche habe.

C Code ist nicht immer so portabel wie er sein könnte.

Na das wäre ja der Vorteil von dem generierten Code. Den kann man relativ einfach so erzeugen, dass er portabel ist. (z.B. indem man uint32_t statt unsighned int nimmt. Das geht dann zwar auf die performance aber das ist mir erstmal wurst.

je mehr Abhängigkeiten

Die sehe ich ja vorher mit ldd.

Boomerang[1] kann dir evtl. helfen.

Das Ding bekomme ich nicht compiliert (Der Code ist grauenhaft schlimmer kann der Code den sie dann generieren garantiert nciht aussehen.) hier so mal ein besonders schöner:

Code: Alles auswählen

m_pImage = new char[m_lImageSize];
[...]
if (off) m_pSections[i].uHostAddr = (ADDRESS)(m_pImage + off);

ADDRESS Ist dabei ein unsigned int... Und jetzt könnt ihr euch alle selber denken, was passiert wenn ihr nen 64Bit pointer in ein 32Bit int packt....

Wie war das mit der Platformunabhänigkeit und C-Code...

Wobei man bei sowas natürlich echt Probleme haben dürfte schönen Code zu schreiben. Das ist halt hässlich.

[dufty]

Das Ding bekomme ich nicht compiliert.

Du versuchst vermutlich dies unter 64bit, was nicht geht ("The current code is not 64-bit clean");
schau Dir das SF an, das Projekt/code ist von 2006.
Es gibt eine 64bit-Version (https://github.com/rsaxvc/boomerang64), welches aber nur 32er-binaries decompilieren kann (wenn überhaupt .

[wanne]

welches aber nur 32er-binaries

Das wäre mir jetzt erstmal wurst. Trotzdem habe ich jetzt eher kleines Vertrauen in das Projekkt. Es scheint schlicht tot zu sein. (Im übrigen gabs auch 2006 schon amd64) Und sagt von sich selbst das es eher mit kleinen einfachen Programmen zurecht kommt. Ich glaub einfach nicht das es funktioniert und deswegen habe ich jetzt auch keine lust darauf ein 32Bit System hochzuziehen (Auch wenn die Abhängigkeiten klein sind).