Hi,
ich habe ein wenig mal über die Sicherheit des Java Bytecodes gelesen.
Dabei bin ich auf jd-gui (ziemlich schnell gestoßen).
Frage - wie schütze ich denn meinen Code?
Ich habe zwar das ein oder andere in google gesehen - z.B. habe ich mal ProGuard ausprobiert.
Leider konnte ich den Code mit jd-gui immer noch lesen.
Beste Grüße
In letzter Konsequenz gar nicht. Ist aber auch bei Sprachen wie C/C++ nicht vollständig möglich. Man braucht nur einen erfahrenen Reverse Engineer. In Java gehts natürlich leichter.
O.K. - ich gebe dir vollkommen recht.
Wenn man genug Geld rein steckt wird man jeden Code wieder „Lesbar“ bekommen,
Ja und für Java gibt es da nichts, was ich sage mal es zumindest für Programme wie jd-gui nicht einfach so lesbar macht?
Die Struktur muss ja auch nach einem Obfuscating erhalten bleiben, da es ja auch interpretiert werden muss. Die Decompiler machen ja nichts anderes, nur dass eben das Code Äquivalent erzeugt wird und nicht derselbige ausgeführt wird.
Außer, dass Kommentare verschwinden und Variablen nicht sprechende Bezeichner haben passiert ja nicht viel. Einige Konstrukte sind im Bytecode teilweise auch anders (Enum) aber im weitesten bleibt die Struktur ja erhalten. Muss ja auch.
Die Frage ist, wovor der Bytecode geschützt werden muss.
Die wenigsten von uns implementieren bahnbrechende Algorithmen, und wenn, dann sollte man sich das patentieren lassen.
Ich habe noch nie großartige Notwendigkeit darin gesehen, den Code zu obfuscaten. Irgendwann ist es auch eine Frage der Praktikabilität. Schließlich muss ich auch immer zur Fehlersuche die Logfiles und Stacktraces erst mal wieder lesbar machen.
Kannst du mir bitte mal eine Einschätzung geben ob dieses Programm was ist oder nicht:
http://www.componio.net/produkte/jinstaller-familie/#.Ug3cH2RNy_o
(JInstaller)
Es soll angeblich sjar Dateien erzeugen die erst zur Laufzeit an die VM decodiert übergeben werden.
Haha. 
[QUOTE=evilhomer;27638]Kannst du mir bitte mal eine Einschätzung geben ob dieses Programm was ist oder nicht:
http://www.componio.net/produkte/jinstaller-familie/#.Ug3cH2RNy_o
(JInstaller)
Es soll angeblich sjar Dateien erzeugen die erst zur Laufzeit an die VM decodiert übergeben werden.[/QUOTE]
Naja super. Dann hänge ich mich halt mit einem Debugger in den Classloader. (Ok, das soll angeblich nicht gehen. Kann ich mir zwar nicht so recht vorstellen, aber dann muss man halt den Decrypter reversen.) Du kannst die Hürde zwar beliebig hoch setzen, aber schlussendlich wird der Code ausgeführt und dazu ist nunmal der Bytecode nötig.
Naja die werden eine Art Native-Classloader gebaut haben, der deren Dateiformat / Schlüssel lesen kann. Mit richtigem Debugger wirst du das immer noch abfangen können 
Irgendwie muss es ja entschlüsselt und in den Speicher gelegt werden und der native Call an defineClass muss kommen, nur der wird irgendwo in der nativen Lib aufgerufen werden.
wir in der Firma nutzen obfuscation. Fuer bug reports gibts dann immer ein de-obfuscator dazu, der das dann wieder richtig stellt.
Als Entwickler kein Aufwand, wies fuer unseren Baumeister ist keine Ahnung 
Also 'ne Idee habe ich da schon länger… Bytecode verschlüsseln schön und gut. Aber wie bereits erwähnt muss irgendwann “defineClass()” aufgerufen werden, wo die Klasse als ByteArray übergeben werden muss, wodurch man sie dort abgreifen kann. Deswegen muss das Bytearray dort noch verschlüsselt übergeben werden und “defineClass()” darf zur Entschlüsselung und im Speicher ablegen nicht läner al ein paar millisekunden (oder gar Nanosekunden) brauchen, als Schutz gegen Debug. Einen solchen Classloader auf ein Dongle gebrannt und evtl. noch native implementiert, sollte sicher genug sein.
Also würdet ihr sagen ( wenn ich es richtig verstehe ).
http://www.componio.net/produkte/jinstaller-familie/#.Ug3cH2RNy_o
Ist eigentlich rausgeworfenes Geld.
Weil es “nur” die Hürde zum dekompilieren etwas hoch setzt.
Egal - wie muss ich euch hier erst einmal noch ein super dickes Danke aussprechen.
Ihr habt mir schon mal ein ganzes Eck weiter geholfen!
[QUOTE=bygones]wir in der Firma nutzen obfuscation. Fuer bug reports gibts dann immer ein de-obfuscator dazu, der das dann wieder richtig stellt.
Als Entwickler kein Aufwand, wies fuer unseren Baumeister ist keine Ahnung ;-)[/QUOTE]
Ja, bei Stacktraces macht es die IDE (die gute IDE) automatisch.
Nur mit einer passenden Lizenz oder dem eh schon vorhandenen Urheberrecht, und vielleicht noch ein wenig mit ProGuard. Das war’s dann auch schon.
Es geht mir hier nicht um den rechtliche Schutz, sondern darum das die Kongruenz nicht in den Code einsehen kann.
Da hat man aber, wenn ich das ganze bis jetzt richtig verstanden habe, mit Java sehr wenig Möglichkeiten.
Benutze einen Obfuscator und wenn du etwas mehr Schutz willst musst du schon auf Dongle-Systeme zurückgreifen (z.B. WiBu http://www.wibu.com/de.html oder Aladdin http://www.safenet-inc.de/anti-piracy-software-ip-schutz/)
Sicher, dass Du überhaupt etwas hast, was Du vor einer „Kongruenz“ schützen musst?
Da hat man aber, wenn ich das ganze bis jetzt richtig verstanden habe, mit Java sehr wenig Möglichkeiten.
Tough luck. Der Popularität von Java oder .Net hats bislang irgendwie nicht geschadet. Wenn Du so viel Angst hast, dann nimm eine nativ kompilierte Sprache. Da dauert die Entwicklung natürlich eventuell länger. In der Zeit entwickelt die Kongruenz vielleicht schon eine Alternative.
Ja was würden wir nur ohne Kongruenz machen? Vielleicht würden wir uns dann mit der Konkurrenz herum ärgern?
Viel mehr Aufwand als einen Obfuscator und eine vernünftige Lizenz würde ich allgemein nicht betreiben.
Denn egal wieviel Aufwand man reinsteckt, Reverse-Engineering kann man immer betreiben (irgendwas muss ja ausgeführt werden), falls der Code zu sehr verschleiert ist baut man einfach das Programm nach (ein fertiges Programm ist meistens sogar besser zu gebrauchen als ein schlecht geschriebenes Pflichtenheft).
Mal ein gängiges Beispiel:
Minecraft.
Der Code ist zwar auch verschleiert, trotzdem sind einige Schnittstellen bekannt um mit decompiling mods zu schreiben.
Geld verdient hat damit (meines Wissens nach) noch keiner, geschweige denn, dass jemand das komplette Projekt neu aufbaut und Minecraft 2.0 rausgebracht hätte wodurch Mojang an Einnahmen verlieren würde.
Im Gegenteil, durch die lockere Politik von Mojang mit Raubkopien wurde das Spiel richtig bekannt, viele Spieler haben sich später dann die gekaufte Version geholt um auf den trusted-Servern spielen zu können.
Edit: und mal ehrlich, was hindert einen daran eine gute Lösung open-source als eigene Lib zu veröffentlichen? (abgesehen von der eigenen Codequalität? :D) Falls man auf Gewinn aus ist, kann man sogar noch ein doppeltes Lizenzmodell fahren (z.B. LGPL oder GPL für nicht-kommerzielle Anwendungen und eine kostenpflichtige Lizenz für kommerzielle Anwendungen). Bei Liferay (http://www.liferay.com/de/) wird genau nach dem System vorgegangen.
Gruß
Ich empfehle http://www.github.com
Dann kannste wenigstens halbwegs sicher nachweisen, dass es wirklich dein Code ist, den du schuetzen willst.
Noch mal: was glaubst du können andere Entwickler mit deinem Code anfangen? Es kochen alle nur mit Wasser und die wenigsten entwickeln bahnbrechende Neuheiten.
Und wie schon erwähnt wurde: Reengineering ist immer möglich.
Meine Erfahrung ist, dass die Leute, die sich darüber die meisten Gedanken machen eher qualitativ schlechteren Code schreiben… nun gut, auch eine Möglichkeit… self obfuscating code