Vor Decompiling schützen
lima-city → Forum → Programmiersprachen → Java
anweisung
aufwand
code
datei
ding
ergebnis
fakt
glauben
http
jahr
leute
paar
programm
quellcode
sekunde
sprache
url
vergessen
verhindern
verwendung
-
Das Decompilen von .jar Dateien ist leicht gemacht, unter dem Stichwort "Java Decompiler" findet man auch schnell eine geeignete Software bei Google. Meine Frage, kann man sich davor schützen? Wenn ja, wie?
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Ist ja möglich, dass ich mich nicht auskenne, aber: eine .jar-Datei ist ein Archiv-Dateiformat.
Von daher hat das mit compilieren und decompilieren nichts zu tun. Kann es sein, dass du meinst, dass niemand Dateien daraus extrahieren darf? Ich weiß allerdings nicht, ob man ein .jar-Archiv irgendwie Passwortschützen kann oder so -
Jetzt fehlt mir gerade das richtige Beispiel, ich poste später eines.
-
Ich bin schwerestens davon überzeugt, dass sowas nicht geht - ausser natürlich, du möchtest die Dateien unausführbar machen. (Man könnte sie einfach verschlüsseln ;) )
Wenn ich .jar Dateien entpacke bekomme ich da zumindest meist .class Dateien (und ähnliches) heraus. Einmal mit einem Decompiler drüber und fertig ist der Source. Sofern ich weiss, sind diese Dateien aber immer Dekompilierbar. Ich fürchte daran kann man nichts ändern.
-
nerdinator schrieb:
Wenn ich .jar Dateien entpacke bekomme ich da zumindest meist .class Dateien (und ähnliches) heraus. Einmal mit einem Decompiler drüber und fertig ist der Source. Sofern ich weiss, sind diese Dateien aber immer Dekompilierbar. Ich fürchte daran kann man nichts ändern.
Doch, daran kann man was ändern, und zwar, indem man einen Obfuscator verwendet. -
burgi schrieb:
nerdinator schrieb:
Wenn ich .jar Dateien entpacke bekomme ich da zumindest meist .class Dateien (und ähnliches) heraus. Einmal mit einem Decompiler drüber und fertig ist der Source. Sofern ich weiss, sind diese Dateien aber immer Dekompilierbar. Ich fürchte daran kann man nichts ändern.
Doch, daran kann man was ändern, und zwar, indem man einen Obfuscator verwendet.
Das ist bei mir alles schon recht lange her und ich habe inzwischen einiges wieder vergessen, aber: trotz der verwendung von einem Obfuscator hat mir ein Decompiler (Ist schon lange her, aber ich glaube jad hieß das ding) noch immer hervorragende Ergebnisse geliefert. Mag sein, dass in den Jahren da nun erhebliche Fortschritte gemacht wurden, aber damals hat es mir zumindest gar nichts gebracht. -
nerdinator schrieb:
Das ist bei mir alles schon recht lange her und ich habe inzwischen einiges wieder vergessen, aber: trotz der verwendung von einem Obfuscator hat mir ein Decompiler (Ist schon lange her, aber ich glaube jad hieß das ding) noch immer hervorragende Ergebnisse geliefert. Mag sein, dass in den Jahren da nun erhebliche Fortschritte gemacht wurden, aber damals hat es mir zumindest gar nichts gebracht.
Ja, klar, ein Ergebnis bekommt man meistens, mit etwas Aufwand ist viel möglich, und ganz verhindern kann man das nie, aber man muss es einem ja nicht noch erleichtern auch!
-
burgi schrieb
Ja, klar, ein Ergebnis bekommt man meistens, mit etwas Aufwand ist viel möglich, und ganz verhindern kann man das nie, aber man muss es einem ja nicht noch erleichtern auch!
Naja, viel Aufwand war das nicht - wie der Threaderöffner bereits vorschlug, habe ich es damals gemacht: Bei Google nachgeschlagen, fündig geworden, kostenloser download, mit ein paar kommandozeilenparametern gestertet (dieser Vorgang war der wohl komplizierteste), ein paar Sekunden gewartet und fertig war das Ergebnis.
Fakt ist doch, dass der "Entwickler" dabei fast mehr arbeit hat, als derjenige, der das dann dekompilieren möchte. Diese Decompiler gibt es doch sicher auch inzwischen mit wunderschöner GUI und ner hübschen Animation, die dann abgespielt wird, während man wartet, bis das Ding das von ganz allein geschafft hat.
Klar, ein Obfuscator ist sicher kein schlechter Ansatz - aber ist das heutzutage noch zweckmäßig? Zwischendurch hörte ich von einer C# Version, die Java-Code in C# umwandelt. Kompiliierte C-Programme galten damals zumindest noch als nicht dekompilierbar (Ich weiss nicht, ob sich daran nun was geändert hat - wie schon gesagt: Mit dem Thema Decompiling habe ich mich vor einige Jahren beschäftigt...) Die Frage ist, ob es den Aufwand wert ist? Ich sag mal: Man kann auch HTML unverständlich schreiben - verzichten wir auf jegliche Standards. Naja, HTML ist da vielleicht ein schlechtes Beispiel. ;D Da steigt man immer noch mal durch.
Ich würde sagen: Hat man eine Idee, die so schützenswert ist, gibt es da denke ich Wege die Rechtlich zu schützen. Wenn es sich um ein kleines Spiel, eine Verschlüsselungssoftware, oder wasweissich handelt, sollte man immer im Auge behalten, dass es davon unmengen auf dem Markt gibt. Ist es dem "Anwender" da so wichtig, jetzt den Quellcode zu erfahren, wenn er damit sowieso nicht reich wird?
Aber da steigt man jetzt denke ich zu weit in das Thema "Datensicherheit" ein. Wie schon gesagt: Man könnte das Programm auch verschlüsseln - dann wäre es lediglich nicht mehr ausführbar. Und selbst da: Ein paar Millionen Jahre Rechenzeit knacken selbst da bisher jeden Algorithmus (von dem ich weiss).
Meine Grundaussage bleibt: Vollständige Sicherheit ist bei sowas nicht möglich. Ein Obfuscator kann einem das ganze Spiel etwas erschweren, aber damit ist auch immer eine ganze Menge Aufwand verbunden. Und der Aufwand wurde mir damals nur unwesentlich erhöht. (Die paar Sekunden kann ich dann auch noch warten... ) Aber wie schon gesagt: Ich habe recht wenig _aktuelle_ erfahrung damit. Mag sein, dass die damals halt noch nicht so weit waren, dass sich heute der Boom ergeben hat, dass sowas nahezu unknackbar ist, oder dass mein ganzer Vortrag hier Unsinn war. Ich kann da nur von meinen eigenen Erfahrungen berichten - welche wie schon öfters betont Jahre alt sind ;) -
Es ist für den Entwickler nicht mehr Aufwand. Einen Obfuscator einzubinden ist meist nur ein Aufwand von 5-10 Minuten und das einmalig. Denn wer unbedingt einen Obfuscator nutzen will hat eh ein ANT/Maven Script im Hintergrund für den Buildprozess am laufen und nur so am Rande: Das offizielle JDK liefert einem sogar einen Java-Decompiler gleich mit. Man müsste also nicht einmal nach einem bei Google suchen ;) Wobei JAD einfach super ist ^^
Wenn du nicht willst das jemand deine Anweisungen zurückentwickelt, dann nutz eine andere Sprache. Wobei selbst die kann man letzten Endes in ASM zurückentwickeln. -
Hallo zusammen,
eine 100%-ige lösung kann es gar nicht geben: java muss noch einmal kompiliert werden zur laufzeit. das heißt, das jre muss es parsen können, und was das jre kann kann man auch nachbauen, insofern sind die ganzen versuche nahezu hoffnungslos. ein obfuscator nutz aber etwas, da er die leserlichkeit des quelltextes stark verschlechtert. würde ich immer anwenden (obwohl meine programme sowieso opensource sind).
Gruß Tillorgias -
Ich poste später mal so eine geschützte .jar Datei, wenn man die entschlüsseln will kriegt man nur .class Dateien mit den Namen "a" heraus. Und diese sind nicht lesbar, man erhält nur verschlüsselten Code wie wenn man eine kompilierte .exe Datei mit dem Editor öffnen will.
-
tillorgias schrieb:
java muss noch einmal kompiliert werden zur laufzeit. das heißt, das jre muss es parsen können, und was das jre kann kann man auch nachbauen, insofern sind die ganzen versuche nahezu hoffnungslos. ein obfuscator nutz aber etwas, da er die leserlichkeit des quelltextes stark verschlechtert. würde ich immer anwenden (obwohl meine programme sowieso opensource sind).
Aua, Bauchschmerzen.
Java Quellcode -> Bytecode -> VM
Die JVM liest den Bytecode und über den Bytecode kann man immer zurückentwickeln. Auch obfuscatierte Projekte. Vorteil ist halt, dass die Bezeichner durch A, B, C, A1, A2 etc ersetzt werden. Aber solange man ByteCode Anweisungen versteht benötigt man keinen zurückentwickelten Code. Denn selbst regulär zurückentwickelter Code der nicht obfuskiert wurde zeigt längst nicht 1:1 den Code der vorher zum Compilat geführt hat. Er ist ja nur zurückentwickelt worden aus jenem Bytecode. Von daher, who cares?
Ich poste später mal so eine geschützte .jar Datei, wenn man die entschlüsseln will kriegt man nur .class Dateien mit den Namen "a" heraus. Und diese sind nicht lesbar, man erhält nur verschlüsselten Code wie wenn man eine kompilierte .exe Datei mit dem Editor öffnen will.
Noch mehr Bauchweh. Also wenn ich einen Disassembler anwerfe, sehe ich durchaus Anweisungen bei einer Exe Datei. Ist allerdings ASM und nicht die Sprache mit der das Programm geschrieben wurde...
Beitrag zuletzt geändert: 14.5.2009 15:47:42 von evil-devil -
Hallo,
das meinte ich doch mit "parsen" (war dämlich ausgedrückt
), aber was ich meinte bleibt trotzdem: der bytecode muss noch einmal gelesen werden, und was das jre kann, können i-welche leute, die sich damit beschäftigen, auch. Das ist der Fakt.
Güße, Tillorgias -
tillorgias schrieb:
das meinte ich doch mit "parsen" (war dämlich ausgedrückt), aber was ich meinte bleibt trotzdem: der bytecode muss noch einmal gelesen werden, und was das jre kann, können i-welche leute, die sich damit beschäftigen, auch. Das ist der Fakt.
Das gilt aber auch für Maschinensprache. Oder Assemblersprache, wenn man decompiled...
Also, ich würde mich herrschander Meinung anschließen, dass das unmöglich ist, sicher zu machen. Und übrigens auch gar nicht erstrebenswert, imho... -
tillorgias schrieb:
Hallo,
das meinte ich doch mit "parsen" (war dämlich ausgedrückt), aber was ich meinte bleibt trotzdem: der bytecode muss noch einmal gelesen werden, und was das jre kann, können i-welche leute, die sich damit beschäftigen, auch. Das ist der Fakt.
Güße, Tillorgias
Mal davon abgesehen das es dazu offizielle Dokumentationen gibt und wie schon weiter oben geschrieben beim JDK ein Decompiler gleich dabei liegt. -
merovius schrieb:
Ja, ja die Theorie. In der Praxis sieht es aber so aus, dass kein wirklich funktionierender Decompiler für die Maschinensprache existiert.
tillorgias schrieb:
das meinte ich doch mit "parsen" (war dämlich ausgedrückt), aber was ich meinte bleibt trotzdem: der bytecode muss noch einmal gelesen werden, und was das jre kann, können i-welche leute, die sich damit beschäftigen, auch. Das ist der Fakt.
Das gilt aber auch für Maschinensprache. Oder Assemblersprache, wenn man decompiled...
Also, ich würde mich herrschander Meinung anschließen, dass das unmöglich ist, sicher zu machen. Und übrigens auch gar nicht erstrebenswert, imho...
Java Bytecode nach Java funktioniert dagegen fast perfekt. Selbst wenn der Code obfusciert wurde, es gehen dann nur die Namen der "private" Methoden und Variablen verloren. Mit ein bisschen Mühe kann man sich das aber wieder zusammenreimen.
Beitrag zuletzt geändert: 17.5.2009 19:15:40 von steampunk -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
