Android-Anwendungen Pentesting

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Android-Anwendungen Grundlagen

Es wird dringend empfohlen, diese Seite zuerst zu lesen, um die wichtigsten Bereiche in Bezug auf Android-Sicherheit und die gefährlichsten Komponenten einer Android-Anwendung zu kennen:

Android Applications Basics

ADB (Android Debug Bridge)

Dies ist das Haupttool, mit dem Sie ein Android-Gerät (emuliert oder physisch) verbinden können.
ADB ermöglicht die Steuerung von Geräten entweder über USB oder Network von einem Computer aus. Dieses Hilfsmittel erlaubt das Kopieren von Dateien in beide Richtungen, die Installation und Deinstallation von Apps, die Ausführung von Shell-Befehlen, das Sichern von Daten, das Lesen von logs, sowie weitere Funktionen.

Sieh dir die folgende Liste der ADB Commands an, um zu lernen, wie man adb verwendet.

Smali

Manchmal ist es interessant, den Anwendungscode zu ändern, um auf versteckte Informationen zuzugreifen (z. B. stark obfuskierte Passwörter oder flags). Dann kann es sinnvoll sein, die apk zu dekompilieren, den Code zu ändern und sie neu zu kompilieren.
In this tutorial you can learn how to decompile and APK, modify Smali code and recompile the APK with the new functionality. Dies kann sehr nützlich sein als Alternative für mehrere Tests während der dynamischen Analyse, die präsentiert werden. Behalte also immer diese Möglichkeit im Hinterkopf.

Weitere interessante Tricks

adb shell pm list packages
com.android.insecurebankv2

adb shell pm path com.android.insecurebankv2
package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk

adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
  • Alle splits und base apks mit APKEditor zusammenführen:
mkdir splits
adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
java -jar ../APKEditor.jar m -i splits/ -o merged.apk

# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed

Jezail rooted Android pentesting toolkit (REST API + web UI)

  • Läuft auf einem gerooteten Gerät (Magisk/rootAVD) und startet einen HTTP server on tcp/8080 mit einer Flutter web UI und REST API.
  • Installiere das Release-APK mit Berechtigungen: adb install -g -r jezail.apk, und starte dann die App (der Server startet automatisch).
  • Endpoints: http://<device-ip>:8080/ (UI), http://<device-ip>:8080/api/json (API listing), http://<device-ip>:8080/api/swagger (Swagger).
  • Emulator port-forward, um UI/API vom Host zu erreichen: adb forward tcp:8080 tcp:8080 und dann http://localhost:8080 im Browser öffnen.

Android Enterprise & Work Profile Attacks

Android Enterprise Work Profile Bypass

Case Studies & Vulnerabilities

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Abusing Android Media Pipelines Image Parsers

Firmware Level Zygote Backdoor Libandroid Runtime

Static Analysis

Zuerst solltest du für die Analyse einer APK den Java-Code mit einem Decompiler ansehen.
Bitte, lies hier für Informationen über verschiedene verfügbare Decompiler.

Looking for interesting Info

Allein durch das Betrachten der strings der APK kannst du nach Passwörtern, URLs (https://github.com/ndelphit/apkurlgrep), api keys, encryption, bluetooth uuids, tokens und allem Interessanten suchen… achte auch auf Codeausführungs- Backdoors oder Authentifizierungs-Backdoors (hartkodierte Admin-Credentials in der App).

Firebase

Achte besonders auf firebase URLs und prüfe, ob sie schlecht konfiguriert sind. Mehr Informationen darüber, was Firebase ist und wie man es ausnutzen kann, hier.

Basic understanding of the application - Manifest.xml, strings.xml

Die Untersuchung der Manifest.xml und der strings.xml einer Anwendung kann potenzielle Sicherheitslücken offenbaren. Auf diese Dateien kann mittels Decompiler zugegriffen werden oder indem man die APK-Endung in .zip ändert und sie entpackt.

Vulnerabilities identifiziert aus der Manifest.xml sind unter anderem:

  • Debuggable Applications: Anwendungen, die im Manifest.xml mit debuggable="true" markiert sind, stellen ein Risiko dar, da sie Verbindungen erlauben, die zu Exploits führen können. Für ein besseres Verständnis, wie man Debuggable Applications ausnutzt, siehe ein Tutorial zum Finden und Exploiten von debuggable Applications auf einem Gerät.
  • Backup Settings: Das Attribut android:allowBackup="false" sollte explizit für Anwendungen gesetzt werden, die mit sensiblen Informationen arbeiten, um unautorisierte Daten-Backups via adb zu verhindern, insbesondere wenn USB-Debugging aktiviert ist.
  • Network Security: Benutzerdefinierte Netzwerksicherheitskonfigurationen (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ können Sicherheitsdetails wie Certificate Pins und HTTP-Traffic-Einstellungen spezifizieren. Ein Beispiel ist das Erlauben von HTTP-Traffic für bestimmte Domains.
  • Exported Activities and Services: Das Identifizieren von exportierten Activities und Services im Manifest kann Komponenten aufzeigen, die missbraucht werden könnten. Weitere Analysen während dynamischer Tests können offenbaren, wie diese Komponenten ausgenutzt werden.
  • Content Providers and FileProviders: Offen zugängliche Content Provider könnten unautorisierte Zugriffe oder Änderungen an Daten erlauben. Die Konfiguration von FileProviders sollte ebenfalls genau überprüft werden.
  • Broadcast Receivers and URL Schemes: Diese Komponenten könnten für Exploits genutzt werden, wobei besonderes Augenmerk auf die Art und Weise gelegt werden sollte, wie URL-Schemes auf Eingaben reagieren.
  • SDK Versions: Die Attribute minSdkVersion, targetSDKVersion und maxSdkVersion geben die unterstützten Android-Versionen an und unterstreichen die Bedeutung, veraltete, verwundbare Android-Versionen nicht zu unterstützen.

Aus der strings.xml-Datei können sensible Informationen wie API-Keys, Custom Schemas und andere Entwicklerhinweise entdeckt werden, was die Notwendigkeit einer sorgfältigen Überprüfung dieser Ressourcen unterstreicht.

Tapjacking

Tapjacking ist ein Angriff, bei dem eine bösartige application gestartet wird und sich über eine Opfer-Anwendung legt. Sobald sie die Opfer-App sichtbar überlagert, ist ihre Benutzeroberfläche so gestaltet, dass der Benutzer zur Interaktion verleitet wird, während die Interaktion an die Opfer-App weitergegeben wird.
Effektiv blendet sie den Benutzer aus, so dass er nicht weiß, dass er tatsächlich Aktionen in der Opfer-App ausführt.

Weitere Informationen findest du in:

Tapjacking

Task Hijacking

Eine activity mit launchMode auf singleTask gesetzt und ohne definierte taskAffinity ist für Task Hijacking verwundbar. Das bedeutet, dass eine application installiert werden kann und, wenn sie vor der echten Anwendung gestartet wird, die Task der echten Anwendung übernehmen kann (so wird der Benutzer mit der bösartigen Anwendung interagieren und denken, er benutze die echte).

Mehr Infos in:

Android Task Hijacking

Insecure data storage

Internal Storage

In Android sind Dateien, die im internal storage gespeichert werden, so konzipiert, dass sie ausschließlich von der App, die sie erstellt hat, zugänglich sind. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem durchgesetzt und ist in den meisten Fällen ausreichend. Entwickler nutzen jedoch manchmal Modi wie MODE_WORLD_READABLE und MODE_WORLD_WRITABLE, um Dateien zwischen verschiedenen Anwendungen zu teilen. Diese Modi beschränken den Zugriff nicht und können somit auch von potenziell bösartigen Anwendungen genutzt werden.

  1. Static Analysis:
  • Stelle sicher, dass die Verwendung von MODE_WORLD_READABLE und MODE_WORLD_WRITABLE sorgfältig geprüft wird. Diese Modi können Dateien unbeabsichtigt oder unautorisiert zugänglich machen.
  1. Dynamic Analysis:
  • Überprüfe die Berechtigungen auf Dateien, die von der App erstellt wurden. Insbesondere prüfe, ob Dateien weltweit lesbar oder schreibbar gesetzt sind. Das stellt ein erhebliches Sicherheitsrisiko dar, da jede installierte Anwendung, unabhängig von Herkunft oder Absicht, diese Dateien lesen oder ändern könnte.

External Storage

Beim Umgang mit Dateien im external storage, wie z. B. SD-Karten, sollten bestimmte Vorsichtsmaßnahmen getroffen werden:

  1. Zugänglichkeit:
  • Dateien auf external storage sind global lesbar und schreibbar. Das bedeutet, jede Anwendung oder jeder Benutzer kann auf diese Dateien zugreifen.
  1. Sicherheitsbedenken:
  • Aufgrund des einfachen Zugriffs wird empfohlen, keine sensiblen Informationen auf external storage zu speichern.
  • External storage kann entfernt oder von jeder Anwendung zugänglich gemacht werden, wodurch es weniger sicher ist.
  1. Umgang mit Daten von external storage:
  • Führe immer Input-Validierung auf Daten durch, die von external storage geladen werden. Das ist wichtig, weil diese Daten aus einer nicht vertrauenswürdigen Quelle stammen.
  • Das Speichern von ausführbaren Dateien oder class-Dateien auf external storage zum dynamischen Laden wird dringend abgeraten.
  • Falls deine Anwendung ausführbare Dateien aus external storage laden muss, stelle sicher, dass diese Dateien signiert und kryptografisch verifiziert sind, bevor sie dynamisch geladen werden. Dieser Schritt ist wesentlich für die Erhaltung der Sicherheitsintegrität deiner Anwendung.

External storage kann in /storage/emulated/0 , /sdcard , /mnt/sdcard accessed werden.

Tip

Ab Android 4.4 (API 17) hat die SD-Karte eine Verzeichnisstruktur, die den Zugriff einer App auf das Verzeichnis beschränkt, das speziell für diese App vorgesehen ist. Das verhindert, dass eine bösartige Anwendung Lese- oder Schreibzugriff auf die Dateien einer anderen App erhält.

Sensitive data stored in clear-text

  • Shared preferences: Android erlaubt jeder Anwendung, XML-Dateien im Pfad /data/data/<packagename>/shared_prefs/ zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.
  • Databases: Android erlaubt jeder Anwendung, sqlite-Datenbanken im Pfad /data/data/<packagename>/databases/ zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.

Broken TLS

Accept All Certificates

Aus irgendeinem Grund akzeptieren Entwickler manchmal alle Zertifikate, selbst wenn z. B. der Hostname nicht übereinstimmt, mit Codezeilen wie der folgenden:

SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Eine gute Methode, dies zu testen, ist zu versuchen, den Traffic mit einem Proxy wie Burp abzufangen, ohne das Burp CA auf dem Gerät zu autorisieren. Außerdem kannst du mit Burp ein Zertifikat für einen anderen Hostnamen erzeugen und verwenden.

Fehlerhafte Kryptographie

Schlechte Schlüsselverwaltungsprozesse

Einige Entwickler speichern sensible Daten im lokalen Storage und verschlüsseln sie mit einem im Code hartkodierten/vorhersehbaren Schlüssel. Das sollte nicht gemacht werden, da ein reversing Angreifern ermöglichen könnte, die vertraulichen Informationen zu extrahieren.

Verwendung unsicherer und/oder veralteter Algorithmen

Entwickler sollten keine deprecated algorithms verwenden, um Authorisation checks durchzuführen, Daten zu store oder zu send. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1… Wenn hashes z. B. zum Speichern von Passwörtern verwendet werden, sollten brute-force-resistente Hashes mit Salt eingesetzt werden.

Weitere Prüfungen

  • Es wird empfohlen, das APK zu obfuskieren, um die Arbeit von Reverse-Engineers für Angreifer zu erschweren.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie eigene Prüfungen durchführen, um festzustellen, ob das mobile Gerät gerootet ist, und entsprechend reagieren.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie prüfen, ob ein emulator verwendet wird.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie vor der Ausführung ihre eigene Integrität prüfen, um festzustellen, ob sie modifiziert wurde.
  • Verwende APKiD um zu prüfen, welcher Compiler/ Packer/ Obfuscator zum Erstellen des APK verwendet wurde

React Native Application

Lies die folgende Seite, um zu lernen, wie man einfach auf den JavaScript-Code von React-Anwendungen zugreift:

React Native Application

Xamarin Applications

Lies die folgende Seite, um zu lernen, wie man einfach auf den C#-Code einer Xamarin-Anwendung zugreift:

Xamarin Apps

Superpacked Applications

Laut diesem blog post ist superpacked ein Meta-Algorithmus, der den Inhalt einer Anwendung in eine einzelne Datei komprimiert. Der Blog beschreibt die Möglichkeit, eine App zu erstellen, die diese Art von Apps dekomprimiert… und eine schnellere Methode, die darin besteht, die Anwendung auszuführen und die dekomprimierten Dateien aus dem Dateisystem zu sammeln.

Automatisierte statische Code-Analyse

Das Tool mariana-trench ist in der Lage, Schwachstellen zu finden, indem es den Code der Anwendung scannt. Dieses Tool enthält eine Reihe von known sources (die dem Tool die Stellen anzeigen, an denen die Eingabe vom Benutzer kontrolliert wird), sinks (die dem Tool gefährliche Stellen anzeigen, an denen bösartige Benutzereingaben Schaden verursachen könnten) und rules. Diese Regeln geben Kombinationen von sources-sinks an, die auf eine Schwachstelle hinweisen.

Mit diesem Wissen wird mariana-trench den Code prüfen und mögliche Schwachstellen darin finden.

Secrets leaked

Eine Anwendung kann Secrets (API keys, Passwörter, versteckte urls, Subdomains…) in sich enthalten, die du möglicherweise entdecken kannst. Du könntest ein Tool wie https://github.com/dwisiswant0/apkleaks verwenden

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Weitere interessante Funktionen

  • Code execution: Runtime.exec(), ProcessBuilder(), native code:system()
  • Send SMSs: sendTextMessage, sendMultipartTestMessage
  • Native functions deklariert als native: public native, System.loadLibrary, System.load
  • Read this to learn how to reverse native functions
  • In-memory native code execution via JNI (downloaded shellcode → mmap/mprotect → call):

In Memory Jni Shellcode Execution

Other tricks

content:// protocol

Dynamische Analyse

Zunächst brauchst du eine Umgebung, in der du die Anwendung und die gesamte Umgebung (Burp CA cert, Drozer und Frida hauptsächlich) installieren kannst. Daher wird ein gerootetes Gerät (emuliert oder nicht) dringend empfohlen.

Online Dynamische Analyse

Du kannst ein kostenloses Konto bei: https://appetize.io/ erstellen. Diese Plattform erlaubt es, APKs hochzuladen und auszuführen, daher ist sie nützlich, um zu sehen, wie sich ein apk verhält.

Du kannst sogar die Logs deiner Anwendung im Web sehen und dich über adb verbinden.

Dank der ADB-Verbindung kannst du Drozer und Frida innerhalb der Emulatoren nutzen.

Lokale dynamische Analyse

Verwendung eines Emulators

  • Android Studio (Du kannst x86- und arm-Geräte erstellen, und laut diesem unterstützen neuere x86-Versionen ARM-Bibliotheken ohne einen langsamen ARM-Emulator).
  • Lerne, wie du es auf dieser Seite einrichtest:

AVD - Android Virtual Device

  • Genymotion (kostenlose Version: Personal Edition, du musst ein Konto erstellen. Es wird empfohlen, die Version MIT VirtualBox herunterzuladen, um mögliche Fehler zu vermeiden.)
  • Nox (kostenlos, unterstützt aber kein Frida oder Drozer).

Tip

Beim Erstellen eines neuen Emulators auf einer beliebigen Plattform denke daran, dass je größer der Bildschirm ist, desto langsamer der Emulator läuft. Wähle daher wenn möglich kleinere Bildschirme aus.

Um in Genymotion google services (wie AppStore) zu installieren, musst du auf die rot markierte Schaltfläche im folgenden Bild klicken:

Beachte auch, dass du in der Konfiguration der Android-VM in Genymotion den Bridge Network mode auswählen kannst (das ist nützlich, wenn du dich von einer anderen VM mit den Tools mit der Android-VM verbinden willst).

Verwendung eines physischen Geräts

Du musst die Entwickleroptionen aktivieren und es ist vorteilhaft, wenn du es rootest:

  1. Einstellungen.
  2. (Ab Android 8.0) Wähle System.
  3. Wähle Über das Telefon.
  4. Drücke Build number 7 Mal.
  5. Gehe zurück und du findest die Developer options.

Sobald du die Anwendung installiert hast, sollte das Erste, was du tun solltest, sein, sie auszuprobieren, zu untersuchen, was sie tut, wie sie funktioniert und dich mit ihr vertraut zu machen.
Ich empfehle, diese anfängliche dynamische Analyse mit MobSF dynamic analysis + pidcat durchzuführen, damit wir lernen, wie die Anwendung funktioniert, während MobSF viele interessante Daten erfasst, die du später überprüfen kannst.

Magisk/Zygisk Quick Notes (empfohlen auf Pixel-Geräten)

  • Patch das boot.img mit der Magisk App und flashe es via fastboot, um systemless root zu erhalten
  • Aktiviere Zygisk + DenyList zum Verstecken von Root; ziehe LSPosed/Shamiko in Betracht, wenn stärkere Versteckmethoden benötigt werden
  • Bewahre das originale boot.img auf, um dich von OTA-Updates zu erholen; patch es nach jedem OTA erneut
  • Für Screen-Mirroring verwende scrcpy auf dem Host

Unbeabsichtigte Data Leakage

Logging

Entwickler sollten vorsichtig sein, debug-Informationen öffentlich zugänglich zu machen, da dies zu sensiblen Daten leaks führen kann. Die Tools pidcat und adb logcat werden empfohlen, um Anwendungslogs zu überwachen und sensible Informationen zu identifizieren und zu schützen. Pidcat wird wegen seiner Benutzerfreundlichkeit und Lesbarkeit bevorzugt.

Warning

Beachte, dass seit späteren Versionen als Android 4.0 Anwendungen nur noch auf ihre eigenen Logs zugreifen können. Anwendungen können also nicht auf die Logs anderer Apps zugreifen.
Trotzdem wird empfohlen, keine sensiblen Informationen zu loggen.

Copy/Paste Buffer Caching

Das clipboard-basierte Framework von Android ermöglicht Copy-Paste-Funktionen in Apps, birgt jedoch das Risiko, dass andere Anwendungen auf die Zwischenablage zugreifen können und dadurch sensible Daten exponiert werden. Es ist wichtig, Copy/Paste-Funktionen für sensible Bereiche einer Anwendung wie Kreditkartendaten zu deaktivieren, um Daten leaks zu verhindern.

Crash Logs

Wenn eine Anwendung crasht und Logs speichert, können diese Logs Angreifern helfen, insbesondere wenn die Anwendung nicht reverse-engineered werden kann. Zur Minderung dieses Risikos sollte man vermeiden, bei Abstürzen zu loggen, und falls Logs über das Netzwerk versendet werden müssen, sicherstellen, dass sie über einen SSL-Kanal übertragen werden.

Als pentester, versuche, einen Blick auf diese Logs zu werfen.

Analytics Data Sent To 3rd Parties

Anwendungen integrieren oft Dienste wie Google Adsense, die unbeabsichtigt sensible Daten leak können, wenn Entwickler sie falsch implementieren. Um mögliche Daten leaks zu identifizieren, ist es ratsam, den Traffic der Anwendung abzufangen und zu prüfen, ob sensible Informationen an Drittanbieter gesendet werden.

SQLite DBs

Die meisten Anwendungen verwenden interne SQLite-Datenbanken, um Informationen zu speichern. Untersuche während des pentests die erstellten Datenbanken, die Namen der Tables und Columns sowie alle gespeicherten Daten, da du dort sensible Informationen finden könntest (was eine Schwachstelle wäre).
Datenbanken sollten sich in /data/data/the.package.name/databases befinden, z. B. /data/data/com.mwr.example.sieve/databases

Wenn die Datenbank vertrauliche Informationen speichert und verschlüsselt ist, du aber das Passwort innerhalb der Anwendung finden kannst, ist das trotzdem eine Vulnerability.

Liste die Tabellen mit .tables auf und ermittle die Spalten der Tabellen mit .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

Aus den Drozer Docs: Drozer erlaubt es dir, die Rolle einer Android-App anzunehmen und mit anderen Apps zu interagieren. Es kann alles tun, was eine installierte Anwendung tun kann, wie z. B. Androids Inter-Process Communication (IPC)-Mechanismus nutzen und mit dem zugrunde liegenden Betriebssystem interagieren.
Drozer ist ein nützliches Tool, um exported activities, exported services und Content Providers zu exploitieren, wie du in den folgenden Abschnitten lernen wirst.

Exploiting exported Activities

Read this if you want to refresh what is an Android Activity.
Denke auch daran, dass der Code einer Activity in der onCreate-Methode startet.

Authorisation bypass

Wenn eine Activity exported ist, kannst du ihren Bildschirm von einer externen App aus aufrufen. Daher, wenn eine Activity mit sensitive information exported ist, könntest du die authentication-Mechanismen umgehen, um darauf zuzugreifen.

Learn how to exploit exported activities with Drozer.

Du kannst eine exportierte Activity auch von adb aus starten:

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
adb shell am start -n com.example.demo/com.example.test.MainActivity

HINWEIS: MobSF wird die Verwendung von singleTask/singleInstance als android:launchMode in einer activity als bösartig erkennen, aber aufgrund this, scheint dies offenbar nur auf alten Versionen (API versions < 21) gefährlich zu sein.

Tip

Beachte, dass ein authorisation bypass nicht immer eine Sicherheitslücke ist; das hängt davon ab, wie der bypass funktioniert und welche Informationen offengelegt werden.

Offenlegung sensibler Informationen

Activities können auch Ergebnisse zurückgeben. Wenn es dir gelingt, eine exportierte und ungeschützte activity zu finden, die die Methode setResult aufruft und sensible Informationen zurückgibt, liegt eine Offenlegung sensibler Informationen vor.

Tapjacking

Wenn Tapjacking nicht verhindert wird, könntest du die exportierte activity missbrauchen, um den Benutzer dazu zu bringen, unerwartete Aktionen auszuführen. Für mehr Infos über what is Tapjacking follow the link.

Exploiting Content Providers - Accessing and manipulating sensitive information

Read this if you want to refresh what is a Content Provider.
Content Providers werden im Wesentlichen verwendet, um Daten zu teilen. Wenn eine App Content Providers bereitstellt, kannst du möglicherweise vertrauliche Daten daraus extrahieren. Es ist auch interessant, mögliche SQL injections und Path Traversals zu testen, da diese verwundbar sein könnten.

Learn how to exploit Content Providers with Drozer.

Exploiting Services

Read this if you want to refresh what is a Service.
Denke daran, dass die Aktionen eines Service in der Methode onStartCommand beginnen.

Ein Service ist im Grunde etwas, das Daten empfangen, verarbeiten und (optional) eine Antwort zurückgeben kann. Wenn eine Anwendung also Dienste exportiert, solltest du den Code prüfen, um zu verstehen, was er tut, und ihn dynamisch testen, um vertrauliche Informationen zu extrahieren, Authentifizierungsmaßnahmen zu umgehen…

Learn how to exploit Services with Drozer.

Exploiting Broadcast Receivers

Read this if you want to refresh what is a Broadcast Receiver.
Denke daran, dass die Aktionen eines Broadcast Receiver in der Methode onReceive beginnen.

Ein Broadcast Receiver wartet auf eine bestimmte Art von Nachricht. Je nachdem, wie der Receiver die Nachricht verarbeitet, könnte er verwundbar sein.
Learn how to exploit Broadcast Receivers with Drozer.

Exploiting Schemes / Deep links

Du kannst manuell nach deep links suchen, Tools wie MobSF oder Skripte wie this one verwenden.
Du kannst ein deklariertes scheme mit adb oder einem Browser öffnen:

adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]

Beachte, dass du den package name weglassen kannst und das Mobilgerät automatisch die App aufruft, die diesen Link öffnen sollte.

<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>

Ausgeführter Code

Um den Code zu finden, der in der App ausgeführt wird, gehe zur Activity, die vom deeplink aufgerufen wird, und suche nach der Funktion onNewIntent.

Sensitive Informationen

Jedes Mal, wenn du einen deep link findest, überprüfe, dass er keine sensiblen Daten (wie Passwörter) über URL-Parameter empfängt, denn jede andere Anwendung könnte den deep link imitieren und diese Daten stehlen!

Parameter im Pfad

Du musst auch prüfen, ob ein deep link einen Parameter im Pfad der URL verwendet, z. B.: https://api.example.com/v1/users/{username}, in diesem Fall kannst du ein path traversal erzwingen, indem du auf etwas wie example://app/users?username=../../unwanted-endpoint%3fparam=value zugreifst.
Beachte, dass, wenn du die korrekten Endpunkte in der Anwendung findest, du möglicherweise ein Open Redirect verursachen kannst (wenn ein Teil des Pfads als Domainname verwendet wird), eine account takeover (wenn du Benutzerdetails ohne CSRF-Token ändern kannst und der vuln Endpunkt die richtige Methode verwendet hat) und jede andere vuln. Mehr Info dazu hier.

Weitere Beispiele

Ein interessanter bug bounty report über Links (/.well-known/assetlinks.json).

Inspektion der Transportschicht und Verifikationsfehler

  • Zertifikate werden nicht immer korrekt überprüft von Android-Anwendungen. Es ist üblich, dass diese Anwendungen Warnungen ignorieren und selbstsignierte Zertifikate akzeptieren oder in einigen Fällen auf HTTP-Verbindungen zurückfallen.
  • Die Aushandlungen während des SSL/TLS-Handshakes sind manchmal schwach, es werden unsichere Cipher Suites verwendet. Diese Schwachstelle macht die Verbindung anfällig für man-in-the-middle (MITM)-Angriffe und ermöglicht es Angreifern, die Daten zu entschlüsseln.
  • Leakage of private information stellt ein Risiko dar, wenn Anwendungen sich über sichere Kanäle authentifizieren, anschließend aber für andere Transaktionen über unsichere Kanäle kommunizieren. Dieser Ansatz schützt sensible Daten, wie Session-Cookies oder Benutzerdetails, nicht vor Abfangversuchen durch bösartige Akteure.

Certificate Verification

Wir konzentrieren uns auf die Zertifikatüberprüfung. Die Integrität des Serverzertifikats muss überprüft werden, um die Sicherheit zu erhöhen. Das ist entscheidend, da unsichere TLS-Konfigurationen und die Übertragung sensibler Daten über unverschlüsselte Kanäle erhebliche Risiken darstellen können. Für detaillierte Schritte zur Überprüfung von Serverzertifikaten und zur Behebung von Schwachstellen bietet diese Ressource umfassende Anleitung.

SSL Pinning

SSL Pinning ist eine Sicherheitsmaßnahme, bei der die Anwendung das Serverzertifikat gegen eine bekannte Kopie prüft, die innerhalb der Anwendung gespeichert ist. Diese Methode ist wesentlich, um MITM-Angriffe zu verhindern. Die Implementierung von SSL Pinning wird dringend empfohlen für Anwendungen, die sensible Informationen verarbeiten.

Traffic-Inspektion

Um HTTP-Traffic zu inspizieren, ist es notwendig, das Zertifikat des Proxy-Tools zu installieren (z. B. Burp). Ohne dieses installierte Zertifikat ist verschlüsselter Traffic möglicherweise nicht über den Proxy sichtbar. Eine Anleitung zum Installieren eines benutzerdefinierten CA-Zertifikats findest du hier.

Apps, die auf API Level 24 and above abzielen, erfordern Änderungen an der Network Security Config, damit das CA-Zertifikat des Proxys akzeptiert wird. Dieser Schritt ist entscheidend für die Inspektion verschlüsselten Traffics. Anweisungen zum Ändern der Network Security Config findest du in diesem Tutorial.

Wenn Flutter verwendet wird, musst du die Anweisungen auf dieser Seite befolgen. Das liegt daran, dass das einfache Hinzufügen des Zertifikats in den Store nicht funktioniert, da Flutter eine eigene Liste gültiger CAs hat.

Statische Erkennung von SSL/TLS pinning

Bevor du Runtime-Bypässe versuchst, solltest du schnell kartieren, wo Pinning in der APK durchgesetzt wird. Statische Erkennung hilft dir, Hooks/Patches zu planen und dich auf die richtigen Codepfade zu konzentrieren.

Tool: SSLPinDetect

  • Open-Source-Statikanalyse-Tool, das die APK in Smali dekompiliert (via apktool) und nach kuratierten Regex-Mustern für SSL/TLS pinning-Implementierungen sucht.
  • Meldet den genauen Dateipfad, die Zeilennummer und einen Codeauszug für jeden Treffer.
  • Deckt gängige Frameworks und benutzerdefinierte Codepfade ab: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init mit custom TrustManagers/KeyManagers und Network Security Config XML pins.

Installation

  • Voraussetzungen: Python >= 3.8, Java im PATH, apktool
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Verwendung

# Basic
python sslpindetect.py -f app.apk -a apktool.jar

# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v

Beispiel pattern rules (JSON) Verwende oder erweitere signatures, um proprietary/custom pinning styles zu erkennen. Du kannst dein eigenes JSON laden und scan at scale.

{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}

Notes and tips

  • Fastes Scannen großer Apps via Multi-Threading und memory-mapped I/O; vor-kompilierte regex reduziert Overhead/False Positives.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Typische Detection-Ziele für die weitere Triage:
  • OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
  • Declarative pins in res/xml network security config and manifest references
  • Nutze die gefundenen Stellen, um Frida-Hooks, statische Patches oder Konfigurationsprüfungen zu planen, bevor du dynamisch testest.

Umgehung von SSL Pinning

Wenn SSL Pinning implementiert ist, wird seine Umgehung erforderlich, um HTTPS-Verkehr zu untersuchen. Verschiedene Methoden stehen dafür zur Verfügung:

  • Automatically modify the apk to bypass SSLPinning with apk-mitm. Der größte Vorteil dieser Option ist, dass du kein root benötigst, um SSL Pinning zu umgehen, aber du musst die Anwendung löschen und die neue installieren, und das funktioniert nicht immer.
  • Du kannst Frida (unten besprochen) verwenden, um diesen Schutz zu umgehen. Hier findest du eine Anleitung, um Burp+Frida+Genymotion zu nutzen: https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/
  • Du kannst auch versuchen, SSL Pinning automatisch zu umgehen mit objection: objection --gadget com.package.app explore --startup-command "android sslpinning disable"
  • Du kannst auch versuchen, SSL Pinning automatisch mit MobSF dynamic analysis zu umgehen (weiter unten erklärt)
  • Falls du immer noch denkst, dass es Traffic gibt, den du nicht erfasst, kannst du versuchen, den Traffic mit iptables an burp weiterzuleiten. Lies diesen Blog: https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62

Suche nach gängigen Web-Schwachstellen

Es ist wichtig, innerhalb der Anwendung auch nach gängigen Web-Schwachstellen zu suchen. Detaillierte Informationen zur Identifizierung und Behebung dieser Schwachstellen gehen über den Rahmen dieser Zusammenfassung hinaus, werden aber an anderer Stelle ausführlich behandelt.

Frida

Frida ist ein dynamic instrumentation toolkit für Developer, Reverse-Engineers und Security-Researchers.
Du kannst auf laufende Anwendungen zugreifen und Methoden zur Laufzeit hooken, um das Verhalten zu ändern, Werte zu ändern, Werte zu extrahieren oder anderen Code auszuführen…
Wenn du Android-Anwendungen pentesten willst, musst du wissen, wie man Frida benutzt.

Anti-instrumentation & SSL pinning bypass workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Dump Memory - Fridump

Prüfe, ob die Anwendung sensible Informationen im Speicher ablegt, die sie nicht ablegen sollte, wie Passwörter oder mnemonics.

Using Fridump3 you can dump the memory of the app with:

# With PID
python3 fridump3.py -u <PID>

# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"

Dies erstellt einen memory dump im Ordner ./dump, und dort könntest du mit etwas wie grep suchen:

strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"

Sensible Daten im Keystore

Auf Android ist der Keystore der beste Ort, um sensible Daten zu speichern, jedoch ist es bei ausreichenden Rechten immer noch möglich, darauf zuzugreifen. Da Anwendungen hier dazu neigen, sensible Daten im Klartext zu speichern, sollten pentests dies prüfen, da ein root user oder jemand mit physischem Zugriff auf das Gerät diese Daten stehlen könnte.

Selbst wenn eine App Daten im Keystore ablegt, sollten diese Daten verschlüsselt sein.

Um auf die Daten im Keystore zuzugreifen, kann dieses Frida script verwendet werden: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

frida -U -f com.example.app -l frida-scripts/tracer-cipher.js

Fingerprint/Biometrics Bypass

Mit folgendem Frida-Skript könnte es möglich sein, die von Android-Anwendungen verwendete bypass fingerprint authentication zu umgehen, mit der sie bestimmte sensible Bereiche schützen:

frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>

Hintergrundbilder

Wenn du eine Anwendung in den Hintergrund schickst, speichert Android einen snapshot der Anwendung, sodass beim Wiederherstellen in den Vordergrund zuerst das Bild geladen wird, bevor die App selbst geladen wird, wodurch es so aussieht, als sei die App schneller gestartet.

Wenn dieser snapshot jedoch sensible Informationen enthält, könnte jemand mit Zugriff auf den Snapshot diese Informationen stehlen (beachte, dass du root brauchst, um darauf zuzugreifen).

Die Snapshots werden üblicherweise gespeichert unter: /data/system_ce/0/snapshots

Android bietet die Möglichkeit, das Erfassen von Screenshots durch Setzen des Layout-Parameters FLAG_SECURE zu verhindern. Wenn dieses Flag verwendet wird, werden die Fensterinhalte als sicher behandelt, wodurch verhindert wird, dass sie in Screenshots erscheinen oder auf nicht-sicheren Displays angezeigt werden.

getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);

Android Application Analyzer

Dieses Tool kann Ihnen helfen, verschiedene Werkzeuge während der dynamischen Analyse zu verwalten: https://github.com/NotSoSecure/android_application_analyzer

Intent Injection

Entwickler erstellen oft Proxy-Komponenten wie activities, services und broadcast receivers, die diese Intents verarbeiten und an Methoden wie startActivity(...) oder sendBroadcast(...) weitergeben, was riskant sein kann.

Die Gefahr besteht darin, dass Angreifer durch Umleiten dieser Intents nicht-exportierte App-Komponenten auslösen oder auf sensible Content Provider zugreifen können. Ein bemerkenswertes Beispiel ist die WebView-Komponente, die URLs mittels Intent.parseUri(...) in Intent-Objekte umwandelt und diese dann ausführt, was potenziell zu bösartigen Intent injections führen kann.

Essential Takeaways

  • Intent Injection ist vergleichbar mit dem Web-Problem Open Redirect.
  • Exploits beinhalten das Übergeben von Intent-Objekten als Extras, die umgeleitet werden können, um unsichere Operationen auszuführen.
  • Es kann nicht-exportierte Komponenten und Content Provider für Angreifer zugänglich machen.
  • Die Konvertierung von URLs zu Intent-Objekten durch WebView kann unbeabsichtigte Aktionen ermöglichen.

Android Client Side Injections and others

Wahrscheinlich kennen Sie diese Art von Schwachstellen aus dem Web. Sie müssen bei Android-Anwendungen besonders vorsichtig mit diesen Schwachstellen sein:

  • SQL Injection: Wenn Sie mit dynamischen Abfragen oder Content-Providers arbeiten, stellen Sie sicher, dass Sie parameterisierte Queries verwenden.
  • JavaScript Injection (XSS): Vergewissern Sie sich, dass JavaScript- und Plugin-Unterstützung für alle WebViews deaktiviert ist (standardmäßig deaktiviert). More info here.
  • Local File Inclusion: WebViews sollten keinen Zugriff auf das Dateisystem haben (standardmäßig aktiviert) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: In mehreren Fällen wird der Cookie nach dem Beenden der Session nicht widerrufen oder sogar auf die Festplatte gespeichert
  • Secure Flag in cookies

Automatic Analysis

MobSF

Static analysis

Vulnerabilitätsbewertung der Anwendung mithilfe eines ansprechenden webbasierten Frontends. Sie können auch dynamische Analysen durchführen (aber Sie müssen die Umgebung vorbereiten).

docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Notice that MobSF can analyse Android(apk), IOS(ipa) and Windows(apx) applications (Windows applications must be analyzed from a MobSF installed in a Windows host).
Also, if you create a ZIP file with the source code if an Android or an IOS app (go to the root folder of the application, select everything and create a ZIPfile), it will be able to analyse it also.

MobSF also allows you to diff/Compare analysis and to integrate VirusTotal (you will need to set your API key in MobSF/settings.py and enable it: VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). You can also set VT_UPLOAD to False, then the hash will be upload instead of the file.

Assisted Dynamic analysis with MobSF

MobSF kann auch bei dynamic analysis für Android sehr hilfreich sein, aber in diesem Fall musst du MobSF und genymotion auf deinem Host installieren (ein VM oder Docker funktioniert nicht). Note: You need to start first a VM in genymotion and then MobSF.
The MobSF dynamic analyser can:

  • Dump application data (URLs, logs, clipboard, screenshots made by you, screenshots made by “Exported Activity Tester”, emails, SQLite databases, XML files, and other created files). All of this is done automatically except for the screenshots, you need to press when you want a screenshot or you need to press “Exported Activity Tester” to obtain screenshots of all the exported activities.
  • Capture HTTPS traffic
  • Use Frida to obtain runtime information

From android versions > 5, it will automatically start Frida and will set global proxy settings to capture traffic. It will only capture traffic from the tested application.

Frida

By default, it will also use some Frida Scripts to bypass SSL pinning, root detection and debugger detection and to monitor interesting APIs.
MobSF can also invoke exported activities, grab screenshots of them and save them for the report.

To start the dynamic testing press the green bottom: “Start Instrumentation”. Press the “Frida Live Logs” to see the logs generated by the Frida scripts and “Live API Monitor” to see all the invocation to hooked methods, arguments passed and returned values (this will appear after pressing “Start Instrumentation”).
MobSF also allows you to load your own Frida scripts (to send the results of your Friday scripts to MobSF use the function send()). It also has several pre-written scripts you can load (you can add more in MobSF/DynamicAnalyzer/tools/frida_scripts/others/), just select them, press “Load” and press “Start Instrumentation” (you will be able to see the logs of that scripts inside “Frida Live Logs”).

Moreover, you have some Auxiliary Frida functionalities:

  • Enumerate Loaded Classes: It will print all the loaded classes
  • Capture Strings: It will print all the capture strings while using the application (super noisy)
  • Capture String Comparisons: Could be very useful. It will show the 2 strings being compared and if the result was True or False.
  • Enumerate Class Methods: Put the class name (like “java.io.File”) and it will print all the methods of the class.
  • Search Class Pattern: Search classes by pattern
  • Trace Class Methods: Trace a whole class (see inputs and outputs of all methods of th class). Remember that by default MobSF traces several interesting Android Api methods.

Once you have selected the auxiliary module you want to use you need to press “Start Intrumentation” and you will see all the outputs in “Frida Live Logs”.

Shell

Mobsf also brings you a shell with some adb commands, MobSF commands, and common shell commands at the bottom of the dynamic analysis page. Some interesting commands:

help
shell ls
activities
exported_activities
services
receivers

HTTP-Tools

Wenn HTTP-Verkehr erfasst wird, kannst du eine unansehnliche Ansicht des erfassten Verkehrs im “HTTP(S) Traffic”-Bereich unten sehen oder eine schönere Ansicht über die grüne Schaltfläche “Start HTTPTools”. Über die zweite Option kannst du die captured requests an proxies wie Burp oder Owasp ZAP senden.
Um dies zu tun, power on Burp –> turn off Intercept –> in MobSB HTTPTools select the request –> drücke “Send to Fuzzer” –> select the proxy address (http://127.0.0.1:8080\).

Sobald du die dynamische Analyse mit MobSF beendet hast, kannst du auf “Start Web API Fuzzer” drücken, um fuzz http requests und nach Schwachstellen zu suchen.

Tip

Nachdem du eine dynamische Analyse mit MobSF durchgeführt hast, können die Proxy-Einstellungen fehlerhaft sein und lassen sich nicht über die GUI beheben. Du kannst die Proxy-Einstellungen folgendermaßen zurücksetzen:

adb shell settings put global http_proxy :0

Unterstützte dynamische Analyse mit Inspeckage

Du kannst das Tool von Inspeckage bekommen.
Dieses Tool verwendet einige Hooks, um dir während einer dynamischen Analyse zu zeigen, was in der Anwendung passiert.

Yaazhini

Dies ist ein großartiges Tool, um static analysis mit einer GUI durchzuführen

Qark

Dieses Tool ist dafür ausgelegt, nach verschiedenen security related Android application vulnerabilities zu suchen, entweder im source code oder in packaged APKs. Das Tool ist außerdem capable of creating a “Proof-of-Concept” deployable APK und ADB commands, um einige der gefundenen Schwachstellen auszunutzen (Exposed activities, intents, tapjacking…). Wie bei Drozer muss das Testgerät nicht gerootet werden.

pip3 install --user qark  # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
qark --java path/to/parent/java/folder
qark --java path/to/specific/java/file.java

ReverseAPK

  • Zeigt alle extrahierten Dateien zur einfachen Referenz an
  • Dekompiliert APK-Dateien automatisch in Java- und Smali-Format
  • Analysiert AndroidManifest.xml auf gängige Schwachstellen und Verhalten
  • Statische Quellcode-Analyse auf gängige Schwachstellen und Verhalten
  • Geräteinfo
  • und mehr
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER ist eine Kommandozeilenanwendung, die unter Windows, MacOS X und Linux verwendet werden kann und .apk Dateien nach Schwachstellen durchsucht. Dazu dekomprimiert sie APKs und wendet eine Reihe von Regeln an, um diese Schwachstellen zu erkennen.

Alle Regeln sind in einer rules.json-Datei gebündelt, und jedes Unternehmen oder jeder Tester kann eigene Regeln erstellen, um genau das zu analysieren, was benötigt wird.

Lade die aktuellen Binärdateien von der download page herunter

super-analyzer {apk_file}

StaCoAn

StaCoAn ist ein crossplatform-Tool, das Entwicklern, bugbounty hunters und ethical hackers bei der Durchführung von static code analysis an mobilen Anwendungen hilft.

Das Konzept besteht darin, dass Sie Ihre mobile Anwendungsdatei (eine .apk- oder .ipa-Datei) per Drag & Drop auf die StaCoAn-Anwendung ziehen und diese einen visuellen und portablen Bericht für Sie erzeugt. Sie können die Einstellungen und wordlists anpassen, um ein individuelles Erlebnis zu erhalten.

Download latest release:

./stacoan

AndroBugs

AndroBugs Framework ist ein System zur Analyse von Android-Sicherheitslücken, das Entwickler oder hackers dabei unterstützt, potenzielle Sicherheitslücken in Android-Anwendungen zu finden.
Windows releases

python androbugs.py -f [APK file]
androbugs.exe -f [APK file]

Androwarn

Androwarn ist ein Tool, dessen Hauptzweck darin besteht, potenziell bösartige Verhaltensweisen einer Android-Anwendung zu erkennen und den Benutzer zu warnen.

Die Erkennung erfolgt durch static analysis des Dalvik-Bytecodes der Anwendung, repräsentiert als Smali, mithilfe der Bibliothek androguard.

Dieses Tool sucht nach häufigen Verhaltensmustern von “bösen” Anwendungen wie: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution…

python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3

MARA Framework

MARA ist ein Framework für Reverse-Engineering und Analyse mobiler Anwendungen. Es ist ein Tool, das häufig verwendete Werkzeuge für das Reverse-Engineering und die Analyse mobiler Anwendungen zusammenführt, um beim Testen mobiler Anwendungen gegen die OWASP mobilen Sicherheitsbedrohungen zu unterstützen. Sein Ziel ist es, diese Aufgabe für mobile Anwendungs-Entwickler und Sicherheitsexperten einfacher und benutzerfreundlicher zu gestalten.

Es kann:

Koodous

Nützlich zur Erkennung von Malware: https://koodous.com/

Obfuscating/Deobfuscating code

Beachte, dass abhängig vom Dienst und der Konfiguration, die du zum Obfuskieren des Codes verwendest, Secrets möglicherweise obfuskriert werden oder nicht.

ProGuard

From Wikipedia: ProGuard ist ein Open-Source-Kommandozeilen-Tool, das Java-Code schrumpft, optimiert und obfuskiert. Es ist in der Lage, Bytecode zu optimieren sowie ungenutzte Instruktionen zu erkennen und zu entfernen. ProGuard ist freie Software und wird unter der GNU General Public License, Version 2, vertrieben.

ProGuard wird als Teil des Android SDK ausgeliefert und läuft beim Erstellen der Anwendung im Release-Modus.

DexGuard

Finde eine Schritt-für-Schritt-Anleitung zum Deobfuskieren des APKs unter https://blog.lexfo.fr/dexguard.html

(Aus dieser Anleitung) Zuletzt, als wir nachgesehen haben, war der DexGuard-Betriebsmodus:

  • lade eine Ressource als InputStream;
  • gib das Ergebnis an eine Klasse weiter, die von FilterInputStream erbt, um es zu entschlüsseln;
  • führe einige nutzlose Obfuskationen durch, um ein paar Minuten Zeit eines Reversers zu verschwenden;
  • gib das entschlüsselte Ergebnis an einen ZipInputStream, um eine DEX-Datei zu erhalten;
  • lade schließlich die resultierende DEX als Resource mittels der loadDex-Methode.

DeGuard

DeGuard kehrt den Obfuskationsprozess um, der von Android-Obfuskationstools durchgeführt wird. Dadurch werden zahlreiche Sicherheitsanalysen ermöglicht, einschließlich Code-Inspektion und Bibliotheksvorhersage.

Du kannst ein obfuskiertes APK zu ihrer Plattform hochladen.

[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app

This is a LLM tool to find any potential security vulnerabilities in android apps and deobfuscate android app code. Uses Google’s Gemini public API.

Simplify

Es ist ein generischer Android-Deobfuscator. Simplify führt eine Art virtuelle Ausführung einer App durch, um ihr Verhalten zu verstehen, und versucht dann, den Code so zu optimieren, dass er sich identisch verhält, aber für Menschen leichter zu verstehen ist. Jeder Optimierungstyp ist einfach und generisch, sodass es unerheblich ist, welche spezifische Obfuskationsart verwendet wurde.

APKiD

APKiD liefert Informationen darüber, wie eine APK erstellt wurde. Es identifiziert viele Compiler, Packer, Obfuskatoren und andere merkwürdige Dinge. Es ist wie PEiD für Android.

Manual

Read this tutorial to learn some tricks on how to reverse custom obfuscation

Labs

Androl4b

AndroL4b ist eine Android-Sicherheits-VM basierend auf ubuntu-mate und beinhaltet eine Sammlung der neuesten Frameworks, Tutorials und Labs von verschiedenen Security-Enthusiasten und Forschern zum Reverse Engineering und zur Malware-Analyse.

References

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks