quellcode aus exe-Datei

[Assarbad]

Zitat von Gentleman:

mich würde mal interessieren ob es möglich ist den quellcode eines delphi-programms aus der *.exe zu lesen und wenn es möglich ist, wie es geht.

Nicht in dieser Form. DeDe, IDA, ResourceHacker und andere Tools (zB PEiD und viele unzählige andere Tools) können helfen eine Programmstruktur zu verstehen. Allein der zeitliche Aufwand ist so immens, daß man meist nur einen spezifischen Teil, der einen interessiert, untersucht.

Zitat von Oxmyx:

Nein, es ist nicht möglich. Sicherlich, man kann sich die Maschinencode-Befehle mit einem Disassembler anschauen, aber damit wird man keine Freude haben. Variablen, Funktionen, Prozeduren, Klassen, etc. existieren nicht mehr im Maschinencode, und die bekommt man auch nicht mehr so zurück, wie sie ursprünglich geschrieben wurden.

Bitte? Was existiert nicht mehr? Das ist ja lächerlich, bitte bilde dich erstmal weiter. Natürlich existieren all diese Dinge noch. Eine Klasse hat zB üblicherweise eine VTable. Je nach Compiler kann man herausbekommen wie der this/Self-Pointer weitergegeben wird (oft in einem Register).
Variablen bilden den Stackframe ...

Klar gibt es keine Namen. Man kann auch nicht unterscheiden, ob eine bestimmte Ansammlung von Variablen eine Struktur (record/struct) ist, oder einfach eine aufeinanderfolgende Deklaration verschiedener Variablen.

Klassen usw. werden meist schon anhand der RTTI erkannt. Mit spezifischen Tools wie DeDe wird es dann noch ein Stück einfacher, da DeDe natürlich die Strukturen (i.e. Klassen) der Borland-VCL kennt.

Aber bitte, die obige Aussage ist so unhaltbar!

Zitat von delphman:

Wenn man Assembler kann kommt schon Freude auf.....

Wer kann Assembler ? gebt mir euer Wissen !

Dazu gibt es hervorragende Bücher. Desweiteren ist es beim Disassemblen so, daß die Übung den Meister macht, denn so viele Bücher gibt's auch wieder nicht, und (kostenlose) Tutorials fast garnicht. Liegt unter anderem daran, daß 1. die entsprechenden Tools teuer sind (IDA PRo Standard kostet ~400 EUR) und 2. RE höher berechnet wird (~2fach von Programmierbezahlung).
Wenn also ein Kundiger sein Wissen weitergibt, verschenkt er weit wertvolleres Wissen. Außerdem ist RE (Reverse Engineering) zeitaufwendig und damit auch das Verfassen eines Tutorials.

Zitat von Oxmyx:

Nein, es kommt auch für denjenigen keine Freude auf, der Assembler kann. Man kann mit einer Million Maschinenbefehlen einfach nichts anfangen, weil es ja z.B. keine Variablennamen gibt (es gibt auch keine Variablen an sich), es gibt keine höheren Programmstrukturen, es gibt einfach fast überhaupt nichts mehr von dem, was ursprünglich den Programmcode in Delphi ausgemacht hat.

Häh?

Zitat von phXql:

das is dasselbe wie wenn du versuchst, von nem lied wieder die noten rauszubekommen. in manchen fällen gehts, in anderen halt nich

IDA ist mein "absolutes Gehör", kann ich da nur sagen!

Um es nochmal zu rekapitulieren. Man kann theoretisch auch MS Word disassemblieren (lassen wir mal die rechtliche und/oder moralische Diskussion außen vor), aber man muß dann auch viele Mannjahre dafür veranschlagen.
Außerdem bleibt zu bemerken, daß die API-Funktionen, sei es nun in ELF oder PE-Binaries, und manchmal auch Strings die Rettungsanker des Reverse-Engineers im weiten Meer des Assemblercode sind.

Dennoch bleibt weiterhin die Aussage, daß Kompilieren sicherlich eine der besten Verschlüsselungen für Sourcecode ist

PS: Übrigens, was brächten mir denn die Variablennamen, wenn zB ein Ungar ein Programm geschrieben hätte und er zur Vergabe der Variablennamen ungarische Wörter und Abkürzungen benutzt hätte?

[Oxmyx]

Zitat von Assarbad:

Bitte? Was existiert nicht mehr? Das ist ja lächerlich, bitte bilde dich erstmal weiter. Natürlich existieren all diese Dinge noch. Eine Klasse hat zB üblicherweise eine VTable. Je nach Compiler kann man herausbekommen wie der this/Self-Pointer weitergegeben wird (oft in einem Register).
Variablen bilden den Stackframe ...

Ja, ist doch so. Aus einer Funktion wird ein Stück ausführbarer Code irgendwo im Speicher, der angesprungen werden kann. Aus Variablen werden Speicheradressen. Ein Methodenaufruf ist nur das Anspringen der Funktion mit Übergabe des this-Pointers (wie du sagtest), etc... Da existiert nichts mehr von den ursprünglichen Funktionen, Klassen und Variablen. Das ist alles nur noch ausführbarer Maschinencode, und nirgends ist der Code versteckt, den du mal in Delphi programmiert hast.
Nebenbei wäre ich vorsichtig, jemandem in einer Diskussion zu unterstellen, ungebildet zu sein...

Zitat:

Klar gibt es keine Namen. Man kann auch nicht unterscheiden, ob eine bestimmte Ansammlung von Variablen eine Struktur (record/struct) ist, oder einfach eine aufeinanderfolgende Deklaration verschiedener Variablen.

Klassen usw. werden meist schon anhand der RTTI erkannt. Mit spezifischen Tools wie DeDe wird es dann noch ein Stück einfacher, da DeDe natürlich die Strukturen (i.e. Klassen) der Borland-VCL kennt.

Standardmäßig erzeugt Delphi für Klassen keine RTTI (meines Wissens nach wird nur TPersistent und IInvokable mit RTTI kompiliert).

[Assarbad]

Zitat von Oxmyx:

Ja, ist doch so. Aus einer Funktion wird ein Stück ausführbarer Code irgendwo im Speicher, der angesprungen werden kann. Aus Variablen werden Speicheradressen. Ein Methodenaufruf ist nur das Anspringen der Funktion mit Übergabe des this-Pointers (wie du sagtest), etc... Da existiert nichts mehr von den ursprünglichen Funktionen, Klassen und Variablen. Das ist alles nur noch ausführbarer Maschinencode, und nirgends ist der Code versteckt, den du mal in Delphi programmiert hast.

Na sicher doch. Und jetzt erklärst du mir wie das Programm laufen soll, wenn ja "nichts mehr" da ist? Na? Also entweder drückst du dich komplett falsch aus, weil du Funktionsnamen oder Variablennamen oder Klassennamen meinst, aber Funktionen oder Variablen oder Klassen sagst, oder du hast tatsächlich noch kein Disassemblat gesehen. Ich kann dir gern einige zeigen, dann siehst du, daß sogar viele der Informationen, von denen du glaubst sie seien fort, noch (oft nur implizit) enthalten sind.

Sie (die Funktionen, Variablen und Klassen, insofern nicht wegoptimiert - zB durch Delphis Smartlinking) sind alle noch da, haben zwar keinen Namen (auch das läßt dich mit einem interaktiven Disassembler, wie IDA, ändern) aber sehr wohl eine Bedeutung. Und genau nach dieser sucht man als RE. Übrigens ist der bisher schrecklichste Code, den ich gesehen habe, VB-Code. Das Problem dort ist, daß man quasi mit der Runtime auf "du" sein muß um die Bedeutung der Funktionen zu kennen. Schlecht, wenn man VB aufgrund von schlechten Erfahrungen seit 2 Jahren vernachlässigt hat

Zitat von Oxmyx:

Nebenbei wäre ich vorsichtig, jemandem in einer Diskussion zu unterstellen, ungebildet zu sein...

Ich hasse es, wenn mir Leute etwas unterstellen oder in meine Aussagen reinstecken, was objektiv in meiner Aussage nicht enthalten ist. Lies dir den Satz nochmal genau durch. Etwas grotesk, aber ich hatte ähnliche Probleme schon mit einer anderen Gruppe von Menschen :-\
Das ist ja lächerlich, bitte bilde dich erstmal weiter.
Weiterbilden kann man sich wohl kaum, wenn es keine Basis gibt! Weiterbilden bedeutet meist, sich zu einem bestimmten Gebiet noch mehr Wissen anzueignen, oder?

Ich empfinde deine Unterstellung ziemlich beleidigend.

Zitat von Oxmyx:

Standardmäßig erzeugt Delphi für Klassen keine RTTI (meines Wissens nach wird nur TPersistent und IInvokable mit RTTI kompiliert).

Bei Delphi wird dies aber dank der Tatsache, daß es sich um einen Singlepass-Compiler handelt, wieder dadurch wettgemacht, daß die Strukturen der VCL bekannt sind. Man kann also relativ unkompliziert den Lib-Code from echten Programm trennen. Und von einigen Programmen bleibt dann nicht mehr viel. Mit der VCL hast du soweit ich mich entsinne aber immer auch RTTI mit drin, will mich da aber nicht drauf festnageln lassen. Wenn du andere Infos hast, dann bring sie doch mal hier ein.

Begreift doch mal bitte, daß RE nicht daran scheitert, daß man "1 Million" Assembler-Mnemonics nicht verstehen könnte, sondern vielmehr daran, daß der Zeitaufwand so riesig ist. Der Aufwand ein Programm (komplett!) zu reversen übersteigt bei weitem den Aufwand so ein Programm selber neu zu schreiben.

Meist wird RE verwendet um:
- Viren/Malware zu analysieren
- Software zu cracken (was zweifelhaft ist, wenn die Ergebnisse veröffentlicht werden)
- Kompatibilität zu anderer Software herzustellen (zB zum DOS-Programm von dem die Quellen fehlen)

In allen diesen Fällen kann meist eine Komplettanalyse des Disassemblats vermieden werden, indem der RE smart genug ist die entsprechenden interessanten Stellen schnellstmöglich herauszufiltern.

[Hansa]

Ich vergleiche so etwas immer mit einer wertvollen chinesischen Vase. Fällt die auf den Boden und liegt nur noch in Bruchstücken vor, dann kann man sie mit immensem Aufwand vielleicht wieder in etwa zusammensetzen. Aber ob sie dicht ist und keiner merkt, daß sie kaputt war, das wage ich zu bezweifeln. 8)

[Oxmyx]

Zitat von Assarbad:

Na sicher doch. Und jetzt erklärst du mir wie das Programm laufen soll, wenn ja "nichts mehr" da ist? Na? Also entweder drückst du dich komplett falsch aus, weil du Funktionsnamen oder Variablennamen oder Klassennamen meinst, aber Funktionen oder Variablen oder Klassen sagst, oder du hast tatsächlich noch kein Disassemblat gesehen. Ich kann dir gern einige zeigen, dann siehst du, daß sogar viele der Informationen, von denen du glaubst sie seien fort, noch (oft nur implizit) enthalten sind.

Sie (die Funktionen, Variablen und Klassen, insofern nicht wegoptimiert - zB durch Delphis Smartlinking) sind alle noch da, haben zwar keinen Namen (auch das läßt dich mit einem interaktiven Disassembler, wie IDA, ändern) aber sehr wohl eine Bedeutung. Und genau nach dieser sucht man als RE. Übrigens ist der bisher schrecklichste Code, den ich gesehen habe, VB-Code. Das Problem dort ist, daß man quasi mit der Runtime auf "du" sein muß um die Bedeutung der Funktionen zu kennen. Schlecht, wenn man VB aufgrund von schlechten Erfahrungen seit 2 Jahren vernachlässigt hat

Ändert doch nichts daran, dass die Funktionen, die du selbst Wort für Wort, Zeile für Zeile in Delphi eingetippt hast, ersetzt wurden durch Maschinencode. D.h. man kann nicht einfach den Maschinencode "rückübersetzen" und dann erwarten, den Delphi-Quelltext wieder zu haben. Das meinte ich. Vom Delphi-Quelltext ist tatsächlich nichts mehr da, weil der Compiler ja im Prinzip das "Hoch" in "Hochsprache" beseitigt hat.

[runger]

Hallo,

ihr dreht euch doch im Kreis, merkt ihr das nicht?
Ein Stückchen weit hat jeder von euch recht. Wenn mans ganz exakt nimmt
ist eine Rückübersetzung nicht möglich. Ich darf dann nämlich nicht davon
ausgehen dass die VCL bekannt ist.
Aber mit Hilfsmittel und künstlich generierten Bezeichnern ( was sind Bezeichner eigentlich
nichts als Rauch und für die Funktion unwesentlich ) wird man schon etwas über den
Code herausfinden können, aber nicht alles.

Rainer
( Schliesst diesen Beitrag, der bringt nichts als Streit! )

[Assarbad]

Zitat von Hansa:

Ich vergleiche so etwas immer mit einer wertvollen chinesischen Vase. Fällt die auf den Boden und liegt nur noch in Bruchstücken vor, dann kann man sie mit immensem Aufwand vielleicht wieder in etwa zusammensetzen. Aber ob sie dicht ist und keiner merkt, daß sie kaputt war, das wage ich zu bezweifeln. 8)

*g* siehe oben. Das ist ja auch nicht gefragt. Meist reicht es die Vase teilweise zusammenzusetzen oder um es anders bildlich zu machen: es reicht oft, die Bruchstücke zu zeichnen um danach herauszufinden wie man die Stücke zusammensetzen kann. Archäologen machen das so.

Zitat von Oxmyx:

Ändert doch nichts daran, dass die Funktionen, die du selbst Wort für Wort, Zeile für Zeile in Delphi eingetippt hast, ersetzt wurden durch Maschinencode. D.h. man kann nicht einfach den Maschinencode "rückübersetzen" und dann erwarten, den Delphi-Quelltext wieder zu haben. Das meinte ich. Vom Delphi-Quelltext ist tatsächlich nichts mehr da, weil der Compiler ja im Prinzip das "Hoch" in "Hochsprache" beseitigt hat.

Okay, jetzt ist klar worauf du hinaus willst. Klar die Repräsentation der Funktionen (usw) in Delphi ist verloren, nicht aber der Inhalt, die Bedeutung dahinter. Das Problem war wohl, daß wir auf 2 verschiedenen Ebenen diskutiert haben.

Zitat von runger:

Aber mit Hilfsmittel und künstlich generierten Bezeichnern ( was sind Bezeichner eigentlich nichts als Rauch und für die Funktion unwesentlich ) wird man schon etwas über den Code herausfinden können, aber nicht alles.

Schon allein dadurch, daß einiges "wegoptimiert" wird, kann man nicht alles herausfinden. Aber siehe oben, ist oft auch garnicht gewünscht (oder besser ausgedrückt: meistens garnicht nötig) - macht aber u.U. die Analyse schwerer.

[Hansa]

Zitat von Assarbad:

... Meist reicht es die Vase teilweise zusammenzusetzen...

Ich meinte eine Blumenvase, also so ein Ding wo Wasser reinkommt und dann eben Blumen. Dann nützt mir ein teilweises zusammensetzen nichts, wenn ein Stück im Boden fehlt.

[s.h.a.r.k]

Dumme Frage: Aber wieso sollte man von Programmen den kompletten Code auslesen können?! Wäre irgendwo nicht unbedingt schlau... Okey es gibt natürlich Möglichkeiten, aber das gilt dann wohl eher als cracken oder? Denn dann wär n Crack schreiben ja verdammt einfach oder?!

[Assarbad]

Zitat von s.h.a.r.k:

Dumme Frage: Aber wieso sollte man von Programmen den kompletten Code auslesen können?!

Hier wäre die Definitionsfrage was "Code" ist. Für mich ist auch ein Disassemblat "Code". Es geht immer - nur nicht den Code in die Ursprungsform zu bringen (außer zB bei sowas wie VB, Perl, Java also Scriptsprachen) - es sei denn, der Code benutzt Laufzeitverschlüsselung. Auch dazu findet sich bereits hier im Forum etwas. Dazu muß das Programm nach dem Kompilieren nochmals behandelt werden um relevante Codeteile zu verschlüsseln. Zur Laufzeit werden diese dann entschlüsselt.

Zitat von s.h.a.r.k:

Wäre irgendwo nicht unbedingt schlau... Okey es gibt natürlich Möglichkeiten, aber das gilt dann wohl eher als cracken oder? Denn dann wär n Crack schreiben ja verdammt einfach oder?!

*heul* Wieso ist denn bitte deiner Meinung nach "RE == Cracken"?

Setzt du Antivirensoftware ein? Dann setzt du nach deiner Meinung Software von Crackern ein, denn was meinst du wie man Malware analysiert?

Ich klinke mich hier besser aus der Diskussion aus, bringt eh nix, weil offenbar eine skurrile Vorstellung von RE vorherrscht.