Was ist der umgekehrte Analyse- und Schutzmechanismus der Android-App?

Möchten Sie die gängigen Schutzmethoden von Android-Apps und die entsprechenden umgekehrten Analysemethoden kennenlernen?

In dieser Freigabe werden mehrere Aspekte der Android-APP-Sicherheit besprochen, darunter verschleierter Code, allgemeine Dex-Härtung, geteilte Dex-Härtung und virtuelle Maschinenhärtung. Diese Inhalte haben sich in den letzten Jahren in China zu einem wichtigen Trend beim Sicherheitsschutz von Android-Apps entwickelt.

1. Verschleierter Code

Java-Code ist eine plattformübergreifende, interpretierte Sprache und wird in Zwischen-„Bytecode“ kompiliert und in Klassendateien gespeichert. Aufgrund der Notwendigkeit, plattformübergreifend zu sein, enthalten diese Bytecodes eine große Menge semantischer Informationen und lassen sich leicht in Java-Quellcode dekompilieren. Entwickler verschleiern häufig kompilierte Klassendateien, um den Java-Quellcode besser zu schützen.

Verschleierung besteht darin, das freigegebene Programm so zu reorganisieren und zu verarbeiten, dass der verarbeitete Code dieselbe Funktion ausführt wie der vorverarbeitete Code. Selbst wenn die Dekompilierung erfolgreich ist, ist es schwierig, die Identität des Programms zu ermitteln . Echte Semantik. ProGuard ist ein Open-Source-Projekt, das Bytecode verschleiern, reduzieren und optimieren kann.

Proguard-Verarbeitungsflussdiagramm ist unten dargestellt, einschließlich vier Hauptlinks: Komprimierung, Optimierung, Verschleierung und Vorprüfung:

Komprimierung (Schrumpfen): nutzlose Klassen, Felder, Methoden und Attribute erkennen und entfernen;

Optimieren: Bytecode optimieren und nutzlose Anweisungen entfernen. Optimieren Sie den Code, Nicht-Eintrittsknotenklassen werden mit privaten/statischen/endgültigen hinzugefügt, nicht verwendete Parameter werden gelöscht und einige Methoden werden möglicherweise zu Inline-Code

Verschleieren: Verwenden Sie a, b, c, d. Benennen Sie Klassen, Felder und um Methoden mit solch kurzen und bedeutungslosen Namen;

Preveirfy: Preflight des verarbeiteten Codes auf der Java-Plattform, um sicherzustellen, dass die geladene Klassendatei ausführbar ist.

In der Freigabe zeigte Zhong Yaping ein Beispiel für den Apk-Effekt nach der Verwendung von Proguard zum Dekompilieren von Dex2jar:

Nach der Proguard-Verarbeitung

Der Proguard-Ofuscator kann den Code nicht nur schützen, sondern auch optimieren Die Größe des kompilierten Programms reduziert die Speichernutzung.

Rückwärtsanalyse von verschleiertem Code

Zhong Yaping hat ein fremdes Tool namens DEGUADR freigegeben, das statistische Methoden verwendet, um Code für die Dekompilierung zu entschleieren. Obwohl die Genauigkeit dieses Tools nicht 100 % beträgt, kann es dennoch teilweise bei der Dekompilierung des Codes helfen. ?? Dex-Verstärkung

Mit der kontinuierlichen Weiterentwicklung der Sicherheitstechnologie sind neue „Verstärkungstechnologien“ entstanden, um die Schutzstärke von Android zu verbessern. Die DEX-Verstärkung besteht darin, DEX-Dateien zu packen und zu schützen, um zu verhindern, dass sie durch statische Dekompilierungstools geknackt werden und der Quellcode verloren geht. Als erstes erscheint die Gesamtlösung für die Verstärkungstechnologie.

Das Prinzip der gesamten Verstärkungstechnologie ist wie oben gezeigt, einschließlich des Ersetzens von application/classes.dex, des Entschlüsselns/dynamischen Ladens der ursprünglichen Classes.dex, des Aufrufs der ursprünglichen anwendungsbezogenen Methoden und des Festlegens des ursprünglichen Anwendungsobjekts/ Benennen Sie die relevanten internen Variablen des Systems. Vier Hauptverbindungen. Der kritischste Schritt besteht darin, die ursprüngliche Datei „classes.dex“ zu entschlüsseln/dynamisch zu laden, die kompilierte endgültige Dex-Quellcodedatei zu verschlüsseln und dann den Anwendungsstart des neuen Projekts in einem neuen Projekt zu verwenden, um den ursprünglichen Projektcode zu entschlüsseln und in den Speicher zu laden dann Der aktuelle Prozess wird durch entschlüsselten Code ersetzt, der den Quellcode gut verbergen und eine direkte Dekompilierung verhindern kann.

Umkehranalyse der gesamten Dex-Verstärkung

Es gibt zwei häufig verwendete Methoden für die umgekehrte Analyse der gesamten Dex-Verstärkung. Eine besteht darin, gewaltsam im Speicher nach dexn035 zu suchen und es dann wegzuwerfen. Das Folgende ist ein Beispiel für die Auswirkung auf einem 32-Bit-System:

Eine andere Methode ist HookdvmDexFileOpenPartial(void* addr, int len, DvmDex**).

3. Split-Dex-Verstärkung

Da sich der Geschäftsumfang bis zu einem gewissen Grad weiterentwickelt, werden ständig neue Funktionen und neue Klassenbibliotheken hinzugefügt. Gleichzeitig nimmt die Größe des entsprechenden APK-Pakets stark zu Das System kann die Sicherheitsanforderungen nicht gut erfüllen. Zusätzlich zum Gesamtverstärkungsschema sind technische Lösungen mit geteilter Verstärkung entstanden.

Aber wie oben gezeigt, werden bei der Verstärkung der Dex-Datei einige der fehlenden Daten durch entschlüsselte Daten ersetzt. Manchmal kann diese Aufteilung und Ersetzung auch zu ungenauen Daten führen. Sie müssen die Datenstruktur der Dex-Datei verstehen, um zu bestimmen, welche Art von Daten aufgeteilt werden sollen.

Dex-Dateistruktur ist äußerst komplex. Die folgende Abbildung zeigt die wichtigeren Inhalte. Tatsächlich handelt es sich bei einer Dex-Datei um eine Datei, deren Kern die Klasse ist. Die wichtigsten Teile sind Klassendaten und Klassencode, die ihre eigenen spezifischen Schnittstellen und Befehlsdaten haben. Da die Klassendaten und Bytecode-Daten nicht verloren gehen und die Dekompilierung nicht abgeschlossen ist, ist die Sicherheit hoch.

Umgekehrte Analyse der geteilten Dex-Verstärkung

Für die umgekehrte Analyse der geteilten Dex-Verstärkung, wie unten gezeigt, können Sie diese durch Klassendaten ersetzen, um eine neue Dex-Datei zusammenzustellen, obwohl diese nicht vollständig mit der ursprünglichen Dex-Datei übereinstimmt Es stellt aber auch bis zu einem gewissen Grad das Erscheinungsbild der geteilten Daten wieder her.注意 要

Es wird darauf hingewiesen, dass diese Methode nur auf die Datenverformung der aufgeteilten einmaligen Vervollständigung anwendbar ist. Das heißt, versuchen Sie, die Verwendung zu vermeiden, wenn es andere Schutzmaßnahmen gibt Ideen, und selbst wenn nötig, versuchen Sie es nur wiederherzustellen, wenn diese Klasse verwendet wird.

Darüber hinaus gibt es ein Tool auf niedrigerer Ebene namens Dexhunter. Dieses Tool ist fortschrittlicher, weist jedoch auch einige Einschränkungen auf. Beispielsweise werden einige Befehlsdaten optimiert und die resultierende Codeschnittstelle ist nicht sehr schön. usw.虚 、

4. Verstärkung der virtuellen Maschine

Die Verarbeitung von Bytes ist eine Möglichkeit, die virtuelle Maschine zu verstärken. Sie kann auch als DEX-Split-Verstärkung angesehen werden. Das Folgende ist ein herkömmlicher Android-Systemcode, der durch eine virtuelle Maschine gehärtet wurde und dann eine Härtungskompilierung durchführt. Selbst wenn die ersetzten Daten wiederhergestellt werden, liegen sie nicht in der Form von add-int v0 vor. v1, v2, sub-int v0, v1, v2, mul-int v0, v1 Ersetzen Sie diese drei Anweisungen von v2 und führen Sie dann eine Härtungskompilierung durch. Selbst wenn die ersetzten Daten nicht wiederhergestellt werden in den vorherigen Bytecode umgewandelt, und der Sicherheitsfaktor ist hoch.

Umgekehrte Analyse der virtuellen Maschinenhärtung – HOOK-JNI-Schnittstelle

Die umgekehrte Analyse auf diese Weise kann einerseits über die HOOK-JNI-Schnittstelle erreicht werden und verfügt über zwei Implementierungsmethoden.

Eine ist die Schnittstelle, die sich auf den Betrieb von Klassenmitgliedern/statischen Variablen bezieht, wie zum Beispiel:

GetStaticDoubleFieldSetStaticDoubleField GetDoubleField SetDoubleField…

(Byte, Objekt, int, long…)

Die zweite ist die Reflexion, die Klassenmethoden aufruft, wie zum Beispiel :

CallVoidMethodACallBooleanMethodA CallShortMethodA CallObjectMethodA …

CallStaticVoidMethodACallStaticBooleanMethodA CallStaticShortMethodA CallStaticObjectMethodA …

CallObjectMe thodA(JNIEnv* env, jobject object, jmethoID method, …)

Implementieren Sie eine virtuelle Maschine über die HOOKJNI-Schnittstelle Verstärkte Reverse-Analyse

Verwenden Sie die HOOK-JNI-Schnittstelle, um den ungefähren Aufrufprozess der APP zu verstehen, ohne dass ein zugrunde liegendes Reverse Engineering erforderlich ist. Bei komplexen Aufrufprozessen oder bei einer großen Anzahl von Virtualisierungsmethoden erscheint diese umgekehrte Analysemethode jedoch verwirrend für Anweisungen, die zur Ausführung nicht in die Java-Schicht zurückgespiegelt werden müssen, wie z. B. arithmetische und logische Operationen. es kann nicht überwacht werden.

Umgekehrte Analyse der Härtung virtueller Maschinen – Analyse der Befehls-Opcode-Zuordnung

Andererseits kann eine umgekehrte Analyse auch durch Analyse der Befehls-Opcode-Zuordnung durchgeführt werden. Die folgenden Methoden können angewendet werden, wenn dieselbe Härtungsversion oder Zuordnungsbeziehung verwendet wird: 🎜In tatsächlichen Situationen ändert sich jedoch die Zuordnungsbeziehung zwischen den einzelnen Bewehrungen zufällig. Wie unten gezeigt, kann die Zuordnungsbeziehung in diesem Fall nicht direkt hergestellt werden.

                                                                                                                                                                               Die Zuordnungsbeziehung, die nicht vom Opcode abhängt, bezieht sich nur auf die Struktur der virtuellen Maschine. Daher muss die Zuordnungsbeziehung basierend auf der Offset-Beziehung hergestellt werden, um eine umgekehrte Analyse durchzuführen.

                                                   

Das obige ist der detaillierte Inhalt vonWas ist der umgekehrte Analyse- und Schutzmechanismus der Android-App?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!