Java Dateien verschlüsseln?

[OoAnfaengeroO]

Moin!

ich hätte da ne Frage: Wie kann ich Java Dateien verschlüsseln? Also dass man beim dekompilieren nichts mehr erkennt.

MfG

 

[Noctarius]

Meinst du Obfuscation?

 

[OoAnfaengeroO]

Wahrscheinlich Halt so, dass die Dateien beim dekompilieren total unleserlich sind.

 

[Gast2]

Die Lösung hat Noctarius dir ja schon verraten, gibts da noch ne Frage?

 

[OoAnfaengeroO]

Naja, wie man es eben macht.. Gegoogelt habe ich schon, aber wirklich schlau werde ich daraus nicht ..

 

[Gast2]

Hm, das kann man doch auf den entsprechenden Seiten alles nachlesen.

Man nehmen beispielsweise mal ProGuard (erster Google Treffer): ProGuard
-> Manual -> Usage: ProGuard

Gibts danach immer noch Unklarheiten?

 

[OoAnfaengeroO]

Naja, sagen wir mal, Englisch ist nicht so mein Ding.. Vor allem aber wäre es halt toll, wenn man irgendwo eine "vereinfachte" Anleitung kriegen würde - Schließlich will ich es nur "obfuscaten", und dieses ProGuard scheint ja noch viiel mehr zu machen xD

 

[Gast2]

Dann bemüh halt mal Google ein wenig

http://www.google.de/url?sa=t&rct=j...sg=AFQjCNEVr85fQzPYHzpcd3AvsdNpYCO3Kw&cad=rja
yGuard - Java Bytecode Obfuskator und Shrinker

 

[gst]

Naja, wenn du dich dermaßen für deinen Code schämst dann solltest du deine Zeit nicht mit Verschleierung vergeuden sondern lieber das Programmieren üben.

 

[Noctarius]

Sagen wir mal so "mal eben obfuskieren" geht nicht. Sobald ein Programm etwas komplizierter wird muss man sich mit dem Obfuscator auseinander setzen und entsprechend Flags deaktieren oder Klassen für bestimmte Aktionen ausschließen.

 

[Spacerat]

Für genialen Code muss man sich nicht schämen, den muss man härter verschlüsseln, als mit simpler Obfuscation. Z.B. mit nem eigenen ClassLoadern die die Class-Dateien mit RSA ver- und entschlüsseln. Bei den Geschichten muss man sich schon sehr anstrengen um überhaupt an Quelltext zu kommen. Allerdings muss man sich auch ebenso anstrengen, um es zu realisieren.

 

[gst]

Für genialen Code muss man sich nicht schämen, den muss man härter verschlüsseln, als mit simpler Obfuscation.

Oh wie konnte ich das im Eingangsposting bloß übersehen? Der TE braucht bei seinem Kenntnisstand natürlich den härteren Stoff. :lol:

 

[Kevin94]

Was soll es denn bringen, die .class Dateien zu verschlüsseln? Irgendwo muss doch der Schlüssel unautoriziert zugänglich sein, und der ClassLoader selber ist auch nicht verschlüsselt. Wenn jemand sich also den Code des ClassLoader anschaut, sich den Schlüssel auf die selbe Weise wie das Programm hohlt und dann einfach die .class Dateien entschlüsselt, war die ganze Mühe um sonst. Da macht es doch deutlich mehr Arbeit sich durch Obfuscation zu wühlen.
Sinn macht das nur, wenn die .class Dateien von einem Webserver entschlüsselt werden, aber das hätte eine miserable Performence zur Folge.

 

[Marcinek]

Es gibt JREs, die verschlüsselte Archive entschlüsseln und ausführen.

Da dies dann kein Java Code mehr ist, ist es deutlich schwerer an den Schlüssel zu kommen.

Ich hatte mal ein Link einer Firma, die das anbietet, finde ich gerade aber nicht.

 

[Gast2]

Wie kann ich Java Dateien verschlüsseln? Also dass man beim dekompilieren nichts mehr erkennt.

OT:

beginnend bei einer einfachen XOR Verschlüsselung, über AES dann RSA und so weiter. Oder Google - da steht im großen Ganzen das es NICHT geht.

 

[turtle]

Wie hier bereits angemerkt wurde, stellt eine Software-Verschlüsselung mit Java nur eine Verzögerung fürs Knacken dar, da der Java-Code eh verifiziert werden MUSS und dies gelingt nur mit dem reinen unverfälschten Bytecode.

Es gibt aber Dongles, die dies recht praktisch anbieten. Hier fällt mir der Wibukey ein.

 

[trööhööt]

Moin!

ich hätte da ne Frage: Wie kann ich Java Dateien verschlüsseln? Also dass man beim dekompilieren nichts mehr erkennt.

MfG

"verschlüsseln" geht schon mal überhaupt nicht ... denn die VM muss den code ja lesen können ... ergo : zur runtime muss es entschlüsselt werden ... und dafür muss es irgendwo un-verschlüsselt eine info geben wie dies abläuft ... und dabei ist es egal ob man direkt einen schlüssel mit nem passenden class-loader findet oder lediglich liest das die daten über einen server laufen ... ergebnis ist gleich : zur runtime liegen die daten un-verschlüsselt im RAM da die VM ja mit arbeiten muss ...


"obfuscation" ... oder auf deutsch : "sicherheit durch unwissenheit" ist eine der wohl meistgenutzen verfahren um etwas zu schützen ... und dennoch ist es gleichzeitig eines der wohl anfälligsten ...
wenn wir dieses prinzip mal nur auf java beschränken kann man nur das gleiche sagen wie oben : es muss zur runtime code zur verfügung stehen mit der die VM etwas anfangen kann ...
natürlich gibt es bei der byte-code obfuscation möglichkeiten die dafür sorgen das z.b. daraus de-compileter source so nicht mehr re-compilebar ist ... oder man nutzt gewisse eigenheiten eines systems aus (unter win z.b. kann man keine datei mit dem namen "aux.class" erstellen ... dafür aber direkt in ein archiv schreiben > kann also nicht entpackt werden um "normalen" de-compilern angriffsfläche zu bieten) ...
grundsätzlich lässt sich aber sagen : das was man aus dem de-compiler code rausbekommt ist zwar SCHWER zu lesen ... aber nicht 100% sicher UNLESBAR ...


grundsätzliche "sicherheit" von daten gibt es so in java nicht ... und auch in keiner anderen sprache die ich kenne ... und es gibt auch genug beispiele im wahren leben die zeigen das sowas nicht wirklich funktioniert ... und trotzdem versuchen und tun es einige ...


um auf deine frage zurückzukommen, ob und wie es möglich ist java-daten so zu editieren das man diese nicht wieder sinnvoll herstellen kann, gibt es eine klare antwort : das geht einfach nicht ... zumindest nicht so lange es eine standard-VM noch ausführen soll

 

[pro2]

Du kannst deine Java Anwendung auch komplett nativ kompilieren, sodass gar kein Java mehr zur Ausführung benötigt wird.

Desktop, Server, Embedded Java SE Implementations - Excelsior

Da kann man natürlich keinen Code mehr draus machen.

 

[trööhööt]

Du kannst deine Java Anwendung auch komplett nativ kompilieren, sodass gar kein Java mehr zur Ausführung benötigt wird.

Desktop, Server, Embedded Java SE Implementations - Excelsior

Da kann man natürlich keinen Code mehr draus machen.

sorry ... aber mit einem wort "LOL" ...

du weist schon das man auch native-code wieder in halbwegs verständlichen source umwandeln kann .. oder ?

außerdem : ob nun ein virtueller cpu mit seinem befehlsatz etwas macht oder ein nativer cpu mit seinem ... wenn man sich tief genug mit sowas beschäftigt braucht man keinen source mehr ...

wirklich ... aber der post gehört in die kategorie : "schnkelklopfer für beinlose" ...

 

[Spacerat]

Naja... "ES GEHT NICHT" ist in Sachen Softwareentwicklung relativ unmöglich. Relativ, weil bei SW Sicherungen, kann man es einem wirklich nur schwerer machen.
Ein normaler ClassLoader benötigt ein Bytearray des Bytecodes der zu ladenden Klasse. Wo dieses Array aber herkommt ist ihm dabei relativ schnurz. Evtl. aus einer Container-Klasse, die beim Initialisieren erstens eine Signatur ihres Classloaders abfragt und zweitens die Klasse nur entschlüsselt, wenn der Bytecode in einem gewissen Zeitrahmen abverlangt wird. Wenn man das Ganze noch native realisiert, hat man beim Debuggen in Eclipse schon mal ganz schlechte Karten, bleibt nur noch IDA-Pro oder ähnliches.
Der einzige Schlüssel, der dazu veröffentlicht werden muss ist der RSA-PublicKey. Evtl. käme man damit tatsächlich sogar an den Bytecode, das bringt einem aber nichts, weil man ihn mangels RSA-PrivateKey schlecht ändern kann. Selbiges gilt auch für die Signatur des ClassLoaders

 

[Noctarius]

Natürlich muss nur der PublicKey freigegeben werden aber zum Entschlüsseln reicht der. Du kannst danach nur keinen geänderten Source mehr passend zum PK verschlüsseln.

 

[Spacerat]

@Noctarius: Was war PK doch gleich? Private- oder PublicKey?

Davon mal ab... Es ist immer die Frage, welche Beweggründe man hat, seine Daten zu verschlüsseln. Einer wäre, dass wirklich niemand darauf kommen soll, wie sein ach so geheimer Algo im einzelnen funktioniert - das kann man schlicht vergessen. Ein anderer wäre, wenn man seine Software zu Geld machen will und sich deswegen ein recht ausgeklügeltes Ladesystem mit Lizenzverwaltung erdenkt und entwickelt. Ob da jemand an Code kommt, den er ohnehin nicht ändern kann, ist dann mehr oder weniger egal.

 

[Noctarius]

PK = PubKey (stimmt war dumme Abkürzung ^^)

Wenn ich meine Software gegen unerlaubte Benutzung schützen will würde ich Dongles nutzen (Wibu z.B., wurde auch schon genannt).