Die Probleme der Code-Obfuskation
Code-Obfuskation ist die früheste Lösung, die zum Schutz von Java-Code eingesetzt wurde, und sie ist auch die direkteste Lösung.
Code-Obfuskation umfasst typischerweise die folgenden vier Methoden:
- Umwandlung von Paketnamen, Klassennamen und Variablennamen
- Änderung der Kontrollstrukturen, wie z.B. Kontrollfluss-Abflachung, Hinzufügen unveränderlicher Prädikate usw.
- String-Obfuskation oder -Verschlüsselung
- Hinzufügen von nutzlosem Code
Code-Obfuskation kann die Lesbarkeit von dekompiliertem Code erheblich verringern und die Schwierigkeit der statischen Analyse erhöhen, aber egal wie die Code-Obfuskation durchgeführt wird, die Ausführungslogik des Programms wird nicht verändert.
JVM-Bytecode ist ein sehr klarer und explizit semantischer Zwischencode, der sehr gut lesbar ist. Bei obfuskierten Klassendateien können diese, selbst wenn sie nicht in lesbaren Java-Quellcode zurückgewandelt werden können, immer noch auf Bytecode-Ebene analysiert werden. Aufgrund der hohen semantischen Natur von Java-Bytecode ist dieser Prozess tatsächlich relativ einfach.
Wir haben eine JVM-Bytecode-Ausführungsengine mit den Programmiersprachen Java und Kotlin entwickelt. Benutzer können dieses Projekt verwenden, um Java-Programme auf Bytecode-Ebene in IntelliJ IDEA dynamisch zu debuggen. Weitere Informationen finden Sie im folgenden Artikel.
https://protector4j.com/de/articles/jvm-bytecode-engine-written-with-java-and-kotlin/
Und wir verwenden diese Engine, um zu versuchen, einen bekannten obfuskierten Code zu knacken. Der spezifische Prozess kann im folgenden Artikel nachgelesen werden
http://protector4j.com/de/articles/deobfuscate-with-vlx-vmengine/
Fazit
Aus der obigen Analyse ist ersichtlich, dass JVM-Bytecode aufgrund seiner hohen Semantik sehr leicht zu analysieren und zu lesen ist. Die Ausführungslogik kann durch dynamisches Debugging leicht analysiert werden. Das Schreiben von dynamischen Debugging-Tools ist keine sehr komplexe Aufgabe, daher ist Obfuskation keine zuverlässige Schutzlösung.