nicht angemeldet
Dekompilieren erschwert durch Obfuscator.. wie eigentlich?
0 0 
Der Martin
Dekompilieren erschwert durch Obfuscator.. wie eigentlich?
Hallo,
hab mich immer schon gefragt, wieso das Disassemblieren einer Anwendung idR kein Problem darstellt, dass Zurückkompilieren hingegen schon,
Nach Recherrche bei Wikipedia bin ich auf den Obfuscator-Artikel gestoßen (http://de.wikipedia.org/wiki/Obfuscator), der mir zumindest den Hinweis gibt, dass es sich um kein technisches Problem, sondern um Verschlüsselungstechniken handelt. Was mir jetzt nicht ganz klar ist, ist folgender Sachverhalt: Der Obfuscator scheint ja "unsinnigen" Code hinzuzufügen, bzw. vorhandene Programmroutinen zu "verunstalten", so dass sie erstmal unlogisch erscheinen.... doch die Funktionalität des Codes bleibt doch prinzipiell erhalten, oder? Die sogenannte Verschlüsselung besteht demnach in Umformungen zu umständlichen Programmabläufen, quasi "Spaghetticode"... doch all das wäre doch kein Hindernis für einen fähigen Programmierer bestimmte Funktionen nachzuvollziehen? Wie sonst wäre z.B. das Cracken möglich (nur als Anwendungsbeispeil einer Dekompilation, soll nicht weiter ausgeführt werden)... bin mal gespannt auf eure Ansichten dazu ;-?
MfG Hans
-
Sup!
Der Obfuscator benennt einfach alle Funktionen, Variablen, Klassen etc. um, um einen möglichen Angreifer zu verwirren, ausserdem werden ggf. Abläufe umgebaut etc.
Wenn man einen Code lesen muss, wo es zum Buchstaben "a" eine Klasse, eine Klassenvariable, Instanzvariablen, globale Variablen, lokale Variablen, etc. gibt (je nach Sprache gibt es viele verschiedene Skopes, in denen irgendwas "a" heissen kann), dann ist das schon relativ schwer.
Und wenn ein Compiler erstmal einen Code optimiert hat und man ihn dann dissassembliert, hat das ganze oft nicht mehr viel mit dem Ursprungs-Code zu tun, da muss man schon recht gut sein, um den Sinn einer einzigen Funktion rauszufinden.Gruesse,
Bio
--
Never give up, never surrender!!!-
Hi,
Der Obfuscator benennt einfach alle Funktionen, Variablen, Klassen etc. um
... und damit sind alle vom Programmierer sorgsam gewählten "sprechenden" Bezeichner erstmal futsch. Dazu kommt dann, dass jegliche Formatierung des Quellcodes durch Einrückungen soweit wie möglich "komprimiert" wird, dass Kommentare gelöscht werden usw.
Und wenn ein Compiler erstmal einen Code optimiert hat und man ihn dann dissassembliert, hat das ganze oft nicht mehr viel mit dem Ursprungs-Code zu tun, da muss man schon recht gut sein, um den Sinn einer einzigen Funktion rauszufinden.
Wenn ich mir den vom Compiler "optimierten" Code ansehe, stelle ich manchmal fest: "Stimmt, warum habe ich das nicht gleich so geschrieben?" Viel häufiger kann ich aber an den Assembler-Anweisungen ziemlich genau Schritt für Schritt meinen Algorithmus wiedererkennen.
Ciao,
Martin--
Wenn Zeit das Kostbarste ist, was wir haben, dann ist Zeitverschwendung die größte aller Verschwendungen.
(Benjamin Franklin, amerikanischer Tüftler und Politiker)-
Hallo,
danke erstmal für eure Antworten... Ich könnte das Problem als guter Assembler-Programmierer aber umgehen, in dem ich es beim Disassemblieren belasse. sprich nicht in "Formatierungsnöte" gerate, da ich den ursprünglcihen Code nicht berühre?
MfG Hans
-
Hi,
Ich könnte das Problem als guter Assembler-Programmierer aber umgehen, in dem ich es beim Disassemblieren belasse.
natürlich, es ist dir freigestellt[1], den Maschinencode eines Programms zu disassemblieren und zu versuchen, daraus die Programmlogik zu rekonstruieren. Das ist aber ohne Kommentare, ohne Variablen- und Funktionsnamen sowie ohne eine gewisse Vorahnung sehr, sehr schwierig.
So long,
Martin[1] Die Lizenzbestimmungen eines Softwareprodukts erklären "Reverse Engineering", wozu auch das Disassemblieren zählt, häufig für nicht erlaubt. Ob du dich dieser Klausel beugen willst, sei dir überlassen.
--
Fettflecke werden wieder wie neu, wenn man sie regelmäßig mit etwas Butter einschmiert.
-
-
-