1. Einführung
2. Grundlagen der Android-Anwendung
3. Einstieg in das Reverse-Engineering von Android-Apps
   • Übung 1
4. Reverse-Engineering von Android-Apps. DEX Bytecode
   • Übung 2
   • Übung 3
   • Übung 4
5. Reverse Engineering von Android Apps – Native Bibliotheken
   • Übung 5
   • Übung 6
6. Reverse Engineering von Android-Apps – Obfuscation
   • Übung 7
7. Abschluss

Build an App

Einer meiner wichtigsten Ratschläge für Leute, die Dinge zurückentwickeln wollen, was auch immer es sein mag, ist zu versuchen, das zu bauen, was man nachbauen will. Im Falle von Android haben Sie Glück, denn es gibt so viele kostenlose Ressourcen, mit denen Sie Ihre erste Anwendung erstellen können. Wenn Sie noch nie eine Android-Anwendung erstellt haben, schlage ich vor, dass Sie dort anfangen. Suchen Sie sich eines der verfügbaren Tutorials und Videos aus, das Ihr Interesse weckt, und beginnen Sie mit der Erstellung. Wenn du verstehst, wie ein Entwickler etwas baut, ist es viel einfacher zu verstehen, wie man es zurückentwickelt.

Grundlagenübersicht

Gut! Du hast eine App gebaut oder die Grundlagen der Android-App-Entwicklung gelernt. Hier ist ein Überblick über einige der wichtigen Punkte. Diese Seite „Application Fundamentals“ in den Android-Entwicklerdokumenten ist eine gute Übersicht.

• Android-Anwendungen liegen im APK-Dateiformat vor. APK ist im Grunde eine ZIP-Datei. (Sie können die Dateierweiterung in .zip umbenennen und unzip verwenden, um den Inhalt zu öffnen und zu sehen.)
• APK-Inhalt (nicht vollständig)
  • AndroidManifest.xml
  • META-INF/
    • Das Zertifikat befindet sich hier!
  • classes.dex
    • Dalvik Bytecode für die Anwendung im DEX-Dateiformat. Dies ist der Java- (oder Kotlin-) Code, den die Anwendung standardmäßig ausführen wird.
  • lib/
    • Native Bibliotheken für die Anwendung befinden sich standardmäßig hier! Unter dem Verzeichnis lib/ befinden sich die cpu-spezifischen Verzeichnisse. Z.B.: armeabi, mips,
  • assets/
    • Alle anderen Dateien, die von der Anwendung benötigt werden können.
    • Zusätzliche native Bibliotheken oder DEX-Dateien können hier enthalten sein. Dies kann vor allem dann der Fall sein, wenn Malware-Autoren versuchen, zusätzlichen Code (nativ oder Dalvik) zu „verstecken“, indem sie ihn nicht an den Standardspeicherorten einfügen.

Dalvik & Smali

Die meisten Android-Anwendungen sind in Java geschrieben. Kotlin wird ebenfalls unterstützt und ist mit Java interoperabel. Wenn ich im weiteren Verlauf dieses Workshops von „Java“ spreche, können Sie davon ausgehen, dass ich „Java oder Kotlin“ meine. Anstatt dass der Java-Code wie bei Desktop-Anwendungen in der Java Virtual Machine (JVM) ausgeführt wird, wird Java in Android in das Dalvik Executable (DEX) Bytecode-Format kompiliert. Bei früheren Android-Versionen wurde der Bytecode von der virtuellen Dalvik-Maschine übersetzt. Bei neueren Android-Versionen wird die Android Runtime (ART) verwendet.
Wenn Entwickler in Java schreiben und der Code in DEX-Bytecode kompiliert wird, arbeiten wir beim Reverse Engineering in die entgegengesetzte Richtung.

Smali ist die für Menschen lesbare Version von Dalvik Bytecode. Technisch gesehen sind Smali und baksmali die Namen der Tools (Assembler bzw. Disassembler), aber in Android verwenden wir oft den Begriff „Smali“, um uns auf Anweisungen zu beziehen. Wenn Sie sich mit Reverse Engineering oder Computerarchitektur an kompiliertem C/C++-Code befasst haben. SMALI ist wie der Assembler: zwischen dem höheren Quellcode und dem Bytecode.

Für den folgenden Hello World Java Code:

public static void printHelloWorld() {System.out.println("Hello World")}

Der Smali Code wäre:

.method public static printHelloWorld()V.registers 2sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;const-string v1, "Hello World"invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)Vreturn-void.end method

Der Smali Befehlssatz ist hier verfügbar.

In den meisten Fällen, in denen Sie Android-Anwendungen zurückentwickeln, müssen Sie nicht in Smali arbeiten. Die meisten Anwendungen können auf eine noch höhere Ebene gehoben werden, nämlich in dekompiliertes Java. Wie alle Tools können auch Java-Decompiler Fehler haben. Wenn die dekompilierte Java-Ausgabe fragwürdig aussieht, empfehle ich Ihnen, sich die Smali-Ausgabe anzusehen. Arbeiten Sie Zeile für Zeile mit der Befehlsreferenz, um herauszufinden, was der Code tut.

Um das Smali von DEX zu erhalten, können Sie das baksmali-Tool (Disassembler) verwenden, das unter https://github.com/JesusFreke/smali/wiki verfügbar ist. Das Smali-Tool ermöglicht es Ihnen, Smali zurück in DEX zu assemblieren.

Einstiegspunkte der Anwendung

Einer der wichtigsten Punkte beim Reverse Engineering ist es, zu wissen, wo man mit der Analyse beginnt, und Einstiegspunkte für die Codeausführung sind ein wichtiger Teil davon.

Startaktivität

Die Startaktivität ist das, was sich die meisten Leute als Einstiegspunkt in eine Android-Anwendung vorstellen. Die Launcher-Aktivität ist die Aktivität, die gestartet wird, wenn ein Benutzer auf das Symbol für eine Anwendung klickt. Sie können die Launcher-Aktivität bestimmen, indem Sie sich das Manifest der Anwendung ansehen. In der Startaktivität sind die folgenden MAIN- und LAUNCHER-Intents aufgeführt.

Denken Sie daran, dass nicht jede Anwendung eine Startaktivität hat, insbesondere Anwendungen ohne Benutzeroberfläche. Beispiele für Anwendungen ohne Benutzeroberfläche (und damit ohne Launcher-Aktivität) sind vorinstallierte Anwendungen, die Dienste im Hintergrund ausführen, wie z. B. Voicemail.

<activity android:name=".LauncherActivity"><intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter></activity>

Dienste

Dienste laufen im Hintergrund ohne Benutzeroberfläche. Es gibt eine Vielzahl von Möglichkeiten, wie sie gestartet werden können und somit einen Einstiegspunkt für Anwendungen darstellen. Der Standardweg, auf dem ein Dienst als Einstiegspunkt für eine Anwendung gestartet werden kann, ist über Intents.

Wenn die startService API aufgerufen wird, um einen Dienst zu starten, wird die onStart Methode im Dienst ausgeführt.

Broadcast-Empfänger

Broadcasts kann man sich als Messaging-System vorstellen und Broadcast-Empfänger sind die Zuhörer. Wenn eine Anwendung einen Empfänger für einen bestimmten Broadcast registriert hat, wird der Code in diesem Empfänger ausgeführt, wenn das System den Broadcast sendet. Es gibt zwei Möglichkeiten, wie eine Anwendung einen Empfänger registrieren kann: im Manifest der Anwendung oder dynamisch im Code der Anwendung mit dem registerReceiver() API-Aufruf.

In beiden Fällen werden zur Registrierung des Empfängers die Absichtsfilter für den Empfänger festgelegt. Diese Intent-Filter sind die Broadcasts, die den Empfänger auslösen sollen.

Wenn die spezifischen Broadcasts gesendet werden, für die der Empfänger registriert ist, wird onReceive in der BroadcastReceiver-Klasse ausgeführt.

Exportierte Komponenten (Dienste & Aktivitäten)

Dienste und Aktivitäten können auch „exportiert“ werden, was anderen Prozessen auf dem Gerät erlaubt, den Dienst zu starten oder die Aktivität zu starten. Die Komponenten werden exportiert, indem ein Element im Manifest wie unten angegeben wird. Standardmäßig android:exported="false", es sei denn, dieses Element ist im Manifest auf true gesetzt oder es sind Intent-Filter für die Activity oder den Service definiert.

<service android:name=".ExampleExportedService" android:exported="true"/><activity android:name=".ExampleExportedActivity" android:exported="true"/>

Anwendungsunterklasse

Android-Anwendungen können eine Unterklasse von Application definieren. Anwendungen können, müssen aber nicht eine eigene Unterklasse von Application definieren. Wenn eine Android-Anwendung eine Unterklasse von Application definiert, wird diese Klasse vor jeder anderen Klasse in der Anwendung instanziiert.

Wenn die Methode attachBaseContext in der Unterklasse von Application definiert ist, wird sie zuerst aufgerufen, vor der Methode onCreate.

NEXT > 3. Erste Schritte mit der Umkehrung von Android-Apps