Android-App-Struktur

Eine Android-App wird als APK (Android Package) ausgeliefert. Dabei handelt es sich eigentlich um ein ZIP-Archiv, das den kompilierten Code, Ressourcen und Metadaten enthält.

Da es sich um eine ZIP-Datei handelt, können Sie sie einfach entpacken und ihren Inhalt untersuchen. Dies ist der erste Schritt beim Mobile Pentesting.

Eine extrahierte APK enthält:

• AndroidManifest.xml: App-Konfiguration.
• classes.dex: kompilierter Bytecode.
• res/ und resources.arsc: Ressourcen.
• lib/: native Bibliotheken.
• META-INF/: Informationen zur Signierung.

Die Datei AndroidManifest.xml deklariert die Komponenten, Berechtigungen und Konfiguration der App. In der APK liegt sie in einer binären XML-Form vor, die von Werkzeugen dekodiert werden kann.

Sie ist die wichtigste einzelne Datei, um die Angriffsfläche einer App zu verstehen.

Java-/Kotlin-Quellcode wird in DEX-Bytecode (Dalvik Executable) in classes.dex kompiliert. Moderne Android-Systeme führen ihn über ART (Android Runtime) aus.

DEX kann wieder in Richtung lesbaren Code konvertiert werden. Dies macht sich die statische Analyse von APKs zunutze.

Android-Apps bestehen aus vier Komponententypen:

• Activities: Bildschirme bzw. Benutzeroberflächen.
• Services: Hintergrundaufgaben.
• Broadcast Receivers: reagieren auf Systemereignisse.
• Content Providers: teilen Daten zwischen Apps.

Eine mit android:exported="true" markierte Komponente kann von anderen Apps aufgerufen werden. Führt eine solche Komponente ohne Prüfungen sensible Aktionen aus, stellt sie eine Angriffsfläche dar.

Pentester suchen nach exportierten Activities, Services und Providern, die Daten preisgeben oder privilegierte Aktionen ausführen.

Apps fordern Berechtigungen im Manifest an (zum Beispiel INTERNET, READ_SMS, ACCESS_FINE_LOCATION).

Zu weit gefasste Berechtigungen deuten auf riskantes Verhalten oder übermäßigen Datenzugriff hin. Auch benutzerdefinierte Berechtigungen können falsch konfiguriert sein und unbefugten Zugriff ermöglichen.

Android isoliert jede App in einer eigenen Sandbox mit einer eindeutigen Linux-UID. Standardmäßig können Apps nicht auf die Daten anderer Apps zugreifen.

Schwachstellen entstehen, wenn Apps diese Grenze abschwächen, etwa durch weltweit lesbare Dateien oder offengelegte Provider.

Eine installierte App speichert private Daten unter /data/data/<package>/: Datenbanken, gemeinsame Einstellungen und Dateien.

Auf einem gerooteten Gerät oder über Sicherungskopien untersucht ein Pentester dieses Verzeichnis auf unsicher gespeicherte Geheimnisse. Dies wird in einem späteren Kapitel behandelt.

Jede APK ist digital signiert; die Signatur befindet sich in META-INF/. Android überprüft sie bei der Installation und bei Updates.

Wenn Sie eine App ändern und neu verpacken, müssen Sie sie erneut signieren. Deshalb verlassen sich Entwickler auf die Signierung, um Manipulationen zu erkennen.

Leistungskritische oder verschleierte Logik kann in nativen Bibliotheken (.so-Dateien) unter lib/ liegen, die aus C/C++ kompiliert wurden.

Diese befinden sich nicht in DEX und erfordern daher eine separate Analyse mit nativen Disassemblern. Entwickler verstecken hier manchmal Geheimnisse, weil sie fälschlicherweise glauben, nativer Code sei schwerer zu untersuchen.

Rufen Sie sich ins Gedächtnis, welches Manifest-Attribut eine Komponente für andere Apps sichtbar macht.

Sie verstehen nun die Struktur von Android-Apps:

• Eine APK ist eine ZIP-Datei mit AndroidManifest.xml, classes.dex, Ressourcen und Signierungsdaten.
• Apps verwenden vier Komponenten; exportierte Komponenten stellen eine Angriffsfläche dar.
• Berechtigungen und die app-eigene Sandbox regeln den Zugriff. Private Daten befinden sich unter /data/data/.
• APKs werden signiert, um Manipulationen zu erkennen.

Als Nächstes dekompilieren Sie eine APK im Rahmen der statischen Analyse.