Android Anwendungen Pentesting

Reading time: 40 minutes

tip

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

Unterstützen Sie HackTricks

Android Anwendungen Grundlagen

Es wird dringend empfohlen, diese Seite zu lesen, um die wichtigsten Teile 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, das du benötigst, um eine Android-Gerät (emuliert oder physisch) zu verbinden.
ADB ermöglicht die Steuerung von Geräten entweder über USB oder Network von einem Computer aus. Dieses Werkzeug 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 und weitere Funktionen.

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

Smali

Manchmal ist es interessant, den Anwendungscode zu modifizieren, um auf versteckte Informationen zuzugreifen (z. B. stark obfuskierte Passwörter oder flags). Dann kann es sinnvoll sein, das APK zu dekompilieren, den Code zu ändern und es wieder zu kompilieren.
In this tutorial you can learn how to decompile and APK, modify Smali code and recompile the APK with the new functionality. Das kann sehr nützlich sein als alternative for several tests during the dynamic analysis, die vorgestellt werden. Dann, Behalte diese Möglichkeit immer im Hinterkopf.

Weitere interessante Tricks

bash
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
  • Führe alle splits und base apks mit APKEditor:
bash
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

Fallstudien & Schwachstellen

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Statische Analyse

Zuerst solltest du bei der Analyse einer APK den Java-Code ansehen mit einem Decompiler.
Please, read here to find information about different available decompilers.

Nach interessanten Informationen suchen

Wenn du dir einfach die strings der APK ansiehst, kannst du nach Passwörtern, URLs (https://github.com/ndelphit/apkurlgrep), api-Keys, Verschlüsselung, bluetooth uuids, Tokens und allem Interessanten suchen... achte sogar auf Code-Ausführungs backdoors oder Authentifizierungs-Backdoors (hardcoded admin credentials to the app).

Firebase

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

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

Die Untersuchung der Manifest.xml und strings.xml Dateien einer Anwendung kann potenzielle Sicherheitslücken offenlegen. Auf diese Dateien kann mit Decompilern zugegriffen werden oder indem man die Dateiendung der APK in .zip ändert und diese entpackt.

Schwachstellen, die aus der Manifest.xml identifiziert werden können, umfassen:

  • Debuggable Applications: Anwendungen, die im Manifest.xml mit debuggable="true" gesetzt sind, stellen ein Risiko dar, da sie Verbindungen erlauben können, die zu einer Ausnutzung führen. Für ein tieferes Verständnis, wie man debuggable applications ausnutzt, siehe ein Tutorial zum Finden und Ausnutzen debuggable applications auf einem Gerät.
  • Backup Settings: Das Attribut android:allowBackup="false" sollte explizit für Anwendungen gesetzt werden, die mit sensiblen Informationen arbeiten, um unautorisierte Daten-Backups über adb zu verhindern, besonders wenn usb debugging aktiviert ist.
  • Network Security: Eigene network security Konfigurationen (android:networkSecurityConfig="@xml/network_security_config") in res/xml/ können Sicherheitsdetails wie Certificate-Pinning und Einstellungen zum HTTP-Traffic spezifizieren. Ein Beispiel ist die Erlaubnis von HTTP-Traffic für bestimmte Domains.
  • Exported Activities and Services: Das Auffinden von exportierten Activities und Services im Manifest kann Komponenten aufzeigen, die missbraucht werden könnten. Weitere Analyse während dynamischer Tests kann offenbaren, wie diese Komponenten ausgenutzt werden können.
  • Content Providers and FileProviders: Offen gelegte 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 besondere Aufmerksamkeit darauf gelegt werden sollte, wie URL-Schemes für Eingabe-Schwachstellen gehandhabt werden.
  • SDK Versions: Die Attribute minSdkVersion, targetSDKVersion und maxSdkVersion geben die unterstützten Android-Versionen an und heben die Bedeutung hervor, keine veralteten, verwundbaren Android-Versionen zu unterstützen.

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

Tapjacking

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

Find more information in:

Tapjacking

Task Hijacking

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

Mehr Infos in:

Android Task Hijacking

Unsichere Datenspeicherung

Interner Speicher

In Android sind Dateien, die im internen Speicher gespeichert werden, so konzipiert, dass sie ausschließlich von der App zugänglich sind, die sie erstellt hat. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem durchgesetzt und ist für die Sicherheitsanforderungen der 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 schränken jedoch nicht den Zugriff auf diese Dateien durch andere Anwendungen ein, einschließlich potenziell bösartiger.

  1. Statische Analyse:
  • Stelle sicher, dass die Verwendung von MODE_WORLD_READABLE und MODE_WORLD_WRITABLE sorgfältig überprüft wird. Diese Modi können Dateien unbeabsichtigt oder unautorisiert zugänglich machen.
  1. Dynamische Analyse:
  • Überprüfe die Berechtigungen von Dateien, die von der App erstellt wurden. Insbesondere prüfe, ob Dateien so gesetzt sind, dass sie weltweit lesbar oder beschreibbar sind. Dies kann ein erhebliches Sicherheitsrisiko darstellen, da es jeder installierten Anwendung, unabhängig von deren Herkunft oder Absicht, erlauben würde, diese Dateien zu lesen oder zu ändern.

Externer Speicher

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

  1. Zugänglichkeit:
  • Dateien auf externem Speicher 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 externem Speicher zu speichern.
  • Externer Speicher kann entfernt oder von jeder Anwendung ausgelesen werden, was ihn weniger sicher macht.
  1. Umgang mit Daten vom externen Speicher:
  • Führe stets Input-Validation für Daten durch, die vom externen Speicher abgerufen werden. Das ist wichtig, da die Daten aus einer nicht vertrauenswürdigen Quelle stammen.
  • Das Speichern von ausführbaren Dateien oder Klassendateien auf externem Speicher zum dynamischen Laden wird dringend abgeraten.
  • Falls deine Anwendung ausführbare Dateien vom externen Speicher laden muss, stelle sicher, dass diese Dateien signiert und kryptographisch verifiziert sind, bevor sie dynamisch geladen werden. Dieser Schritt ist entscheidend für die Sicherheitsintegrität deiner Anwendung.

External storage can be accessed in /storage/emulated/0 , /sdcard , /mnt/sdcard

tip

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

Sensible Daten im Klartext

  • Shared preferences: Android erlaubt jeder Anwendung, einfach XML-Dateien im Pfad /data/data/<packagename>/shared_prefs/ zu speichern, und manchmal ist es möglich, in diesem Ordner sensible Informationen im Klartext zu finden.
  • Databases: Android erlaubt jeder Anwendung, leicht sqlite-Datenbanken im Pfad /data/data/<packagename>/databases/ zu speichern, und manchmal ist es möglich, in diesem Ordner sensible Informationen im Klartext zu 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:

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

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

Fehlerhafte Kryptographie

Schlechte Schlüsselverwaltungsprozesse

Einige Entwickler speichern sensible Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hardcodierten/vorhersehbaren Schlüssel. Das sollte vermieden werden, da durch Reverse Engineering Angreifer vertrauliche Informationen extrahieren könnten.

Verwendung unsicherer und/oder veralteter Algorithmen

Entwickler sollten keine veralteten Algorithmen zur Durchführung von Autorisierungsprüfungen, zum Speichern oder Senden von Daten verwenden. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1... Wenn hashes beispielsweise verwendet werden, um Passwörter zu speichern, sollten brute-force-resistant 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 (z. B. Bank-Apps), sollte sie eigene Prüfungen durchführen, um festzustellen, ob das mobile Gerät rooted ist, und entsprechend handeln.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie prüfen, ob ein emulator verwendet wird.
  • Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie vor der Ausführung ihre Integrität prüfen, um zu prüfen, ob sie verändert wurde.
  • Use APKiD to check which compiler/packer/obfuscator was used to build the APK

React Native Application

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

React Native Application

Xamarin Applications

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

Xamarin Apps

Superpacked Applications

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

Automated Static Code Analysis

The tool mariana-trench is capable of finding vulnerabilities by scanning the code of the application. This tool contains a series of known sources (that indicates to the tool the places where the input is controlled by the user), sinks (which indicates to the tool dangerous places where malicious user input could cause damages) and rules. These rules indicates the combination of sources-sinks that indicates a vulnerability.

With this knowledge, mariana-trench will review the code and find possible vulnerabilities on it.

Secrets leaked

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

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Andere interessante Funktionen

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

In Memory Jni Shellcode Execution

Other tricks

content:// protocol

Dynamische Analyse

First of all, you need an environment where you can install the application and all the environment (Burp CA cert, Drozer and Frida mainly). Therefore, a rooted device (emulated or not) is extremely recommended.

Online Dynamic analysis

Du kannst ein kostenloses Konto unter: https://appetize.io/ erstellen. Diese Plattform erlaubt es, APKs hochzuladen und auszuführen, daher ist sie nützlich, um das Verhalten einer APK zu beobachten.

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

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

Lokale Dynamische Analyse

Verwendung eines Emulators

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

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, aber es unterstützt Frida oder Drozer nicht).

tip

Beim Erstellen eines neuen Emulators auf jeder Plattform gilt: Je größer der Bildschirm ist, desto langsamer läuft der Emulator. Wähle daher nach Möglichkeit kleine Bildschirme.

Um Google Services (wie den AppStore) in Genymotion zu installieren, musst du den rot markierten Button im folgenden Bild klicken:

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

Verwendung eines physischen Geräts

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

  1. Settings.
  2. (Ab Android 8.0) Wähle System.
  3. Wähle About phone.
  4. Drücke Build number 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 mit ihr vertraut machen.
Ich empfehle, diese anfängliche dynamische Analyse mit MobSF dynamic analysis + pidcat durchzuführen, damit wir lernen, wie die Anwendung funktioniert, während MobSF viele interessante Daten erfasst, die du später überprüfen kannst.

Magisk/Zygisk 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 Verbergen von Root; erwäge LSPosed/Shamiko, wenn stärkere Verbergung nötig ist
  • Bewahre das originale boot.img auf, um von OTA-Updates wiederherstellen zu können; re-patche nach jedem OTA
  • Für Screen-Mirroring verwende scrcpy auf dem Host

Unintended Data Leakage

Logging

Entwickler sollten vorsichtig sein, Debug-Informationen öffentlich preiszugeben, da dies zu sensitiven Daten leaks führen kann. Die Tools pidcat und adb logcat werden zur Überwachung von Anwendungs-Logs empfohlen, um sensible Informationen zu identifizieren und zu schützen. Pidcat wird wegen seiner Benutzerfreundlichkeit und Lesbarkeit bevorzugt.

warning

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

Copy/Paste Buffer Caching

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

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. Zur Minderung dieses Risikos sollte Logging bei Abstürzen vermieden werden; falls Logs über das Netzwerk übertragen werden müssen, stelle sicher, dass sie über einen SSL-Kanal gesendet werden. Als pentester solltest du versuchen, diese Logs einzusehen.

Analytics Data Sent To 3rd Parties

Anwendungen integrieren oft Dienste wie Google Adsense, die unbeabsichtigt sensible Daten leaks verursachen können, wenn sie falsch implementiert wurden. Um mögliche Daten leaks zu identifizieren, empfiehlt es sich, den Traffic der Anwendung zu intercepten und zu prüfen, ob sensible Informationen an Drittanbieter gesendet werden.

SQLite DBs

Die meisten Anwendungen verwenden interne SQLite-Datenbanken zur Speicherung von Informationen. Während des pentests solltest du dir die erstellten Datenbanken, die Namen der Tabellen und Spalten und alle gespeicherten Daten ansehen, da 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 zwar verschlüsselt, du aber das password innerhalb der Anwendung finden kannst, ist das weiterhin eine Vulnerability.

Liste die Tabellen mit .tables auf und liste die Spalten der Tabellen 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 is s useful tool to exploit exported activities, exported services and Content Providers as you will learn in the following sections.

Exploiting exported Activities

Read this if you want to refresh what is an Android Activity.
Also remember that the code of an activity starts in the onCreate method.

Authorisation bypass

When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with sensitive information is exported you could bypass the authentication mechanisms to access it.

Learn how to exploit exported activities with Drozer.

You can also start an exported activity from adb:

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

HINWEIS: MobSF will detect as malicious the use of singleTask/singleInstance as android:launchMode in an activity, but due to this, apparently this is only dangerous on old versions (API versions < 21).

tip

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

Sensible Informationen leak

Activities können auch Ergebnisse zurückgeben. Wenn du eine exportierte und ungeschützte Activity findest, die die setResult-Methode aufruft und sensible Informationen zurückgibt, liegt ein sensibler Informations-leak vor.

Tapjacking

Wenn Tapjacking nicht verhindert wird, könntest du die exportierte Activity missbrauchen, um den Benutzer unerwartete Aktionen ausführen zu lassen. For more info about 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 grundsätzlich verwendet, um Daten zu teilen. Wenn eine App Content providers anbietet, kannst du möglicherweise sensible Daten daraus extrahieren. Es ist auch interessant, mögliche SQL injections und Path Traversals zu testen, da diese verwundbar sein könnten.

Learn how to exploit Content Providers with Drozer.

Exploiting Services

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

Ein Service ist im Grunde genommen etwas, das Daten empfangen, sie verarbeiten und eine Antwort zurückgeben (oder nicht) kann. 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...
Learn how to exploit Services with Drozer.

Exploiting Broadcast Receivers

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

Ein Broadcast Receiver wartet auf eine Art Nachricht. Abhängig davon, wie der Receiver die Nachricht verarbeitet, kann er verwundbar sein.
Learn how to exploit Broadcast Receivers with Drozer.

Exploiting Schemes / Deep links

You can look for deep links manually, using tools like MobSF or scripts like this one.
Du kannst ein deklariertes scheme mit adb oder einem browser öffnen:

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

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

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

Ausgeführter Code

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

Sensible Informationen

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

Parameter im Pfad

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

Mehr Beispiele

Ein interessanter Bug-Bounty-Report über Links (/.well-known/assetlinks.json).

Transport-Layer-Inspektion und Verifizierungsfehler

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

Certificate Verification

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

SSL Pinning

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

Traffic Inspection

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

Anwendungen, die auf API Level 24 und höher abzielen, erfordern Änderungen an der Network Security Config, um das CA-Zertifikat des Proxys zu akzeptieren. Dieser Schritt ist entscheidend, um verschlüsselten Traffic zu inspizieren. Für Anweisungen zum Ändern der Network Security Config siehe dieses Tutorial.

Wenn Flutter verwendet wird, musst du die Anweisungen auf dieser Seite befolgen. Das liegt daran, dass das bloße Hinzufügen des Zertifikats in den Store nicht funktioniert, da Flutter seine 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-Tool, das das APK nach 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 benutzerdefinierte Code-Pfade 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
bash
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Verwendung

bash
# 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-Musterregeln (JSON) Verwende oder erweitere Signaturen, um proprietäre/benutzerdefinierte pinning-Stile zu erkennen. Du kannst dein eigenes JSON laden und in großem Maßstab scannen.

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

Notizen und Tipps

  • Schnelles Scannen großer Apps mittels Multi-Threading und memory-mapped I/O; vorkompilierte regex reduziert Overhead/False-Positives.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Typische Erkennungsziele zur weiteren Triage:
  • OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
  • Declarative pins in res/xml network security config and manifest references
  • Nutze die gefundenen Stellen, um Frida hooks, statische Patches oder config reviews vor dynamischen Tests zu planen.

Umgehung von SSL Pinning

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

Suche nach häufigen Web-Schwachstellen

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

Frida

Frida ist ein dynamisches Instrumentierungs-Toolkit für Entwickler, Reverse-Engineers und Security-Researcher.
Du kannst auf laufende Anwendungen zugreifen und Methoden zur Laufzeit hooken, um 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.

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 liegen sollten, wie Passwörter oder mnemonics.

Mit Fridump3 kannst du den Speicher der App dumpen mit:

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

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

Das wird den Speicher in den Ordner ./dump schreiben, und dort könntest du mit etwas wie grep suchen:

bash
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

In 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 häufig sensible Daten im Klartext ablegen, sollten pentests dies als root user prüfen, da jemand mit physischem Zugriff auf das Gerät diese Daten stehlen könnte.

Selbst wenn eine App Daten im keystore gespeichert hat, sollten diese verschlüsselt sein.

Um auf die Daten im keystore zuzugreifen, kannst du dieses Frida-Skript verwenden: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

bash
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 bypass fingerprint authentication durchzuführen, die Android-Anwendungen möglicherweise verwenden, um bestimmte sensible Bereiche zu schützen:

bash
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, sodass beim Wiederherstellen in den Vordergrund zuerst das Bild geladen wird, bevor die App vollständig startet — dadurch wirkt es, als wäre die App schneller geladen.

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

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

Android bietet eine Möglichkeit, die Screenshot-Aufnahme zu verhindern, indem man das Layout-Parameter FLAG_SECURE setzt. Durch die Verwendung dieses Flags werden die Fensterinhalte als sicher behandelt, wodurch verhindert wird, dass sie in Screenshots erscheinen oder auf nicht-sicheren Displays angezeigt werden.

bash
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(...) weiterreichen, was riskant sein kann.

Die Gefahr liegt darin, Angreifern zu erlauben, nicht-exportierte App-Komponenten zu triggern oder durch Umlenken dieser Intents auf sensitive 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 malicious Intent injections führen kann.

Essential Takeaways

  • Intent Injection ist ähnlich wie das Open Redirect-Problem im Web.
  • Exploits beinhalten das Weitergeben 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 exponiert werden.
  • Die Konvertierung von URLs zu Intent-Objekten durch WebView kann unbeabsichtigte Aktionen ermöglichen.

Android Client Side Injections and others

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

  • SQL Injection: Beim Umgang mit dynamischen Abfragen oder Content-Providers stellen Sie sicher, dass 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: Bei WebViews sollte der Zugriff auf das Dateisystem deaktiviert sein (standardmäßig aktiviert) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: In mehreren Fällen werden beim Beenden der Android-Anwendung die Cookies nicht zurückgezogen oder sogar auf die Festplatte gespeichert
  • Secure Flag in cookies

Automatic Analysis

MobSF

Statische Analyse

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

bash
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) Anwendungen analysieren kann (Windows applications must be analyzed from a MobSF installed in a Windows host).
Außerdem, wenn du eine ZIP-Datei mit dem Quellcode einer Android- oder IOS-App erstellst (gehe in den Root-Ordner der Anwendung, markiere alles und erstelle eine ZIP-Datei), kann MobSF diese ebenfalls analysieren.

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

Assisted Dynamic analysis with MobSF

MobSF kann auch bei der dynamic analysis von Android sehr hilfreich sein, in diesem Fall musst du jedoch MobSF und genymotion auf deinem Host installieren (eine VM oder Docker funktioniert nicht). 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

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

Frida

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

Um das dynamic testing zu starte, 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 zu den gehookten Methoden, übergebene Argumente und Rückgabewerte zu sehen (das erscheint nachdem du "Start Instrumentation" gedrückt hast).
MobSF erlaubt dir auch, eigene Frida scripts zu laden (um die Ergebnisse deiner Frida-Skripte an MobSF zu senden, benutze die Funktion send()). Es enthält außerdem several pre-written scripts, die du laden kannst (du kannst weitere in MobSF/DynamicAnalyzer/tools/frida_scripts/others/ hinzufügen), einfach auswählen, "Load" drücken und dann "Start Instrumentation" (du kannst die Logs dieser Skripte in "Frida Live Logs" sehen).

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

  • Enumerate Loaded Classes: Gibt alle geladenen Klassen aus
  • Capture Strings: Gibt alle erfassten Strings während der Nutzung der Anwendung aus (sehr laut/“noisy”)
  • Capture String Comparisons: Sehr nützlich. 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 listet alle Methoden der Klasse auf.
  • Search Class Pattern: Suche Klassen nach Muster
  • Trace Class Methods: Trace eine ganze Klasse (zeige Eingaben und Ausgaben aller Methoden der Klasse). Denk daran, dass MobSF standardmäßig mehrere interessante Android API-Methoden traced.

Sobald du das auxiliary module ausgewählt hast, das du verwenden möchtest, musst du "Start Intrumentation" drücken und du wirst alle Ausgaben in "Frida Live Logs" sehen.

Shell

MobSF bringt außerdem eine Shell mit einigen adb Befehlen, MobSF commands, und allgemeinen shell commands am unteren Rand der dynamic analysis-Seite. Einige interessante Befehle:

bash
help
shell ls
activities
exported_activities
services
receivers

HTTP tools

Wenn HTTP-Verkehr erfasst wird, kannst du eine grobe Ansicht des erfassten Verkehrs unten im "HTTP(S) Traffic"-Button sehen 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 dies zu tun: power on Burp --> turn off Intercept --> in MobSB HTTPTools die Anfrage auswählen --> drücken "Send to Fuzzer" --> die Proxy-Adresse 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 fuzz http requests durchzuführen und nach Schwachstellen zu suchen.

tip

Nach einer dynamic analysis mit MobSF können die Proxy-Einstellungen fehlerhaft sein und du kannst sie nicht über die GUI beheben. Du kannst die Proxy-Einstellungen wie folgt reparieren:

adb shell settings put global http_proxy :0

Assisted Dynamic Analysis with Inspeckage

You can get the tool from Inspeckage.
Dieses Tool nutzt einige Hooks, um dir zu zeigen, was in der Anwendung passiert, während du eine dynamic analysis durchführst.

Yaazhini

Dies ist ein tolles 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 capable of creating a "Proof-of-Concept" deployable APK und ADB commands, um einige der gefundenen Schwachstellen auszunutzen (Exposed activities, intents, tapjacking...). Wie bei Drozer ist es nicht notwendig, das Testgerät zu rooten.

bash
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 schnellen Übersicht an
  • Dekompiliert 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
bash
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 Schwachstellen analysiert. Dazu entpackt 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 oder jeder Tester kann eigene Regeln erstellen, um das zu analysieren, was sie benötigen.

Lade die neuesten Binaries von der download page herunter.

super-analyzer {apk_file}

StaCoAn

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

Das Konzept ist, dass du die mobile Anwendungsdatei (eine .apk- oder .ipa-Datei) per Drag & Drop auf die StaCoAn-Anwendung ziehst und sie einen visuellen und portablen Bericht für dich erzeugt. Du kannst die Einstellungen und wordlists anpassen, um ein individuelles Erlebnis zu erhalten.

Herunterladen latest release:

./stacoan

AndroBugs

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

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

Dieses Tool sucht nach üblichen 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

MARA ist ein Mobile Application Reverse engineering and Analysis Framework. Es ist ein Tool, das häufig verwendete mobile application reverse engineering- und analysis-Tools zusammenführt, um bei der Prüfung von mobilen Anwendungen gegen die OWASP mobile security threats zu unterstützen. Ziel ist es, diese Aufgabe für mobile Application-Entwickler und Security-Professionals einfacher und zugänglicher zu machen.

Es kann:

Koodous

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

Obfuskation/Deobfuskation von Code

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

ProGuard

Von Wikipedia: ProGuard ist ein Open-Source-Command-Line-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 vertrieben.

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

DexGuard

Einen Schritt-für-Schritt-Guide zum Deobfuskieren der APK findet man unter https://blog.lexfo.fr/dexguard.html

(Aus diesem Guide) Bei unserer letzten Überprüfung war der Dexguard Betriebsmodus:

  • lade eine Ressource als InputStream;
  • leite das Ergebnis an eine Klasse weiter, die von FilterInputStream erbt, um es zu entschlüsseln;
  • mache einige nutzlose Obfuskationen, um einem Reverser ein paar Minuten Zeit zu rauben;
  • leite das entschlüsselte Ergebnis an einen ZipInputStream, um eine DEX-Datei zu erhalten;
  • lade schließlich die resultierende DEX als Resource mittels der loadDex-Methode.

DeGuard

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

Du kannst eine obfuskierte APK auf deren Plattform hochladen.

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

Dies ist ein LLM-Tool, um potenzielle security vulnerabilities in android apps zu finden und android app code zu deobfuskieren. Verwendet die öffentliche Google Gemini API.

Simplify

Ist ein generischer android deobfuscator. Simplify führt eine Art virtuelle Ausführung einer App durch, um ihr Verhalten zu verstehen, und versucht dann, den Code so zu optimieren, dass er identisch funktioniert, aber für einen Menschen leichter verständlich ist. Jede Optimierungsart ist einfach und generisch, daher spielt es keine Rolle, welche konkrete Art der Obfuskation verwendet wurde.

APKiD

APKiD liefert Informationen darüber, wie eine APK erstellt wurde. Es identifiziert viele Compiler, packer, obfuscators und andere merkwürdige Sachen. 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-Security-VM basierend auf ubuntu-mate und enthält eine Sammlung aktueller Frameworks, Tutorials und Labs von verschiedenen Security-Geeks und Researchern für reverse engineering und malware analysis.

Referenzen

tip

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

Unterstützen Sie HackTricks