Wie zu sperren, die kompilierten Java-Klassen zu verhindern, Dekompilierung?

Question

Wie Sperre ich kompilierte Java Klassen zu verhindern, Dekompilierung?

Ich weiß, das muss sehr gut diskutiertes Thema im Internet, aber ich konnte nicht kommen zu keinem Ergebnis, nachdem verweisen.

Viele Menschen lassen obfuscator, aber Sie nur tun, umbenennen von Klassen, Methoden und Felder, die mit hart-zu-erinnern Sequenzen von Zeichen, aber, was über sensible Konstante Werte?

Für Beispiel, die Sie entwickelt haben, die die Verschlüsselung und Entschlüsselung Komponente basiert auf einem Passwort-basierte Verschlüsselung.Nun, in diesem Fall, ist jede Durchschnittliche person Java verwenden können JAD dekompilieren Sie die class-Datei und abrufen die Passwort-Wert (definiert als Konstante) sowie Salz und im Gegenzug können die Daten entschlüsseln durch das schreiben von kleinen, unabhängigen Programm!

Oder sollten solche sensiblen Komponenten gebaut werden, die in nativem code (für Beispiel, VC++), und rufen Sie über JNI?

Answer 1

Einige der mehr erweiterte Java-bytecode obfuscators viel mehr tun, als einfach nur Klasse name mangling. Zelix KlassMaster, zum Beispiel können auch stellen Sie Ihre code-flow in einer Weise, die macht es wirklich schwer zu Folgen, und arbeitet als eine ausgezeichnete code-Optimierer...

Auch viele der obfuscators sind auch in der Lage zu klettern, Ihre string-Konstanten und entfernen Sie nicht verwendete code.

Eine andere mögliche Lösung (nicht unbedingt ohne die Verschleierung), ist die Verwendung verschlüsselte JAR-Dateien und einen benutzerdefinierten classloader, der für die Entschlüsselung (vorzugsweise mit native runtime library).

Dritte (und möglicherweise bietet den stärksten Schutz) ist zu verwenden native ahead of time Compiler GCC oder Excelsior JET, zum Beispiel, kompilieren Sie Ihren Java-code, der direkt auf eine Plattform-spezifische native binary.

In jedem Fall haben Sie sich daran zu erinnern, dass, wie das Sprichwort sagt, im Estnischen "die Schleusen sind für Tiere".Was bedeutet, dass jedes Stück code ist vorhanden (in den Speicher geladen), während der Laufzeit und genügend Geschick, Entschlossenheit und motivation, Menschen zu dekompilieren, zu entschlüsseln und knacken Sie Ihre code...Ihre Aufgabe ist einfach, um den Prozess so unangenehm, wie Sie können und immer noch halten die Sache arbeiten...

Answer 2

Solange Sie haben Zugang zu den verschlüsselten Daten und der software, die entschlüsselt ist, gibt es im Grunde keine Möglichkeit, Sie können dies vollkommen sicher ist.Möglichkeiten, dies wurde gelöst, bevor Sie verwenden irgendeine form von externer black box zu behandeln, Verschlüsselung/Entschlüsselung, wie dongles, remote authentication Server, etc.Aber selbst dann, da der Anwender besitzt vollen Zugriff auf das eigene system, das macht die Dinge schwierig, aber nicht unmöglich -es sei denn, Sie können binden Sie Ihre Produkt direkt an die Funktionalität, gespeichert in die "black box", als, sagen wir, online-gaming-Servern.

Answer 3

Haftungsausschluss:Ich bin kein Sicherheitsexperte.

Das klingt wie eine schlechte Idee:Sie sind, weil jemand verschlüsseln Sie die Dinge mit einem "versteckten" Schlüssel, den Sie ihm geben.Ich glaube nicht, dass dies geschützt werden kann.

Vielleicht asymmetrische Tasten funktionieren könnte:

• bereitstellen einer verschlüsselten Lizenz-die mit einem öffentlichen Schlüssel zu entschlüsseln
• lassen Sie die Kunden zu schaffen eine neue Lizenz und senden Sie es an Sie für die Verschlüsselung
• senden Sie eine neue Lizenz an den client zurück.

Ich bin mir nicht sicher, aber ich glaube, dass der client kann tatsächlich verschlüsseln der Lizenz-key mit dem öffentlichen Schlüssel, den Sie ihm gab.Dann können Sie entschlüsseln mit Ihrem privaten Schlüssel und re-verschlüsseln als gut.

Sie könnten halten Sie eine separate public - /private key-paar pro Kunde zu machen Sie sicher, Sie sind eigentlich immer Sachen aus den richtigen Kunden - jetzt Sie sind verantwortlich für die Schlüssel...

Answer 4

Egal, was Sie tun, kann es 'dekompiliert'.Heck, Sie können einfach zerlegen.Oder schauen Sie in einen memory-dump zu finden, Ihre Konstanten.Sehen Sie, die computer Bedürfnisse zu kennen, so dass Sie Ihren code benötigen, um zu.

Was zu tun?

Versuchen Sie nicht zu Schiff den Schlüssel als eine Feste Konstante in Ihrem code:Halten Sie es als eine per-user-Einstellung.Der Benutzer verantwortlich für die auf der Suche nach dem Schlüssel.

Answer 5

@jatanp:oder noch besser, Sie können zu dekompilieren, entfernen Sie den Lizenz-code und kompilieren.Mit Java, ich denke nicht wirklich, dass es ist eine angemessene, hack-proof-Lösung für dieses problem.Nicht einmal ein böses kleines dongle konnte verhindern, dass dies mit Java.

Mein eigenes biz-Manager sorgen über diese, und ich denke zu viel.Aber dann wieder, die wir verkaufen, unsere Anwendung in großen Unternehmen, die in der Regel zur Einhaltung der Lizenzbedingungen-in der Regel eine sichere Umgebung, Dank der Erbsenzähler und Rechtsanwälte.Der Akt der Dekompilierung selbst kann illegal sein, wenn Sie Ihre Lizenz ist korrekt geschrieben.

So, ich habe zu Fragen, tun Sie wirklich benötigen gehärtetem Schutz, wie Sie suchen für Ihre Anwendung?Was macht Ihr Kundenstamm Aussehen?(Corporates?Oder der teenager-gamer-Massen, in denen das wäre eher ein Problem?)

Answer 6

Wenn Sie suchen für eine lizenzierungslösung, können Sie aus dem TrueLicense API.Es basiert auf der Verwendung von asymmetrischen Schlüsseln.Jedoch, es bedeutet nicht, dass Ihre Anwendung nicht geknackt werden.Jede Anwendung, die geknackt werden kann, mit genug Aufwand.Was wirklich wichtig ist, wie Stu antwortete, herauszufinden, wie stark der Schutz, den Sie benötigen.

Answer 7

Ich glaube nicht, dass es eine effektive offline-Piraterie-Methode.Die Videospiel-Industrie hat versucht zu finden, dass viele mal, und Ihre Programme hat immer geknackt.Die einzige Lösung ist, dass das Programm muss ausgeführt werden, online verbunden mit Ihren Servern, so dass Sie können überprüfen, die lincense key, und dass es nur eine aktive Verbindung, die der Lizenznehmer zu einer Zeit.Dies ist, wie World of Warcraft oder Diablo funktioniert.Obwohl es private Server, entwickelt für Sie zu bypass die Sicherheit.

Having said that, ich glaube nicht, dass die mittlere/große Unternehmen nutzen illegal kopierte software, weil die Kosten für die Lizenz für Sie ist minimal (vielleicht, ich weiß nicht, wie viel Sie goig, um kostenlos für Ihr Programm) im Vergleich zu den Kosten einer Testversion.

Answer 8

Sie verwenden können, byte-code Verschlüsselung mit keine Angst vor.

Die Tatsache ist, dass die oben zitierten Papier "Cracking Java-byte-code Verschlüsselung" enthält eine Logik Trugschluss.Die wichtigste Forderung des Papiers ist vor dem ausführen alle Klassen müssen entschlüsselt werden und an den ClassLoader.defineClass(...) Methode.Aber das ist nicht wahr.

Die Annahme, die hier verpasst wird vorausgesetzt, dass Sie sich in authentisch oder standard -, java-run-time-Umgebung.Nichts kann verlangen, dass der geschützten java-app nicht nur die Einführung dieser Klassen, sondern auch entschlüsseln und übergeben Sie an ClassLoader.In anderen Worten, wenn Sie in der standard-JRE können Sie nicht abfangen defineClass(...) Methode, da die standard-java hat keine API für diese Zwecke, und wenn Sie geändert JRE mit gepatcht ClassLoader oder andere "hacker-trick" können Sie das nicht, weil er geschützt java-app wird nicht funktionieren, und deshalb haben Sie nichts, um Sie abzufangen.Und völlig egal, welche "patch finder" verwendet wird, oder die trick von Hackern genutzt.Diese technischen details sind eine ganz andere Geschichte.

Answer 9

Q:Wenn ich verschlüsseln .die class-Dateien und verwenden Sie einen benutzerdefinierten classloader zu laden und zu entschlüsseln, die Sie auf der fliege, wird dies verhindern, dass die Dekompilierung?

A:Das problem der Verhinderung der Java-byte-code Dekompilierung ist fast so alt sein wie die Sprache selbst.Trotz einer Reihe von obfuscation-tools auf dem Markt, Anfänger Java-Programmierer weiter zu denken, neue und clevere Möglichkeiten zum Schutz Ihres geistigen Eigentums.In diesem Java-Q&A-Teil habe ich einige Mythen zu zerstreuen, die sich um eine Idee Häufig rehashed in Diskussionsforen.

Die extreme Leichtigkeit, mit der Java .class-Dateien wieder rekonstruiert werden kann in die Java-Quellen, die eng an die Originale hat viel zu tun mit dem Java-byte-code design-Ziele und trade-offs.Unter anderem Java-byte-code wurde entwickelt für Kompaktheit, Plattform-Unabhängigkeit, Netzwerk-Mobilität und die einfache Analyse von byte-code-Interpreter und JIT (just-in-time)/HotSpot dynamischen Compiler.Wohl, die kompiliert .class-Dateien, die Ausdruck der Programmierer die Absicht so klar, Sie könnte einfacher sein, zu analysieren, als das original-source-code.

Mehrere Dinge, die getan werden kann, wenn nicht zu verhindern, Dekompilierung vollständig, zumindest zu erschweren.Für Beispiel, wie eine post-Kompilation Schritt könnte man die massage .Klasse Daten, um den byte-code schwerer zu Lesen, wenn dekompiliert oder schwieriger zu dekompilieren, in gültigen Java-code (oder beides).Techniken wie der Durchführung extremen Methodennamen überladen Arbeit sowie für die früheren, und die Manipulation der Ablaufsteuerung zum erstellen von Kontroll-Strukturen nicht möglich, vertreten durch die Java-syntax für das letztere.Die weitere erfolgreiche kommerzielle obfuscators verwenden Sie eine Mischung aus diesen und anderen Techniken.

Leider, beide Ansätze sind tatsächlich ändern Sie den code der JVM ausgeführt wird, und viele Nutzer fürchten sich (zu Recht), dass diese transformation stellt neue bugs zu Ihren Anwendungen.Außerdem Methode und Feld umbenennen kann die Ursache für Reflexion-Anrufe zu stoppen.Ändern eigentlichen Klassen-und Paketnamen können brechen mehrere andere Java-API (JNDI (Java Naming and Directory Interface), URL, Provider, etc.).Zusätzlich zu veränderten Namen, wenn die Assoziation zwischen der Klasse byte-code-offsets und Quelle der Zeilennummern geändert wird, ist die Wiederherstellung der ursprünglichen exception stack Trace-könnte schwierig werden.

Dann gibt es die Möglichkeit der Verschleierung der ursprünglichen Java-Quellcode.Aber grundsätzlich diese verursacht ähnliche Probleme.Verschlüsseln, nicht zu verschleiern?

Vielleicht ist die oben hat gemacht Sie denken, "was, wenn statt der Manipulation der byte-code, den ich verschlüsseln alle meine Klassen nach der Kompilierung und entschlüsseln Sie auf den Fliegen innerhalb der JVM (die getan werden kann, mit einem benutzerdefinierten classloader)?Dann die JVM führt meine ursprüngliche byte-code und doch gibt es nichts zu dekompilieren oder zurück zu entwickeln, richtig?"

Leider, Sie wäre falsch, sowohl im denken, dass Sie waren die ersten, die kommen auf diese Idee und denken, dass es tatsächlich funktioniert.Und der Grund hat nichts zu tun mit der Stärke der Verschlüsselung.