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
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
Grundlagen zu Android-Anwendungen
Es wird dringend empfohlen, diese Seite zuerst zu lesen, um die wichtigsten Teile in Bezug auf Android-Sicherheit und die gefährlichsten Komponenten einer Android-Anwendung kennenzulernen:
ADB (Android Debug Bridge)
Dies ist das Hauptwerkzeug, das Sie benötigen, um sich mit einem 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 Tool 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.
Schauen Sie sich die folgende Liste der ADB Commands an, um zu lernen, wie man adb verwendet.
Smali
Manchmal ist es interessant, den Anwendungscode zu modifizieren, 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 als Alternative für mehrere Tests während der dynamischen Analyse sehr nützlich sein, die noch vorgestellt werden. Behalte dann immer diese Möglichkeit im Hinterkopf.
Weitere interessante Tricks
- Spoofing your location in Play Store
- Play Integrity attestation spoofing (SafetyNet replacement)
- Shizuku Privileged API (ADB-based non-root privileged access)
- Exploiting Insecure In-App Update Mechanisms
- Abusing Accessibility Services (Android RAT)
- Android IME / InputMethodService Abuse (Malicious Keyboards)
- NFC/EMV Relay via HCE (Android Tap-to-Pay abuse)
- Download APKs: https://apps.evozi.com/apk-downloader/, https://apkpure.com/es/, https://www.apkmirror.com/, https://apkcombo.com/es-es/apk-downloader/, https://github.com/kiber-io/apkd
- 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 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
Arm64 Static Linear Map Kaslr Bypass
Static Analysis
Zunächst sollten Sie bei der Analyse einer APK den Java-Code mit einem Decompiler ansehen.
Bitte lesen Sie hier, um Informationen zu den verschiedenen verfügbaren Decompilern zu finden.
Looking for interesting Info
Allein durch das Betrachten der strings der APK können Sie nach Passwörtern, URLs (https://github.com/ndelphit/apkurlgrep), api-Schlüsseln, Verschlüsselung, bluetooth uuids, tokens und allem Interessanten suchen… achten Sie auch auf Codeausführungs-backdoors oder Authentifizierungs-Backdoors (hardcodierte Admin-Zugangsdaten in der App).
Firebase
Achten Sie besonders auf firebase URLs und prüfen Sie, ob diese falsch konfiguriert sind. Mehr Informationen darüber, was Firebase ist und wie man es ausnutzen kann, finden Sie 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 man mit Decompilern zugreifen oder indem man die APK-Endung in .zip ändert und diese dann entpackt.
Vulnerabilities, die aus der Manifest.xml identifiziert werden können, umfassen:
- Debuggable Applications: Anwendungen, die als debuggable (
debuggable="true") in der Manifest.xml gesetzt 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 auf einem Gerät findet und ausnutzt, siehe ein Tutorial dazu. - Backup Settings: Das Attribut
android:allowBackup="false"sollte explizit für Anwendungen gesetzt werden, die mit sensiblen Informationen arbeiten, um unautorisierte Datenbackups via adb zu verhindern, insbesondere wenn usb debugging aktiviert ist. - Network Security: Benutzerdefinierte network security Konfigurationen (
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: Das Identifizieren von exportierten Activities und Services im Manifest kann Komponenten hervorheben, die missbraucht werden könnten. Weitere Analyse während dynamischer Tests kann zeigen, wie diese Komponenten ausgenutzt werden können.
- Content Providers and FileProviders: Offen exponierte Content Provider 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, wobei besonderes Augenmerk darauf zu legen ist, wie URL-Schemata für Eingaben gehandhabt werden.
- SDK Versions: Die Attribute
minSdkVersion,targetSDKVersionundmaxSdkVersiongeben die unterstützten Android-Versionen an und machen deutlich, warum es wichtig ist, keine veralteten, verwundbaren Android-Versionen zu unterstützen.
Aus der strings.xml-Datei können sensible Informationen wie API-Schlüssel, benutzerdefinierte 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 oberhalb einer Opferanwendung positioniert. Sobald sie die Opfer-App sichtbar überdeckt, ist ihre Benutzeroberfläche so gestaltet, dass sie den Benutzer zum Interagieren verleitet, während sie die Interaktion an die Opfer-App weitergibt.
Effektiv blendet sie den Benutzer aus, sodass er nicht weiß, dass er tatsächlich Aktionen auf der Opfer-App ausführt.
Weitere Informationen finden Sie in:
Task Hijacking
Eine activity mit launchMode auf singleTask gesetzt ohne definierte taskAffinity ist anfällig für Task Hijacking. Das bedeutet, dass eine application installiert werden kann, die, wenn sie vor der echten Anwendung gestartet wird, die Task der echten Anwendung hijacken könnte (so dass der Benutzer mit der malicious application interagiert und denkt, er benutze die echte).
Mehr Infos in:
Insecure data storage
Interner Speicher
In Android sind Dateien, die im internal storage abgelegt werden, so ausgelegt, dass sie ausschließlich von der app, die sie erstellt hat, zugänglich sind. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem durchgesetzt und ist für die meisten Anwendungen in der Regel ausreichend. Entwickler verwenden jedoch manchmal Modi wie MODE_WORLD_READABLE und MODE_WORLD_WRITABLE, um Dateien zwischen verschiedenen Anwendungen zu teilen. Diese Modi schränken den Zugriff auf diese Dateien jedoch nicht ein, sodass andere Anwendungen, einschließlich potenziell bösartiger, darauf zugreifen können.
- Static Analysis:
- Stellen Sie sicher, dass die Verwendung von
MODE_WORLD_READABLEundMODE_WORLD_WRITABLEsorgfältig geprüft wird. Diese Modi können Dateien unbeabsichtigt oder unautorisiert zugänglich machen.
- Dynamic Analysis:
- Überprüfen Sie die Berechtigungen für Dateien, die von der App erstellt werden. Prüfen Sie insbesondere, ob Dateien für alle lesbar oder schreibbar gesetzt sind. Das stellt ein erhebliches Sicherheitsrisiko dar, da jede auf dem Gerät installierte Anwendung, unabhängig von Herkunft oder Absicht, diese Dateien lesen oder ändern könnte.
Externer Speicher
Beim Umgang mit Dateien auf external storage, wie SD-Karten, sollten bestimmte Vorsichtsmaßnahmen getroffen werden:
- Zugänglichkeit:
- Dateien auf external storage sind global lesbar und schreibbar. Das bedeutet, dass jede Anwendung oder jeder Benutzer auf diese Dateien zugreifen kann.
- Sicherheitsbedenken:
- Aufgrund der einfachen Zugänglichkeit sollte keine sensiblen Informationen auf external storage gespeichert werden.
- External storage kann entfernt werden oder von jeder Anwendung gelesen werden, wodurch es weniger sicher ist.
- Umgang mit Daten aus dem externen Speicher:
- Führen Sie stets Input-Validation für Daten durch, die aus external storage gelesen werden. Das ist entscheidend, da die Daten aus einer untrusted Quelle stammen.
- Das Speichern von ausführbaren Dateien oder class files auf external storage zur dynamischen Ladung wird dringend abgeraten.
- Falls Ihre Anwendung ausführbare Dateien aus external storage laden muss, stellen Sie sicher, dass diese Dateien signiert und kryptografisch verifiziert sind, bevor sie dynamisch geladen werden. Dieser Schritt ist wichtig, um die Sicherheitsintegrität Ihrer Anwendung zu wahren.
External storage kann unter /storage/emulated/0, /sdcard, /mnt/sdcard erreicht 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. Dies verhindert, dass bösartige Anwendungen Lese- oder Schreibzugriff auf die Dateien einer anderen App erlangen.
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 können in diesem Ordner sensible Informationen im Klartext gefunden werden. - Databases: Android erlaubt jeder Anwendung, sqlite-Datenbanken im Pfad
/data/data/<packagename>/databases/zu speichern, und manchmal können in diesem Ordner sensible Informationen im Klartext gefunden werden.
Broken TLS
Accept All Certificates
Aus irgendeinem Grund akzeptieren Entwickler manchmal alle Zertifikate, selbst wenn beispielsweise der Hostname nicht übereinstimmt, mit Codezeilen wie der folgenden:
SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
Eine gute Möglichkeit, 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 können Sie mit Burp ein Zertifikat für einen anderen Hostnamen erzeugen und verwenden.
Fehlerhafte Kryptographie
Schlechte Schlüsselverwaltung
Einige Entwickler speichern sensitive Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hardcoded/predictable Schlüssel. Das sollte nicht gemacht werden, da Reverse-Engineering 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 z. B. zum Speichern von Passwörtern verwendet werden, sollten salt-geschützte, brute-force resistant hashes eingesetzt werden.
Weitere Prüfungen
- Es wird empfohlen, das APK zu obfuscate the APK, um die Arbeit des Reverse-Engineerings für Angreifer zu erschweren.
- Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie eigene own checks to see if the mobile is rooted durchführen 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 ihre eigene Integrität vor der Ausführung prüfen, um festzustellen, ob sie verändert wurde.
- Verwenden Sie APKiD, um zu prüfen, welcher Compiler/Packager/Obfuscator zum Erstellen des APK verwendet wurde
React Native Application
Lesen Sie die folgende Seite, um zu lernen, wie man einfach auf den javascript code von React-Anwendungen zugreift:
Xamarin Applications
Lesen Sie die folgende Seite, um zu lernen, wie man einfach auf C#-Code einer xamarin applications zugreift:
Superpacked Applications
Laut diesem blog post ist superpacked ein Meta-Algorithmus, der den Inhalt einer Anwendung in eine einzelne Datei komprimiert. Der Blog behandelt 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 vom Dateisystem zu sammeln.
Automatisierte statische Code-Analyse
Das Tool mariana-trench ist in der Lage, vulnerabilities zu finden, indem es den code der Anwendung scans. 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 Schäden verursachen könnten) und rules. Diese Regeln geben die Kombination von sources-sinks an, die auf eine Schwachstelle hinweist.
Mit diesem Wissen wird mariana-trench den Code prüfen und mögliche vulnerabilities darin finden.
Secrets leaked
Eine Anwendung kann Secrets (API keys, passwords, versteckte urls, Subdomains…) enthalten, die Sie möglicherweise entdecken können. Sie können ein Tool wie https://github.com/dwisiswant0/apkleaks verwenden.
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 - Lies das, um zu lernen how to reverse native functions
- In-memory native code execution via JNI (downloaded shellcode → mmap/mprotect → call):
In Memory Jni Shellcode Execution
Other tricks
Dynamische Analyse
Zunächst benötigen Sie eine Umgebung, in der Sie die Anwendung und die gesamte Umgebung (vor allem Burp CA cert, Drozer und Frida) installieren können. Daher wird ein rooted Gerät (emuliert oder nicht) dringend empfohlen.
Online Dynamic analysis
Sie können ein kostenloses Konto bei https://appetize.io/ erstellen. Diese Plattform erlaubt das Hochladen und Ausführen von APKs, sodass sie nützlich ist, um zu sehen, wie sich ein APK verhält.
Sie können sogar die Logs Ihrer Anwendung im Web sehen und sich über adb verbinden.
.png)
Dank der ADB-Verbindung können Sie Drozer und Frida in den Emulatoren verwenden.
Lokale dynamische Analyse
Verwendung eines Emulators
- Android Studio (Sie können x86- und arm-Geräte erstellen, und laut diesem** unterstützen neuere x86** Versionen ARM-Libraries ohne einen langsamen ARM-Emulator).
- Lernen Sie, es auf dieser Seite einzurichten:
- Genymotion (Kostenlose Version: Personal Edition, Sie müssen ein Konto erstellen. Es wird empfohlen, die Version WITH VirtualBox herunterzuladen, um mögliche Fehler zu vermeiden.)
- Nox (Kostenlos, unterstützt jedoch kein Frida oder Drozer).
Tip
Beim Erstellen eines neuen Emulators auf jeder Plattform bedenken Sie, dass je größer der Bildschirm ist, desto langsamer der Emulator läuft. Wählen Sie also wenn möglich kleine Bildschirme.
Um google services (wie AppStore) in Genymotion zu installieren, müssen Sie auf die rot markierte Schaltfläche des folgenden Bildes klicken:
.png)
Beachten Sie außerdem, dass Sie in der Konfiguration der Android VM in Genymotion den Bridge Network mode auswählen können (das ist nützlich, wenn Sie von einer anderen VM aus eine Verbindung zur Android-VM mit den Tools herstellen möchten).
Verwendung eines physischen Geräts
Sie müssen die Debugging-Optionen aktivieren und es ist vorteilhaft, wenn Sie es rooten können:
- Einstellungen.
- (Ab Android 8.0) Wählen Sie System.
- Wählen Sie Über das Telefon.
- Drücken Sie Build number 7 Mal.
- Gehen Sie zurück und Sie finden die Entwickleroptionen.
Sobald Sie die Anwendung installiert haben, sollten Sie sie zuerst ausprobieren und untersuchen, was sie tut, wie sie funktioniert und sich mit ihr vertraut machen.
Ich empfehle, diese initiale dynamische Analyse mit MobSF dynamic analysis + pidcat durchzuführen, damit wir lernen, wie die Anwendung funktioniert, während MobSF viele interessante Daten erfasst, die Sie später überprüfen können.
Magisk/Zygisk Kurzanmerkungen (empfohlen bei Pixel-Geräten)
- Boot.img mit der Magisk-App patchen und per fastboot flashen, um systemless root zu erhalten
- Zygisk + DenyList aktivieren, um Root zu verbergen; ziehen Sie LSPosed/Shamiko in Betracht, wenn ein stärkeres Verbergen erforderlich ist
- Behalten Sie das originale boot.img, um sich von OTA-Updates zu erholen; nach jedem OTA neu patchen
- Für Screen-Mirroring verwenden Sie scrcpy auf dem Host
Unintended Data Leakage
Logging
Entwickler sollten vorsichtig sein, Debug-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 Benutzerfreundlichkeit und Lesbarkeit bevorzugt.
Warning
Beachten Sie, dass seit späteren neueren als Android 4.0 Anwendungen nur auf ihre eigenen Logs zugreifen können. Anwendungen können also nicht die Logs anderer Apps einsehen.
Trotzdem wird empfohlen, keine sensiblen Informationen zu loggen.
Copy/Paste-Zwischenablage
Das auf der Zwischenablage basierende Framework von Android ermöglicht Copy-Paste-Funktionalität in Apps, birgt jedoch ein Risiko, da andere Anwendungen auf die Zwischenablage access können und dadurch sensible Daten exponiert werden können. Es ist wichtig, Copy/Paste-Funktionen für sensible Bereiche einer Anwendung, wie Kreditkartendaten, zu deaktivieren, um data leaks zu vermeiden.
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, vermeiden Sie Logging bei Crashes, und falls Logs über das Netzwerk gesendet werden müssen, stellen Sie sicher, dass sie über einen SSL-Kanal übertragen werden.
Als pentester sollten Sie versuchen, sich diese Logs anzusehen.
Analytics Data Sent To 3rd Parties
Anwendungen integrieren oft Dienste wie Google Adsense, die durch fehlerhafte Implementierung der Entwickler unbeabsichtigt leak sensitive data können. Um mögliche data leaks zu identifizieren, empfiehlt es sich, 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. Prüfen Sie während des Pentests die erstellten Databases, die Namen der Tables und Columns und alle gespeicherten Daten, da Sie dort sensitive information finden könnten (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 encrypted ist, Sie jedoch das password innerhalb der Anwendung find können, ist das trotzdem eine vulnerability.
Enumerieren Sie die Tabellen mit .tables und listen Sie die Spalten der Tabellen mit .schema <table_name> auf.
Drozer (Exploit Activities, Content Providers and Services)
Aus den Drozer Docs: Drozer erlaubt es Ihnen, 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 darunter liegenden Betriebssystem interagieren. .
Drozer ist ein nützliches Tool, um exported activities, exported services und Content Providers auszunutzen, wie Sie in den folgenden Abschnitten lernen werden.
Exploiting exported Activities
Read this if you want to refresh what is an Android Activity.
Denken Sie auch daran, dass der Code einer Activity in der onCreate-Methode startet.
Authorisation bypass
Wenn eine Activity exportiert ist, können Sie ihren Bildschirm von einer externen App aus aufrufen. Daher, wenn eine Activity mit sensitive information exported ist, könnten Sie die authentication-Mechanismen bypass, um darauf zuzugreifen.
Learn how to exploit exported activities with Drozer.
Sie können eine exportierte Activity auch ü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 diesem PR ist das offenbar nur auf alten Versionen gefährlich (API versions < 21).
Tip
Beachte, dass ein authorisation bypass nicht immer eine Schwachstelle ist; das hängt davon ab, wie der bypass funktioniert und welche Informationen offengelegt werden.
Sensitive information leakage
Activities can also return results. Wenn du es schaffst, 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önntest du die exportierte activity missbrauchen, um den Benutzer dazu zu bringen, unerwartete Aktionen auszuführen. Für mehr Informationen zu was Tapjacking ist, folge dem Link.
Exploiting Content Providers - Accessing and manipulating sensitive information
Lies das, wenn du auffrischen willst, was ein Content Provider ist.
Content providers werden im Grunde verwendet, um Daten zu teilen. Wenn eine App Content providers bereitstellt, kannst du möglicherweise sensible Daten daraus extrahieren. Es ist außerdem interessant, mögliche SQL injections und Path Traversals zu testen, da diese verwundbar sein könnten.
Lerne, wie man Content Providers mit Drozer ausnutzt.
Exploiting Services
Lies das, wenn du auffrischen willst, was ein Service ist.
Denke daran, dass die Aktionen eines Service in der Methode onStartCommand beginnen.
Ein Service ist im Grunde etwas, das Daten empfangen kann, diese verarbeitet und (möglicherweise) eine Antwort zurückgibt. Wenn eine Anwendung also Services exportiert, solltest du den Code prüfen, um zu verstehen, was er macht, und ihn dynamisch testen, um vertrauliche Informationen zu extrahieren, Authentifizierungsmaßnahmen zu umgehen…
Lerne, wie man Services mit Drozer ausnutzt.
Exploiting Broadcast Receivers
Lies das, wenn du auffrischen willst, was ein Broadcast Receiver ist.
Denke daran, dass die Aktionen eines Broadcast Receiver in der Methode onReceive starten.
Ein Broadcast Receiver wartet auf einen bestimmten Nachrichtentyp. Je nachdem, wie der Receiver die Nachricht verarbeitet, könnte er verwundbar sein.
Lerne, wie man Broadcast Receivers mit Drozer ausnutzt.
Exploiting Schemes / Deep links
Du kannst nach deep links manuell suchen, mit Tools wie MobSF oder Skripten wie diesem.
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 Paketnamen 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 zu der Activity, die vom deeplink aufgerufen wird, und suche die Funktion onNewIntent.
 (1) (1) (1).png)
Sensible Informationen
Jedes Mal, wenn du einen deeplink findest, überprüfe, dass er keine sensiblen Daten (wie Passwörter) über URL-Parameter erhält, da jede andere Anwendung den deeplink vortäuschen und diese Daten stehlen könnte!
Parameter im Pfad
Du musst außerdem prüfen, ob ein deeplink einen Parameter im Pfad der URL verwendet, z. B.: https://api.example.com/v1/users/{username}, in diesem Fall kannst du eine path traversal erzwingen, indem du etwas wie: example://app/users?username=../../unwanted-endpoint%3fparam=value aufrufst .
Beachte, dass du, wenn du die korrekten Endpoints in der Anwendung findest, möglicherweise eine Open Redirect (wenn ein Teil des Pfads als Domainname verwendet wird), account takeover (wenn du Benutzerdaten ohne CSRF-Token ändern kannst und der verwundbare Endpoint die richtige Methode verwendet) und jede andere vuln verursachen kannst. Mehr info about this here.
Weitere Beispiele
Ein interessanter Bug-Bounty-Bericht über Links (/.well-known/assetlinks.json).
Inspektion der Transportschicht und Verifikationsfehler
- Certificates are not always inspected properly von Android-Anwendungen. Es ist üblich, dass diese Anwendungen Warnungen übersehen und self-signed certificates akzeptieren oder in manchen Fällen auf HTTP-Verbindungen zurückfallen.
- Negotiations during the SSL/TLS handshake are sometimes weak, es werden unsichere cipher suites verwendet. 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 stellt ein Risiko dar, wenn Anwendungen sich über sichere Kanäle authentifizieren, aber für andere Transaktionen über nicht sichere Kanäle kommunizieren. Dieser Ansatz schützt sensitive data wie Session-Cookies oder Benutzerdetails nicht vor dem Abfangen durch bösartige Akteure.
Zertifikatsprüfung
Wir konzentrieren uns auf certificate verification. 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 im App-Paket gespeicherte, bekannte Kopie prüft. Diese Methode ist essenziell zur Verhinderung von MITM-Angriffen. Die Implementierung von SSL Pinning wird dringend empfohlen für Anwendungen, die sensitive informationen verarbeiten.
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 zum Installieren eines benutzerdefinierten CA-Zertifikats, click here.
Apps, die auf API Level 24 and above abzielen, benötigen Änderungen an der Network Security Config, um das CA-Zertifikat des Proxys zu akzeptieren. Dieser Schritt ist kritisch, um verschlüsselten Traffic zu inspizieren. Für Anweisungen zur Änderung der Network Security Config, refer to this tutorial.
Wenn Flutter verwendet wird, musst du den Anweisungen auf this page folgen. Das liegt daran, dass das bloße Hinzufügen des Zertifikats in den Store nicht ausreicht, da Flutter eine eigene Liste gültiger CAs hat.
Statische Erkennung von SSL/TLS pinning
Bevor du Runtime-Bypässe versuchst, mappe schnell, wo pinning im APK durchgesetzt wird. Statische Erkennung hilft dir, Hooks/Patches zu planen und dich auf die richtigen Code-Pfade zu konzentrieren.
Tool: SSLPinDetect
- Open-source static-analysis utility, das das APK in Smali dekompiliert (via apktool) und nach kuratierten regex-Mustern von SSL/TLS pinning Implementierungen scannt.
- Meldet den genauen Dateipfad, die Zeilennummer und einen Codeausschnitt für jeden Treffer.
- Deckt gängige Frameworks und custom code paths 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 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
Beispielmusterregeln (JSON) Verwende oder erweitere Signaturen, um proprietäre/benutzerdefinierte pinning‑Stile zu erkennen. Du kannst dein eigenes JSON laden und im großen Maßstab scannen.
{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}
Notes and tips
- Schnelles Scannen großer Apps mittels Multithreading und memory-mapped I/O; vorcompilierte 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
- Benutzerdefinierte TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
- Benutzerdefinierte SSL-Kontexte: SSLContext.getInstance + SSLContext.init mit benutzerdefinierten Managern
- Deklarative Pins in res/xml network security config und Verweise im Manifest
- Nutze 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 notwendig, um HTTPS-Traffic zu inspizieren. Dafür stehen verschiedene Methoden zur Verfügung:
- Automatisch modifiziere die apk, um SSLPinning mit apk-mitm zu umgehen. Der größte Vorteil dieser Option ist, dass du kein Root benötigst, um das SSL Pinning zu umgehen, aber du musst die Anwendung löschen und die neue installieren, und das funktioniert nicht immer.
- Du kannst Frida (weiter unten besprochen) nutzen, um diesen Schutz zu umgehen. Hier ist ein Guide für Burp+Frida+Genymotion: https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/
- Du kannst auch versuchen, automatisch das SSL Pinning zu umgehen mit objection:
objection --gadget com.package.app explore --startup-command "android sslpinning disable" - Du kannst auch versuchen, automatisch das SSL Pinning zu umgehen mit MobSF dynamic analysis (weiter unten erklärt)
- Wenn du immer noch denkst, dass Traffic fehlt, kannst du versuchen, den Traffic mithilfe von 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, in der Anwendung auch nach gängigen Web-Schwachstellen zu suchen. Detaillierte Informationen zum Identifizieren und Beheben dieser Schwachstellen gehen über diese Zusammenfassung hinaus, werden aber ausführlich an anderer Stelle behandelt.
Frida
Frida ist ein dynamisches Instrumentierungs-Toolkit für Entwickler, Reverse-Engineer und Sicherheitsforscher.
Du kannst auf laufende Anwendungen zugreifen und zur Laufzeit Methoden hooken, um das Verhalten zu ändern, Werte zu verändern, Werte zu extrahieren, anderen Code auszuführen…
Wenn du Android-Anwendungen pentesten willst, musst du wissen, wie man Frida benutzt.
- Learn how to use Frida: Frida tutorial
- Some “GUI” for actions with Frida: https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security
- Ojection is great to automate the use of Frida: https://github.com/sensepost/objection , https://github.com/dpnishant/appmon
- You can find some Awesome Frida scripts here: https://codeshare.frida.re/
- Try to bypass anti-debugging / anti-frida mechanisms loading Frida as in indicated in https://erfur.github.io/blog/dev/code-injection-without-ptrace (tool linjector)
Anti-instrumentation & SSL pinning bypass workflow
Android Anti Instrumentation And Ssl Pinning Bypass
Speicher auslesen - Fridump
Prüfe, ob die Anwendung sensible Informationen im Speicher ablegt, die dort nicht gespeichert werden sollten, z. B. Passwörter oder mnemonics.
Mit Fridump3 kannst du den Speicher der App dumpen mit:
# With PID
python3 fridump3.py -u <PID>
# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"
Dies wird den Speicher im Ordner ./dump ausgeben, 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
Unter Android ist der Keystore der beste Ort, um sensible Daten zu speichern. Mit ausreichenden Rechten ist es jedoch weiterhin möglich, darauf zuzugreifen. Da Anwendungen hier oft sensible Daten im Klartext ablegen, 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 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, bypass fingerprint authentication bei Android-Anwendungen zu realisieren, die eingesetzt werden, um bestimmte sensible Bereiche zu 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. Beim Wiederherstellen in den Vordergrund wird dieses Bild geladen, bevor die App selbst vollständig gestartet ist, sodass es so aussieht, als sei die App schneller geladen.
Wenn dieser Snapshot jedoch sensible Informationen enthält, könnte jemand mit Zugriff auf den Snapshot diese Informationen stehlen (Hinweis: zum Zugriff ist root erforderlich).
Die Snapshots werden üblicherweise gespeichert unter: /data/system_ce/0/snapshots
Android bietet eine Möglichkeit, die Erfassung 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 können.
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
Android Application Analyzer
Dieses Tool kann Ihnen 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 ermöglichen, nicht-exportierte App-Komponenten auszulösen oder durch Umleiten dieser Intents auf sensible content providers zuzugreifen. 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.
Wesentliche Erkenntnisse
- 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. - Dadurch können nicht-exportierte Komponenten und content providers für Angreifer offengelegt werden.
- Die URL-zu-
Intent-Konvertierung vonWebViewkann unbeabsichtigte Aktionen ermöglichen.
Android Client Side Injections und andere
Wahrscheinlich kennen Sie diese Art von Schwachstellen aus dem Web. Bei Android-Anwendungen müssen Sie besonders vorsichtig mit diesen Schwachstellen sein:
- SQL Injection: Beim Umgang mit dynamischen Abfragen oder Content-Providers sollten Sie parametrisierte Abfragen verwenden.
- JavaScript Injection (XSS): Verify that JavaScript and Plugin support is disabled for any WebViews (disabled by default). More info here.
- Local File Inclusion: WebViews should have access to the file system disabled (enabled by default) -
(webview.getSettings().setAllowFileAccess(false);). More info here. - Eternal cookies: In mehreren Fällen wird, wenn die Android-Anwendung die Session beendet, das Cookie nicht widerrufen oder es kann sogar auf die Festplatte gespeichert werden
- Secure Flag in cookies
Automatische Analyse
MobSF
Statische Analyse
.png)
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
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.
Unterstützte dynamische Analyse mit MobSF
MobSF kann auch sehr hilfreich für dynamic analysis in Android sein, aber in diesem Fall musst du MobSF und genymotion auf deinem Host installieren (a VM or Docker won’t work). Note: You need to start first a VM in genymotion and 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
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”).
.png)
Moreover, you have some Auxiliary Frida functionalities:
- Enumerate Loaded Classes: Es listet alle geladenen Klassen auf
- Capture Strings: Gibt alle capture strings während der Nutzung der Anwendung aus (sehr viele Ausgaben)
- Capture String Comparisons: Kann sehr nützlich sein. Es zeigt die 2 Strings, die verglichen werden, und ob das Ergebnis True oder False war.
- Enumerate Class Methods: Gib den Klassennamen an (z. B. “java.io.File”) und es werden alle Methoden der Klasse ausgegeben.
- Search Class Pattern: Suche Klassen nach Muster
- Trace Class Methods: Trace eine ganze Klasse (zeigt Eingaben und Ausgaben aller Methoden der Klasse). Denk daran, dass MobSF standardmäßig bereits mehrere interessante Android Api-Methoden trace’t.
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 stellt dir 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 Befehle:
help
shell ls
activities
exported_activities
services
receivers
HTTP-Tools
When http traffic is capture you can see an ugly view of the captured traffic on “HTTP(S) Traffic” bottom or a nicer view in “Start HTTPTools” green bottom. From the second option, you can send the captured requests to proxies like Burp or Owasp ZAP.
To do so, power on Burp –> turn off Intercept –> in MobSB HTTPTools select the request –> press “Send to Fuzzer” –> select the proxy address (http://127.0.0.1:8080\).
Sobald du die dynamische Analyse mit MobSF abgeschlossen hast, kannst du auf “Start Web API Fuzzer” klicken, um http requests zu fuzzen und nach Schwachstellen zu suchen.
Tip
Nach einer dynamischen Analyse mit MobSF können die Proxy-Einstellungen falsch konfiguriert sein und sich nicht über die GUI beheben lassen. Du kannst die Proxy-Einstellungen folgendermaßen reparieren:
adb shell settings put global http_proxy :0
Assisted Dynamic Analysis with Inspeckage
You can get the tool from Inspeckage.
Dieses Tool verwendet einige Hooks, um dir während einer dynamischen Analyse zu zeigen, was in der Anwendung passiert.
Yaazhini
This is a great tool to perform static analysis with a GUI
.png)
Qark
Dieses Tool ist darauf ausgelegt, verschiedene sicherheitsrelevante Android-Anwendungs-Schwachstellen zu finden, entweder im source code oder in packaged APKs. Das Tool ist außerdem in der Lage, eine deploybare “Proof-of-Concept” APK und ADB commands zu erstellen, 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 an
- Dekompiliert APK-Dateien automatisch in Java- und Smali-Format
- Analysiert AndroidManifest.xml auf common vulnerabilities und Verhalten
- Statische Quellcodeanalyse auf common vulnerabilities und Verhalten
- Geräteinformationen
- 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 auf Schwachstellen untersucht. Sie macht dies, indem sie APKs dekomprimiert und eine Reihe von Regeln anwendet, um diese Schwachstellen zu erkennen.
Alle Regeln sind zentral in einer rules.json Datei, und jedes Unternehmen oder jeder Tester kann eigene Regeln erstellen, um das zu analysieren, was sie benötigen.
Lade die neuesten Binärdateien von der download page herunter
super-analyzer {apk_file}
StaCoAn
.png)
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 erstellt. Sie können die Einstellungen und wordlists anpassen, um ein maßgeschneidertes Erlebnis zu erhalten.
Download 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 Hauptziel es ist, potenziell bösartige Verhaltensweisen einer Android-Anwendung zu erkennen und den Nutzer zu warnen.
Die Erkennung erfolgt durch die statische Analyse des Dalvik-Bytecodes der Anwendung, der als Smali dargestellt wird, mithilfe der Bibliothek androguard.
Dieses Tool sucht nach typischen Verhaltensweisen 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
.png)
MARA ist ein Mobile Application Reverse engineering and Analysis Framework. Es ist ein Tool, das gängig verwendete Tools für Reverse Engineering und Analyse von mobilen Anwendungen zusammenführt, um beim Testen von mobilen Anwendungen gegen die OWASP mobile security threats zu unterstützen. Ziel ist es, diese Aufgabe für mobile application developers und security professionals einfacher und zugänglicher zu machen.
Es kann:
- Java- und Smali-Code mit verschiedenen 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
- APK via [apk-deguard.com] deobfuscate
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 obfuskiert sind oder nicht.
ProGuard
From Wikipedia: ProGuard ist ein Open-Source-Kommandozeilen-Tool, das Java-Code schrumpft, optimiert und obfuskiert. Es kann Bytecode optimieren sowie ungenutzte Instruktionen erkennen und 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
Find a step-by-step guide to deobfuscate the apk in https://blog.lexfo.fr/dexguard.html
(Laut dieser Anleitung) Beim letzten Mal, als wir nachgesehen haben, war der DexGuard-Betriebsmodus:
- lädt eine Ressource als InputStream;
- leitet das Ergebnis an eine Klasse, die von FilterInputStream erbt, um es zu decrypten;
- führt einige nutzlose Obfuskationen durch, um einem Reverser ein paar Minuten Zeit zu rauben;
- leitet das entschlüsselte Ergebnis an einen ZipInputStream, um eine DEX-Datei zu erhalten;
- lädt schließlich die resultierende DEX als Resource mittels der
loadDex-Methode.
DeGuard
DeGuard kehrt den Obfuskationsprozess um, der von Android-Obfuskationstools durchgeführt wird. Dies ermöglicht zahlreiche Sicherheitsanalysen, einschließlich Code-Inspektion und das Vorhersagen/Erkennen von Libraries.
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 security vulnerabilities in android apps zu finden und Android-App-Code zu deobfuscate. Verwendet die öffentliche Gemini-API von Google.
Simplify
Es ist ein generischer android deobfuscator. Simplify führt eine Anwendung virtuell aus, um ihr Verhalten zu verstehen, und versucht dann, den Code so zu optimieren, dass er sich identisch verhält, aber für einen Menschen leichter zu verstehen ist. Jeder Optimierungstyp ist einfach und generisch, daher spielt es keine Rolle, welche spezifische Art von Obfuskation verwendet wurde.
APKiD
APKiD gibt dir Informationen darüber, wie eine APK erstellt wurde. Es identifiziert viele compilers, packers, obfuscators und andere merkwürdige Dinge. Es ist das 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 enthält eine Sammlung der neuesten Frameworks, Tutorials und Labs von verschiedenen Security-Geeks und Forschern für Reverse Engineering und Malware-Analyse.
References
- Play Integrity API: How It Works & How to Bypass It
- https://owasp.org/www-project-mobile-app-security/
- https://appsecwiki.com/#/ It is a great list of resources
- https://maddiestone.github.io/AndroidAppRE/ Android quick course
- https://manifestsecurity.com/android-application-security/
- https://github.com/Ralireza/Android-Security-Teryaagh
- https://www.youtube.com/watch?v=PMKnPaGWxtg&feature=youtu.be&ab_channel=B3nacSec
- SSLPinDetect: Advanced SSL Pinning Detection for Android Security Analysis
- SSLPinDetect GitHub
- smali-sslpin-patterns
- Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa
- CoRPhone — Android in-memory JNI execution and packaging pipeline
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
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.


