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

Grundlagen zu Android-Anwendungen

Es wird dringend empfohlen, diese Seite zuerst zu lesen, um die wichtigsten Teile im Zusammenhang mit Android-Sicherheit und die gefährlichsten Komponenten einer Android-Anwendung kennenzulernen:

Android Applications Basics

ADB (Android Debug Bridge)

Dies ist das Haupttool, das Sie benötigen, um ein Android-Gerät (emuliert oder physisch) zu verbinden.
ADB ermöglicht die Steuerung von Geräten entweder über USB oder Netzwerk von einem Computer aus. Dieses Dienstprogramm 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.

Sehen Sie sich die folgende Liste der ADB Commands an, um zu lernen, wie man adb benutzt.

Smali

Manchmal ist es interessant, den Anwendungs-Code zu modifizieren, um auf versteckte Informationen zuzugreifen (z. B. stark obfuskierte Passwörter oder Flags). Dann kann es sinnvoll sein, das apk zu dekompilieren, den Code zu ändern und es neu zu kompilieren.
In diesem Tutorial kannst du lernen, wie man ein APK dekompiliert, Smali-Code ändert und das APK mit der neuen Funktionalität neu kompiliert. Das kann sehr nützlich sein als Alternative für mehrere Tests während der dynamischen Analyse, die im Folgenden vorgestellt werden. Daher behalte diese Möglichkeit immer im Hinterkopf.

Other interesting tricks

Automatisierte Multi-Source APK-Beschaffung (justapk)

pip install justapk (Python 3.11+). Die CLI schreibt JSON auf stdout und Fortschritt auf stderr (pipe-freundlich). Sie versucht eine deterministische Fallback-Kette über APK20 → F-Droid → APKPure (mobile API) → APKMirror (HTML scrape) → Uptodown (mobile API) → APKCombo (HTML scrape). Cloudflare-geschützte Quellen verwenden curl_cffi mit TLS-Fingerprint-Imitation, um echte Clients zu imitieren und Bot-Erkennungsblockaden zu reduzieren.

justapk download <package>              # auto fallback
justapk download <package> -s apkpure   # pin a source / version / output dir
justapk search telegram
justapk info org.telegram.messenger
justapk convert app.xapk -o output/      # merges splits, re-signs with debug key

convert fügt XAPK/split APKs zusammen und signiert sie mit einem debug key, wodurch sich die APK-Signatur/Herkunft vom Original unterscheidet (nur für Tests/Analysen verwenden, nicht für Produktionsinstallationen).

  • APK vom Gerät extrahieren:
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

Android malware tradecraft (loaders, fileless DEX, persistence)

Native staging + fileless DEX loaders

Einige Android-Dropper betten eine native Bibliothek (lib*.so) ein, die eine zweite ELF entschlüsselt und schreibt (z. B. l.so) in einen temporären Pfad, sie über JNI lädt und anschließend die eigentliche Logik als DEX nur im Speicher mit dalvik.system.InMemoryDexClassLoader lädt. Das verringert die statische Sichtbarkeit des Payloads und verhindert das Schreiben von classes*.dex auf die Festplatte.

Praktische Triage-Punkte:

  • Achte auf native libs, die früh dlopen aufrufen oder System.loadLibrary verwenden und dann Java-Methoden über obfuskierte Stack-Strings auflösen (z. B. XOR-decoded auf dem Stack).
  • Achte auf InMemoryDexClassLoader in logs/strings oder Hooks, was auf fileless DEX-Ausführung hinweist.

Schneller Frida-Hook zum Dumpen des in-memory DEX-Puffers:

Java.perform(() => {
const IM = Java.use('dalvik.system.InMemoryDexClassLoader');
IM.$init.overload('java.nio.ByteBuffer','java.lang.ClassLoader').implementation = function(buf, parent){
const arr = Java.array('byte', buf.array());
const fos = Java.use('java.io.FileOutputStream').$new("/sdcard/memdex.dex");
fos.write(arr); fos.close();
return this.$init(buf, parent);
};
});

Anti-analysis kill-switch

Packed loaders often beenden sich selbst, wenn Emulator- oder Analyseprüfungen fehlschlagen (z. B. CPU_ABI-Validierung) durch Aufruf:

android.os.Process.killProcess(android.os.Process.myPid());

Persistence via foreground service + MediaPlayer loop

Ein leichtgewichtiges Persistenzmuster besteht darin, einen foreground service mit einer pinned notification am Leben zu erhalten und kontinuierlich eine nahezu unhörbare Audio-Schleife über MediaPlayer abzuspielen. Dadurch bleibt der Prozess „aktiv“ und das OS beendet ihn seltener wegen Inaktivität. Achte auf ForegroundService + MediaPlayer-Verwendung, die ein kleines Asset (oft nur wenige Sekunden) in einer Schleife abspielt.

Accessibility overlay + ACTION_SET_TEXT hijacking

Nachdem ein Benutzer Accessibility gewährt hat, können Banking-Trojaner die foreground app überwachen, ein realistisches Overlay rendern (oft WebView HTML, das als Base64 gespeichert ist) und Transaktionsfelder mit AccessibilityNodeInfo.ACTION_SET_TEXT ersetzen. Dadurch ist eine stille Empfängeradressänderung möglich, während das Opfer eine plausible UI sieht.

Minimales Beispiel für Textersetzung:

Bundle args = new Bundle();
args.putCharSequence(AccessibilityNodeInfo.ACTION_ARGUMENT_SET_TEXT_CHARSEQUENCE,
"ATTACKER_USDT_ADDRESS");
node.performAction(AccessibilityNodeInfo.ACTION_SET_TEXT, args);

Legitimate push infrastructure as C2 gating

Statt benutzerdefinierter Sockets verwendet some malware oft Firebase Cloud Messaging (FCM) als C2-Kanal. FCM-Nachrichten können Telemetriechecks (Ladezustand, Akku %, Temperatur, Benutzerinaktivität) auslösen und Aktionen wie mining oder fraud für Stealth gate.

Encrypted native payload staging with filename‑derived keys

Native Payloads können als verschlüsselte ELF-Blobs geliefert und mit CipherInputStream() entschlüsselt werden, wobei ein Schlüssel aus SHA‑1 des heruntergeladenen Dateinamens abgeleitet wird. Jeder Dateiname/Version erzeugt einen eigenen Schlüssel, was die Wiederverwendung statischer IOCs erschwert.

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

  • Läuft auf einem rooted device (Magisk/rootAVD) und startet einen HTTP server on tcp/8080 mit einer Flutter web UI und REST API.
  • Installiere die Release-APK mit Rechten: adb install -g -r jezail.apk, dann starte die App (Server startet automatisch).
  • Endpunkte: 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 ansehen mit einem Decompiler.
Bitte, read here to find information about different available decompilers.

Looking for interesting Info

Allein durch das Durchsuchen der strings der APK kannst du nach passwords, 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 (hardcoded admin credentials in der App).

Firebase

Achte besonders auf firebase URLs und prüfe, ob sie schlecht konfiguriert sind. More information about whats is FIrebase and how to exploit it here.

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

Die Untersuchung der Manifest.xml und strings.xml einer Anwendung kann potenzielle Sicherheitslücken offenlegen. Diese Dateien sind über Decompiler zugänglich oder indem man die APK-Endung in .zip umbenennt und sie dann entpackt.

Vulnerabilities identifiziert aus der Manifest.xml umfassen:

  • Debuggable Applications: Anwendungen, die im Manifest.xml als debuggable (debuggable="true") gesetzt sind, stellen ein Risiko dar, da sie Verbindungen erlauben, die zu einer Ausnutzung führen können. Für ein tieferes Verständnis, wie man debuggable Applications ausnutzt, siehe ein Tutorial zur Findung und Ausnutzung debuggable Applications auf einem Gerät.
  • Backup Settings: Das Attribut android:allowBackup="false" sollte explizit für Anwendungen gesetzt werden, die sensible Informationen verarbeiten, um unautorisierte Datenbackups über adb zu verhindern, besonders wenn USB-Debugging aktiviert ist.
  • Network Security: Custom network security configurations (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ können Sicherheitsdetails wie Certificate Pins und HTTP-Traffic-Einstellungen spezifizieren. Ein Beispiel ist das Zulassen von HTTP-Traffic für bestimmte Domains.
  • Exported Activities and Services: Exported activities und services im Manifest können Komponenten hervorheben, die missbraucht werden könnten. Weitere Analysen während dynamic testing können zeigen, wie diese Komponenten ausgenutzt werden.
  • Content Providers and FileProviders: Offen zugängliche content providers könnten unautorisierte Zugriffe oder Modifikationen von Daten erlauben. Die Konfiguration von FileProviders sollte ebenfalls geprüft werden.
  • Broadcast Receivers and URL Schemes: Diese Komponenten könnten für Exploits genutzt werden, mit besonderem Fokus darauf, wie URL-Schemes auf input-Schwachstellen geprüft werden.
  • SDK Versions: Die Attribute minSdkVersion, targetSDKVersion und maxSdkVersion geben die unterstützten Android-Versionen an und machen deutlich, wie wichtig es ist, keine veralteten, verwundbaren Android-Versionen zu unterstützen.

Aus der strings.xml 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 malicious application gestartet wird und sich über einer Opfer-Anwendung positioniert. 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 weitergereicht wird.
Effektiv blendet sie den Benutzer daraufhin aus, dass er tatsächlich Aktionen in der Opfer-App durchführt.

Find more information in:

Tapjacking

Task Hijacking

Eine activity mit launchMode auf singleTask ohne definierte taskAffinity ist für Task Hijacking anfällig. Das bedeutet, dass eine application installiert werden kann und wenn sie vor der echten Anwendung gestartet wird, sie die Task der echten Anwendung hijacken könnte (so dass der Benutzer mit der malicious application interagiert, in dem Glauben, er benutze die echte).

More info 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 zugänglich sind, die sie erstellt hat. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem durchgesetzt und ist in der Regel ausreichend für die Sicherheitsanforderungen der meisten Anwendungen. Entwickler nutzen jedoch manchmal Modi wie MODE_WORLD_READABLE und MODE_WORLD_WRITABLE, um Dateien zwischen verschiedenen Anwendungen zu teilen. Diese Modi beschränken jedoch nicht den Zugriff auf diese Dateien durch andere Anwendungen, einschließlich potenziell bösartiger.

  1. Static Analysis:
  • Ensure, 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:
  • Verify die Berechtigungen auf Dateien, die von der App erstellt wurden. Insbesondere prüfe, ob Dateien global lesbar oder beschreibbar gesetzt sind. Das kann ein erhebliches Sicherheitsrisiko darstellen, da jede auf dem Gerät installierte Anwendung, unabhängig von Herkunft oder Absicht, diese Dateien lesen oder verändern könnte.

External Storage

Beim Umgang mit Dateien auf external storage, wie SD-Karten, sollten bestimmte Vorsichtsmaßnahmen getroffen werden:

  1. Accessibility:
  • Dateien auf external storage sind global lesbar und schreibbar. Das bedeutet, jede Anwendung oder jeder Benutzer kann auf diese Dateien zugreifen.
  1. Security Concerns:
  • Aufgrund der leichten Zugänglichkeit wird empfohlen, keine sensiblen Informationen auf external storage zu speichern.
  • External storage kann entfernt oder von jeder Anwendung gelesen werden, was die Sicherheit verringert.
  1. Handling Data from External Storage:
  • Führe stets Input Validation auf Daten durch, die aus external storage geladen werden. Das ist wichtig, weil die Daten aus einer untrusted source stammen.
  • Das Speichern von Executables oder class files auf external storage zum dynamischen Nachladen wird stark abgeraten.
  • Falls deine Anwendung ausführbare Dateien aus external storage laden muss, stelle sicher, dass diese Dateien signed und kryptografisch verifiziert sind, bevor sie dynamically geladen werden. Dieser Schritt ist entscheidend für die Integrität der Sicherheit 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 einschränkt, das speziell für diese App vorgesehen ist. Das verhindert, dass eine malicious application Lese- oder Schreibzugriff auf die Dateien einer anderen App erhält.

Sensitive data stored in clear-text

  • Shared preferences: Android erlaubt jeder Anwendung, einfach xml-Dateien im Pfad /data/data/<packagename>/shared_prefs/ zu speichern, und manchmal findet man dort sensitive Informationen im Klartext.
  • Databases: Android erlaubt jeder Anwendung, sqlite-Datenbanken im Pfad /data/data/<packagename>/databases/ zu speichern, und manchmal findet man dort sensitive Informationen im Klartext.

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);

A good way to test this is to try to capture the traffic using some proxy like Burp without authorising Burp CA inside the device. Also, you can generate with Burp a certificate for a different hostname and use it.

Fehlerhafte Kryptographie

Schlechte Schlüsselverwaltungsprozesse

Einige Entwickler speichern sensible Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hardcoded/predictable Schlüssel. Das sollte nicht gemacht werden, da ein gewisses reversing es Angreifern erlauben könnte, die vertraulichen Informationen zu extrahieren.

Verwendung unsicherer und/oder veralteter Algorithmen

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

Weitere Prüfungen

  • Es wird empfohlen, die APK zu obfuscate, um die Arbeit der Reverse Engineers für Angreifer zu erschweren.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie eigene Checks durchführen, um zu prüfen, ob das mobile Gerät rooted ist, und entsprechend handeln.
  • 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 der APK verwendet wurde

React Native-Anwendung

Read the following page to learn how to easily access javascript code of React applications:

React Native Application

Xamarin-Anwendungen

Read the following page to learn how to easily access C# code of a xamarin applications:

Xamarin Apps

Superpacked Applications

According to this blog post superpacked is a Meta algorithm that compress the content of an application into a single file. The blog talks about the possibility of creating an app that decompress these kind of apps… and a faster way which involves to execute the application and gather the decompressed files from the filesystem.

Automatisierte statische Code-Analyse

Das Tool mariana-trench ist in der Lage, vulnerabilities zu finden, indem es den code der Anwendung scannt. Dieses Tool enthält eine Reihe von known sources (die dem Tool die places anzeigen, an denen die input vom Benutzer controlled wird), sinks (die dem Tool dangerous places anzeigen, wo bösartige Benutzereingaben Schaden anrichten könnten) und rules. Diese Regeln geben die combination von sources-sinks an, die auf eine Schwachstelle hinweisen.

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

Secrets leaked

An application may contain secrets (API keys, passwords, hidden urls, subdomains…) inside of it that you might be able to discover. You could us a tool such as https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Andere interessante Funktionen

  • Code execution: Runtime.exec(), ProcessBuilder(), native code:system()
  • Send SMSs: sendTextMessage, sendMultipartTestMessage
  • Native functions declared as 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

Weitere Tricks

content:// protocol

Dynamische Analyse

Zuerst benötigst 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 rooted Gerät (emuliert oder nicht) dringend empfohlen.

Online Dynamische Analyse

Du kannst einen kostenlosen Account bei: https://appetize.io/ erstellen. Diese Plattform erlaubt es dir, APKs hochzuladen und auszuführen, daher ist sie nützlich, um zu sehen, wie sich eine 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 emulators verwenden.

Lokale dynamische Analyse

Verwendung eines Emulators

  • Android Studio (Du kannst x86 und arm Geräte erstellen, und laut this latest x86 versions support ARM libraries ohne einen langsamen arm emulator zu benötigen).
  • Lerne, wie man es einrichtet, auf dieser Seite:

AVD - Android Virtual Device

  • Genymotion (Free version: Personal Edition, du musst einen Account erstellen. It’s recommend to download the version WITH VirtualBox um mögliche Fehler zu vermeiden.)
  • Nox (kostenlos, unterstützt jedoch Frida oder Drozer nicht).

Tip

Wenn du einen neuen emulator auf einer beliebigen Plattform erstellst, denke daran: Je größer der Bildschirm, desto langsamer läuft der emulator. Wähle deshalb wenn möglich kleine Bildschirme.

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

Beachte außerdem, 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 möchtest).

Verwendung eines physischen Geräts

Du musst die debugging-Optionen aktivieren und es ist gut, wenn du es rooten kannst:

  1. Settings.
  2. (FromAndroid 8.0) Wähle System.
  3. Wähle About phone.
  4. Drücke Build number 7 Mal.
  5. Gehe zurück und du wirst die Developer options finden.

Sobald du die Anwendung installiert hast, sollte das Erste sein, sie auszuprobieren, zu untersuchen, was sie macht, wie sie funktioniert und dich damit 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 Kurznotizen (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 Root-Hiding; ziehe LSPosed/Shamiko in Betracht, wenn stärkeres Hiding nötig ist
  • Bewahre das originale boot.img auf, um bei OTA-Updates wiederherstellen zu können; repatche nach jedem OTA
  • Für Screen-Mirroring nutze scrcpy auf dem Host

Unintended Data Leakage

Logging

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

Warning

Beachte, dass ab later newer than Android 4.0 applications are only able to access their own logs. Anwendungen können also nicht auf die Logs anderer Apps zugreifen.
Trotzdem wird empfohlen, keine sensiblen Informationen zu loggen.

Copy/Paste Buffer Caching

Das auf der Zwischenablage basierende Framework von Android ermöglicht Copy-Paste-Funktionen in Apps, birgt jedoch das Risiko, dass andere applications auf die Clipboard-Daten zugreifen können und dadurch sensible Informationen offengelegt werden. Es ist wichtig, Copy/Paste-Funktionen für sensible Bereiche einer Anwendung (z. B. Kreditkartendaten) zu deaktivieren, um data leaks zu verhindern.

Crash Logs

Wenn eine Anwendung abstürzt und Logs speichert, können diese Logs Angreifern helfen, besonders wenn die Anwendung nicht reverse-engineered werden kann. Um dieses Risiko zu mindern, vermeide Logging bei Abstürzen, und wenn Logs über das Netzwerk gesendet werden müssen, stelle sicher, dass sie über einen SSL-Kanal übertragen werden.

Als pentester, try to take a look to these logs.

Analytics Data Sent To 3rd Parties

Anwendungen integrieren oft Dienste wie Google Adsense, die unbeabsichtigt sensible Daten leaken können, wenn sie von Entwicklern falsch implementiert wurden. Um mögliche data leaks zu identifizieren, ist es ratsam, den Traffic der Anwendung zu intercepten und zu überprüfen, ob sensible Informationen an third-party services gesendet werden.

SQLite DBs

Die meisten Anwendungen verwenden interne SQLite-Datenbanken, um Informationen zu speichern. Während des pentest solltest du einen Blick auf die erstellten Databases, die Namen der Tables und Columns und alle gespeicherten Daten werfen, da du dort möglicherweise sensible Informationen findest (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 verschlüsselt speichert und du das Passwort innerhalb der Anwendung finden kannst, ist das trotzdem eine Vulnerability.

Enumeriere die Tabellen mit .tables und die Spalten der Tabellen mit .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer allows you to assume the role of an Android app and interact with other apps. It can do anything that an installed application can do, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .
Drozer ist ein nützliches Tool, um exported activities, exported services und Content Providers auszunutzen, wie du in den folgenden Abschnitten lernen wirst.

Ausnutzen exportierter 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 Screen von einer externen App aus aufrufen. Daher könntest du, wenn eine Activity mit sensitive information exported ist, die authentication-Mechanismen bypassen, um darauf zuzugreifen.

Learn how to exploit exported activities with Drozer.

Du kannst auch eine exportierte Activity über adb 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 dieses Pull Requests ist das offenbar nur auf alten Versionen (API-Versionen < 21) gefährlich.

Tip

Beachten Sie, dass ein authorisation bypass nicht immer eine Verwundbarkeit ist; es hängt davon ab, wie der Bypass funktioniert und welche Informationen offengelegt werden.

Sensitive information leakage

Activities can also return results. Wenn es Ihnen gelingt, eine exportierte und ungeschützte Activity zu finden, die die Methode setResult aufruft und sensible Informationen zurückgibt, liegt eine sensitive information leakage vor.

Tapjacking

Wenn Tapjacking nicht verhindert wird, könnten Sie die exportierte Activity missbrauchen, um den Benutzer unerwartete Aktionen ausführen zu lassen. Für mehr Informationen über was Tapjacking ist, folgen Sie dem Link.

Exploiting Content Providers - Accessing and manipulating sensitive information

Lesen Sie dies, wenn Sie auffrischen möchten, was ein Content Provider ist.
Content Providers werden grundsätzlich verwendet, um Daten zu teilen. Wenn eine App Content Providers zur Verfügung stellt, können Sie möglicherweise sensible Daten daraus extrahieren. Es ist auch interessant, mögliche SQL injections und Path Traversals zu testen, da diese anfällig sein könnten.

Erfahren Sie, wie man Content Providers mit Drozer ausnutzt.

Exploiting Services

Lesen Sie dies, wenn Sie auffrischen möchten, was ein Service ist.
Denken Sie 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 Services exportiert, sollten Sie den Code überprüfen, um zu verstehen, was er tut, und ihn dynamisch testen, um vertrauliche Informationen zu extrahieren, Authentifizierungsmaßnahmen zu umgehen…
Erfahren Sie, wie man Services mit Drozer ausnutzt.

Exploiting Broadcast Receivers

Lesen Sie dies, wenn Sie auffrischen möchten, was ein Broadcast Receiver ist.
Denken Sie 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.
Erfahren Sie, wie man Broadcast Receivers mit Drozer ausnutzt.

Exploiting Schemes / Deep links

Sie können manuell nach deep links suchen, Tools wie MobSF oder Skripte wie dieses verwenden.
Sie können 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 Paketnamen weglassen kannst und das mobile Gerä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>

Code executed

In order to find the code, das in der App ausgeführt wird, go to the activity called by the deeplink and search the function onNewIntent.

Sensitive Informationen

Every time you find a deep link check that it’s not receiving sensitive data (like passwords) via URL parameters, because any other application could impersonate the deep link and steal that data!

Parameters in path

You must check also if any deep link is using a parameter inside the path of the URL like: https://api.example.com/v1/users/{username} , in that case you can force a Path Traversal accessing something like: example://app/users?username=../../unwanted-endpoint%3fparam=value .
Beachte, dass, wenn du die korrekten Endpoints in der Anwendung findest, du möglicherweise einen Open Redirect (wenn ein Teil des Pfads als Domainname verwendet wird), eine account takeover (wenn du Benutzerdaten ohne CSRF token ändern kannst und der verwundbare Endpoint die richtige Methode nutzte) und andere Schwachstellen verursachen kannst. Mehr Informationen dazu.

More examples

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

Transport-Layer-Inspektion und Verifikationsfehler

  • Certificates are not always inspected properly by Android applications. Es ist üblich, dass diese Anwendungen Warnungen übergehen und selbstsignierte Zertifikate akzeptieren oder in manchen Fällen auf HTTP-Verbindungen zurückfallen.
  • Negotiations during the SSL/TLS handshake are sometimes weak, wobei unsichere Cipher Suites verwendet werden. Diese Schwachstelle macht die Verbindung anfällig für man-in-the-middle (MITM) Angriffe, wodurch Angreifer die Daten entschlüsseln können.
  • Leakage of private information ist ein Risiko, wenn Anwendungen sich über sichere Kanäle authentifizieren, dann aber für andere Transaktionen über nicht gesicherte Kanäle kommunizieren. Dieser Ansatz schützt sensible Daten, wie Session-Cookies oder Benutzerdetails, nicht vor der Abfangung durch bösartige Akteure.

Certificate Verification

Wir konzentrieren uns auf die Zertifikatsprüfung. Die Integrität des Serverzertifikats muss verifiziert 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 this resource umfassende Anleitung.

SSL Pinning

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

Traffic Inspection

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. Für eine Anleitung zur Installation eines benutzerdefinierten CA-Zertifikats, click here.

Anwendungen, die auf API Level 24 and above abzielen, erfordern Änderungen an der Network Security Config, um das CA-Zertifikat des Proxys zu akzeptieren. Dieser Schritt ist entscheidend, um verschlüsselten Traffic zu inspizieren. Für Anweisungen zur Änderung der Network Security Config, refer to this tutorial.

If Flutter is being used you need to follow the instructions in this page. Das liegt daran, dass das einfache Hinzufügen des Zertifikats in den Store nicht ausreicht, da Flutter seine eigene Liste gültiger CAs hat.

Static detection of SSL/TLS pinning

Bevor du runtime bypasses versuchst, mappe schnell, wo Pinning im APK durchgesetzt wird. Statische Analyse hilft dir, Hooks/Patches zu planen und dich auf die richtigen code paths zu konzentrieren.

Tool: SSLPinDetect

  • Open-source static-analysis utility that decompiles the APK to Smali (via apktool) and scans for curated regex patterns of SSL/TLS pinning implementations.
  • Reports exact file path, line number, and a code snippet for each match.
  • Covers common frameworks and custom code paths: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, and Network Security Config XML pins.

Install

  • Prereqs: Python >= 3.8, Java on 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-Regeln (JSON) Verwende oder erweitere signatures, um proprietäre/custom pinning-Stile zu erkennen. Du kannst dein eigenes JSON laden und in großem Maßstab scannen.

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

Hinweise und Tipps

  • Schnelles Scannen großer Apps mittels Multi-Threading und memory-mapped I/O; vorkompilierte regex reduziert Overhead/False Positives.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Typische Erkennungsziele 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
  • Verwende die gefundenen Stellen, um Frida hooks, statische Patches oder Konfigurationsreviews vor dynamischen Tests zu planen.

Umgehung von SSL Pinning

Wenn SSL Pinning implementiert ist, ist dessen Umgehung nötig, um HTTPS-Traffic zu untersuchen. Dafür stehen verschiedene Methoden zur Verfügung:

Suche nach häufigen Web-Schwachstellen

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

Frida

Frida ist ein dynamisches Instrumentierungs-Toolkit für Entwickler, Reverse-Engineers und Security-Researcher.
Du kannst auf laufende Anwendungen zugreifen und Methoden zur Laufzeit hooken, um Verhalten zu ändern, Werte zu ändern, Werte zu extrahieren, anderen Code auszuführen…
Wenn du Android-Anwendungen pentest, musst du wissen, wie man Frida benutzt.

Anti-instrumentation & SSL Pinning Bypass-Workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Speicher auslesen - Fridump

Prüfe, ob die Anwendung sensitive Informationen im Speicher ablegt, die sie nicht ablegen sollte, z. B. Passwörter oder Mnemonics.

Mit Fridump3 kannst du den Speicher der App mit:

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

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

Das wird den Speicher im Ordner ./dump ablegen, und dort kannst 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

Unter 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 dazu neigen, hier sensible Daten in clear text zu speichern, sollten pentests dies überprü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 speichert, sollten diese Daten verschlüsselt sein.

Um auf die Daten im Keystore zuzugreifen, kann dieses Frida-Skript 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 dem folgenden Frida-Skript könnte es möglich sein, die von Android-Anwendungen verwendete bypass fingerprint authentication zu umgehen, um bestimmte sensible Bereiche zu schützen:

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

Hintergrundbilder

Wenn eine Anwendung in den Hintergrund gelegt wird, speichert Android einen Snapshot der Anwendung, sodass beim Wiederherstellen in den Vordergrund zuerst dieses Bild geladen wird, bevor die App startet, wodurch es so aussieht, als wäre die App schneller geladen.

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

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

Android bietet eine Möglichkeit, das Erfassen von Screenshots zu verhindern, indem man den Layout-Parameter FLAG_SECURE setzt. Durch die Verwendung dieses Flags 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 dir helfen, verschiedene Tools 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(...) weiterreichen, was riskant sein kann.

Die Gefahr besteht darin, Angreifern zu erlauben, nicht-exportierte App-Komponenten auszulösen oder auf sensitive content providers zuzugreifen, indem diese Intents fehlgeleitet werden. Ein bemerkenswertes Beispiel ist die WebView-Komponente, die URLs mittels Intent.parseUri(...) in Intent-Objekte umwandelt und diese dann ausführt, was potenziell zu Intent injections führen kann.

Essential Takeaways

  • Intent Injection ist ähnlich wie das Open Redirect-Problem im Web.
  • 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 providers für Angreifer offenlegen.
  • Die URL-zu-Intent-Konvertierung von WebView kann unbeabsichtigte Aktionen ermöglichen.

Android Client Side Injections and others

Wahrscheinlich kennst du diese Art von Schwachstellen aus dem Web. Bei Android-Anwendungen musst du besonders vorsichtig mit diesen Schwachstellen sein:

  • SQL Injection: Bei dynamischen Abfragen oder Content-Providern stelle sicher, dass parameterisierte Queries verwendet werden.
  • JavaScript Injection (XSS): Verifiziere, dass JavaScript- und Plugin-Support für alle WebViews deaktiviert ist (standardmäßig deaktiviert). More info here.
  • Local File Inclusion: Bei WebViews sollte der Zugriff auf das Dateisystem deaktiviert sein (standardmäßig aktiviert) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: In mehreren Fällen wird beim Beenden der Session durch die Android-Anwendung das cookie nicht zurückgezogen oder es kann sogar auf die Festplatte gespeichert werden
  • Secure Flag in cookies

Automatic Analysis

MobSF

Statische Analyse

Vulnerability assessment of the application using a nice web-based frontend. You can also perform dynamic analysis (but you need to prepare the environment).

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

Beachte, dass MobSF Android(apk), IOS(ipa) und Windows(apx) Anwendungen (Windows applications must be analyzed from a MobSF installed in a Windows host).
Außerdem, wenn du eine ZIP-Datei mit dem Quellcode einer Android- oder IOS-App erstellst (geh in den Root-Ordner der Anwendung, wähle alles aus und erstelle eine ZIPfile), kann es diese ebenfalls analysieren.

MobSF erlaubt außerdem, diff/Compare Analysen durchzuführen und VirusTotal zu integrieren (du musst deinen API-Schlüssel in MobSF/settings.py setzen und es aktivieren: VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). Du kannst VT_UPLOAD auch auf False setzen, dann wird statt der Datei der hash upload.

Unterstützte dynamische Analyse mit MobSF

MobSF kann auch bei der dynamischen Analyse von Android sehr hilfreich sein, aber in diesem Fall musst du MobSF und genymotion auf deinem Host installieren (eine VM oder Docker funktioniert nicht). Hinweis: Du musst start first a VM in genymotion und then MobSF.
Der MobSF dynamic analyser kann:

  • 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

Ab Android versions > 5 startet es Frida automatisch und setzt globale proxy-Einstellungen, um den Traffic zu erfassen. Es wird nur den Traffic der getesteten Anwendung erfassen.

Frida

Standardmäßig verwendet es außerdem einige Frida Scripts, um bypass SSL pinning, root detection und debugger detection sowie um monitor interesting APIs.
MobSF kann auch invoke exported activities, Screenshots davon erstellen und diese für den Report save.

Um das dynamische Testing zu start drücke den grünen Button: “Start Instrumentation”. Drücke “Frida Live Logs”, um die von den Frida-Scripts generierten Logs zu sehen, und “Live API Monitor”, um alle Invocations an gehookte Methoden, übergebene Argumente und Rückgabewerte zu sehen (das erscheint nach dem Drücken von “Start Instrumentation”).
MobSF erlaubt es auch, eigene Frida scripts zu laden (um die Ergebnisse deiner Frida scripts an MobSF zu senden, benutze die Funktion send()). Es hat außerdem several pre-written scripts, die du laden kannst (du kannst weitere in MobSF/DynamicAnalyzer/tools/frida_scripts/others/ hinzufügen), wähle sie einfach aus, drücke “Load” und dann “Start Instrumentation” (du kannst die Logs dieser Scripts in “Frida Live Logs” sehen).

Außerdem gibt es einige Auxiliary Frida-Funktionalitäten:

  • Enumerate Loaded Classes: Es gibt alle geladenen Klassen aus
  • Capture Strings: Es gibt alle capture strings aus, während die Anwendung benutzt wird (super noisy)
  • Capture String Comparisons: Kann sehr nützlich sein. Es wird die 2 strings, die verglichen werden, zeigen und ob das Ergebnis True oder False war.
  • Enumerate Class Methods: Gib den Klassennamen an (z. B. “java.io.File”) und es gibt alle Methoden der Klasse aus.
  • Search Class Pattern: Search classes by pattern
  • Trace Class Methods: Trace eine whole class (siehe Eingaben und Ausgaben aller Methoden der Klasse). Denk daran, dass MobSF standardmäßig mehrere interessante Android Api-Methoden trace.

Sobald du das Auxiliary-Modul ausgewählt hast, das du verwenden möchtest, musst du “Start Intrumentation” drücken und du wirst alle Ausgaben in “Frida Live Logs” sehen.

Shell

MobSF stellt außerdem eine Shell mit einigen adb commands, MobSF commands, und gängigen shell commands am unteren Rand der dynamic analysis Seite zur Verfügung. Einige interessante Kommandos:

help
shell ls
activities
exported_activities
services
receivers

HTTP-Tools

Wenn HTTP-Traffic erfasst wird, sehen Sie eine unansehnliche Ansicht des erfassten Verkehrs im Button “HTTP(S) Traffic” oder eine schönere Ansicht im grünen Button “Start HTTPTools”. Bei der zweiten Option können Sie 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ücken Sie “Send to Fuzzer” –> select the proxy address (http://127.0.0.1:8080\).

Sobald Sie die dynamische Analyse mit MobSF abgeschlossen haben, können Sie auf “Start Web API Fuzzer” klicken, um fuzz http requests und nach Schwachstellen zu suchen.

Tip

Nach der Durchführung einer dynamischen Analyse mit MobSF können die Proxy-Einstellungen fehlerhaft sein und sich nicht über die GUI beheben lassen. Sie können die Proxy-Einstellungen folgendermaßen korrigieren:

adb shell settings put global http_proxy :0

Unterstützte dynamische Analyse mit Inspeckage

Sie können das Tool von Inspeckage beziehen.
Dieses Tool verwendet einige Hooks, um Ihnen während einer dynamischen Analyse zu zeigen, was in der Anwendung passiert.

Yaazhini

Dies ist ein großartiges Tool, um statische Analyse mit einer GUI durchzuführen

Qark

Dieses Tool ist darauf ausgelegt, mehrere security related Android application vulnerabilities zu finden, 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 ist es nicht nötig, das Testgerät zu rooten.

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
  • 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äteinformationen
  • und mehr
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER ist eine command-line application, die unter Windows, MacOS X und Linux verwendet werden kann und .apk Dateien nach vulnerabilities analysiert. Sie macht dies, indem sie APKs dekomprimiert und eine Reihe von rules anwendet, um diese vulnerabilities zu erkennen.

Alle rules sind in einer rules.json Datei zentriert, und jedes Unternehmen oder jeder Tester kann eigene rules erstellen, um das zu analysieren, was benötigt wird.

Lade die neuesten binaries von der download page herunter

super-analyzer {apk_file}

StaCoAn

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

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

Herunterladen latest release:

./stacoan

AndroBugs

AndroBugs Framework ist ein System zur Analyse von Android-Schwachstellen, das Entwicklern oder hackers hilft, 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ösartiges Verhalten einer Android-Anwendung zu erkennen und den Benutzer zu warnen.

Die Erkennung erfolgt durch static analysis des Dalvik-Bytecodes der Anwendung, dargestellt als Smali, mit der Bibliothek androguard.

Dieses Tool sucht nach common behavior of “bad” applications 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 Mobile Application Reverse engineering and Analysis Framework. Es ist ein Tool, das häufig verwendete Reverse-Engineering- und Analyse-Tools für mobile Anwendungen zusammenführt, um beim Testen mobiler Apps gegen die OWASP mobile security threats zu unterstützen. Ziel ist es, diese Aufgabe für Mobile-App-Entwickler und Security-Professionals einfacher und nutzerfreundlicher zu machen.

Es kann:

  • Java- und Smali-Code mithilfe verschiedener Tools extrahieren
  • APKs analysieren mit: smalisca, ClassyShark, androbugs, androwarn, APKiD
  • Private Informationen aus der APK mittels regexps extrahieren.
  • Das Manifest analysieren.
  • Gefundene Domains analysieren mit: pyssltest, testssl und whatweb
  • APKs via [apk-deguard.com] deobfuskieren

Koodous

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

Obfuskierung/Deobfuskierung von Code

Beachte, dass abhängig vom Service und der Konfiguration, die du zum Obfuskieren des Codes verwendest, Geheimnisse möglicherweise obfuskiert sind oder nicht.

ProGuard

Aus Wikipedia: ProGuard ist ein Open-Source-Kommandozeilen-Tool, das Java-Code verkleinert, 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 verteilt.

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

DexGuard

Eine Schritt-für-Schritt-Anleitung zum Deobfuskieren der apk findest du unter https://blog.lexfo.fr/dexguard.html

(Aus diesem Guide) Als wir das letzte Mal nachgesehen haben, war der Betriebsmodus von DexGuard folgender:

  • load a resource as an InputStream;
  • feed the result to a class inheriting from FilterInputStream to decrypt it;
  • do some useless obfuscation to waste a few minutes of time from a reverser;
  • feed the decrypted result to a ZipInputStream to get a DEX file;
  • finally load the resulting DEX as a Resource using the loadDex method.

DeGuard

DeGuard kehrt den Obfuskierungsprozess um, der von Android-Obfuskierungstools durchgeführt wird. Dadurch werden zahlreiche Security-Analysen ermöglicht, einschließlich Code-Inspektion und Erkennung von Bibliotheken.

Du kannst eine obfuskierte APK auf deren Plattform hochladen.

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

Dies ist ein LLM-Tool, um mögliche Sicherheitslücken in Android-Apps zu finden und Android-App-Code zu deobfuskieren. Verwendet die öffentliche Google Gemini API.

Simplify

Es ist ein generischer Android-Deobfuskator. Simplify führt eine App virtuell aus, um ihr Verhalten zu verstehen, und versucht dann, den Code zu optimieren, sodass er sich identisch verhält, aber für einen Menschen leichter verständlich ist. Jede Optimierungsart ist einfach und generisch, daher ist es egal, welche konkrete Obfuskationstechnik verwendet wurde.

APKiD

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

Manual

Lies dieses Tutorial, um einige Tricks zum Reverse-Engineering benutzerdefinierter Obfuskation zu lernen

Labs

Androl4b

AndroL4b ist eine Android-Security-VM auf Basis von ubuntu-mate und enthält eine Sammlung aktueller Frameworks, Tutorials und Labs von verschiedenen Security-Geeks und Forschern für Reverse Engineering und Malware-Analyse.

Referenzen

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