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, mit dem Lesen dieser Seite zu beginnen, um die wichtigsten Bereiche im Zusammenhang mit Android-Sicherheit und die gefährlichsten Komponenten in einer Android-Anwendung kennenzulernen:

Android Applications Basics

ADB (Android Debug Bridge)

Dies ist das Hauptwerkzeug, mit dem Sie ein Android-Gerät (emuliert oder physisch) verbinden können.
ADB ermöglicht es, Geräte entweder über USB oder Netzwerk von einem Computer aus zu steuern. Dieses Tool erlaubt das Kopieren von Dateien in beide Richtungen, die Installation und Deinstallation von Apps, die Ausführung von Shell-Kommandos, das Sichern von Daten, das Lesen von Logs, sowie weitere Funktionen.

Sieh dir die folgende Liste der ADB-Befehle an, um zu erfahren, wie man adb benutzt.

Smali

Manchmal ist es interessant, den Anwendungscode zu ändern, um auf versteckte Informationen zuzugreifen (z. B. stark obfuskierte Passwörter oder Flags). In solchen Fällen kann es sinnvoll sein, die APK zu dekompilieren, den Code zu ändern und neu zu kompilieren.
In diesem Tutorial kannst du lernen, wie man eine APK dekompiliert, Smali-Code ändert und die APK mit der neuen Funktionalität rekonstruiert. Das kann sehr nützlich als Alternative für verschiedene Tests während der dynamischen Analyse sein, die noch vorgestellt werden. Behalte diese Möglichkeit immer im Hinterkopf.

Weitere interessante Tricks

adb shell pm list packages
com.android.insecurebankv2

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

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

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

Android Enterprise & Work Profile Attacks

Android Enterprise Work Profile Bypass

Fallstudien & Schwachstellen

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

Statische Analyse

Zunächst sollten Sie eine APK analysieren, indem Sie den Java-Code mit einem Decompiler ansehen.
Bitte lesen Sie hier, um Informationen über verfügbare Decompiler zu finden.

Nach interessanten Informationen suchen

Schon durch das Betrachten der strings einer 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 sogar auf Code-Execution backdoors oder Authentifizierungs-backdoors (hardcodierte Admin-Zugangsdaten in der App).

Firebase

Achten Sie besonders auf firebase URLs und prüfen Sie, ob sie falsch konfiguriert sind. Mehr Informationen darüber, was Firebase ist und wie man es ausnutzen kann, hier.

Grundlegendes Verständnis der Anwendung - Manifest.xml, strings.xml

Die Untersuchung der Manifest.xml- und strings.xml-Dateien einer Anwendung kann potenzielle Sicherheitslücken offenbaren. Auf diese Dateien kann man mit Decompilern zugreifen oder indem man die APK-Endung in .zip umbenennt und sie dann entpackt.

Aus der Manifest.xml identifizierte Vulnerabilities umfassen:

  • Debuggable Applications: Anwendungen, die im Manifest.xml mit debuggable="true" markiert sind, stellen ein Risiko dar, da sie Verbindungen erlauben, die zu einer Ausnutzung führen können. Für ein besseres Verständnis, wie man debuggable Anwendungen ausnutzt, siehe Tutorials zum Auffinden und Exploitieren debuggable Anwendungen auf einem Gerät.
  • Backup Settings: Das Attribut android:allowBackup="false" sollte explizit für Anwendungen gesetzt werden, die mit sensiblen Informationen arbeiten, um unautorisierte Daten-Backups über adb zu verhindern, besonders 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-Pinning und HTTP-Verkehrseinstellungen spezifizieren. Ein Beispiel wäre das Zulassen von HTTP-Traffic für bestimmte Domains.
  • Exported Activities and Services: Das Auffinden exportierter Activities und Services im Manifest kann Komponenten hervorheben, die missbraucht werden könnten. Eine weitergehende Analyse während dynamischer Tests kann offenbaren, wie diese Komponenten ausgenutzt werden können.
  • Content Providers and FileProviders: Offen exponierte Content Provider könnten unautorisierten Zugriff oder Änderungen an Daten erlauben. Die Konfiguration von FileProviders sollte ebenfalls genau geprüft werden.
  • Broadcast Receivers and URL Schemes: Diese Komponenten könnten für Exploits genutzt werden, mit besonderem Augenmerk darauf, wie URL-Schemes für Eingabeverwundbarkeiten gehandhabt werden.
  • SDK Versions: Die Attribute minSdkVersion, targetSDKVersion und maxSdkVersion geben die unterstützten Android-Versionen an und heben hervor, wie wichtig es ist, keine veralteten, verwundbaren Android-Versionen zu unterstützen.

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

Tapjacking

Tapjacking ist ein Angriff, bei dem eine bösartige Application gestartet wird und sich über eine Opfer-Anwendung legt. Sobald sie die Opfer-App sichtbar überdeckt, ist die Benutzeroberfläche so gestaltet, dass der Benutzer zur Interaktion verleitet wird, während die Interaktion an die Opfer-App weitergereicht wird.
Im Effekt wird der Benutzer geblendet und merkt nicht, dass er tatsächlich Aktionen in der Opfer-App ausführt.

Weitere Informationen finden Sie in:

Tapjacking

Task Hijacking

Eine Activity mit dem launchMode auf singleTask ohne definierte taskAffinity ist anfällig für Task Hijacking. Das bedeutet, dass eine Application installiert werden kann, und wenn sie vor der echten Anwendung gestartet wird, könnte sie die Task der echten Anwendung kapern (so dass der Benutzer mit der bösartigen Anwendung interagiert und denkt, er verwendet die echte).

Mehr Infos in:

Android Task Hijacking

Unsichere Datenspeicherung

Internal Storage

In Android sind Dateien, die im internal storage gespeichert werden, dazu vorgesehen, ausschließlich von der App, die sie erstellt hat, zugänglich zu sein. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem durchgesetzt und ist für die meisten Anwendungen in der Regel ausreichend. Entwickler nutzen jedoch manchmal Modi wie MODE_WORLD_READABLE und MODE_WORLD_WRITABLE, um Dateien zwischen verschiedenen Anwendungen zu teilen. Diese Modi beschränken den Zugriff nicht auf diese Dateien durch andere Anwendungen, einschließlich potenziell bösartiger.

  1. Statische Analyse:
  • Prüfen Sie den Einsatz von MODE_WORLD_READABLE und MODE_WORLD_WRITABLE sorgfältig. Diese Modi können Dateien unbeabsichtigt oder unautorisiert zugänglich machen.
  1. Dynamische Analyse:
  • Überprüfen Sie die Berechtigungen der von der App erstellten Dateien. Insbesondere prüfen Sie, ob Dateien weltweit lesbar oder beschreibbar gesetzt sind. Dies kann ein erhebliches Sicherheitsrisiko darstellen, da es jeder Anwendung auf dem Gerät erlauben würde, unabhängig von Herkunft oder Absicht, diese Dateien zu lesen oder zu ändern.

External Storage

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

  1. Zugänglichkeit:
  • Dateien auf external storage sind global lesbar und schreibbar. Das bedeutet, jede Anwendung oder jeder Benutzer kann auf diese Dateien zugreifen.
  1. Sicherheitsbedenken:
  • Aufgrund der einfachen Zugänglichkeit wird empfohlen, keine sensiblen Informationen auf external storage zu speichern.
  • External storage kann entfernt oder von jeder Anwendung gelesen werden, wodurch es weniger sicher ist.
  1. Umgang mit Daten von External Storage:
  • Führen Sie stets Input-Validation für Daten durch, die von external storage abgerufen werden. Dies ist entscheidend, da die Daten aus einer nicht vertrauenswürdigen Quelle stammen.
  • Das Speichern von ausführbaren Dateien oder class-Dateien auf external storage zum dynamischen Laden wird dringend abgeraten.
  • Wenn Ihre Anwendung unbedingt ausführbare Dateien von external storage laden muss, stellen Sie sicher, dass diese Dateien signiert und kryptographisch verifiziert sind, bevor sie dynamisch geladen werden. Dieser Schritt ist wesentlich, um die Sicherheitsintegrität Ihrer Anwendung zu gewährleisten.

Auf external storage kann zugegriffen werden unter /storage/emulated/0 , /sdcard , /mnt/sdcard

Tip

Beginnend mit Android 4.4 (API 17) hat die SD-Karte eine Verzeichnisstruktur, die den Zugriff einer App auf das Verzeichnis begrenzt, das speziell für diese App vorgesehen ist. Dies verhindert, dass bösartige Anwendungen Lese- oder Schreibzugriff auf die Dateien einer anderen App erhalten.

Sensible Daten im Klartext gespeichert

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

Broken TLS

Accept All Certificates

Aus irgendeinem Grund akzeptieren Entwickler manchmal alle Zertifikate, selbst wenn zum Beispiel 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-Zertifikat auf dem Gerät zu authorisieren. Außerdem kannst du mit Burp ein Zertifikat für einen anderen Hostnamen erzeugen und verwenden.

Fehlerhafte Kryptographie

Schlechte Schlüsselverwaltungsprozesse

Einige Entwickler speichern sensitive Daten im lokalen Speicher und verschlüsseln sie mit einem im Code fest kodierten/vorhersehbaren Schlüssel. Das sollte nicht gemacht werden, da Reverse Engineering es Angreifern ermöglichen kann, die vertraulichen Informationen zu extrahieren.

Verwendung unsicherer und/oder veralteter Algorithmen

Entwickler sollten keine deprecated algorithms verwenden, um Authorisationchecks durchzuführen, Daten zu speichern oder zu senden. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1… Wenn z. B. hashes verwendet werden, um Passwörter zu speichern, sollten brute-force-resistente Hashes mit Salt verwendet werden.

Weitere Prüfungen

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

React Native-Anwendung

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

React Native Application

Xamarin-Anwendungen

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

Xamarin Apps

Superpacked-Anwendungen

Laut diesem blog post ist superpacked ein Meta-Algorithmus, der den Inhalt einer Anwendung in eine einzelne Datei komprimiert. Der Blog beschreibt die Möglichkeit, eine App zu erstellen, die diese Art von Apps dekomprimiert… und einen schnelleren Weg, der 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, Schwachstellen zu finden, indem es den Code der Anwendung scannt. Dieses Tool enthält eine Reihe von known sources (die dem Tool die Stellen anzeigen, an denen die Eingabe vom Benutzer kontrolliert wird), sinks (die dem Tool gefährliche Stellen anzeigen, an denen bösartige Benutzereingaben Schaden verursachen könnten) und rules. Diese Regeln geben die Kombination von sources-sinks an, die auf eine Schwachstelle hinweist.

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

Secrets leaked

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

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Weitere interessante Funktionen

  • Codeausführung: Runtime.exec(), ProcessBuilder(), native code:system()
  • SMS senden: sendTextMessage, sendMultipartTestMessage
  • Native-Funktionen deklariert als native: public native, System.loadLibrary, System.load
  • Lies dies, um zu lernen wie man native Funktionen reverse-engineert
  • In-Memory-Ausführung nativen Codes über JNI (heruntergeladener shellcode → mmap/mprotect → Aufruf):

In Memory Jni Shellcode Execution

Weitere Tricks

content:// protocol

Dynamische Analyse

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

Online Dynamische Analyse

Du kannst ein kostenloses Konto erstellen unter: https://appetize.io/. Diese Plattform erlaubt es, APKs hochzuladen und auszuführen, daher ist sie nützlich, um zu sehen, wie ein APK sich 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 in den Emulatoren verwenden.

Lokale dynamische Analyse

Verwendung eines Emulators

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

AVD - Android Virtual Device

  • Genymotion (Free version: Personal Edition, du musst ein Konto erstellen. Es wird empfohlen, die Version WITH VirtualBox herunterzuladen, um mögliche Fehler zu vermeiden.)
  • Nox (Kostenlos, unterstützt jedoch Frida oder Drozer nicht).

Tip

Beim Erstellen eines neuen Emulators auf einer beliebigen Plattform beachte, dass je größer der Bildschirm ist, desto langsamer der Emulator läuft. Wähle also nach Möglichkeit kleine Bildschirme.

Um google services (wie AppStore) in Genymotion zu installieren, musst du auf den rot markierten Button des folgenden Bildes 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 willst).

Verwendung eines physischen Geräts

Du musst die Debugging-Optionen aktivieren und es ist hilfreich, wenn du es rooten kannst:

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

Sobald du die Anwendung installiert hast, solltest du sie zuerst ausprobieren und untersuchen, was sie tut, wie sie funktioniert und dich damit vertraut machen.
Ich schlage vor, 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 prüfen kannst.

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

  • Patch das boot.img mit der Magisk-App und flash es via fastboot, um systemless root zu erhalten
  • Aktiviere Zygisk + DenyList zum Root-Hiding; ziehe LSPosed/Shamiko in Betracht, wenn stärkeres Hiding erforderlich ist
  • Bewahre das originale boot.img auf, um nach OTA-Updates wiederherstellen zu können; patch es nach jedem OTA erneut
  • Für Screen-Mirroring verwende scrcpy auf dem Host

Unintended Data Leakage

Logging

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

Warning

Beachte, dass ab neueren Versionen als Android 4.0 Anwendungen nur auf ihre eigenen Logs zugreifen können. Anwendungen können also nicht auf Logs anderer Apps zugreifen.
Dennoch wird empfohlen, keine sensiblen Informationen zu protokollieren.

Copy/Paste Buffer Caching

Androids clipboard-basiertes Framework ermöglicht Copy-Paste-Funktionalität in Apps, birgt jedoch ein Risiko, da andere Anwendungen auf die Zwischenablage zugreifen können, was potenziell sensitive Daten preisgeben kann. Es ist wichtig, Copy/Paste-Funktionen in sensiblen Bereichen der Anwendung, wie Kreditkartendetails, zu deaktivieren, um data leaks zu verhindern.

Crash Logs

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

Als pentester, versuche, dir diese Logs anzusehen.

Analytics Data Sent To 3rd Parties

Anwendungen integrieren oft Dienste wie Google Adsense, die unbeabsichtigt sensitive data leaken können aufgrund fehlerhafter Implementierung durch Entwickler. Um potenzielle data leaks zu identifizieren, empfiehlt es sich, den Traffic der Anwendung abzufangen und zu prüfen, ob sensible Informationen an Third-Party-Dienste gesendet werden.

SQLite DBs

Die meisten Anwendungen werden interne SQLite databases verwenden, um Informationen zu speichern. Während des pentest sieh dir die erstellten databases, die Namen der tables und columns und alle gespeicherten data an, weil du sensible Informationen finden könntest (was eine Schwachstelle wäre).
Datenbanken sollten sich in /data/data/the.package.name/databases befinden, z. B. /data/data/com.mwr.example.sieve/databases

Wenn die Datenbank vertrauliche Informationen speichert und verschlüsselt ist, du aber das password in der Anwendung finden kannst, ist das immer noch eine Schwachstelle.

Liste die tables mit .tables auf und liste die columns der tables mit .schema <table_name> auf

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 exploit exported activities, exported services and Content Providers wie du in den folgenden Abschnitten lernen wirst.

Exploiting exported Activities

Lies dies, wenn du auffrischen möchtest, was eine Android Activity ist.
Denke auch daran, dass der Code einer Activity in der onCreate-Methode startet.

Authorisation bypass

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

Lerne, wie man exportierte Activities mit Drozer ausnutzt.

Du kannst 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 von this ist dies offenbar nur auf alten Versionen (API versions < 21) gefährlich.

Tip

Beachte, dass ein authorisation bypass nicht immer eine Schwachstelle ist — es hängt davon ab, wie der bypass funktioniert und welche Informationen offengelegt werden.

Leck sensibler Informationen

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

Tapjacking

Wenn Tapjacking nicht verhindert wird, könntest du die exportierte Activity ausnutzen, um den Benutzer unerwartete Aktionen ausführen zu lassen. Für mehr Informationen über what is Tapjacking follow the link.

Exploiting Content Providers - Accessing and manipulating sensitive information

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

Learn how to exploit Content Providers with Drozer.

Exploiting Services

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

Ein Service ist im Grunde genommen etwas, das Daten empfangen, diese verarbeiten und (oder nicht) eine Antwort zurückgeben kann. Wenn eine Anwendung also einige Services exportiert, solltest du den Code prüfen, um zu verstehen, was er macht, und ihn dynamisch testen, um vertrauliche Informationen zu extrahieren, authentication measures zu bypassen…
Learn how to exploit Services with Drozer.

Exploiting Broadcast Receivers

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

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

Exploiting Schemes / Deep links

Du kannst nach deep links manuell suchen, mit Tools wie MobSF oder Skripten wie this one.
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 omit the package name 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>

Ausgeführter Code

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

Sensible Informationen

Jedes Mal, wenn du einen deep link findest, überprüfe, dass it keine sensiblen Daten (wie passwords) via URL parameters empfängt, denn jede andere Anwendung könnte den deep link impersonate und diese Daten stehlen!

Parameter im Pfad

Du must check also if any deep link is using a parameter inside the path der URL wie: https://api.example.com/v1/users/{username} , in dem Fall kannst du eine Path Traversal erzwingen, indem du z. B. example://app/users?username=../../unwanted-endpoint%3fparam=value aufrufst.
Beachte, dass du, wenn du die korrekten Endpunkte in der Anwendung findest, möglicherweise einen Open Redirect (wenn ein Teil des Pfads als Domainname verwendet wird), account takeover (wenn du users details ohne CSRF token ändern kannst und der vuln endpoint die richtige Methode verwendete) und andere Schwachstellen auslösen kannst. Mehr info about this here.

An interesting bug bounty report about links (/.well-known/assetlinks.json).

Inspektion der Transportschicht und Verifikationsfehler

  • Zertifikate werden nicht immer korrekt geprüft von Android-Anwendungen. Es ist üblich, dass diese Anwendungen Warnungen übersehen und selbstsignierte Zertifikate akzeptieren oder in einigen Fällen auf HTTP-Verbindungen zurückfallen.
  • Die Aushandlungen während des SSL/TLS-Handshakes sind manchmal schwach, es werden unsichere Cipher Suites eingesetzt. Diese Schwachstelle macht die Verbindung anfällig für man-in-the-middle (MITM)-Angriffe und ermöglicht Angreifern das Entschlüsseln der Daten.
  • Leakage of private information ist ein Risiko, wenn Anwendungen sich über sichere Kanäle authentifizieren, anschließend aber für andere Transaktionen über unsichere Kanäle kommunizieren. Dieser Ansatz schützt sensitive data, wie session cookies oder user details, nicht vor dem Abfangen durch böswillige Akteure.

Zertifikatsprüfung

Wir konzentrieren uns auf Zertifikatsprüfung. Die Integrität des Serverzertifikats muss verifiziert werden, um die Sicherheit zu erhöhen. Das ist wichtig, 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 Anleitungen.

SSL Pinning

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

Traffic-Inspektion

Um HTTP-Traffic zu inspizieren, ist es notwendig, das Zertifikat des Proxy-Tools zu installieren (z. B. Burp). Ohne die Installation dieses Zertifikats ist verschlüsselter Traffic möglicherweise nicht über den Proxy sichtbar. Für eine Anleitung zum Installieren eines benutzerdefinierten CA-Zertifikats, click here.

Anwendungen, die API Level 24 and above anvisieren, 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.

Wenn Flutter verwendet wird, musst du den Anweisungen auf this page folgen. Dies liegt daran, dass allein das Hinzufügen des Zertifikats zum Store nicht ausreicht, da Flutter eine eigene Liste gültiger CAs hat.

Statische Erkennung von SSL/TLS pinning

Bevor du Runtime-Bypasses versuchst, kartiere schnell, wo Pinning im APK durchgesetzt wird. Statische Entdeckung hilft dir, Hooks/Patches zu planen und dich auf die richtigen Code-Pfade zu konzentrieren.

Tool: SSLPinDetect

  • Open-source statische Analyse-Utility, das das APK zu Smali dekompiliert (via apktool) und nach kuratierten regex-Mustern von SSL/TLS pinning-Implementierungen sucht.
  • 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

Beispiel pattern rules (JSON) Verwende oder erweitere signatures, um proprietäre/custom pinning styles zu erkennen. Du kannst dein eigenes JSON laden und in großem Umfang 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 Multithreading und memory-mapped I/O; vorkompilierte Regex reduziert Overhead/Falschmeldungen.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Typische Erkennungsziele zur weiteren Triage:
  • OkHttp: CertificatePinner-Verwendung, setCertificatePinner, okhttp3/okhttp package references
  • Benutzerdefinierte TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted-Überschreibungen
  • Benutzerdefinierte SSL-Kontexte: SSLContext.getInstance + SSLContext.init mit benutzerdefinierten Managern
  • Deklarative Pins in res/xml network security config and manifest references
  • 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, wird dessen Umgehung notwendig, um HTTPS-Traffic zu untersuchen. Verschiedene Methoden stehen dafür 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 SSL Pinning zu umgehen, allerdings musst du die Anwendung deinstallieren und die neue Version installieren, und das funktioniert nicht immer.
  • Du kannst Frida (weiter unten besprochen) verwenden, um diesen Schutz zu umgehen. Hier findest du einen Guide, um Burp+Frida+Genymotion zu nutzen: https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/
  • Du kannst auch versuchen, SSL Pinning automatisch zu umgehen mit objection: objection --gadget com.package.app explore --startup-command "android sslpinning disable"
  • Du kannst auch versuchen, SSL Pinning automatisch zu umgehen mit MobSF dynamic analysis (weiter unten erklärt)
  • Wenn du immer noch denkst, dass es Traffic gibt, den du nicht erfasst, kannst du versuchen, den Traffic an burp mittels iptables weiterzuleiten. Lies diesen Blog: https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62

Suche nach typischen Web-Schwachstellen

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

Frida

Frida ist ein dynamisches Instrumentierungs-Toolkit für Entwickler, Reverse-Engineers und Sicherheitsforscher.
Du kannst laufende Anwendungen ansprechen und Methoden zur Laufzeit hooken, um Verhalten zu ändern, Werte zu verändern, Werte zu extrahieren oder anderen Code auszuführen…
Wenn du Android-Anwendungen pentesten möchtest, musst du wissen, wie man Frida verwendet.

Anti-instrumentation & SSL pinning bypass workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Speicher ausdumpen - Fridump

Prüfe, ob die Anwendung sensible Informationen im Speicher ablegt, die dort nicht sein sollten, z. B. Passwörter oder mnemonics.

Mit Fridump3 kannst du den Speicher der App ausdumpen 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 mit ausreichenden Rechten immer noch possible to access it. Da Anwendungen dazu neigen, hier sensitive data in clear text zu speichern, sollten pentests dies als root user prüfen, da jemand mit physischem Zugriff auf das Gerät diese Daten stehlen könnte.

Auch wenn eine App Daten im Keystore gespeichert hat, sollten diese verschlüsselt sein.

Um auf die Daten im Keystore zuzugreifen, kann man dieses Frida script verwenden: 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 script könnte es möglich sein, die von Android-Anwendungen durchgeführte bypass fingerprint authentication zu umgehen, mit der bestimmte sensible Bereiche geschützt werden:

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

Hintergrundbilder

Wenn du eine Anwendung in den Hintergrund legst, speichert Android einen Snapshot der Anwendung, damit beim Wiederherstellen in den Vordergrund zuerst das Bild geladen wird, bevor die App selbst, sodass es so aussieht, als wäre die App schneller gestartet.

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 normalerweise gespeichert unter: /data/system_ce/0/snapshots

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

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

Android Application Analyzer

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

Intent Injection

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

Die Gefahr besteht darin, Angreifern zu erlauben, non-exported App-Komponenten aufzurufen 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 non-exported Komponenten und content providers für Angreifer exponiert werden.
  • Die Umwandlung von URLs in Intent-Objekte durch WebView kann 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 bei diesen Schwachstellen besonders vorsichtig sein:

  • SQL Injection: Bei dynamischen Abfragen oder Content-Providers sollten Sie parameterisierte Abfragen verwenden.
  • JavaScript Injection (XSS): Stellen Sie sicher, dass JavaScript- und Plugin-Unterstützung für alle WebViews deaktiviert ist (standardmäßig deaktiviert). More info here.
  • Local File Inclusion: WebViews sollten keinen Zugriff auf das Dateisystem haben (standardmäßig aktiviert) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: In mehreren Fällen wird beim Beenden der Android-Anwendung das Cookie nicht zurückgezogen oder es könnte sogar auf die Festplatte gespeichert werden
  • Secure Flag in cookies

Automatische Analyse

MobSF

Statische Analyse

Sicherheitsbewertung der Anwendung über ein ansprechendes webbasiertes Frontend. Sie können auch dynamische Analyse durchführen (aber Sie müssen die Umgebung vorbereiten).

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

Beachte, dass MobSF Android(apk), IOS(ipa) and Windows(apx) applications (Windows applications must be analyzed from a MobSF installed in a Windows host).
Auch wenn du eine ZIP-Datei mit dem Quellcode einer Android- oder IOS-App erstellst (gehe ins Root-Verzeichnis der Anwendung, wähle alles aus und erstelle eine ZIPfile), kann sie ebenfalls analysiert werden.

MobSF ermöglicht außerdem, diff/Compare Analysen durchzuführen und VirusTotal zu integrieren (du musst deinen API-Schlüssel in MobSF/settings.py setzen und 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 hochgeladen.

Unterstützte Dynamic analysis 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 (eine VM oder Docker wird nicht funktionieren). Hinweis: Du musst zuerst eine VM in genymotion starten und dann MobSF.
Der MobSF dynamic analyser kann:

  • Dump application data (URLs, logs, clipboard, Screenshots, die du selbst machst, Screenshots, die vom “Exported Activity Tester” erstellt werden, emails, SQLite databases, XML files, und andere erzeugte Dateien). All dies geschieht automatisch, außer bei den Screenshots — du musst den Button drücken, wenn du einen Screenshot möchtest, oder “Exported Activity Tester” drücken, um Screenshots aller exportierten Activities zu erhalten.
  • Capture HTTPS traffic
  • Use Frida to obtain runtime information

Ab Android versions > 5 wird es Frida automatisch starten und globale proxy-Einstellungen setzen, 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 zu umgehen und um monitor interesting APIs.
MobSF kann außerdem invoke exported activities, screenshots davon erstellen und diese für den Bericht speichern.

Um mit dem dynamischen Test zu starten, drücke den grünen Button: “Start Instrumentation”. Drücke “Frida Live Logs”, um die von den Frida-Skripten erzeugten Logs zu sehen, und “Live API Monitor”, um alle Aufrufe gehookter Methoden, übergebene Argumente und Rückgabewerte zu sehen (dies erscheint, nachdem du auf “Start Instrumentation” gedrückt hast).
MobSF erlaubt dir auch, eigene Frida scripts zu laden (um die Ergebnisse deiner Frida-Skripte an MobSF zu senden, verwende die Funktion send()). Es enthält außerdem mehrere vorgefertigte Skripte, 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 Skripte in “Frida Live Logs” sehen).

Außerdem stehen dir einige Auxiliary Frida functionalities zur Verfügung:

  • Enumerate Loaded Classes: Gibt alle geladenen Klassen aus
  • Capture Strings: Gibt während der Nutzung der Anwendung alle erfassten Strings aus (sehr viele Ausgaben)
  • Capture String Comparisons: Kann sehr nützlich sein. Zeigt die 2 verglichenen Strings und ob das Ergebnis True oder False war.
  • Enumerate Class Methods: Gib den Klassennamen ein (z. B. “java.io.File”) und es werden alle Methoden der Klasse ausgegeben.
  • Search Class Pattern: Suche Klassen anhand eines Patterns
  • Trace Class Methods: Trace einer ganzen Klasse (siehe Eingaben und Ausgaben aller Methoden der Klasse). Beachte, dass MobSF standardmäßig mehrere interessante Android Api methods trace.

Sobald du das gewünschte Auxiliary-Modul ausgewählt hast, 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 bereit. Einige interessante Befehle:

help
shell ls
activities
exported_activities
services
receivers

HTTP-Tools

Wenn HTTP-Traffic erfasst wird, siehst du eine grobe Ansicht des aufgezeichneten Traffics über den “HTTP(S) Traffic” Button unten oder eine schönere Ansicht über den grünen “Start HTTPTools” Button. Über die zweite Option kannst du die captured requests an proxies wie Burp oder Owasp ZAP senden.
Um das zu tun: power on Burp –> turn off Intercept –> in MobSF HTTPTools die Anfrage auswählen –> auf “Send to Fuzzer” drücken –> die proxy address auswählen (http://127.0.0.1:8080\).

Sobald du die dynamic analysis 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 dynamic analysis mit MobSF können die proxy settings fehlerhaft konfiguriert sein und du kannst sie nicht über die GUI beheben. Du kannst die proxy settings folgendermaßen zurücksetzen:

adb shell settings put global http_proxy :0

Assisted Dynamic Analysis with Inspeckage

Du kannst das Tool von Inspeckage beziehen.
Dieses Tool verwendet einige Hooks, um dir zu zeigen, was in der Anwendung passiert, während du eine dynamic analysis durchführst.

Yaazhini

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

Qark

Dieses Tool wurde entwickelt, um verschiedene security related Android application vulnerabilities zu finden, entweder im source code oder in packaged APKs. Das Tool ist außerdem in der Lage, eine “Proof-of-Concept” deployable APK und ADB commands zu erstellen, um einige der gefundenen Schwachstellen zu exploitieren (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
  • Dekom­piliert APK-Dateien automatisch in Java- und Smali-Format
  • Analysiert AndroidManifest.xml auf häufige Schwachstellen und Verhalten
  • Statische Quellcode-Analyse auf häufige Schwachstellen und Verhalten
  • Geräteinformationen
  • und mehr
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER ist eine Kommandozeilen-Anwendung, die unter Windows, MacOS X und Linux verwendet werden kann und .apk Dateien auf der Suche nach Schwachstellen analysiert. Dazu dekomprimiert sie APKs und wendet eine Reihe von Regeln an, um diese Schwachstellen zu erkennen.

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

Die neuesten Binärdateien finden Sie auf der download page

super-analyzer {apk_file}

StaCoAn

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

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

Herunterladen latest release:

./stacoan

AndroBugs

AndroBugs Framework ist ein Analyse-System für Android-Sicherheitslücken, 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, den Benutzer vor potenziell bösartigem Verhalten einer Android-Anwendung zu erkennen und zu warnen.

Die Erkennung erfolgt durch die static analysis des Dalvik bytecode der Anwendung, dargestellt als Smali, mithilfe der androguard library.

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

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

MARA Framework

MARA ist ein Framework für Mobile Application Reverse engineering und Analysis. Es ist ein Tool, das häufig verwendete mobile Application reverse engineering- und Analyse-Tools 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‑Entwickler und Sicherheitsprofis einfacher und benutzerfreundlicher zu machen.

Es kann:

Koodous

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

Obfuscating/Deobfuscating code

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

ProGuard

Von Wikipedia: ProGuard ist ein Open‑Source-Kommandozeilen‑Tool, das Java‑Code schrumpft, optimiert und obfuskiert. Es kann Bytecode optimieren sowie ungenutzte Anweisungen 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 ausgeliefert und läuft beim Erstellen der Anwendung im Release‑Modus.

DexGuard

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

(Aus diesem Guide) Beim letzten Mal, als wir nachgeschaut haben, war der Modus der Dexguard‑Operation:

  • eine Ressource als InputStream laden;
  • das Ergebnis an eine Klasse weitergeben, die von FilterInputStream erbt, um sie zu decrypten;
  • einige nutzlose Obfuskationen durchführen, um ein paar Minuten Zeit eines Reversers zu verbrauchen;
  • das decrypted Ergebnis an einen ZipInputStream übergeben, um eine DEX‑Datei zu erhalten;
  • schließlich die resultierende DEX als Resource mittels der loadDex‑Methode laden.

DeGuard

DeGuard kehrt den Prozess der Obfuskation um, der von Android‑obfuscation‑Tools durchgeführt wird. Dadurch werden zahlreiche Sicherheitsanalysen ermöglicht, einschließlich Code‑Inspektion und Vorhersage 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 Sicherheitslücken in Android‑Apps zu finden und Android‑App‑Code zu deobfuscate. Verwendet Google’s Gemini public API.

Simplify

Es ist ein generischer android deobfuscator. Simplify führt die App praktisch 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 zu verstehen ist. Jeder Optimierungstyp ist einfach und generisch, daher spielt es keine Rolle, welche spezifische Art der Obfuskation verwendet wurde.

APKiD

APKiD gibt Auskunft darüber, wie ein APK erstellt wurde. Es identifiziert viele compilers, packers, obfuscators und andere merkwürdige Dinge. Es ist PEiD für Android.

Manual

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

Labs

Androl4b

AndroL4b ist eine Android‑Security‑Virtual‑Machine auf Ubuntu‑MATE‑Basis und enthält eine Sammlung aktueller Frameworks, Tutorials und Labs von verschiedenen Security‑Enthusiasten und Forschern für Reverse Engineering und Malware‑Analyse.

References

Tip

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

Unterstützen Sie HackTricks