Obfuscator?
- Themenstarter Snape
- Beginndatum
Thomas Darimont
Erfahrenes Mitglied
Hallo!
Davon gibt es haufenweise, sogar welche die umsonst sind ;-)
Proguard: http://sourceforge.net/projects/proguard/
Javaguard: http://sourceforge.net/projects/javaguard/
Bei Obfuscatoren gibt es mehrere Techniken, eine wäre etwa den direkten Java Source Code zu modifizieren so dass Bezeichner (Klassenname, Variablenname, Methodenname) nach einem bestimmten Schema ausgetauscht werden.
Beispielsweise bekommt die erste Variable den Namen "a" die zweite bekommt "b" die dritte "c" usw. genau das selbe bei den Methoden die erste Methode bekommt den Namen "a" -> a() die zweite Methode bekommt "b" etc.
Auch Klassennamen können auf diese Weise vom Obfuscator transformiert werden. Letztere führt aber nicht selten zu Problemen, da daruch u.U. der Reflectionmechanismus ausgehebelt wird, aber das ist eine andere Geschichte ;-)
Zum anderen gibt es aber noch sogenannte Bytecodeobfuscatoren welche den Javabytecode manipulieren, so dass das Programm nach einem Decompilieren mit einem Java Decompiler wie etwa (JAD) nicht mehr erneut kompilierbar ist. Das wird zum Beispiel dadurch erreicht, dass im Bytecode nachträglich irgendwelche Bezeichner Namen von Java Schlüsselwörtern erhalten, sprich aus einer Variable Namens "tax" wird u.U. en "try" ... diese Namensänderungen jucken java nicht innerhalb des Programms jedoch javac meldet bei diesen Namen den Fehler, dass man keine reservierten Schlüsselwörter als Bezeichner verwenden darf.
HTH
Gruß Tom
Davon gibt es haufenweise, sogar welche die umsonst sind ;-)
Proguard: http://sourceforge.net/projects/proguard/
Javaguard: http://sourceforge.net/projects/javaguard/
Bei Obfuscatoren gibt es mehrere Techniken, eine wäre etwa den direkten Java Source Code zu modifizieren so dass Bezeichner (Klassenname, Variablenname, Methodenname) nach einem bestimmten Schema ausgetauscht werden.
Beispielsweise bekommt die erste Variable den Namen "a" die zweite bekommt "b" die dritte "c" usw. genau das selbe bei den Methoden die erste Methode bekommt den Namen "a" -> a() die zweite Methode bekommt "b" etc.
Auch Klassennamen können auf diese Weise vom Obfuscator transformiert werden. Letztere führt aber nicht selten zu Problemen, da daruch u.U. der Reflectionmechanismus ausgehebelt wird, aber das ist eine andere Geschichte ;-)
Zum anderen gibt es aber noch sogenannte Bytecodeobfuscatoren welche den Javabytecode manipulieren, so dass das Programm nach einem Decompilieren mit einem Java Decompiler wie etwa (JAD) nicht mehr erneut kompilierbar ist. Das wird zum Beispiel dadurch erreicht, dass im Bytecode nachträglich irgendwelche Bezeichner Namen von Java Schlüsselwörtern erhalten, sprich aus einer Variable Namens "tax" wird u.U. en "try" ... diese Namensänderungen jucken java nicht innerhalb des Programms jedoch javac meldet bei diesen Namen den Fehler, dass man keine reservierten Schlüsselwörter als Bezeichner verwenden darf.
HTH
Gruß Tom
squeaker
Erfahrenes Mitglied
spar's dir
Ganz ehrlich: obfuscatoren kannst du Dir sparen. Das verhindert das cracken eines Programmes und das Auslesen der Seriennummer auch nicht. Du musst dir blos überlegen, dass die meisten Leute die so etwas betreiben normalerweise auf Assembler-Level arbeiten und mit viel "fieseren" Tricks umgehen könnnen.
Der beste Schutz nicht gecrackt zu werden ist es ein Programm zu schreiben welches nur wenige wollen.
Ausserdem solltest du nicht vergessen, wenn du obfuscaten willst, eine entsprechend unordentliche Klassenstruktur zu schaffen, damit es nicht offensichtlich wird wo die Abfrage ist und weiterhin dafür zu sorgen, dass die Passwortabfrage in einer Klasse ist die unbedingt benötigt wird (damit diese Klasse nicht einfach ausgetauscht wird) und am besten auch noch verteilt. Aber selbst dann sollte es immer noch relativ einfach sein.
Weitere Möglichkeiten: Klassen von Hand mit eigenem Class-Loader laden und dafür sorgen, dass die Checksumme stimmt (um das Austauschen von Klassen zu verhindern), Strings nicht im Klartext spreichern sonder dynamisch erzeugen (damit nicht einfach nach entsprechenden Strings bzw. Dateinamen gesucht wird).
Ich hab zwar noch nie ein Java-Programm gecrackt, aber ich würde die Klassen decompilen und dann nach GUI-Klassen suchen. Von da aus komme ich sicher zur Passwort-Abfrage.
P.S.: Auf jedenfall ohne Debug-Informationen compilen, sonst sind ganz sicher noch alle Kommentare im class file.
Ganz ehrlich: obfuscatoren kannst du Dir sparen. Das verhindert das cracken eines Programmes und das Auslesen der Seriennummer auch nicht. Du musst dir blos überlegen, dass die meisten Leute die so etwas betreiben normalerweise auf Assembler-Level arbeiten und mit viel "fieseren" Tricks umgehen könnnen.
Der beste Schutz nicht gecrackt zu werden ist es ein Programm zu schreiben welches nur wenige wollen.
Ausserdem solltest du nicht vergessen, wenn du obfuscaten willst, eine entsprechend unordentliche Klassenstruktur zu schaffen, damit es nicht offensichtlich wird wo die Abfrage ist und weiterhin dafür zu sorgen, dass die Passwortabfrage in einer Klasse ist die unbedingt benötigt wird (damit diese Klasse nicht einfach ausgetauscht wird) und am besten auch noch verteilt. Aber selbst dann sollte es immer noch relativ einfach sein.
Weitere Möglichkeiten: Klassen von Hand mit eigenem Class-Loader laden und dafür sorgen, dass die Checksumme stimmt (um das Austauschen von Klassen zu verhindern), Strings nicht im Klartext spreichern sonder dynamisch erzeugen (damit nicht einfach nach entsprechenden Strings bzw. Dateinamen gesucht wird).
Ich hab zwar noch nie ein Java-Programm gecrackt, aber ich würde die Klassen decompilen und dann nach GUI-Klassen suchen. Von da aus komme ich sicher zur Passwort-Abfrage.
P.S.: Auf jedenfall ohne Debug-Informationen compilen, sonst sind ganz sicher noch alle Kommentare im class file.
Franz Degenhardt
Erfahrenes Mitglied
Hab mit proguard auch gute Erfahrungen gemacht. Mit dem mitgeliefertem gui erziehlt man schnell erste Ergebnisse und durch den proguard-ant-task ist es auch für komplexere Projekte geeignet.
Probleme hatte ich mit Factory-klassen, in denen leider zu viel geshrinkt wurde. Dies lässt sich aber umgehen.
Ist schon erstaunlich was beim shrinken so alles wegfällt und lässt einen selbst nochmal über den Code nachdenken.
Grüsse TrueSun
Probleme hatte ich mit Factory-klassen, in denen leider zu viel geshrinkt wurde. Dies lässt sich aber umgehen.
Ist schon erstaunlich was beim shrinken so alles wegfällt und lässt einen selbst nochmal über den Code nachdenken.
Grüsse TrueSun
Re: spar's dir
Siehe meine ursprüngliche Frage:
"Oder kennt jemand noch eine andere Möglichkeit, z.B. ein EasterEgg zu verstecken?"
D.h. es geht nicht ums cracken sondern ums Verstecken eines EasterEggs, was möglichst weder mal eben so nebenbei vom PL gefunden werden kann noch auffällige Spuren im CVS hinterlässt.
Siehe meine ursprüngliche Frage:
"Oder kennt jemand noch eine andere Möglichkeit, z.B. ein EasterEgg zu verstecken?"
D.h. es geht nicht ums cracken sondern ums Verstecken eines EasterEggs, was möglichst weder mal eben so nebenbei vom PL gefunden werden kann noch auffällige Spuren im CVS hinterlässt.
squeaker
Erfahrenes Mitglied
das mit dem cracken war nicht bösartig gemeint. ob man nun ein easter-egg verstecken will oder eine passwortabfrage ist von der Sache her das selbe. In deinem Fall aber erregt obfuscated-code im cvs mehr aufsehen als ein Stück von Hand geschriebener Code der "normal" ausschaut.
So'ne Idee:
Schreib ne Klasse die irgendwelche komplizierten Berechnungen durchführt und am besten mehrere Ergebnisse in einem Vektor zurückliefert. Mit einem bestimmten Parametersatz aufgerufen wird allerdings in dem Vektor (der ja nur Objects enthält) ein anderes Objekt, nämlich dein generiertes EasterEgg gespeichert. Dieses kann dann einfach angezeigt werden. Am besten sollte eine Klasse geeignet sein, welche irgendwelche uninteressanten aber komplizierten Layout-Berechnungen durchführt, da dann die Swing/AWT-Klassen deines Eastereggs nicht auffallen.
So'ne Idee:
Schreib ne Klasse die irgendwelche komplizierten Berechnungen durchführt und am besten mehrere Ergebnisse in einem Vektor zurückliefert. Mit einem bestimmten Parametersatz aufgerufen wird allerdings in dem Vektor (der ja nur Objects enthält) ein anderes Objekt, nämlich dein generiertes EasterEgg gespeichert. Dieses kann dann einfach angezeigt werden. Am besten sollte eine Klasse geeignet sein, welche irgendwelche uninteressanten aber komplizierten Layout-Berechnungen durchführt, da dann die Swing/AWT-Klassen deines Eastereggs nicht auffallen.
Dario Linsky
Erfahrenes Mitglied
Auch wenn's gerade etwas offtopic ist: Wie stellst du dir vor, dass man Java-Bytecode disassemblieren kann? Bei nativ kompilierten Anwendungen mag das gehen, aber bei Java-Anwendungen wird man da wohl nicht weit kommen, denke ich.
squeaker
Erfahrenes Mitglied
hast du dir schon einmal angeschaut, was die diversen Java Decompiler ausspucken? Im wesentlichen den kompletten Quellcode, teilweise auch mit Variablen, Klassen und Methodennamen sowie Kommentaren.
Ausserdem ist der Java-Byte-Code auch nur Assembler für die JVM, noch dazu ein relativ einfacher. Aber meistens braucht man gar nicht auf diese Ebene zurückfallen (siehe oben).
Ausserdem ist der Java-Byte-Code auch nur Assembler für die JVM, noch dazu ein relativ einfacher. Aber meistens braucht man gar nicht auf diese Ebene zurückfallen (siehe oben).
