Hallo,

ich musste zu meinem Projektpraktikum für die Uni auch ein Whitepaper zum Thema "Vergleich von Assembler und Intermediate Language mit besonderem Bezug zur Dekompilierbarkeit" schreiben.
Ich hab selbiges jetzt soweit abgeschlossen, dass ich mir gedacht hab ich frag mal hier noch, ob sich ein paar Leute finden die das Thema vielleicht interessiert und sich das ganze Ding mal durchlesen. Ich würde mich sehr über ein bisschen Feedback, Anregungen und Kritik freuen!

Gruß, Manuel

Kleine Anmerkung zu Seite 5, Abschnitt Register-Arten:
Bitte Unstruction Pointer entweder auch mit Übersetzen (da das bei den anderen auch ist) oder anderweitig etwas abheben.

Hinweis auf Decompiler: Seite 7: Siehe boomerang.sourceforge.net/

Anmerkung Seite 9: Für Assembler liegen auch Obfuscator-Programme vor, deren Runtime-Performance aber nicht sonderlich herausragend ist. Frag uall, der hatte da glaube mal einen gecoded.

Seite 10: "So zeigt z.B. dieser Artikel [] ..." Da fehlt irgndwie was ...

Allgemeiner Hinweis: Bei TeX kann man einstellen, dass keine Farbigen Rahmen im Links angelegt werden, sondern die verlinkten Stellen an sich einfach Farbig hervorgehoben sind. Außerdem kann man das Inhaltsverzeichnis die Seitennummern verlinken, was auch wesentlich gebräuchlicher ist. Die entsprechenden TeX-Befehle kann ich Dir gern geben.

Mit dem Fazit geh ich mit. Auch sonst ist die BEschreibung recht ausführlich und gut gelungen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Kleine Anmerkung zu Seite 5, Abschnitt Register-Arten: Bitte Unstruction Pointer entweder auch mit Übersetzen (da das bei den anderen auch ist) oder anderweitig etwas abheben. Hinweis auf Decompiler: Seite 7: Siehe boomerang.sourceforge.net/ Anmerkung Seite 9: Für Assembler liegen auch Obfuscator-Programme vor, deren Runtime-Performance aber nicht sonderlich herausragend ist. Frag uall, der hatte da glaube mal einen gecoded. Seite 10: "So zeigt z.B. dieser Artikel [] ..." Da fehlt irgndwie was ... Allgemeiner Hinweis: Bei TeX kann man einstellen, dass keine Farbigen Rahmen im Links angelegt werden, sondern die verlinkten Stellen an sich einfach Farbig hervorgehoben sind. Außerdem kann man das Inhaltsverzeichnis die Seitennummern verlinken, was auch wesentlich gebräuchlicher ist. Die entsprechenden TeX-Befehle kann ich Dir gern geben. Mit dem Fazit geh ich mit. Auch sonst ist die BEschreibung recht ausführlich und gut gelungen.

Danke für die Anmerkungen! Boomerang kenn ich und hab ich auch ausprobiert, allerdings mit eher mäßigem Erfolg (das Prog hängt sich auf). Aber du hast recht, ich könnte einen Verweis darauf einfügen.
Der fehlende Verweis wird noch ergänzt, ob ich noch was zu Obfuskatoren für native Programme schreib überleg ich mir noch, aber danke für den Hinweis.

@TeX: ich verwende das Package hyperref, die farbigen Rahmen hab ich inzwischen schon entfernt. Aber du kannst mir gerne noch die Befehle geben die du meinst.

Gruß, Manuel

Hallo.

Habe einen kleinen Tippfehler gefunden:

Auf Seite 6 oben steht:

er hantiert nur mit den Bits und tut genau das, was der Programmierer ihm auftragt.

Müsste das nicht "aufträgt" heißen?

Außerdem schreibt man ".NET Programme" eigentlich zusammen - also ".NET-Programme" (z.B. auf S.14 unter Dekompilierbarkeit). Genauso "C# Beispiel" (-> "C#-Beispiel") oder "IL Code" (-> "IL-Code") - das sind nämlich alles zusammengesetzte Nomen (de.wikipedia.org/wiki/Deppenleerzeichen).

Andererseits schreibt sich aber "Reverse Engineering" getrennt (aber groß) - genau wie zum Beispiel "Common Intermediate Language"!

So - genug Gemecker: Ansonsten finde ich den Text wohlstrukturiert und gut verständlich.

Gruß,
Waldteufel

-> Entscheidung ist äquvalent zu dem Halteproblem [13], von dem Alan Turing bereits 1936 bewiesen hat, dass es nicht entscheidbar ist
: du meinst sicher unentscheidbar

-> schlimmstenfalls mit deinem Hardware Debugger.
: einem

-> die versuchen zu erkennen ob ein Debugger „anwesend“ ist oder ähnliches.
: ähnliches? rausnehmen...

-> Artikel [] wie man fanststellt
: welcher?

->aber darauf komme ich später noch einmal zurück.
: wird in einem späteren Abschitt beschrieben.

-> Dabei muss man, gemäß
: Dabei wird

-> generelle hätte ich solche Sachen wie Tool/Memory Dump eher in deutsch geschrieben (Programm, Hilgsprogramm, Speicherabbild) bzw. wenn du zu viele hast, eventuell sogar ein Glossary anlegen
-> Fußnoten werden bei meinen Profs nicht gerne gesehen
-> "man", "ich" usw. sollte (man xD) besser in einer wissenschaftlichen Arbeit (nicht benutzen xD) nicht benutzt werden, ist in der Einleitung aber ok
-> auf die Titelseite sollten: Universität (Wien), Faktultät (für Informatik), Fachbereich (Ingenieurwissenschaften), Fachgebiet (wissenscahtliches Rechnen), Institut, Betreuer, Name, Matrikelnummer, Datum, Titel, Untertitel

Wie ewünscht, hier mal meine Einstellungen für Hyperref, mit den Farblinks:



HTH.

P.S.: Für Delphi könntest Du DeDe mit als Referenz aufnehmen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Sehr schön, danke! Weiter so!!

@uall: nicht entscheidbar/unentscheidbar geht wohl beides..
Es handelt sich hierbei um ein Whitepaper, das nur ein Zusatz zu meinem Projektpraktikum ist und nicht um etwas "offizielles" wie eine Diplomarbeit. Insofern gibt es keine so genauen Vorschriften was das Titelblatt angeht, aber ich werd es vermutlich noch ändern. Dasselbe gilt für ein Glossary - ist nicht wirklich notwendig, ich wollte aber nicht alle Begriffe eindeutschen, sonst endet es noch so wie bei vielen schlecht übersetzten Fachbüchern wo dann ein "Deadlock" eine "Verklemmung" ist oder ein "stateless server" ein "zustandsloser Dienstanbieter".

@BenBE: danke, werd ich mal probiern..

Motzi hat folgendes geschrieben:

... wo dann ein "Deadlock" eine "Verklemmung" ist...

Nee, also dann schon lieber 'Totenlocke'.

Deadlock würde aber gemeinhin mit 'Blockade' oder 'sich gegenseitig blockieren' übersetzt. Das ist wenigstens zutreffender, als die 'Verklemmung'.

Also wir haben auf der Uni 2 Bücher (eines über Operating Systems und eines über Distributed Systems) und es wurde uns nahegelegt die englischen Versionen der beiden Bücher zu kaufen - und zwar weil die beiden obigen Beispiele tatsächlich so in den deutschen Übersetzungen vorkommen!
Aber gerade bei Fachliteratur tendiere ich sowieso immer dazu mir die englischen Originale zu kaufen...

Eine Sache noch zu denglischen Fachausdrücken: Ich glaube, es gibt ein gesundes Mittelmaß zwischen der Verwendung von Fachausdrücken und dem Selbstverständnis der eigenen (deutschen) Sprache.

So, habs mal durchgelesen:

Disassemblierung ist nur die textuelle Repräsentation des Maschinencodes und hat Nichts mit Dekompilierung zu tun. Ich würde auch nicht soweit gehen, einen Assembler als 'Compiler' zu bezeichnen, obwohl er das streng genommen ist. Das ist so, als ob man das Zerschnippeln eines Apfels als 'kochen' bezeichnen würde .

Ein Decompiler muss doch auch immer wissen, mit welchem Compiler in welcher Version und mit welchen Einstellungen das Kompilat erzeugt wurde. Ggf. könnte er versuchen, die Einstellungen zu erraten. Auch dieser Hinweis fehlt.

Auch muss man zwischen reinem Assembler und einem Kompilat unterscheiden. Handgebissener Assembler lässt sich per se nicht dekompilieren, ein Kompilat manchmal schon.

Persönlich würde ich in ein paar Sätzen die grundlegende Arbeit eines Compilers darlegen (häppchenweise Übersetzung des Programmcodes in Assembler). Wenn ich für jedes Programmsegment des Quellcodes ('If','While' etc.) die Happen kenne, kann ich logischerweise aus dem Assemblercode durch einfache Mustererkennung den Originalquellcode wieder herstellen. Einzig die Namen der Bezeichner sind u.U. verloren.

Hier würde ich nochmal recherchieren.

alzaimar hat folgendes geschrieben:

Disassemblierung ist nur die textuelle Repräsentation des Maschinencodes und hat Nichts mit Dekompilierung zu tun. Ich würde auch nicht soweit gehen, einen Assembler als 'Compiler' zu bezeichnen, obwohl er das streng genommen ist. Das ist so, als ob man das Zerschnippeln eines Apfels als 'kochen' bezeichnen würde .

Naja, ganz so simple sind weder Assemblierung, noch Disassemblierung..! Auch im Assemblercode verwendet man Variablennamen, und du wirst wohl auch kaum die Adressen deiner calls und jumps selbst berechnen. Bei der Disassemblierung hat man das Problem, dass man zwischen Code und Daten, und zwischen Pointern und Konstanten unterscheiden muss - aber das steht eigentlich eh auch in meinem Whitepaper..

alzaimar hat folgendes geschrieben:

Ein Decompiler muss doch auch immer wissen, mit welchem Compiler in welcher Version und mit welchen Einstellungen das Kompilat erzeugt wurde. Ggf. könnte er versuchen, die Einstellungen zu erraten. Auch dieser Hinweis fehlt.

Nein muss er nicht. Ich verweise einfach mal auf www.program-transfor...ilationFaqRefutation

alzaimar hat folgendes geschrieben:

Auch muss man zwischen reinem Assembler und einem Kompilat unterscheiden. Handgebissener Assembler lässt sich per se nicht dekompilieren, ein Kompilat manchmal schon.

Wie meinst du das?

alzaimar hat folgendes geschrieben:

Persönlich würde ich in ein paar Sätzen die grundlegende Arbeit eines Compilers darlegen (häppchenweise Übersetzung des Programmcodes in Assembler). Wenn ich für jedes Programmsegment des Quellcodes ('If','While' etc.) die Happen kenne, kann ich logischerweise aus dem Assemblercode durch einfache Mustererkennung den Originalquellcode wieder herstellen. Einzig die Namen der Bezeichner sind u.U. verloren.

Naja, das geht schon über reine Mustererkennung hinaus..! Im Endeffekt läuft es auf komplexe Datenfluss- und Kontrollflussanalysen hinaus. Siehe www.program-transfor...DecompilationProcess