Probleme mit der Verschlüsselung von Java-Klassendateien

Neben der Obfuskation ist die Klassendatei-Verschlüsselung eine naheliegende Methode zum Code-Schutz. Viele Lösungen verwenden Agenten, um Klassendateien zu verschlüsseln und sie beim Laden der Klasse zu entschlüsseln. Diese Lösungen übersehen jedoch einen wichtigen Punkt: den integrierten Attachment-Mechanismus der JVM.

JVM-Attachment-Mechanismus

Um die Analyse und Überwachung des Programmbetriebs zu erleichtern, verfügen normale JVMs über Attachment-Funktionen. Benutzer können Tools wie jhsdb verwenden, um sich an den JVM-Prozess anzuhängen, seine Speicherdaten anzuzeigen und zu analysieren. Darüber hinaus sind diese Speicherdaten ordnungsgemäß nach der Datenstruktur in der Quelldatei organisiert, was auch als eingebauter Backdoor-Mechanismus der JVM verstanden werden kann.

Der folgende Artikel beschreibt, wie der JVM-Attach-Mechanismus verwendet wird, um Klassendatei-Informationen im Speicher zu lesen und zu speichern.

https://protector4j.com/de/articles/cracking-encrypted-java-applications-jhsdb/

Zusätzlich zum jhsdb-Tool, das mit dem JDK geliefert wird, können Sie auch Alibabas Arthas verwenden, um laufende Java-Prozesse zu analysieren.

HOOK-verwandte Funktionen zum Erhalten dynamisch geladener Klasseninformationen

Einige Schutzmethoden laden Klasseninformationen dynamisch über Reflection, und dieser Ansatz kann auch verwendet werden, um Echtzeit-Klasseninformationen durch DLL-Injection zu erhalten. Weitere Details finden Sie in den folgenden zwei Projekten.

https://github.com/ViRb3/jvm-dump-proxy

https://github.com/zorftw/JVM-Native-Classdumping

Fazit

Aufgrund des vorhandenen JVM-Attachment-Mechanismus oder des binären HOOK-Mechanismus kann jeglicher sogenannte verschlüsselte Code, der nicht vom normalen JVM-Betrieb abgekoppelt wurde, leicht mit Attachment-Tools gelesen oder durch DLL-Injection abgefangen werden. Daher ist dies die unwirksamste Schutzlösung.