# Java Code schützen - Key4J



## crazy_N (16. Aug 2004)

Vor einiger Zeit fragte ich mal im Chat, ob es möglich ist, seine Klassen vor dem decompilieren zu schützen. Wir kamen überein, dass sogenannte Obfuscatoren die einzige Möglichkeit wäre, den Code einigermaßen zu schützen. Dabei werden Variablennamen und Methodenamen durch kryptische Bezeichnungen ersetzt, was das Lesen erschwert. Jedoch können moderne Entwicklungsumgebungen mittels Refactoring einen großen Teil dieser Verschleierung wieder rückgängig machen.

Die Firma Step2e entwickelte ein neues Produkt zur Verschlüsselung von Java Klassen. mit der das dekompilieren nicht möglich ist. Hier ein Auszug aus der Herstellerseite:

```
Das Grundproblem

Die Programmiersprache Java erfreut sich seit einigen Jahren immer größer werdender Beliebtheit.
Neben klassischer Client-Programmierung bietet Java vor allem im Bereich verteilter oder
serverbasierter Systeme eine umfassende Lösung für moderne e-Business Anwendungen. Java
Software ist plattformunabhängig, d.h. ein und dasselbe Programm kann sowohl unter Windows,
als auch unter Unix / Linux oder MacOS Betriebssystemen eingesetzt werden. Dies wird dadurch
erreicht, dass eine plattformabhängige sog. Virtuelle Maschine auf dem Zielsystem installiert wird,
in der die eigentlichen Java-Programme dann ablaufen.
Hieraus ergeben sich allerdings zahlreiche Probleme, vor allem im Bereich „Security“. Java-
Quelltext wird in den sog. Bytecode kompiliert und dieser in einer Virtuellen Maschine (JVM)
ausgeführt. Da die Schnittstelle der JVM offen gelegt ist, können Java-Klassen sehr einfach wieder
in den ursprünglichen Quelltext zurück transformiert werden (Decompiler). Dadurch werden alle
eingesetzten Algorithmen, Klassen und Methoden offen zugänglich, die Software damit nicht
schützbar.

Die Lösung

Wibu-Key bietet hervorragende Verschlüsselungsmöglichkeiten. Key4J nutzt diese um Java-Klassen
zu schützen. Eine verschlüsselte Java-Klasse kann von keinem Decompiler „geknackt“ werden und
bietet somit optimalen Schutz für die darin enthaltenen Informationen. Die gewünschten Klassen
werden im „Key4J-Admin“ ausgewählt und anschließend verschlüsselt wieder in die ursprüngliche
Verzeichnishierarchie oder jar-Archive geschrieben. Für die Integration in
Entwicklungsumgebungen wie z.B. Eclipse oder Together kann Key4J auch als Ant-Task aufgerufen
werden.
Beim Ausführen des Programms sorgt der „Key4J-Classloader“ dafür, dass die gesicherten
Informationen ausschließlich im Hauptspeicher des Rechners unverschlüsselt vorliegen. Die
spezielle „Key4J-Security Architecture“ bemerkt sowohl den Austausch als auch Manipulationen des
Original-Classloaders der JVM und führt somit zum derzeit sichersten Schutz für Java-Software.

Performance

Key4J verwendet die indirekte Verschlüsselung von Wibu-Key. Hierbei wird zu Beginn ein
Referenzwert generiert, mit dem dann im Hauptspeicher der komplette Entschlüsselungsprozess
stattfindet. Die Kommuikation mit Wibu-Key wird somit auf ein Minimum reduziert, die
Performance bleibt im Vergleich zur unverschlüsselten Anwendung nahezu unverändert.

Einsatz

Key4J kann eingesetzt werden, ohne bestehende Anwendungen modifizieren zu müssen.
Im „Key4J Admin“ wählen Sie die zu verschlüsselnden Klassen. Diese können nach der
Verschlüsselung wie normale Java-Klassen behandelt und z.B. in jar-Archive gepackt
werden. Eine verschlüsselte Anwendung kann ohne Modifikation der Quelltexte wie folgt
aufgerufen werden:
java –classpath %CLASSPATH%;WkJavaApi.jar de.step2e.key4j.Key4JWrapper
Main_Class Arg0 Arg1...
Hierbei ist Main_Class Ihre Original-Java Anwendung und Arg0, Arg1, ... die von Ihnen
benötigten Parameter.
```







Quelle: http://www.step2e.de/


----------



## bygones (16. Aug 2004)

verschoben zu Sonstiges


----------



## Isaac (16. Aug 2004)

Für den "normalen" Nutzer mag das genügen aber wenn ich da ran will komme ich auch ran und wenn ich einfach den Speicher auslese und das Programm so extrahiere. Ich sehe keinen Grund meine Sourcen extra zu schützen. Der Aufwand gegen Kriminelle Energie ist meist exponentiell zu dem Aufwand den man braucht um den Schutz zu umgehen.


----------



## L-ectron-X (16. Aug 2004)

Isaac, nun mach doch nicht immer alles gleich schlecht.
Lehnen wir uns zurück und warten wir's erst mal ab. :wink:


----------



## Grizzly (16. Aug 2004)

Dies wird auch von der Firma Wibu angeboten. Die haben uns das auf der letzten Linux Tag Messe in Karlsruhe vorgeführt. Ist ganz interessant.


----------



## bygones (16. Aug 2004)

Grizzly hat gesagt.:
			
		

> Dies wird auch von der Firma Wibu angeboten. Die haben uns das auf der letzten Linux Tag Messe in Karlsruhe vorgeführt. Ist ganz interessant.


mhm - hätte ich mir fast gedacht


> Key4J verwendet die indirekte Verschlüsselung von Wibu-Key


----------



## thE_29 (18. Sep 2006)

Da finde ich endlich diesen Thread und dann gibts dieses Produkt scheinbar nicht mehr?!


----------



## foobar (18. Sep 2006)

thE_29 hat gesagt.:
			
		

> Da finde ich endlich diesen Thread und dann gibts dieses Produkt scheinbar nicht mehr?!



Klingt alles sehr interessant, aber anscheinend gibt es das Produkt wirklich nicht mehr. Kennt jemand etwas vergleichbares?


----------



## WPNCC1701D (19. Sep 2006)

Hallo zusammen 

vielleicht ist das was? 

http://www.componio.net/products/jinstaller/jarcryp/

Gruß 
Wolfgang


----------



## Guest (19. Sep 2006)

Naja dann hab ich im endeffekt mein java programm in ein c++ programm konvertiert und das dann "verschlüsselt". Da kann ich auch c++ proggen  und das dann verschlüsseln. Obwohl das könnte ich ja dann wieder in java konvertieren un d das dann verschlüsseln ..... 
 :autsch:


----------



## Guest (25. Sep 2006)

Anonymous hat gesagt.:
			
		

> Naja dann hab ich im endeffekt mein java programm in ein c++ programm konvertiert und das dann "verschlüsselt". Da kann ich auch c++ proggen  und das dann verschlüsseln. Obwohl das könnte ich ja dann wieder in java konvertieren un d das dann verschlüsseln .....
> :autsch:



Hm, so einfach scheint es dann ja nicht zu sein. Wenn ich das richtig verstanden habe, dann benutzen die einen für die Zielplattform  kompilierten Launcher, welcher die Entschlüsselung übernimmt und die Daten dann an die VM übergibt. Wenn man der FAQ glauben darf, dann scheinen Sie auch noch ein paar Klimzüge zu betreiben, damit man nicht ohne weiteres an die Klassendaten kommt. 

 :idea:


----------

