Die Probleme mit der Code-Verschleierung
Code-Verschleierung ist die früheste und zugleich direkteste Lösung zum Schutz von Java-Code.
Code-Verschleierung umfasst typischerweise die folgenden vier Methoden:
- Paketname, Klassenname, Variablennamen-Konvertierung
- Die Kontrollstrukturen ändern sich, z. B. durch Vereinfachung des Kontrollflusses, Hinzufügen unveränderlicher Prädikate usw.
- Zeichenkettenverschleierung oder Verschlüsselung
- Füge unnötigen Code hinzu
Code-Verschleierung kann die Lesbarkeit des dekompilierten Codes erheblich verringern und die Schwierigkeit der statischen Analyse erhöhen, aber egal wie die Code-Verschleierung durchgeführt wird, die Ausführungslogik des Programms wird dadurch nicht verändert.
JVM-Bytecode ist ein sehr klarer und expliziter semantischer Zwischencode, der gut lesbar ist. Selbst wenn verschleierte Klassendateien nicht in lesbaren Java-Quellcode umgewandelt werden können, lassen sie sich dennoch auf Bytecode-Ebene analysieren. Aufgrund der hohen Semantik des Java-Bytecodes ist dieser Prozess vergleichsweise einfach.
Wir haben eine JVM-Bytecode-Ausführungs-Engine mit Java und Kotlin entwickelt. Mit diesem Projekt können Benutzer Java-Programme in IntelliJ IDEA dynamisch auf Bytecode-Ebene debuggen. Weitere Informationen finden Sie im folgenden Artikel.
https://protector4j.com/articles/jvm-bytecode-engine-written-with-java-and-kotlin/
Wir verwenden diese Engine, um einen bekannten verschleierten Code zu knacken; der genaue Prozess wird im folgenden Artikel beschrieben.
http://protector4j.com/articles/deobfuscate-with-vlx-vmengine/
Abschluss
Aus der obigen Analyse geht hervor, dass JVM-Bytecode aufgrund seiner hohen Semantik sehr leicht analysiert und gelesen werden kann. Die Laufzeitlogik lässt sich mithilfe von dynamischem Debugging problemlos untersuchen. Da die Entwicklung von Tools für dynamisches Debugging relativ unkompliziert ist, stellt Verschleierung keine zuverlässige Schutzmaßnahme dar.