Wie Protector4J funktioniert
Protector4J schützt Ihren Java-Quellcode, indem es JAR-Dateien in private, verschlüsselte Jarx-Dateien konvertiert. Wir verfolgen mehrere Ansätze, um die Sicherheit Ihrer Anwendung sowohl auf der JVM- als auch auf der Binärebene zu gewährleisten und einen hochwirksamen Anwendungsschutz zu bieten.
Die Probleme mit Code-Verschleierung
Aufgrund der hohen Semantik des JVM-Bytecodes ist er äußerst einfach zu analysieren und zu lesen. Mithilfe des dynamischen Debuggings lässt sich die laufende Logik leicht analysieren. Das Schreiben eines dynamischen Debugging-Tools ist keine sehr komplizierte Aufgabe. Daher ist Verschleierung keine zuverlässige Schutzlösung.
Die Probleme mit der Klassenverschlüsselung
Aufgrund des Vorhandenseins eines JVM-Anhangsmechanismus kann der gesamte sogenannte verschlüsselte Code, der nicht vom normalen JVM-Betrieb getrennt wurde, mithilfe von Anhangstools problemlos gelesen werden. Daher ist dies die ineffektivste Schutzlösung.
Die Probleme mit dem Schutz von virtuellen Maschinen
Der Virtualisierungsschutz ist die sicherste Codeschutzmethode, kann jedoch aufgrund seiner erheblichen Auswirkungen auf die Leistung nicht auf den gesamten Code in einem Programm angewendet werden. Es kann nur kritischen Code schützen, während bei anderem Code immer noch das Risiko einer Offenlegung besteht. Indem man auf andere Teile des Codes abzielt, kann man funktionale Informationen über den virtualisierten Teil des Codes erhalten.
Die Probleme mit der AOT-Kompilierung
Die AOT-Kompilierung ist schwierig zu konfigurieren und zu kompilieren und es besteht eine hohe Wahrscheinlichkeit, dass sie fehlschlägt. Selbst wenn die Kompilierung erfolgreich ist, ändert sich die Codelogik nur von der Bytecode-Darstellung zur Maschinencode-Darstellung. Seine inhärente Betriebslogik existiert weiterhin ohne besonderen Schutz. Wenn man seinen eigenen Kompilierungs- und Ausführungsmechanismus versteht, ist es immer noch möglich, lesbaren Code zurückzuentwickeln.
Entschleierung mit vlx-vmengine
Entschlüsseln Sie Java-Code mit dem JVM-Bytecode-Ausführungsmodul vlx-vmengine
JVM-Bytecode-Ausführungsmaschine in Java/Kotlin geschrieben
Herkömmliches dynamisches Debuggen von Java kann nur auf der Grundlage des Quellcodes durchgeführt werden. Ohne Quellcode oder verschleierte Java-Klassendateien ist dynamisches Debuggen nicht möglich. Die Ausführung von Java-Programmen basiert auf der JVM, und die JVM verwendet Bytecode als Grundlage für die Ausführung. Wir verwenden Kotlin, um eine JVM-Bytecode-Ausführungs-Engine zu erstellen, die mit modernen IDEs wie IDEA verwendet werden kann, um Java-Programme auf Bytecode-Ebene zu debuggen und das Laufverhalten des Programms zu beobachten.
GraalVM NativeImage Reverse Engineering
Kann der Code von Java-Programmen, die in die Ära der Binärkompilierung eingetreten sind, genauso einfach rückkompiliert werden wie in der Ära des Bytecodes? Was sind die Merkmale von Binärdateien, die von NativeImage kompiliert wurden? Reicht die Stärke der Binärkompilierung aus, um wichtigen Code zu schützen? Um die oben genannten Probleme zu untersuchen, habe ich kürzlich ein NativeImage-Analysetool geschrieben, das einen bestimmten Grad der umgekehrten Ableitung erreicht hat.
Das Hacken einer verschlüsselten Java-Anwendung mit jhsdb (HotSpot Debugger)
Eine Lösung zum Schutz von Java-Code ist die Verschlüsselung der Klassendateien. Solche Lösungen laden verschlüsselte Klassen- oder JAR-Dateien über einen benutzerdefinierten Klassenlader. Aufgrund des vorhandenen JVM-Attach-Mechanismus ist diese Methode nicht effektiv und kann leicht mit Tools geknackt werden, die im JDK enthalten sind.
Extrahieren von Java-Klasseninformationen aus AOT-kompilierten Binärdateien
AOT gilt auch als Lösung für den Schutz von Java-Code, doch leider lassen sich viele Java-Programme mittlerweile nicht mehr vom Framework trennen. Aufgrund der Komplexität des Frameworks müssen selbst von AOT kompilierte Programme Klasseninformationen in die endgültig generierte Binärdatei aufnehmen, und die Klassendateien sind tatsächlich ordentlich im Ressourcenbereich der Binärdatei angeordnet.
Was ist eine JARX-Datei
Die JARX-Datei ist unser proprietäres Archivdateiformat, das zur Verschlüsselung der Daten den gleichen Deflate-Komprimierungsalgorithmus wie Zip und den AES-Verschlüsselungsalgorithmus verwendet.
Die beste Java-Code-Schutzlösung jenseits der Verschleierung
Die Verschlüsselung Ihres Codes schützt Ihr geistiges Eigentum und erhöht die Sicherheit Ihrer Anwendungen erheblich. Es macht IP-Diebstahl, Code-Manipulation und die Entdeckung von Sicherheitslücken so aufwändig und teuer, dass ein Gelegenheitsschnüffler mit einem kostenlosen Java-Decompiler nicht ausreicht.
Excelsior JET Alternative
Protector4J ist mehr als nur ein Ersatz für Excelsior JET