So funktioniert Protector4J
Protector4J schützt Ihren Java-Quellcode, indem es JAR-Dateien in private, verschlüsselte JARX-Dateien umwandelt. Wir verfolgen mehrere Ansätze, um die Sicherheit Ihrer Anwendung sowohl auf JVM- als auch auf Binärebene zu gewährleisten und bieten so einen hochwirksamen Anwendungsschutz.
Die Probleme mit der Code-Verschleierung
Aufgrund der hohen Semantik des JVM-Bytecodes ist dieser extrem leicht zu analysieren und zu lesen. Seine Laufzeitlogik lässt sich mithilfe von dynamischem Debugging einfach untersuchen. Die Entwicklung eines solchen Tools ist nicht besonders komplex. Daher ist Verschleierung kein zuverlässiger Schutzmechanismus.
Die Probleme mit der Klassenverschlüsselung
Aufgrund des JVM-Anhangsmechanismus kann jeglicher sogenannte verschlüsselte Code, der nicht vom normalen JVM-Betrieb getrennt wurde, mithilfe von Anhangswerkzeugen leicht ausgelesen werden. Daher stellt dies die ineffektivste Schutzlösung dar.
Die Probleme mit dem VM-Schutz
Virtualisierungsschutz ist die sicherste Methode zum Schutz von Code, kann aber aufgrund der erheblichen Auswirkungen auf die Leistung nicht auf den gesamten Code eines Programms angewendet werden. Er schützt lediglich kritischen Code, während übriger Code weiterhin gefährdet ist. Durch gezieltes Anvisieren anderer Codeabschnitte lassen sich funktionale Informationen über den virtualisierten Teil des Codes gewinnen.
Die Probleme mit der AOT-Kompilierung
Die AOT-Kompilierung ist schwierig zu konfigurieren und durchzuführen und birgt ein hohes Fehlerrisiko. Selbst bei erfolgreicher Kompilierung ändert sich die Code-Logik lediglich von Bytecode- zu Maschinencode-Darstellung. Die inhärente Funktionslogik bleibt ungeschützt erhalten. Wer den Kompilierungs- und Ausführungsmechanismus versteht, kann dennoch lesbaren Code rekonstruieren.
Entschlüsselung mit vlx-vmengine
Java-Code mit der JVM-Bytecode-Ausführungs-Engine vlx-vmengine deobfuskieren.
JVM-Bytecode-Ausführungs-Engine, geschrieben in Java/Kotlin
Traditionelles dynamisches Debugging in Java ist nur anhand des Quellcodes möglich. Ohne Quellcode oder verschleierte Java-Klassendateien ist dynamisches Debugging unmöglich. Die Ausführung von Java-Programmen basiert auf der JVM (Java Virtual Machine), die Bytecode als Grundlage für die Ausführung verwendet. Wir nutzen Kotlin, um eine JVM-Bytecode-Ausführungs-Engine zu entwickeln, die mit modernen IDEs wie IDEA verwendet werden kann, um Java-Programme auf Bytecode-Ebene zu debuggen und deren Laufzeitverhalten zu beobachten.
GraalVM NativeImage Reverse Engineering
Lässt sich der Code von Java-Programmen, die mittlerweile binär kompiliert werden, genauso einfach rückkompilieren wie im Bytecode-Zeitalter? Welche Eigenschaften haben von NativeImage kompilierte Binärdateien? Ist die Sicherheit der Binärkompilierung ausreichend, um wichtigen Code zu schützen? Um diese Fragen zu untersuchen, habe ich kürzlich ein NativeImage-Analysetool entwickelt, das bereits eine gewisse Rückwärtskompilierung ermöglicht.
Hacking einer verschlüsselten Java-Anwendung mit jhsdb (HotSpot Debugger)
Eine Möglichkeit zum Schutz von Java-Code besteht in der Verschlüsselung der Klassendateien. Dabei werden verschlüsselte Klassen- oder JAR-Dateien über einen benutzerdefinierten Klassenlader geladen. Aufgrund des Attach-Mechanismus der JVM ist diese Methode jedoch nicht effektiv und kann mit den im JDK enthaltenen Tools leicht geknackt werden.
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 heutzutage nicht mehr vom Framework trennen. Aufgrund der Komplexität des Frameworks müssen selbst mit AOT kompilierte Programme Klasseninformationen in die generierte Binärdatei einbinden, und die Klassendateien sind im Ressourcenbereich der Binärdatei übersichtlich angeordnet.
Was ist eine JARX-Datei?
JARX-Dateien sind unser proprietäres Archivdateiformat, das denselben Deflate-Komprimierungsalgorithmus wie Zip und denselben AES-Verschlüsselungsalgorithmus zur Datenverschlüsselung 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. Sie macht IP-Diebstahl, Code-Manipulation und die Entdeckung von Sicherheitslücken so aufwendig und kostspielig, dass ein Gelegenheitsnutzer mit einem kostenlosen Java-Dekompiler nicht ausreicht.
Excelsior JET Alternative
Protector4J ist mehr als nur ein Ersatz für Excelsior JET.