So funktioniert Protector4J
Protector4J schützt Ihren Java-Quellcode, indem jar-Dateien in private verschlüsselte jarx-Dateien konvertiert werden. Wir verfolgen mehrere Ansätze, um die Sicherheit Ihrer Anwendung sowohl auf JVM- als auch auf Binärebene zu gewährleisten und einen hochstarken Anwendungsschutz zu bieten.
Die Probleme mit Code-Verschleierung
Aufgrund der hohen Semantik von JVM-Bytecode ist er extrem leicht zu analysieren und zu lesen. Es ist einfach, seine Ausführungslogik durch dynamisches Debugging zu analysieren. Das Schreiben eines dynamischen Debugging-Tools ist keine sehr komplizierte Aufgabe. Daher ist Verschleierung keine zuverlässige Schutzlösung.
Die Probleme mit Klassenverschlüsselung
Aufgrund der Existenz des JVM-Attachment-Mechanismus können alle sogenannten verschlüsselten Codes, die nicht vom normalen JVM-Betrieb getrennt sind, leicht mit Attachment-Tools gelesen werden. Daher ist dies die unwirksamste Schutzlösung.
Die Probleme mit VM-Schutz
Virtualisierungsschutz ist die sicherste Codeschutzmethode, aber aufgrund seiner erheblichen Auswirkungen auf die Leistung kann er nicht auf alle Codes in einem Programm angewendet werden. Er kann nur kritischen Code schützen, während anderer Code weiterhin dem Risiko der Offenlegung ausgesetzt ist. Durch die Ausrichtung auf andere Codeteile können Funktionsinformationen über den virtualisierten Codeteil erlangt werden.
Die Probleme mit AOT-Kompilierung
Die AOT-Kompilierung ist schwierig zu konfigurieren und zu kompilieren und hat eine hohe Wahrscheinlichkeit des Scheiterns. Selbst wenn die Kompilierung erfolgreich ist, ändert sich die Codelogik nur von der Bytecode-Darstellung zur Maschinencode-Darstellung. Die inhärente Betriebslogik existiert weiterhin ohne besonderen Schutz. Wenn man den eigenen Kompilierungs- und Ausführungsmechanismus verstehen kann, ist es immer noch möglich, lesbaren Code zurückzuentwickeln.
Deobfuskierung mit vlx-vmengine
Java-Code-Deobfuskierung mit der JVM-Bytecode-Ausführungsengine vlx-vmengine
In Java/Kotlin geschriebene JVM-Bytecode-Ausführungsengine
Traditionelles dynamisches Java-Debugging kann nur auf Basis des Quellcodes durchgeführt werden, und ohne Quellcode oder bei verschleierten Java-Klassendateien ist dynamisches Debugging unmöglich. Die Ausführung von Java-Programmen basiert auf der JVM, und die JVM verwendet Bytecode als Ausführungsgrundlage. Wir verwenden Kotlin, um eine JVM-Bytecode-Ausführungsengine zu konstruieren, die mit modernen IDEs wie IDEA verwendet werden kann, um Java-Programme auf Bytecode-Ebene zu debuggen und das Ausführungsverhalten des Programms zu beobachten.
GraalVM NativeImage Reverse Engineering
Können Java-Programme, die in die Ära der binären Kompilierung eingetreten sind, genauso leicht rückkompiliert werden wie in der Bytecode-Ära? Was sind die Eigenschaften von mit NativeImage kompilierten Binärdateien? Reicht die Stärke der binären Kompilierung aus, um wichtigen Code zu schützen? Um die obigen Fragen zu untersuchen, habe ich kürzlich ein NativeImage-Analysetool geschrieben, das ein gewisses Maß an Rückableitung erreicht hat.
Hacken einer verschlüsselten Java-Anwendung mit jhsdb (HotSpot Debugger)
Eine Lösung für den Java-Codeschutz ist die Verschlüsselung der Klassendateien. Solche Lösungen laden verschlüsselte Klassen- oder jar-Dateien über einen benutzerdefinierten Classloader. Aufgrund der Existenz des JVM-Attach-Mechanismus ist diese Methode nicht effektiv und kann leicht mit im JDK enthaltenen Tools geknackt werden.
Extraktion von Java-Klasseninformationen aus AOT-kompilierten Binärdateien
AOT wird auch als Lösung für den Java-Codeschutz angesehen, aber leider können viele Java-Programme nicht vom Framework getrennt werden. 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 denselben Deflate-Komprimierungsalgorithmus wie Zip und den AES-Verschlüsselungsalgorithmus zur Verschlüsselung der Daten verwendet.
Die beste Java-Code-Schutzlösung jenseits der Verschleierung
Die Verschlüsselung Ihres Codes schützt Ihr geistiges Eigentum und verbessert die Sicherheit Ihrer Anwendungen erheblich. Sie macht IP-Diebstahl, Code-Manipulation und die Entdeckung von Sicherheitslücken so aufwändig und teuer, dass ein gelegentlicher Schnüffler mit einem kostenlosen Java-Decompiler nichts ausrichten kann.
Excelsior JET-Alternative
Protector4J ist mehr als nur ein Excelsior JET-Ersatz