diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-xpc-mach-services-abuse.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-xpc-mach-services-abuse.md index 8410d777f9e..1831c779a0a 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-xpc-mach-services-abuse.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-xpc-mach-services-abuse.md @@ -4,9 +4,9 @@ ## Basic Information -**XPC** (Cross-Process Communication) is the primary IPC mechanism on macOS. System daemons expose **Mach services** — named ports registered with `launchd` — that other processes can connect to via `NSXPCConnection`. +**XPC** (Cross-Process Communication) is the primary IPC mechanism on macOS. System daemons expose **Mach services** — named ports registered with `launchd` — that other processes can connect to via `NSXPCConnection`.[[1]](#references) -Every **LaunchDaemon** and **LaunchAgent** plist with a `MachServices` key registers one or more named Mach ports. These are system-wide XPC endpoints that any process can attempt to connect to. +Every **LaunchDaemon** and **LaunchAgent** plist with a `MachServices` key registers one or more named Mach ports. These are system-wide XPC endpoints that any process can attempt to connect to.[[2]](#references) > [!WARNING] > XPC Mach services are the **single largest local privilege escalation attack surface** on macOS. Most local root exploits in recent years went through vulnerable XPC services in LaunchDaemons. Every exposed method in a root daemon is a potential escalation vector. @@ -312,8 +312,8 @@ log stream --predicate 'process == "daemon-name" AND (eventMessage CONTAINS "cra | CVE-2021-30657 | Sysmond XPC privilege escalation | | CVE-2020-9839 | XPC race condition in system daemon | | CVE-2019-8802 | Privileged helper tool missing client verification | -| CVE-2023-32369 | Migraine — SIP bypass through `systemmigrationd` XPC | -| CVE-2022-26712 | PackageKit XPC root escalation | +| CVE-2023-32369 | Migraine — SIP bypass through `systemmigrationd` XPC[[3]](#references) | +| CVE-2022-26712 | PackageKit XPC root escalation[[4]](#references) | ## Enumeration Script @@ -349,7 +349,9 @@ done - [1] [Apple Developer — XPC Services](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html) - [2] [Apple Developer — Daemons and Services Programming Guide](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/Introduction.html) -- [3] [Objective-See — XPC Exploitation](https://objective-see.org/blog.html) -- [4] [OBTS — XPC Attack Surface talks](https://objectivebythesea.org/) +- [3] [New macOS vulnerability, Migraine, could bypass System Integrity Protection — Microsoft Security Blog](https://www.microsoft.com/en-us/security/blog/2023/05/30/new-macos-vulnerability-migraine-could-bypass-system-integrity-protection/) +- [4] [CVE-2022-26712: The POC for SIP-Bypass Is Even Tweetable](https://jhftss.github.io/CVE-2022-26712-The-POC-For-SIP-Bypass-Is-Even-Tweetable/) +- [5] [Objective-See — XPC Exploitation](https://objective-see.org/blog.html) +- [6] [OBTS — XPC Attack Surface talks](https://objectivebythesea.org/) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-protocols.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-protocols.md index 6dc3be70bee..c3087ca365d 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-protocols.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-protocols.md @@ -5,7 +5,7 @@ ## Remote Access Services These are the common macOS services to access them remotely.\ -You can enable/disable these services in `System Settings` --> `Sharing` +You can enable/disable these services in `System Settings` --> `Sharing`[[1]](#references) - **VNC**, known as “Screen Sharing” (tcp:5900) - **SSH**, called “Remote Login” (tcp:22) @@ -38,7 +38,7 @@ sudo launchctl print-disabled system | egrep 'com.apple.screensharing|com.apple. ### Pentesting ARD -Apple Remote Desktop (ARD) is an enhanced version of [Virtual Network Computing (VNC)](https://en.wikipedia.org/wiki/Virtual_Network_Computing) tailored for macOS, offering additional features. A notable vulnerability in ARD is its authentication method for the control screen password, which only uses the first 8 characters of the password, making it prone to [brute force attacks](https://thudinh.blogspot.com/2017/09/brute-forcing-passwords-with-thc-hydra.html) with tools like Hydra or [GoRedShell](https://github.com/ahhh/GoRedShell/), as there are no default rate limits.[[3]](#references) +Apple Remote Desktop (ARD) is an enhanced version of [Virtual Network Computing (VNC)](https://en.wikipedia.org/wiki/Virtual_Network_Computing) tailored for macOS, offering additional features. A notable vulnerability in ARD is its authentication method for the control screen password, which only uses the first 8 characters of the password, making it prone to [brute force attacks](https://thudinh.blogspot.com/2017/09/brute-forcing-passwords-with-thc-hydra.html) with tools like Hydra or [GoRedShell](https://github.com/ahhh/GoRedShell/), as there are no default rate limits.[[2]](#references) Vulnerable instances can be identified using **nmap**'s `vnc-info` script. Services supporting `VNC Authentication (2)` are especially susceptible to brute force attacks due to the 8-character password truncation. @@ -112,8 +112,8 @@ In practice, the abuse case is not limited to Finder. Any **scriptable applicati | Year | CVE | Component | Impact | Fixed in | |------|-----|-----------|--------|----------| -|2023|CVE-2023-42940|Screen Sharing|Incorrect session rendering could cause the *wrong* desktop or window to be transmitted, resulting in leakage of sensitive information|macOS Sonoma 14.2.1 (Dec 2023) | -|2024|CVE-2024-44248|Screen Sharing Server|A user with screen sharing access may be able to view **another user's screen** because of a state-management issue|macOS Ventura 13.7.2 / Sonoma 14.7.2 / Sequoia 15.1 (Oct-Dec 2024) | +|2023|CVE-2023-42940|Screen Sharing|Incorrect session rendering could cause the *wrong* desktop or window to be transmitted, resulting in leakage of sensitive information|macOS Sonoma 14.2.1 (Dec 2023) [[3]](#references)| +|2024|CVE-2024-44248|Screen Sharing Server|A user with screen sharing access may be able to view **another user's screen** because of a state-management issue|macOS Ventura 13.7.2 / Sonoma 14.7.2 / Sequoia 15.1 (Oct-Dec 2024) [[7]](#references)| **Hardening tips** @@ -250,8 +250,8 @@ For broader **mDNS spoofing, impersonation, and cross-subnet discovery** techniq | Year | CVE | Severity | Issue | Patched in | |------|-----|----------|-------|------------| -|2024|CVE-2024-44183|Medium|A logic error in *mDNSResponder* allowed a crafted packet to trigger a **denial-of-service**|macOS Ventura 13.7 / Sonoma 14.7 / Sequoia 15.0 (Sep 2024) | -|2025|CVE-2025-31222|High|A correctness issue in *mDNSResponder* could be abused for **local privilege escalation**|macOS Ventura 13.7.6 / Sonoma 14.7.6 / Sequoia 15.5 (May 2025) | +|2024|CVE-2024-44183|Medium|A logic error in *mDNSResponder* allowed a crafted packet to trigger a **denial-of-service**|macOS Ventura 13.7 / Sonoma 14.7 / Sequoia 15.0 (Sep 2024) [[4]](#references)| +|2025|CVE-2025-31222|High|A correctness issue in *mDNSResponder* could be abused for **local privilege escalation**|macOS Ventura 13.7.6 / Sonoma 14.7.6 / Sequoia 15.5 (May 2025) [[5]](#references)| **Mitigation guidance** @@ -275,14 +275,15 @@ sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.p ## References - [1] [The Mac Hacker's Handbook](https://www.amazon.com/-/es/Charlie-Miller-ebook-dp-B004U7MUMU/dp/B004U7MUMU/ref=mt_other?_encoding=UTF8&me=&qid=) -- [2] [The Art of Mac Malware, Volume I: Analysis - Patrick Wardle](https://taomm.org/vol1/analysis.html) -- [3] [LockBoxx - macOS Red Teaming 206: ARD (Apple Remote Desktop Protocol)](https://lockboxx.blogspot.com/2019/07/macos-red-teaming-206-ard-apple-remote.html) -- [4] [NVD – CVE-2023-42940](https://nvd.nist.gov/vuln/detail/CVE-2023-42940) -- [5] [NVD – CVE-2024-44183](https://nvd.nist.gov/vuln/detail/CVE-2024-44183) +- [2] [LockBoxx - macOS Red Teaming 206: ARD (Apple Remote Desktop Protocol)](https://lockboxx.blogspot.com/2019/07/macos-red-teaming-206-ard-apple-remote.html) +- [3] [NVD – CVE-2023-42940](https://nvd.nist.gov/vuln/detail/CVE-2023-42940) +- [4] [NVD – CVE-2024-44183](https://nvd.nist.gov/vuln/detail/CVE-2024-44183) +- [5] [NVD – CVE-2025-31222](https://nvd.nist.gov/vuln/detail/CVE-2025-31222) - [6] [Palo Alto Unit 42 - Lateral Movement on macOS: Unique and Popular Techniques and In-the-Wild Examples](https://unit42.paloaltonetworks.com/unique-popular-techniques-lateral-movement-macos/) - [7] [Apple Support - About the security content of macOS Sonoma 14.7.2](https://support.apple.com/en-us/121840) - [8] [Apple Screen Sharing Pre-Auth RCE](https://warez.sl0p.foo/apple-screensharing-rce/) - [9] [Apple Support - About the security content of macOS Tahoe 26.6](https://support.apple.com/en-us/128067) - [10] [RFC 5054 - Using the Secure Remote Password (SRP) Protocol for TLS Authentication](https://www.rfc-editor.org/rfc/rfc5054) +- [11] [The Art of Mac Malware, Volume I: Analysis - Patrick Wardle](https://taomm.org/vol1/analysis.html) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/README.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/README.md index d91c11965e5..1ffea545725 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/README.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/README.md @@ -149,4 +149,3 @@ T {{#include ../../../banners/hacktricks-training.md}} - diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md index 8f16ab6b09d..9e70437b04f 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-amfi-applemobilefileintegrity.md @@ -163,6 +163,3 @@ In iOS and jailbreak research you'll still find the traditional model of **loada - [6] [Apple Platform Security Guide — Trust caches](https://support.apple.com/guide/security/trust-caches-sec7d38fbf97/web) {{#include ../../../banners/hacktricks-training.md}} - - - diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-authorizations-db-and-authd.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-authorizations-db-and-authd.md index 7d202d98284..79c49be4014 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-authorizations-db-and-authd.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-authorizations-db-and-authd.md @@ -89,4 +89,5 @@ That will fork and exec `/usr/libexec/security_authtrampoline /bin/ls` as root, - [1] [authenticate-admin-nonshared - Overview of the macOS Authorization Right](https://www.dssw.co.uk/reference/authorization-rights/authenticate-admin-nonshared/) + {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md index d6c3bf368a4..7323e691261 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md +++ b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md @@ -46,7 +46,7 @@ Flags: `--skip-build` (patch only), `--skip-clone`, `--arch`, `--ndk-path`, `--t Many apps only look for obvious indicators (su/Magisk paths/getprop). DenyList often neutralizes naive checks.[[1]](#references) References: -- Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk +- Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk[[9]](#references) ### Play Integrity / Zygisk detections (post‑SafetyNet) @@ -70,9 +70,9 @@ Example: frida -U -f com.example.app -l anti-frida-detection.js ``` -These typically stub Java root/debug checks, process/service scans, and native ptrace(). Useful on lightly protected apps; hardened targets may need tailored hooks. +These typically stub Java root/debug checks, process/service scans, and native ptrace(). Useful on lightly protected apps; hardened targets may need tailored hooks.[[1]](#references)[[2]](#references) -- Codeshare: https://codeshare.frida.re/ +- Codeshare: https://codeshare.frida.re/[[2]](#references) ## Automate with Medusa (Frida framework) @@ -129,7 +129,7 @@ If this works, keep the session stable and proceed to map and stub checks. ## Step 4 — Map detection logic via Jadx and string hunting -Static triage keywords in Jadx:[[1]](#references) +Static triage keywords in Jadx:[[1]](#references)[[5]](#references) - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger" Typical Java patterns: @@ -177,7 +177,7 @@ Java.perform(() => { }); ``` -Quick root detection stub example (adapt to target package/class names): +Quick root detection stub example (adapt to target package/class names):[[12]](#references) ```js Java.perform(() => { @@ -202,7 +202,7 @@ Java.perform(() => { ## Bypass emulator/VM detection (Java stubs) -Common heuristics: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE containing generic/goldfish/ranchu/sdk; QEMU artifacts like /dev/qemu_pipe, /dev/socket/qemud; default MAC 02:00:00:00:00:00; 10.0.2.x NAT; missing telephony/sensors. +Common heuristics: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE containing generic/goldfish/ranchu/sdk; QEMU artifacts like /dev/qemu_pipe, /dev/socket/qemud; default MAC 02:00:00:00:00:00; 10.0.2.x NAT; missing telephony/sensors.[[12]](#references) Quick spoof of Build fields: ```js @@ -219,7 +219,7 @@ Complement with stubs for file existence checks and identifiers (TelephonyManage ## SSL pinning bypass quick hook (Java) -Neutralize custom TrustManagers and force permissive SSL contexts: +Neutralize custom TrustManagers and force permissive SSL contexts:[[12]](#references) ```js Java.perform(function(){ var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager'); @@ -248,7 +248,7 @@ For **mTLS** apps, `SSLContext.init(KeyManager[], TrustManager[], SecureRandom)` - **`TrustManager[]`** validates the **server** certificate. - **`KeyManager[]`** presents the **client** certificate/private key. -If you replace **both** arrays with a generic “trust all” hook, the app may accept Burp's certificate but **stop sending its client certificate**, so the handshake still fails. In mTLS scenarios, keep the original `KeyManager[]` and replace **only** `TrustManager[]`.[[17]](#references) +If you replace **both** arrays with a generic “trust all” hook, the app may accept Burp's certificate but **stop sending its client certificate**, so the handshake still fails. In mTLS scenarios, keep the original `KeyManager[]` and replace **only** `TrustManager[]`.[[17]](#references)[[18]](#references) ```js Java.perform(function () { @@ -274,7 +274,7 @@ A common Android mTLS pattern is: 2. store the private key + issued client cert in **PKCS12** (`.p12`), often with a runtime-derived password, 3. reload that keystore on every request to build a `KeyManager`. -That password can be strong at rest and still be useless during runtime: the app must eventually call `KeyStore.load(...)`, `getCertificate(...)`, and `getKey(alias, password)` in-process. Hook the method/constructor that receives the **decrypted `KeyStore`**, alias, and password (often a custom `KeyManager` wrapper) and dump the live material instead of brute-forcing the `.p12` offline.[[17]](#references) +That password can be strong at rest and still be useless during runtime: the app must eventually call `KeyStore.load(...)`, `getCertificate(...)`, and `getKey(alias, password)` in-process. Hook the method/constructor that receives the **decrypted `KeyStore`**, alias, and password (often a custom `KeyManager` wrapper) and dump the live material instead of brute-forcing the `.p12` offline.[[17]](#references)[[18]](#references) Quick triage: - `privateKey.getEncoded()` returns **bytes** → software/JCE key, usually exportable. @@ -317,7 +317,7 @@ Useful extra hook points when Frida is attached **before enrollment**: ### OkHttp4 / gRPC / Cronet pinning (2024+) -Modern stacks pin inside newer APIs (OkHttp4+, gRPC over Cronet/BoringSSL). Add these hooks when the basic SSLContext hook hangs: +Modern stacks pin inside newer APIs (OkHttp4+, gRPC over Cronet/BoringSSL). Add these hooks when the basic SSLContext hook hangs:[[14]](#references) ```js Java.perform(() => { @@ -368,8 +368,8 @@ strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root' ``` Interactive/native reversing: -- Ghidra: https://ghidra-sre.org/ -- r2frida: https://github.com/nowsecure/r2frida +- Ghidra: https://ghidra-sre.org/[[6]](#references) +- r2frida: https://github.com/nowsecure/r2frida[[7]](#references) Example: neuter ptrace to defeat simple anti‑debug in libc: @@ -396,17 +396,17 @@ objection patchapk --source app.apk ``` Notes: -- Requires apktool; ensure a current version from the official guide to avoid build issues: https://apktool.org/docs/install +- Requires apktool; ensure a current version from the official guide to avoid build issues: https://apktool.org/docs/install[[8]](#references) - Gadget injection enables instrumentation without root but can still be caught by stronger init‑time checks. -Optionally, add LSPosed modules and Shamiko for stronger root hiding in Zygisk environments, and curate DenyList to cover child processes. +Optionally, add LSPosed modules and Shamiko for stronger root hiding in Zygisk environments, and curate DenyList to cover child processes.[[12]](#references) For a complete workflow including script-mode Gadget configuration and bundling your Frida 17+ agent into the APK, see: [Frida Tutorial — Self-contained agent + Gadget embedding](frida-tutorial/README.md) References: -- Objection: https://github.com/sensepost/objection +- Objection: https://github.com/sensepost/objection[[3]](#references) ## Step 8 — Fallback: Patch TLS pinning for network visibility @@ -417,7 +417,7 @@ apk-mitm app.apk # Then install the patched APK and proxy via Burp/mitmproxy ``` -- Tool: https://github.com/shroudedcode/apk-mitm +- Tool: https://github.com/shroudedcode/apk-mitm[[4]](#references) - For network config CA‑trust tricks (and Android 7+ user CA trust), see: {{#ref}} @@ -557,4 +557,5 @@ Notes - [16] [Weaponizing LSPosed: Remote SMS Injection and Identity Spoofing in Modern Payment Ecosystems](https://www.cloudsek.com/blog/weaponizing-lsposed-remote-sms-injection-and-identity-spoofing-in-modern-payment-ecosystems-2) - [17] [How to Bypass mTLS on Android with Frida](https://kiratliygt.medium.com/how-to-bypass-mtls-on-android-with-frida-45c5e71373e8) - [18] [Demo-mTLS- lab app/server](https://github.com/YigitK-1/Demo-mTLS-) + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/android-application-level-virtualization.md b/src/mobile-pentesting/android-app-pentesting/android-application-level-virtualization.md index adfb9a515d7..7c4c7746fc8 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-application-level-virtualization.md +++ b/src/mobile-pentesting/android-app-pentesting/android-application-level-virtualization.md @@ -7,7 +7,7 @@ Application-level virtualization (aka app cloning/container frameworks such as D ## Baseline install/launch vs virtualized execution - **Normal install**: Package Manager extracts APK → `/data/app//com.pkg-/base.apk`, assigns a **unique UID**, and Zygote forks a process that loads `classes.dex`. -- **Dex load primitive**: `DexFile.openDexFile()` delegates to `openDexFileNative()` using absolute paths; virtualization layers commonly hook/redirect this to load guest dex from host-controlled paths. +- **Dex load primitive**: `DexFile.openDexFile()` delegates to `openDexFileNative()` using absolute paths; virtualization layers commonly hook/redirect this to load guest dex from host-controlled paths.[[1]](#references) - **Virtualized launch**: Host starts a process under **its UID**, loads the guest’s `base.apk`/dex with a custom loader, and exposes lifecycle callbacks via Java proxies. Guest storage API calls are remapped to host-controlled paths.[[1]](#references) ## Abuse patterns diff --git a/src/mobile-pentesting/android-app-pentesting/android-enterprise-work-profile-bypass.md b/src/mobile-pentesting/android-app-pentesting/android-enterprise-work-profile-bypass.md index f11585c2b0f..ab421eb2af7 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-enterprise-work-profile-bypass.md +++ b/src/mobile-pentesting/android-app-pentesting/android-enterprise-work-profile-bypass.md @@ -28,7 +28,7 @@ adb install --user 1 legit.apk # java.lang.SecurityException: Shell does not have permission to access user 1 ``` -* You must have **temporary physical access to an unlocked BYOD** to enable Developer Options + USB debugging. +* You must have **temporary physical access to an unlocked BYOD** to enable Developer Options + USB debugging.[[1]](#references) * Identify the **package name** of a Work-Profile app marked as *required* (e.g. `com.workday.workdroidapp`). ## Weaponising the Android Studio multi-user installer diff --git a/src/mobile-pentesting/android-app-pentesting/android-hce-nfc-emv-relay-attacks.md b/src/mobile-pentesting/android-app-pentesting/android-hce-nfc-emv-relay-attacks.md index ca87de9ec17..3994d3dbe2d 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-hce-nfc-emv-relay-attacks.md +++ b/src/mobile-pentesting/android-app-pentesting/android-hce-nfc-emv-relay-attacks.md @@ -7,7 +7,7 @@ Abuse of Android Host Card Emulation (HCE) allows a malicious app set as the default NFC payment service to relay EMV contactless transactions in real-time. The POS terminal talks ISO 14443-4/EMV to the phone; the app’s HostApduService receives APDUs and forwards them over a bidirectional C2 (often WebSocket) to a backend that crafts responses, which are relayed back to the POS. This enables live card emulation without local card data. Campaigns observed at scale rebrand as banks/government apps, prompt to become the default payment app, and auto-exfiltrate device/card data to Telegram bots/channels.[[1]](#references) Key traits -- Android components: HostApduService + default NFC payment handler (category "payment")[[1]](#references) +- Android components: HostApduService + default NFC payment handler (category "payment")[[1]](#references)[[2]](#references) - Transport/C2: WebSocket for APDU relay; Telegram bot API for exfil/ops - Operator workflow: structured commands (login, register_device, apdu_command/apdu_response, get_pin/pin_response, paired, check_status, update_required, telegram_notification, error) - Roles: scanner (read EMV data) vs tapper (HCE/relay) builds @@ -35,7 +35,7 @@ Key traits ``` -Example AID list with EMV payment category (only apps set as default payment can answer these AIDs): +Example AID list with EMV payment category (only apps set as default payment can answer these AIDs):[[3]](#references) ```xml @@ -139,8 +139,8 @@ A complementary role is the **reader/scanner** build running on the victim phone Typical workflow: -1. `onTagDiscovered(Tag)` obtains an `IsoDep` handle with `IsoDep.get(tag)`. -2. The app calls `connect()` and often increases the APDU timeout with `setTimeout(120000)` to survive slow user interaction or backend waits. +1. `onTagDiscovered(Tag)` obtains an `IsoDep` handle with `IsoDep.get(tag)`.[[5]](#references) +2. The app calls `connect()` and often increases the APDU timeout with `setTimeout(120000)` to survive slow user interaction or backend waits.[[4]](#references) 3. It sends **SELECT PPSE** (`2PAY.SYS.DDF01`) to enumerate payment applications exposed by the card. 4. It parses returned TLV/EMV data to recover values such as **PAN/card number**, **expiry**, **application label**, and candidate **AIDs**. 5. The harvested data is serialized and immediately exfiltrated, commonly over the same WebSocket/C2 channel later used by the HCE relay side. @@ -181,7 +181,7 @@ jadx sample.apk -d out-jadx apktool d sample.apk -o out-apktool ``` -If tools disagree about the file list, ZIP offsets, or `AndroidManifest.xml` decoding, rebuild a normalized sample before deeper reversing. Tools such as **apkInspector** are useful here because they inspect ZIP structure and still extract manifest-level artifacts from hostile APK containers. +If tools disagree about the file list, ZIP offsets, or `AndroidManifest.xml` decoding, rebuild a normalized sample before deeper reversing. Tools such as **apkInspector** are useful here because they inspect ZIP structure and still extract manifest-level artifacts from hostile APK containers.[[7]](#references) ## Operator workflows seen in the wild diff --git a/src/mobile-pentesting/android-app-pentesting/android-physical-attacks.md b/src/mobile-pentesting/android-app-pentesting/android-physical-attacks.md index 6d7baef4422..7435f3f8d71 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-physical-attacks.md +++ b/src/mobile-pentesting/android-app-pentesting/android-physical-attacks.md @@ -11,7 +11,7 @@ For **mobile app pentests** and **seizure/forensics threat modeling**, it is use ### Android credential path that matters during physical attacks -Modern Android credential protection is not just the lockscreen UI: +Modern Android credential protection is not just the lockscreen UI:[[2]](#references) - **Gatekeeper** verifies PIN/password/pattern and rate-limits guesses.[[3]](#references) - **Keymaster / KeyMint** releases **authentication-bound keys** only after a valid Gatekeeper token.[[5]](#references) @@ -52,7 +52,7 @@ If you need the early-boot details for MediaTek devices, review: ../../hardware-physical-access/firmware-analysis/android-mediatek-secure-boot-bl2_ext-bypass-el3.md {{#endref}} -Also note that **public tooling such as [MTKClient](https://github.com/bkerler/mtkclient)** makes several MediaTek Boot ROM / download-mode workflows practical on affected chipsets. +Also note that **public tooling such as [MTKClient](https://github.com/bkerler/mtkclient)** makes several MediaTek Boot ROM / download-mode workflows practical on affected chipsets.[[6]](#references) ### Biometric TA AuthToken forgery: root-to-CE bypass without patching Gatekeeper diff --git a/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md b/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md index 17274ec62db..caa0649cd1b 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md +++ b/src/mobile-pentesting/android-app-pentesting/android-task-hijacking.md @@ -116,7 +116,7 @@ Mitigation for legacy devices is the same as classic Task Hijacking **plus** run ## Mitigation -Developers should: +Developers should:[[4]](#references) * Explicitly set `android:taskAffinity=""` at the `` level (recommended) **or** give each activity a unique, private affinity. * For highly sensitive screens, combine the above with `android:launchMode="singleInstance"` or modern [`setLaunchMode`](https://developer.android.com/reference/android/content/pm/ActivityInfo#launchMode) protections. diff --git a/src/mobile-pentesting/android-app-pentesting/android-vpn-bypass.md b/src/mobile-pentesting/android-app-pentesting/android-vpn-bypass.md index 9890d119c9d..a0d74bb5c03 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-vpn-bypass.md +++ b/src/mobile-pentesting/android-app-pentesting/android-vpn-bypass.md @@ -13,7 +13,7 @@ Typical red flags: * The privileged side later **recreates the socket or packet** as `system_server`/system UID and sends it on a network chosen from saved metadata. * The payload is treated as protocol-specific data but the implementation never validates that it really matches the expected frame type. -Example pattern seen in Android 16 QUIC graceful close abuse: +Example pattern seen in Android 16 QUIC graceful close abuse:[[1]](#references) 1. The app enumerates visible networks with `ConnectivityManager.getAllNetworks()` and `getLinkProperties()`. 2. Instead of `Network.bindSocket()` (which enforces VPN lockdown), it creates `new DatagramSocket(new InetSocketAddress(, 0))`. That path reaches the kernel `bind()` syscall, which only checks whether the local IP exists on an interface. diff --git a/src/mobile-pentesting/android-app-pentesting/apk-decompilers.md b/src/mobile-pentesting/android-app-pentesting/apk-decompilers.md index daf0197b24d..30d4de714b9 100644 --- a/src/mobile-pentesting/android-app-pentesting/apk-decompilers.md +++ b/src/mobile-pentesting/android-app-pentesting/apk-decompilers.md @@ -80,6 +80,3 @@ This is especially practical for **field triage**, **mobile malware static analy - [3] [How to Break Your JAR in 2021 - Decompilation Guide for JARs and APKs](https://eiken.dev/blog/2021/02/how-to-break-your-jar-in-2021-decompilation-guide-for-jars-and-apks/#cfr) {{#include ../../banners/hacktricks-training.md}} - - - diff --git a/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md b/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md index 352e2da8437..434c8ecefd2 100644 --- a/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md +++ b/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md @@ -276,7 +276,6 @@ Using [rootAVD](https://github.com/newbit1/rootAVD) with [Magisk](https://github Check the following page to learn how to install a custom CA cert: - {{#ref}} install-burp-certificate.md {{#endref}} @@ -296,5 +295,3 @@ You can **use the GUI** to take a snapshot of the VM at any time: - [3] [Run ARM apps on the Android Emulator (x86 translation)](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html) {{#include ../../banners/hacktricks-training.md}} - - diff --git a/src/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md b/src/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md index ebff01c6d84..38fff740de2 100644 --- a/src/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md +++ b/src/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md @@ -2,7 +2,6 @@ {{#include ../../banners/hacktricks-training.md}} - ## **Method 1 – Bypassing with No Crypto Object Usage** The focus here is on the _onAuthenticationSucceeded_ callback, which is crucial in the authentication process. Researchers at WithSecure developed a [Frida script](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass.js), enabling the bypass of the NULL _CryptoObject_ in _onAuthenticationSucceeded(...)_. The script forces an automatic bypass of the fingerprint authentication upon the method's invocation. Below is a simplified snippet demonstrating the bypass in an Android Fingerprint context, with the full application available on [GitHub](https://github.com/St3v3nsS/InsecureBanking).[[3]](#references) @@ -105,7 +104,7 @@ If the app does **not** subsequently validate the returned `AuthenticationResult Keep an eye on Android security bulletins: several recent kernel-side bugs allow local privilege escalation through the fingerprint HAL and effectively **disable or short-circuit the sensor pipeline**. Examples include: -* **CVE-2023-20995** – logic error in `captureImage` of `CustomizedSensor.cpp` (Pixel 8, Android 13) allowing unlock bypass without user interaction. +* **CVE-2023-20995** – logic error in `captureImage` of `CustomizedSensor.cpp` (Pixel 8, Android 13) allowing unlock bypass without user interaction.[[4]](#references) * **CVE-2024-53835 / CVE-2024-53840** – “possible biometric bypass due to an unusual root cause” patched in the **December 2024 Pixel bulletin**.[[2]](#references) Although these vulnerabilities target the lock-screen, a rooted tester may chain them with app-level flaws to bypass in-app biometrics as well. @@ -124,6 +123,6 @@ Although these vulnerabilities target the lock-screen, a rooted tester may chain - [1] [Universal Android Biometric Bypass – Frida CodeShare](https://codeshare.frida.re/@ax/universal-android-biometric-bypass/) - [2] [Android Pixel Security Bulletin 2024-12-01](https://source.android.com/security/bulletin/pixel/2024-12-01) - [3] [How Secure is your Android Keystore Authentication?](https://labs.reversec.com/posts/2019/08/how-secure-is-your-android-keystore-authentication) - +- [4] [Pixel Update Bulletin—March 2023](https://source.android.com/docs/security/bulletin/pixel/2023-03-01) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/content-protocol.md b/src/mobile-pentesting/android-app-pentesting/content-protocol.md index 388b880cd5e..0992c1f1d47 100644 --- a/src/mobile-pentesting/android-app-pentesting/content-protocol.md +++ b/src/mobile-pentesting/android-app-pentesting/content-protocol.md @@ -2,7 +2,7 @@ {{#include ../../banners/hacktricks-training.md}} -**This is a summary of the post [https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/](https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/)** +**This is a summary of the post [https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/](https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027/)**[[3]](#references) This page focuses on abusing the **`content://` protocol itself** (browser/WebView loads, URI grants, share/import flows). For generic provider enumeration, SQLi, path traversal and permission issues, check [**Exploiting Content Providers**](drozer-tutorial/exploiting-content-providers.md) and [**Intent Injection**](intent-injection.md). @@ -155,10 +155,10 @@ On modern Android versions, direct `/sdcard` paths matter less than **granted** From an offensive perspective, these URIs are attractive because a vulnerable app may call `takePersistableUriPermission()` after receiving them. That turns a one-shot `content://` access into a **long-lived grant** that can survive app restarts or even device reboots. When chaining an exported proxy Activity or an intent-redirection bug, prefer testing **document/tree URIs** in addition to plain MediaStore paths. - - ## References - [1] [CENSUS - Remote exploitation of a man-in-the-disk vulnerability in WhatsApp (CVE-2021-24027)](https://www.census-labs.com/resources/remote-exploitation-of-a-man-in-the-disk-vulnerability-in-whatsapp-cve-2021-24027) - [2] [Microsoft - "Dirty stream" attack: Discovering and mitigating a common vulnerability pattern in Android apps](https://www.microsoft.com/en-us/security/blog/2024/05/01/dirty-stream-attack-discovering-and-mitigating-a-common-vulnerability-pattern-in-android-apps/) +- [3] [census-labs.com - Whatsapp Mitd Remote Exploitation CVE 2021 24027](https://census-labs.com/news/2021/04/14/whatsapp-mitd-remote-exploitation-CVE-2021-24027) + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/README.md b/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/README.md index 13174a77485..7296bb0e627 100644 --- a/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/README.md +++ b/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/README.md @@ -2,8 +2,6 @@ {{#include ../../../banners/hacktricks-training.md}} - - ## APKs to test - [Sieve](https://github.com/mwrlabs/drozer/releases/download/2.3.4/sieve.apk) (from mrwlabs) @@ -29,7 +27,7 @@ adb install drozer.apk ### Starting the Server -Agent is running on port 31415, we need to [port forward](https://en.wikipedia.org/wiki/Port_forwarding) to establish the communication between the Drozer Client and Agent, here is the command to do so: +Agent is running on port 31415, we need to [port forward](https://en.wikipedia.org/wiki/Port_forwarding) to establish the communication between the Drozer Client and Agent, here is the command to do so:[[4]](#references) ```bash adb forward tcp:31415 tcp:31415 @@ -64,7 +62,7 @@ drozer console connect ### Package -Find the **name** of the package filtering by part of the name: +Find the **name** of the package filtering by part of the name:[[6]](#references) ```bash dz> run app.package.list -f sieve @@ -112,7 +110,7 @@ Attack Surface: ``` - **Activities**: Maybe you can start an activity and bypass some kind of authorization that should be prevent you from launching it. -- **Content providers**: Maybe you can access private data or exploit some vulnerability (SQL Injection or Path Traversal). +- **Content providers**: Maybe you can access private data or exploit some vulnerability (SQL Injection or Path Traversal).[[3]](#references) - **Services**: - **is debuggable**: [Learn more](#is-debuggeable) @@ -137,7 +135,7 @@ Package: com.mwr.example.sieve **Start activity**: -Maybe you can start an activity and bypass some kind of authorization that should be prevent you from launching it. +Maybe you can start an activity and bypass some kind of authorization that should be prevent you from launching it.[[5]](#references) ```bash dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.sieve.PWList @@ -269,7 +267,7 @@ run app.broadcast.send --action org.owasp.goatdroid.fourgoats.SOCIAL_SMS --compo ### Is debuggeable A prodduction APK should never be debuggeable.\ -This mean that you can **attach java debugger** to the running application, inspect it in run time, set breakpoints, go step by step, gather variable values and even change them.[ InfoSec institute has an excellent article](../exploiting-a-debuggeable-applciation.md) on digging deeper when you application is debuggable and injecting runtime code. +This mean that you can **attach java debugger** to the running application, inspect it in run time, set breakpoints, go step by step, gather variable values and even change them.[ InfoSec institute has an excellent article](../exploiting-a-debuggeable-applciation.md) on digging deeper when you application is debuggable and injecting runtime code.[[2]](#references) When an application is debuggable, it will appear in the Manifest: @@ -283,22 +281,13 @@ You can find all debuggeable applications with **Drozer**: run app.package.debuggable ``` -## Tutorials - -- [https://resources.infosecinstitute.com/android-penetration-tools-walkthrough-series-drozer/#gref](https://resources.infosecinstitute.com/android-penetration-tools-walkthrough-series-drozer/#gref) -- [https://github.com/mgcfish/mobiletools/blob/master/\_posts/2016-08-01-Using-Drozer-for-application-security-assessments.md](https://github.com/mgcfish/mobiletools/blob/master/_posts/2016-08-01-Using-Drozer-for-application-security-assessments.md) -- [https://www.hackingarticles.in/android-penetration-testing-drozer/](https://www.hackingarticles.in/android-penetration-testing-drozer/) -- [https://medium.com/@ashrafrizvi3006/how-to-test-android-application-security-using-drozer-edc002c5dcac](https://medium.com/@ashrafrizvi3006/how-to-test-android-application-security-using-drozer-edc002c5dcac) - -## More info - -- [https://blog.dixitaditya.com/android-pentesting-cheatsheet/](https://blog.dixitaditya.com/android-pentesting-cheatsheet/) - ## References - [1] [Drozer User Guide (mwri-drozer-user-guide-2015-03-23.pdf)](https://labs.withsecure.com/content/dam/labs/docs/mwri-drozer-user-guide-2015-03-23.pdf) +- [2] [Android Penetration Testing Tools Walkthrough Series: Drozer](https://resources.infosecinstitute.com/android-penetration-tools-walkthrough-series-drozer/#gref) +- [3] [Using Drozer for Application Security Assessments](https://github.com/mgcfish/mobiletools/blob/master/_posts/2016-08-01-Using-Drozer-for-application-security-assessments.md) +- [4] [Android Penetration Testing: Drozer](https://www.hackingarticles.in/android-penetration-testing-drozer/) +- [5] [How to Test Android Application Security Using Drozer](https://medium.com/@ashrafrizvi3006/how-to-test-android-application-security-using-drozer-edc002c5dcac) +- [6] [Android Pentesting Cheatsheet](https://blog.dixitaditya.com/android-pentesting-cheatsheet/) {{#include ../../../banners/hacktricks-training.md}} - - - diff --git a/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/exploiting-content-providers.md b/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/exploiting-content-providers.md index 61c6e809021..bf51f5c9025 100644 --- a/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/exploiting-content-providers.md +++ b/src/mobile-pentesting/android-app-pentesting/drozer-tutorial/exploiting-content-providers.md @@ -4,7 +4,7 @@ ## Intro -Data is **supplied from one application to others** on request by a component known as a **content provider**. These requests are managed through the **ContentResolver class** methods. Content providers can store their data in various locations, such as a **database**, **files**, or over a **network**. +Data is **supplied from one application to others** on request by a component known as a **content provider**. These requests are managed through the **ContentResolver class** methods. Content providers can store their data in various locations, such as a **database**, **files**, or over a **network**.[[6]](#references) In the _Manifest.xml_ file, the declaration of the content provider is required. For instance: @@ -116,7 +116,7 @@ Knowing the name of the columns you could also **modify the entries**: ### **SQL Injection** It is simple to test for SQL injection **(SQLite)** by manipulating the **projection** and **selection fields** that are passed to the content provider.\ -When quering the Content Provider there are 2 interesting arguments to search for information: _--selection_ and _--projection_: +When quering the Content Provider there are 2 interesting arguments to search for information: _--selection_ and _--projection_:[[7]](#references) ![Delete content - SQL Injection: When quering the Content Provider there are 2 interesting arguments to search for information: --selection and --projection](<../../../images/image (784).png>) @@ -159,11 +159,11 @@ Accessible tables for uri content://jakhar.aseem.diva.provider.notesprovider/not ### writePermission omission + blind SQLi via update() -A common OEM mistake is to export a ContentProvider with a readPermission but omit writePermission. When writePermission is null, any app can call insert/update/delete if those methods are implemented. If update() concatenates the caller-controlled WHERE (selection) directly into an SQL statement, you can build a blind inference oracle and exfiltrate data from other tables in the same SQLite DB (even those normally protected by privileged read permissions like READ_SMS).[[1]](#references) +A common OEM mistake is to export a ContentProvider with a readPermission but omit writePermission. When writePermission is null, any app can call insert/update/delete if those methods are implemented. If update() concatenates the caller-controlled WHERE (selection) directly into an SQL statement, you can build a blind inference oracle and exfiltrate data from other tables in the same SQLite DB (even those normally protected by privileged read permissions like READ_SMS).[[1]](#references)[[2]](#references) Key idea -- Exported provider, readPermission set, writePermission omitted -- update(uri, values, where, whereArgs) returns rows-affected; UNIQUE constraint errors also indicate a write attempt happened +- Exported provider, readPermission set, writePermission omitted[[3]](#references)[[4]](#references) +- update(uri, values, where, whereArgs) returns rows-affected; UNIQUE constraint errors also indicate a write attempt happened[[5]](#references) - Attack controls WHERE to evaluate a Boolean expression over a subquery that reads secret data from co-located tables - If the provider’s table is empty, insert() can be abused to seed a row so update() affects ≥1 row @@ -266,7 +266,7 @@ dz> run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc ### **Path Traversal** -If you can access files, you can try to abuse a Path Traversal (in this case this isn't necessary but you can try to use "_../_" and similar tricks). +If you can access files, you can try to abuse a Path Traversal (in this case this isn't necessary but you can try to use "_../_" and similar tricks).[[7]](#references) ``` dz> run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc/hosts @@ -352,7 +352,7 @@ Safer design for developers: ### Drozer 3.x (Python 3) is out -WithSecure resumed maintenance of drozer in 2022 and ported the framework to **Python 3** (latest **3.1.0 – April 2024**). +WithSecure resumed maintenance of drozer in 2022 and ported the framework to **Python 3** (latest **3.1.0 – April 2024**).[[9]](#references) Besides compatibility fixes, new modules that are particularly useful when working with Content Providers include: * `scanner.provider.exported` – list only providers with `android:exported="true"`. @@ -384,7 +384,7 @@ Combine it with `run-as ` or a rooted shell to test internal-only providers | CVE | Year | Component | Bug class | Impact | |-----|------|-----------|-----------|--------| -| CVE-2024-43089 | 2024 | MediaProvider | Path traversal in `openFile()` | Arbitrary file read from any app’s private storage | +| CVE-2024-43089 | 2024 | MediaProvider | Path traversal in `openFile()` | Arbitrary file read from any app’s private storage[[10]](#references) | | CVE-2023-35670 | 2023 | MediaProvider | Path traversal | Information disclosure | Re-create CVE-2024-43089 on a vulnerable build: diff --git a/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md b/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md index 2cedddcf03f..be5bab32482 100644 --- a/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md +++ b/src/mobile-pentesting/android-app-pentesting/exploiting-a-debuggeable-applciation.md @@ -10,7 +10,7 @@ This section of the post is a summary from the post [**https://medium.com/@shubh ### **Making the App Debuggable** -Content based on https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0 +Content based on https://medium.com/@shubhamsonani/hacking-with-precision-bypass-techniques-via-debugger-in-android-apps-27fd562b2cc0[[1]](#references) 1. **Decompile the APK:** diff --git a/src/mobile-pentesting/android-app-pentesting/firmware-level-zygote-backdoor-libandroid_runtime.md b/src/mobile-pentesting/android-app-pentesting/firmware-level-zygote-backdoor-libandroid_runtime.md index 19419f55380..fed511d64fe 100644 --- a/src/mobile-pentesting/android-app-pentesting/firmware-level-zygote-backdoor-libandroid_runtime.md +++ b/src/mobile-pentesting/android-app-pentesting/firmware-level-zygote-backdoor-libandroid_runtime.md @@ -93,7 +93,7 @@ Practical implications: ## Persistence & forensic tips - Supply chain placement: malicious static lib `libVndxUtils.a` linked into `libandroid_runtime.so` during build (e.g., `vendor/mediatek/proprietary/external/libutils/arm[64]/libVndxUtils.a`).[[1]](#references) -- Firmware auditing: firmware images ship as Android Sparse `super.img`; use `lpunpack` (or similar) to extract partitions and inspect `libandroid_runtime.so` for extra calls in `println_native`. +- Firmware auditing: firmware images ship as Android Sparse `super.img`; use `lpunpack` (or similar) to extract partitions and inspect `libandroid_runtime.so` for extra calls in `println_native`.[[2]](#references) - On-device artifacts: presence of `/data/dalvik-cache/arm*/system@framework@vndx_10x.jar@classes.jar`, logcat tag `AK_CPP`, or protected broadcasts named `com.action.SystemOptimizeService`/`com.action.SystemProtectService` indicate compromise.[[1]](#references) - For Android rootkits deployed from apps instead of factory supply chain, also inspect:[[3]](#references) - APK `assets/` for polyglot PNGs with appended data after `IEND` diff --git a/src/mobile-pentesting/android-app-pentesting/flutter.md b/src/mobile-pentesting/android-app-pentesting/flutter.md index bb5f72f445a..eba97eae7c6 100644 --- a/src/mobile-pentesting/android-app-pentesting/flutter.md +++ b/src/mobile-pentesting/android-app-pentesting/flutter.md @@ -15,7 +15,7 @@ This is a summary of this [blog post](https://sensepost.com/blog/2025/intercepti * Symbols in libflutter.so are **stripped & mangled**, hiding the certificate-verification function from dynamic tools. ### Fingerprint the exact Flutter stack -When **reFlutter** cannot auto-patch the APK (unsupported engine hash, debug engine, missing `libapp.so`, newer release), avoid guessing offsets and derive the exact Flutter/BoringSSL pair first. +When **reFlutter** cannot auto-patch the APK (unsupported engine hash, debug engine, missing `libapp.so`, newer release), avoid guessing offsets and derive the exact Flutter/BoringSSL pair first.[[2]](#references) Step | Command / File | Outcome ----|----|---- @@ -25,7 +25,7 @@ Map hash → Engine | `curl -s https://raw.githubusercontent.com/Impact-I/reFlut If hash is missing | `python3 gen_enginehash.py` in reFlutter `scripts/` | Fresh local hash table for newer/debug builds Pull dependent commits | Flutter release `DEPS` file | Exact `dart_boringssl_rev` / BoringSSL commit -Find [get_snapshot_hash.py here](https://github.com/Impact-I/reFlutter/blob/main/scripts/get_snapshot_hash.py). A bogus hash such as repeated `4` values usually means the script was run against `libflutter.so` instead of `libapp.so`. +Find [get_snapshot_hash.py here](https://github.com/Impact-I/reFlutter/blob/main/scripts/get_snapshot_hash.py). A bogus hash such as repeated `4` values usually means the script was run against `libflutter.so` instead of `libapp.so`.[[2]](#references)[[3]](#references) ### Target: `ssl_crypto_x509_session_verify_cert_chain()` * Located in **`ssl_x509.cc`** inside BoringSSL. @@ -38,7 +38,7 @@ Find [get_snapshot_hash.py here](https://github.com/Impact-I/reFlutter/blob/main * In `ssl_x509.cc`, force `return 1;` * (Optional) In `socket_android.cc`, hard-code a proxy (`"10.0.2.2:8080"`). 3. **Re-compile** libflutter.so, drop it back into the APK/IPA, sign, install. -4. **Pre-patched builds** for common versions are shipped in the reFlutter GitHub releases to save hours of build time. +4. **Pre-patched builds** for common versions are shipped in the reFlutter GitHub releases to save hours of build time.[[3]](#references) ### Option B – Live hooking with **Frida** (the “hard-core” path) Because the symbol is stripped, you pattern-scan the loaded module for its first bytes, then change the return value on the fly. @@ -123,7 +123,7 @@ When pattern-based scripts fail across architectures (e.g., x86_64 vs ARM), dire - Extract the right-ABI library from the APK: `unzip -j app.apk "lib/*/libflutter.so" -d libs/` and pick the one matching the device. - Resolve the exact BoringSSL revision from the matching Flutter `DEPS`, fetch `ssl/ssl_x509.cc`, and identify `ssl_crypto_x509_session_verify_cert_chain`. - Use the line number of the `OPENSSL_PUT_ERROR(...)` inside that exact source revision as a **scalar search anchor** in Ghidra. The line number is compiled into the error path, so searching for that constant (for example `239`) is often faster than guessing patterns in a stripped binary. -- If the scalar search is noisy, fall back to **Search → For Strings → `ssl_client` → XREFs** and keep only candidates that decompile into a 3-argument function matching `SSL_SESSION *`, `SSL_HANDSHAKE *`, `uint8_t *` semantics.[[4]](#references) +- If the scalar search is noisy, fall back to **Search → For Strings → `ssl_client` → XREFs** and keep only candidates that decompile into a 3-argument function matching `SSL_SESSION *`, `SSL_HANDSHAKE *`, `uint8_t *` semantics.[[4]](#references)[[5]](#references)[[6]](#references) - Compute the runtime offset: `function_address - image_base`. Example: `0x00840950 - 0x00100000 = 0x00740950`. - Hook at runtime by base + offset and force success: diff --git a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md index b239d6fdbd1..4edd73cb7fd 100644 --- a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md +++ b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md @@ -12,7 +12,7 @@ pip install frida-tools pip install frida ``` -**Download and install** in the android the **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).\ +**Download and install** in the android the **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).[[3]](#references)\ One-liner to restart adb in root mode, connect to it, upload frida-server, give exec permissions and run it in backgroud: ```bash @@ -56,7 +56,7 @@ Two common ways to instrument Android apps with Frida:[[1]](#references)[[3]](#references) ```bash # Download the matching frida-server binary for your device's arch @@ -111,7 +111,7 @@ Notes If the APK is debuggable (android:debuggable="true"), you can attach over JDWP and inject a native library at a Java breakpoint. No root and no APK repackaging.[[6]](#references)[[7]](#references)[[8]](#references)[[9]](#references) -- Repo: https://github.com/frankheat/frida-jdwp-loader +- Repo: https://github.com/frankheat/frida-jdwp-loader[[6]](#references) - Requirements: ADB, Python 3, USB/Wireless debugging. App must be debuggable (emulator with `ro.debuggable=1`, rooted device with `resetprop`, or rebuild manifest). Quick start: diff --git a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-1.md b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-1.md index 080f3ad0873..56fb5f5f443 100644 --- a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-1.md +++ b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-1.md @@ -3,7 +3,7 @@ {{#include ../../../banners/hacktricks-training.md}} -**This is a summary of the post**: [https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1)\ +**This is a summary of the post**: [https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1)[[3]](#references)\ **APK**: [https://github.com/t0thkr1s/frida-demo/releases](https://github.com/t0thkr1s/frida-demo/releases)\ **Source Code**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo) @@ -170,12 +170,10 @@ In this tutorial you have hooked methods using the name of the method and _.impl You can see that in [the next tutorial](frida-tutorial-2.md). - - - ## References - [1] [Frida News (Android 14–16 fixes & Frida 17.x releases)](https://frida.re/news/) - [2] [zygisk-gadget – Zygisk module that loads frida-gadget](https://github.com/hackcatml/zygisk-gadget) +- [3] [medium.com - Introduction To Frida](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-2.md b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-2.md index 3b42fb54264..a7621fd56fc 100644 --- a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-2.md +++ b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/frida-tutorial-2.md @@ -2,7 +2,8 @@ {{#include ../../../banners/hacktricks-training.md}} -**This is a summary of the post**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Parts 2, 3 and 4)\ + +**This is a summary of the post**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Parts 2, 3 and 4)[[3]](#references)\ **APKs and Source code**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples) This part focuses on **overloaded methods**, **calling app code from your Frida script**, **keeping references to live Java objects**, and **using Python as a controller** for interactive instrumentation. @@ -302,5 +303,6 @@ There is a part 5 that is not explained here because it doesn't add anything sub - [1] [Frida JavaScript API](https://frida.re/docs/javascript-api/) - [2] [Frida 17.0.0 Released](https://frida.re/news/2025/05/17/frida-17-0-0-released/) +- [3] [11x256.github.io - Frida Hooking Android Part 2](https://11x256.github.io/Frida-hooking-android-part-2) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial.md b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial.md index 64068a34eb8..b95551a35c8 100644 --- a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial.md +++ b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/objection-tutorial.md @@ -22,7 +22,7 @@ For this tutorial I am going to use the APK that you can download here: app-release.zip {{#endfile}} -Or from its [original repository ](https://github.com/asvid/FridaApp)(download app-release.apk) +Or from its [original repository](https://github.com/asvid/FridaApp) (download app-release.apk) ### Installation diff --git a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/owaspuncrackable-1.md b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/owaspuncrackable-1.md index 9ad82c51bba..6d3656b2d95 100644 --- a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/owaspuncrackable-1.md +++ b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/owaspuncrackable-1.md @@ -5,12 +5,12 @@ --- -**This is a summary of the post**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)[[3]](#references)\ +**This is a summary of the post**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)[[1]](#references)\ **APK**: [https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk](https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk) ## Solution 1 -Based in [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)[[3]](#references) +Based in [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)[[1]](#references) **Hook the _exit()**_ function and **decrypt function** so it print the flag in frida console when you press verify: @@ -55,7 +55,7 @@ Java.perform(function () { ## Solution 2 -Based in [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)[[3]](#references) +Based in [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)[[1]](#references) **Hook rootchecks** and decrypt function so it print the flag in frida console when you press verify: @@ -168,8 +168,6 @@ objection -g owasp.mstg.uncrackable1 explore \ ## References -- [1] Frida release announcement – "Frida 16.0 (2023-04-02): Android 12/13 reliability fixes & spawn API overhaul" -- [2] Objection 1.12 – "Spawn-only mode for Android 14" (BlackHat USA 2024 talk slides) -- [3] [Android Hacking with FRIDA](https://joshspicer.com/android-frida-1) +- [1] [Android Hacking with FRIDA](https://joshspicer.com/android-frida-1) -{{#include ../../../banners/hacktricks-training.md}} \ No newline at end of file +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/google-ctf-2018-shall-we-play-a-game.md b/src/mobile-pentesting/android-app-pentesting/google-ctf-2018-shall-we-play-a-game.md index bb97457e201..681e8a11cb4 100644 --- a/src/mobile-pentesting/android-app-pentesting/google-ctf-2018-shall-we-play-a-game.md +++ b/src/mobile-pentesting/android-app-pentesting/google-ctf-2018-shall-we-play-a-game.md @@ -67,5 +67,3 @@ Make the application run the loop 100000 times when you win the first time. To d You need to do this inside a physical device as (I don't know why) this doesn't work in an emulated device. {{#include ../../banners/hacktricks-training.md}} - - diff --git a/src/mobile-pentesting/android-app-pentesting/in-memory-jni-shellcode-execution.md b/src/mobile-pentesting/android-app-pentesting/in-memory-jni-shellcode-execution.md index bd70f2e0d3b..0a46a1f21cf 100644 --- a/src/mobile-pentesting/android-app-pentesting/in-memory-jni-shellcode-execution.md +++ b/src/mobile-pentesting/android-app-pentesting/in-memory-jni-shellcode-execution.md @@ -106,7 +106,7 @@ Delivery - The backdoored/test app downloads sc and invokes the JNI bridge shown above - Listen on your operator box for any reverse connection the kernel/user-mode payload establishes[[5]](#references) -Validation workflow for kernel payloads +Validation workflow for kernel payloads[[4]](#references) - Use a symbolized vmlinux for fast reversing/offset recovery - Prototype primitives on a convenient debug image if available, but always re‑validate on the actual Android target (kallsyms, KASLR slide, page-table layout, and mitigations differ) diff --git a/src/mobile-pentesting/android-app-pentesting/inputmethodservice-ime-abuse.md b/src/mobile-pentesting/android-app-pentesting/inputmethodservice-ime-abuse.md index 8251e907770..37aa7ab24c0 100644 --- a/src/mobile-pentesting/android-app-pentesting/inputmethodservice-ime-abuse.md +++ b/src/mobile-pentesting/android-app-pentesting/inputmethodservice-ime-abuse.md @@ -81,4 +81,5 @@ adb shell ime help - **User/MDM**: allowlist trusted keyboards; block unknown IMEs in managed profiles/devices. - **App-side (high risk apps)**: prefer phishing-resistant auth (passkeys/biometrics) and avoid relying on “secret text entry” as a security boundary (a malicious IME sits below the app UI). + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/insecure-in-app-update-rce.md b/src/mobile-pentesting/android-app-pentesting/insecure-in-app-update-rce.md index f7493580438..6b676cc51a6 100644 --- a/src/mobile-pentesting/android-app-pentesting/insecure-in-app-update-rce.md +++ b/src/mobile-pentesting/android-app-pentesting/insecure-in-app-update-rce.md @@ -251,8 +251,8 @@ Also consider stubbing vendor methods such as `PluginVerifier.verifySignature()` ### 5.1 Platform changes that change exploitation -- Apps targeting Android 14 (API 34+) must mark dynamically loaded DEX/JAR/APK files read-only as soon as they are opened and before content is written; otherwise the system throws an exception when the app later tries to load them. -- Apps targeting Android 17 (API 37+) extend the same Safer Dynamic Code Loading rule to native libraries loaded with `System.load()`; writable copied `.so` files now fail with `UnsatisfiedLinkError`. +- Apps targeting Android 14 (API 34+) must mark dynamically loaded DEX/JAR/APK files read-only as soon as they are opened and before content is written; otherwise the system throws an exception when the app later tries to load them.[[2]](#references) +- Apps targeting Android 17 (API 37+) extend the same Safer Dynamic Code Loading rule to native libraries loaded with `System.load()`; writable copied `.so` files now fail with `UnsatisfiedLinkError`.[[2]](#references) - Offensive takeaway: crashes around writable dynamic code are still useful findings. They tell you the app is shipping a custom updater/plugin architecture; move earlier in the chain and tamper with metadata, temp files, unzip destinations, or the decrypted in-memory buffer before the app flips permissions or verifies integrity. --- diff --git a/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md b/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md index b36e843b026..3ce8ef728e7 100644 --- a/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md +++ b/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md @@ -2,10 +2,9 @@ {{#include ../../banners/hacktricks-training.md}} - ## System-wide proxy via ADB -Configure a global HTTP proxy so all apps route traffic through your interceptor (Burp/mitmproxy): +Configure a global HTTP proxy so all apps route traffic through your interceptor (Burp/mitmproxy):[[6]](#references) ```bash # Set proxy (device/emulator must reach your host IP) @@ -71,7 +70,7 @@ Explained in [**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) you n If you need to intercept traffic from **Google Play** emulator images, remember that these AVDs are **production builds**: `adb root` normally fails, but you can still root them with **rootAVD + Magisk** and then inject the proxy CA at runtime. This is useful when the app trusts the Android system store but ignores **user** CAs.[[1]](#references) -1. Root the matching Play Store image (`google_apis_playstore`) with **rootAVD**, cold boot it, finish the **Magisk** setup, and verify root from ADB: +1. Root the matching Play Store image (`google_apis_playstore`) with **rootAVD**, cold boot it, finish the **Magisk** setup, and verify root from ADB:[[2]](#references) ```bash adb shell @@ -102,7 +101,7 @@ This bypasses trust decisions that rely only on the Android system CA store, but ### Alternative: AlwaysTrustUserCerts (Android 7-16 Beta) -If you're on Android 14+ (or on older devices that received Conscrypt Mainline updates and now use `/apex/com.android.conscrypt/cacerts`), the Magisk module **AlwaysTrustUserCerts** automates the bind-mounting required for system trust. It mirrors user CAs into system trust and injects mounts into Zygote/app namespaces so apps see the certs without manual `nsenter` work.[[4]](#references) +If you're on Android 14+ (or on older devices that received Conscrypt Mainline updates and now use `/apex/com.android.conscrypt/cacerts`), the Magisk module **AlwaysTrustUserCerts** automates the bind-mounting required for system trust. It mirrors user CAs into system trust and injects mounts into Zygote/app namespaces so apps see the certs without manual `nsenter` work.[[4]](#references)[[5]](#references) 1. Install the Burp CA as a **user** cert first. 2. Install the module and reboot. diff --git a/src/mobile-pentesting/android-app-pentesting/react-native-application.md b/src/mobile-pentesting/android-app-pentesting/react-native-application.md index 60045f134cb..b22fe0c48b2 100644 --- a/src/mobile-pentesting/android-app-pentesting/react-native-application.md +++ b/src/mobile-pentesting/android-app-pentesting/react-native-application.md @@ -30,7 +30,7 @@ ls ReactNative/assets/ If checking the contents of the `index.android.bundle` you find the JavaScript code of the application (even if minified), you can **analyze it to find sensitive information and vulnerabilities**. -As the bundle contains actually all the JS code of the application it's possible to **divide it in different files** (potentially making easier its reverse engineering) using the **tool [react-native-decompiler](https://github.com/numandev1/react-native-decompiler)**. +As the bundle contains actually all the JS code of the application it's possible to **divide it in different files** (potentially making easier its reverse engineering) using the **tool [react-native-decompiler](https://github.com/numandev1/react-native-decompiler)**.[[3]](#references) ### Webpack @@ -99,7 +99,7 @@ file index.android.bundle index.android.bundle: Hermes JavaScript bytecode, version 96 ``` -However, you can use the tools **[hbctool](https://github.com/bongtrop/hbctool)**, updated forks of hbctool that support newer bytecode versions, **[hasmer](https://github.com/lucasbaizer2/hasmer)**, **[hermes_rs](https://github.com/Pilfer/hermes_rs)** (Rust library/APIs), or **[hermes-dec](https://github.com/P1sec/hermes-dec)** to **disassemble the bytecode** and also to **decompile it to some pseudo JS code**. For example: +However, you can use the tools **[hbctool](https://github.com/bongtrop/hbctool)**, updated forks of hbctool that support newer bytecode versions, **[hasmer](https://github.com/lucasbaizer2/hasmer)**, **[hermes_rs](https://github.com/Pilfer/hermes_rs)** (Rust library/APIs), or **[hermes-dec](https://github.com/P1sec/hermes-dec)** to **disassemble the bytecode** and also to **decompile it to some pseudo JS code**. For example:[[5]](#references) ```bash # Disassemble and re-assemble with hbctool (works only for supported HBC versions) @@ -121,7 +121,7 @@ Tip: The open-source Hermes project also ships developer tools such as `hbcdump` Ideally you should be able to modify the disassembled code (changing a comparison, or a value or whatever you need to modify) and then **rebuild the bytecode** and rebuild the app. -- The original **[hbctool](https://github.com/bongtrop/hbctool)** supports disassembling the bundle and building it back after changes, but historically supported only older bytecode versions. Community-maintained forks extend support to newer Hermes versions (including mid-80s–96) and are often the most practical option to patch modern RN apps. +- The original **[hbctool](https://github.com/bongtrop/hbctool)** supports disassembling the bundle and building it back after changes, but historically supported only older bytecode versions. Community-maintained forks extend support to newer Hermes versions (including mid-80s–96) and are often the most practical option to patch modern RN apps.[[5]](#references) - The tool **[hermes-dec](https://github.com/P1sec/hermes-dec)** does not support rebuilding the bytecode (decompiler/disassembler only), but it’s very helpful to navigate logic and dump strings. - The tool **[hasmer](https://github.com/lucasbaizer2/hasmer)** aims to support both disassembly and assembly for multiple Hermes versions; assembling is still maturing but worth trying on recent bytecode. diff --git a/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md b/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md index 276a74e27ed..f570466893c 100644 --- a/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md +++ b/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md @@ -3,9 +3,9 @@ {{#include ../../banners/hacktricks-training.md}} -**For further information check:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html) +**For further information check:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html)[[17]](#references) -Android apps can use native libraries, typically written in C or C++, for performance-critical tasks. Malware creators also abuse these libraries because ELF shared objects are still harder to decompile than DEX/OAT byte-code. +Android apps can use native libraries, typically written in C or C++, for performance-critical tasks. Malware creators also abuse these libraries because ELF shared objects are still harder to decompile than DEX/OAT byte-code.[[15]](#references) This page focuses on *practical* workflows and *recent* tooling improvements (2023-2025) that make reversing Android `.so` files easier. --- @@ -32,13 +32,13 @@ This page focuses on *practical* workflows and *recent* tooling improvements (20 ``` 4. **Load in a decompiler** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin) and run auto-analysis. Newer Ghidra versions introduced an AArch64 decompiler that recognises PAC/BTI stubs and MTE tags, greatly improving analysis of libraries built with the Android 14 NDK. -5. **Decide on static vs dynamic reversing:** stripped, obfuscated code often needs *instrumentation* (Frida, ptrace/gdbserver, LLDB). +5. **Decide on static vs dynamic reversing:** stripped, obfuscated code often needs *instrumentation* (Frida, ptrace/gdbserver, LLDB).[[16]](#references) --- ### Dynamic Instrumentation (Frida ≥ 16) -Frida’s 16-series brought several Android-specific improvements that help when the target uses modern Clang/LLD optimisations:[[6]](#references) +Frida’s 16-series brought several Android-specific improvements that help when the target uses modern Clang/LLD optimisations:[[1]](#references) * `thumb-relocator` can now *hook tiny ARM/Thumb functions* generated by LLD’s aggressive alignment (`--icf=all`). * Enumerating and rebinding *ELF import slots* works on Android, enabling per-module `dlopen()`/`dlsym()` patching when inline hooks are rejected. @@ -65,7 +65,7 @@ Frida will work out of the box on PAC/BTI-enabled devices (Pixel 8/Android 14+) ### Dumping runtime-decrypted native libraries from memory (Frida soSaver) -When a protected APK keeps native code encrypted or only maps it at runtime (packers, downloaded payloads, generated libs), attach Frida and dump the mapped ELF directly from process memory.[[15]](#references)[[16]](#references) +When a protected APK keeps native code encrypted or only maps it at runtime (packers, downloaded payloads, generated libs), attach Frida and dump the mapped ELF directly from process memory.[[10]](#references)[[11]](#references) **soSaver workflow (Python host + TS/JS Frida agent):** - Hooks `dlopen` and `android_dlopen_ext` to detect load-time library mapping and performs an initial sweep of already loaded modules. @@ -88,7 +88,7 @@ This approach bypasses “only decrypted in RAM” protections by recovering the ### Process-local JNI telemetry via preloaded .so (SoTap) -When full-featured instrumentation is overkill or blocked, you can still gain native-level visibility by preloading a small logger inside the target process. SoTap is a lightweight Android native (.so) library that logs the runtime behavior of other JNI (.so) libraries within the same app process (no root required).[[8]](#references)[[9]](#references)[[10]](#references) +When full-featured instrumentation is overkill or blocked, you can still gain native-level visibility by preloading a small logger inside the target process. SoTap is a lightweight Android native (.so) library that logs the runtime behavior of other JNI (.so) libraries within the same app process (no root required).[[3]](#references)[[4]](#references)[[5]](#references) Key properties: - Initializes early and observes JNI/native interactions inside the process that loads it. @@ -126,7 +126,7 @@ This approach is useful for malware triage and JNI debugging where observing nat ### See also: in‑memory native code execution via JNI -A common attack pattern is to download a raw shellcode blob at runtime and execute it directly from memory through a JNI bridge (no on‑disk ELF). Details and ready‑to‑use JNI snippet here: +A common attack pattern is to download a raw shellcode blob at runtime and execute it directly from memory through a JNI bridge (no on‑disk ELF).[[6]](#references) Details and ready‑to‑use JNI snippet here: {{#ref}} in-memory-jni-shellcode-execution.md @@ -138,7 +138,7 @@ in-memory-jni-shellcode-execution.md | Year | CVE | Affected library | Notes | |------|-----|------------------|-------| -|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Heap buffer overflow reachable from native code that decodes WebP images. Several Android apps bundle vulnerable versions. When you see a `libwebp.so` inside an APK, check its version and attempt exploitation or patching.| | +|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Heap buffer overflow reachable from native code that decodes WebP images. Several Android apps bundle vulnerable versions. When you see a `libwebp.so` inside an APK, check its version and attempt exploitation or patching.|[[2]](#references)| |2024|Multiple|OpenSSL 3.x series|Several memory-safety and padding-oracle issues. Many Flutter & ReactNative bundles ship their own `libcrypto.so`.| When you spot *third-party* `.so` files inside an APK, always cross-check their hash against upstream advisories. SCA (Software Composition Analysis) is uncommon on mobile, so outdated vulnerable builds are rampant. @@ -155,7 +155,7 @@ When you spot *third-party* `.so` files inside an APK, always cross-check their ### Neutralizing early native initializers (.init_array) and JNI_OnLoad for early instrumentation (ARM64 ELF) -Highly protected apps often place root/emulator/debug checks in native constructors that run extremely early via `.init_array`, before `JNI_OnLoad` and long before any Java code executes. You can make those implicit initializers explicit and regain control by:[[12]](#references)[[13]](#references)[[14]](#references) +Highly protected apps often place root/emulator/debug checks in native constructors that run extremely early via `.init_array`, before `JNI_OnLoad` and long before any Java code executes. You can make those implicit initializers explicit and regain control by:[[7]](#references)[[8]](#references)[[9]](#references) - Removing `INIT_ARRAY`/`INIT_ARRAYSZ` from the DYNAMIC table so the loader does not auto-execute `.init_array` entries. - Resolving the constructor address from RELATIVE relocations and exporting it as a regular function symbol (e.g., `INIT0`). - Renaming `JNI_OnLoad` to `JNI_OnLoad0` to prevent ART from calling it implicitly. @@ -308,21 +308,22 @@ make ## References -- [1] [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/) -- [2] [Oracle JNI Spec](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) -- [3] [Android JNI Tips](https://developer.android.com/training/articles/perf-jni) -- [4] [NDK Guides](https://developer.android.com/ndk/guides/) -- [5] [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3) -- [6] [Frida 16.x changelog (Android hooking, tiny-function relocation)](https://frida.re/news/) -- [7] [NVD - CVE-2023-4863 detail (libwebp heap buffer overflow)](https://nvd.nist.gov/vuln/detail/CVE-2023-4863) -- [8] [SoTap: Lightweight in-app JNI (.so) behavior logger](https://github.com/RezaArbabBot/SoTap) -- [9] [SoTap Releases](https://github.com/RezaArbabBot/SoTap/releases) -- [10] [How to work with SoTap?](https://t.me/ForYouTillEnd/13) -- [11] [CoRPhone — JNI memory-only execution pattern and packaging](https://github.com/0xdevil/corphone) -- [12] [Patching Android ARM64 library initializers for easy Frida instrumentation and debugging](https://blog.nviso.eu/2025/10/14/patching-android-arm64-library-initializers-for-easy-frida-instrumentation-and-debugging/) -- [13] [LIEF Project](https://github.com/lief-project/LIEF) -- [14] [JNIInvocation](https://github.com/Ch0pin/JNIInvocation) -- [15] [soSaver — Frida-based live memory dumper for Android `.so` libraries](https://github.com/TheQmaks/sosaver) -- [16] [soSaver Frida agent (TypeScript/JS)](https://github.com/TheQmaks/soSaver-frida) +- [1] [Frida 16.x changelog (Android hooking, tiny-function relocation)](https://frida.re/news/) +- [2] [NVD - CVE-2023-4863 detail (libwebp heap buffer overflow)](https://nvd.nist.gov/vuln/detail/CVE-2023-4863) +- [3] [SoTap: Lightweight in-app JNI (.so) behavior logger](https://github.com/RezaArbabBot/SoTap) +- [4] [SoTap Releases](https://github.com/RezaArbabBot/SoTap/releases) +- [5] [How to work with SoTap?](https://t.me/ForYouTillEnd/13) +- [6] [CoRPhone — JNI memory-only execution pattern and packaging](https://github.com/0xdevil/corphone) +- [7] [Patching Android ARM64 library initializers for easy Frida instrumentation and debugging](https://blog.nviso.eu/2025/10/14/patching-android-arm64-library-initializers-for-easy-frida-instrumentation-and-debugging/) +- [8] [LIEF Project](https://github.com/lief-project/LIEF) +- [9] [JNIInvocation](https://github.com/Ch0pin/JNIInvocation) +- [10] [soSaver — Frida-based live memory dumper for Android `.so` libraries](https://github.com/TheQmaks/sosaver) +- [11] [soSaver Frida agent (TypeScript/JS)](https://github.com/TheQmaks/soSaver-frida) +- [12] [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/) +- [13] [Oracle JNI Spec](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) +- [14] [Android JNI Tips](https://developer.android.com/training/articles/perf-jni) +- [15] [NDK Guides](https://developer.android.com/ndk/guides/) +- [16] [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3) +- [17] [maddiestone.github.io - Reversing Native Libs](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md b/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md index 881da88bbe7..ebdb72ed632 100644 --- a/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md +++ b/src/mobile-pentesting/android-app-pentesting/shizuku-privileged-api.md @@ -209,7 +209,6 @@ This matters during assessments because a previously one-time Wireless Debugging Observed keep-alive enhancements around this pattern include **1x1 foreground activities**, silent `MediaSession` playback, `WakeLock`s, two services in different processes that rebind each other with `BIND_AUTO_CREATE` / `onServiceDisconnected()`, periodic restart alarms, writes to `/proc//oom_score_adj`, and `mlock()` to pin hot pages in RAM. - #### Build-specific kernel exploit staging and KernelSU late-load handoff Another practical pattern is to use **shell-backed Shizuku only as the staging bridge** for a **build-specific local kernel exploit**, then hand the post-root workflow to **KernelSU/ReSukiSU**.[[5]](#references) diff --git a/src/mobile-pentesting/android-app-pentesting/smali-changes.md b/src/mobile-pentesting/android-app-pentesting/smali-changes.md index 812981cc91f..4c480261fb6 100644 --- a/src/mobile-pentesting/android-app-pentesting/smali-changes.md +++ b/src/mobile-pentesting/android-app-pentesting/smali-changes.md @@ -2,7 +2,6 @@ {{#include ../../banners/hacktricks-training.md}} - Sometimes it is interesting to modify the application code to access hidden information for you (maybe well obfuscated passwords or flags). Then, it could be interesting to decompile the apk, modify the code and recompile it. **Opcodes reference:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html) @@ -11,7 +10,7 @@ Sometimes it is interesting to modify the application code to access hidden info Using **Visual Studio Code** and the [APKLab](https://github.com/APKLab/APKLab) extension, you can **automatically decompile**, modify, **recompile**, sign & install the application without executing any command. -Another **script** that facilitates this task a lot is [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh) +Another **script** that facilitates this task a lot is [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh)[[6]](#references) ### Split APKs / App Bundles @@ -87,7 +86,7 @@ jarsigner -keystore key.jks path/to/dist/* ### Optimize new application -**zipalign** is an archive alignment tool that provides important optimisation to Android application (APK) files. [More information here](https://developer.android.com/studio/command-line/zipalign). +**zipalign** is an archive alignment tool that provides important optimisation to Android application (APK) files. [More information here](https://developer.android.com/studio/command-line/zipalign).[[7]](#references) ```bash zipalign [-f] [-v] infile.apk outfile.apk @@ -340,5 +339,6 @@ Rule-driven scanners like PulseAPK Core implement this model to quickly surface - [4] [Android Developers: apksigner](https://developer.android.com/tools/apksigner) - [5] [Android Developers: zipalign](https://developer.android.com/tools/zipalign) - [6] [apk.sh](https://github.com/ax/apk.sh) +- [7] [developer.android.com - Command Line - Zipalign](https://developer.android.com/studio/command-line/zipalign) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/spoofing-your-location-in-play-store.md b/src/mobile-pentesting/android-app-pentesting/spoofing-your-location-in-play-store.md index cb7216ac4bd..34bc8a11e01 100644 --- a/src/mobile-pentesting/android-app-pentesting/spoofing-your-location-in-play-store.md +++ b/src/mobile-pentesting/android-app-pentesting/spoofing-your-location-in-play-store.md @@ -32,8 +32,8 @@ adb shell pm clear com.android.providers.downloads ``` 4. Re-open **Play Store** and inspect **Settings --> General --> Account and device preferences --> Country and profiles**.[[1]](#references) -5. If the target country/profile appears, switch to it and retry the install. Google Play profile changes can take **up to 48 hours** to fully update.[[1]](#references) -6. If the country/profile does not appear, remember that Google expects you to be **in the target country** and to have a **payment method from that country** when creating a new Play country/profile.[[1]](#references) +5. If the target country/profile appears, switch to it and retry the install. Google Play profile changes can take **up to 48 hours** to fully update. +6. If the country/profile does not appear, remember that Google expects you to be **in the target country** and to have a **payment method from that country** when creating a new Play country/profile. ## Rooted / Emulator Workflow diff --git a/src/mobile-pentesting/android-app-pentesting/tapjacking.md b/src/mobile-pentesting/android-app-pentesting/tapjacking.md index 4978fb87dfe..a9b7424642f 100644 --- a/src/mobile-pentesting/android-app-pentesting/tapjacking.md +++ b/src/mobile-pentesting/android-app-pentesting/tapjacking.md @@ -100,7 +100,7 @@ Practical takeaway for red teams: mix an `alpha < 0.8` overlay to bypass Android ## Accessibility Overlay Phishing (Banking-Trojan Variant) -Besides classic Tapjacking, modern Android banking malware families (e.g. **ToxicPanda**, BrasDex, Sova, etc.) abuse the **Accessibility Service** to place a full-screen WebView **overlay** above the legitimate application while still being able to **forward the user input** to the view underneath. This dramatically increases believability and allows attackers to steal credentials, OTPs or even automate fraudulent transactions. +Besides classic Tapjacking, modern Android banking malware families (e.g. **ToxicPanda**, BrasDex, Sova, etc.) abuse the **Accessibility Service** to place a full-screen WebView **overlay** above the legitimate application while still being able to **forward the user input** to the view underneath. This dramatically increases believability and allows attackers to steal credentials, OTPs or even automate fraudulent transactions.[[3]](#references) ### How it works 1. The malicious APK requests the highly-sensitive `BIND_ACCESSIBILITY_SERVICE` permission, usually hiding the request behind a fake Google/Chrome/PDF-viewer dialog. @@ -145,5 +145,6 @@ accessibility-services-abuse.md ## References - [1] [Android Developers – Tapjacking risk & mitigations (updated 2024)](https://developer.android.com/privacy-and-security/risks/tapjacking) - [2] [Zimperium – HOOK v3 overlay expansion (Aug 2025)](https://thehackernews.com/2025/08/hook-android-trojan-adds-ransomware.html) +- [3] [Bitsight – ToxicPanda: The Android Banking Trojan Targeting Europe](https://www.bitsight.com/blog/toxicpanda-android-banking-malware-2025-study) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/ios-pentesting/ios-basics.md b/src/mobile-pentesting/ios-pentesting/ios-basics.md index b1a98f365d3..305cd0b6ffd 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-basics.md +++ b/src/mobile-pentesting/ios-pentesting/ios-basics.md @@ -16,7 +16,7 @@ - `/dev`: Contains device files. - `/Core`: Contains OS core dumps. - `/private/var/mobile/Library/Logs/CrashReporter/*`: Contains crash logs for the specified application. -- `/var/jb`: On modern **rootless jailbreaks**, this usually points to the writable jailbreak bootstrap under `/private/preboot//...`; many modern tweaks, binaries, and jailbreak indicators live here instead of directly under `/`.[[6]](#references) +- `/var/jb`: On modern **rootless jailbreaks**, this usually points to the writable jailbreak bootstrap under `/private/preboot//...`; many modern tweaks, binaries, and jailbreak indicators live here instead of directly under `/`.[[5]](#references) - Many other common Unix folders... ### SQLite DBs @@ -34,7 +34,7 @@ When extracting data, copy the **three files together**. Recent rows often live In iOS, a distinction in privilege exists between the user-accessible applications and the system's core processes. Applications run under the **`mobile`** user identity, while the crucial system processes operate as **`root`**. This separation is enhanced by a sandbox mechanism, which imposes strict limitations on what actions applications can undertake. For instance, even if applications share the same user identity, they are prohibited from accessing or modifying each other's data. -Applications are installed in a specific directory (`private/var/mobile/Applications/{random ID}`) and have restricted read access to certain system areas and functionalities, such as SMS and phone calls. Access to protected areas triggers a pop-up request for user permission. +Applications are installed in a specific directory (`private/var/mobile/Applications/{random ID}`) and have restricted read access to certain system areas and functionalities, such as SMS and phone calls. Access to protected areas triggers a pop-up request for user permission.[[3]](#references)[[6]](#references) From a pentester's perspective, **extensions and widgets are separate sandboxes** with their own `Info.plist`, entitlements, and storage. The main app normally exchanges state with them through **App Groups** and **Keychain access groups**, so inspect the shared containers and every `.appex` inside `PlugIns/` instead of assuming all sensitive state lives only in the main app sandbox. For extension-specific attack surface, check [iOS App Extensions](ios-app-extensions.md). @@ -94,7 +94,7 @@ Brute-forcing the Keychain password involves either attacking the encrypted key #### **Configuring Keychain Item Data Protection** -Data protection levels for Keychain items are set using the `kSecAttrAccessible` attribute during item creation or update. These levels, [as specified by Apple](https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_and_values#1679100), determine when and how Keychain items are accessible:[[1]](#references)[[5]](#references) +Data protection levels for Keychain items are set using the `kSecAttrAccessible` attribute during item creation or update. These levels, [as specified by Apple](https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_and_values#1679100), determine when and how Keychain items are accessible:[[1]](#references)[[4]](#references) - **`kSecAttrAccessibleAlways`**: Accessible anytime, regardless of device lock status. - **`kSecAttrAccessibleAlwaysThisDeviceOnly`**: Always accessible, but not included in backups. @@ -105,7 +105,7 @@ Data protection levels for Keychain items are set using the `kSecAttrAccessible` - **`kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly`**: Requires device passcode, not included in backups. - **`kSecAttrSynchronizable`**: Optional flag that syncs an item through **iCloud Keychain** to the user's other devices. Great for usability, but usually a bad place for device-bound secrets, jailbreak indicators, or local database keys. -**`AccessControlFlags`** further refine access methods, allowing for biometric authentication or passcode use.[[1]](#references)[[5]](#references) During a review, pay special attention to the difference between **`userPresence`** (biometric _or_ passcode) and **`biometryCurrentSet`** (bound to the currently enrolled biometrics and invalidated when the biometric set changes). For high-value local secrets, `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` plus a restrictive access-control flag is the high-water mark; weaker combinations like `AfterFirstUnlock` deserve extra scrutiny. +**`AccessControlFlags`** further refine access methods, allowing for biometric authentication or passcode use.[[1]](#references)[[4]](#references) During a review, pay special attention to the difference between **`userPresence`** (biometric _or_ passcode) and **`biometryCurrentSet`** (bound to the currently enrolled biometrics and invalidated when the biometric set changes). For high-value local secrets, `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` plus a restrictive access-control flag is the high-water mark; weaker combinations like `AfterFirstUnlock` deserve extra scrutiny. #### **Jailbroken Devices Warning** @@ -130,9 +130,9 @@ if userDefaults.bool(forKey: "hasRunBefore") == false { ## **App Capabilities** -In the realm of app development, **sandboxing** plays a crucial role in enhancing security. This process ensures that each app operates within its own unique home directory, thus preventing it from accessing system files or data belonging to other apps. The enforcement of these restrictions is carried out through sandbox policies, which are a part of the **Trusted BSD (MAC) Mandatory Access Control Framework**. +In the realm of app development, **sandboxing** plays a crucial role in enhancing security. This process ensures that each app operates within its own unique home directory, thus preventing it from accessing system files or data belonging to other apps. The enforcement of these restrictions is carried out through sandbox policies, which are a part of the **Trusted BSD (MAC) Mandatory Access Control Framework**.[[3]](#references) -Developers have the ability to configure certain **capabilities or permissions** for their apps, such as **Data Protection** or **Keychain Sharing**. These permissions are applied immediately after the app is installed. Nonetheless, for accessing certain protected resources, the app must obtain explicit consent from the user at the time of the first attempt. This is achieved through the use of _purpose strings_ or _usage description strings_, which are presented to users in a permission request alert.[[3]](#references) +Developers have the ability to configure certain **capabilities or permissions** for their apps, such as **Data Protection** or **Keychain Sharing**. These permissions are applied immediately after the app is installed. Nonetheless, for accessing certain protected resources, the app must obtain explicit consent from the user at the time of the first attempt. This is achieved through the use of _purpose strings_ or _usage description strings_, which are presented to users in a permission request alert.[[2]](#references) For those with access to the source code, verification of permissions included in the `Info.plist` file can be done by: @@ -192,7 +192,7 @@ This example indicates that the app is compatible with the armv7 instruction set ### Entitlements -**Entitlements** are another critical aspect of iOS app development, serving as key-value pairs that grant apps permission to perform certain operations beyond runtime checks. For example, enabling **Data Protection** in an app involves adding a specific entitlement in the Xcode project, which is then reflected in the app's entitlements file or the embedded mobile provision file for IPAs.[[3]](#references) +**Entitlements** are another critical aspect of iOS app development, serving as key-value pairs that grant apps permission to perform certain operations beyond runtime checks. For example, enabling **Data Protection** in an app involves adding a specific entitlement in the Xcode project, which is then reflected in the app's entitlements file or the embedded mobile provision file for IPAs.[[2]](#references) For quick triage, the most interesting entitlement checks are usually: @@ -209,10 +209,10 @@ If the entitlements file isn't directly present in the package, extract it from ## References - [1] [iOS Data Storage - OWASP MASTG](https://mas.owasp.org/MASTG/iOS/0x06d-Testing-Data-Storage) -- [2] [iOS Platform APIs - OWASP owasp-mastg (0x06h-Testing-Platform-Interaction.md)](https://github.com/OWASP/owasp-mastg/blob/master/Document/0x06h-Testing-Platform-Interaction.md) -- [3] [MASTG-TEST-0069: Testing App Permissions - OWASP MASTG](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0069/) -- [4] [iOS Platform APIs - OWASP MASTG](https://mas.owasp.org/MASTG/iOS/0x06h-Testing-Platform-Interaction/) -- [5] [Keychain data protection - Apple Support](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web) -- [6] [Rootless ( -l ) - palera1n docs](https://docs.palera.in/docs/reference/environment-types/) +- [2] [MASTG-TEST-0069: Testing App Permissions - OWASP MASTG](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0069/) +- [3] [iOS Platform APIs - OWASP MASTG](https://mas.owasp.org/MASTG/iOS/0x06h-Testing-Platform-Interaction/) +- [4] [Keychain data protection - Apple Support](https://support.apple.com/guide/security/keychain-data-protection-secb0694df1a/web) +- [5] [Rootless ( -l ) - palera1n docs](https://docs.palera.in/docs/reference/environment-types/) +- [6] [iOS Platform APIs - OWASP owasp-mastg (0x06h-Testing-Platform-Interaction.md)](https://github.com/OWASP/owasp-mastg/blob/master/Document/0x06h-Testing-Platform-Interaction.md) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/ios-pentesting/ios-custom-uri-handlers-deeplinks-custom-schemes.md b/src/mobile-pentesting/ios-pentesting/ios-custom-uri-handlers-deeplinks-custom-schemes.md index e70d4175564..60e1aad7184 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-custom-uri-handlers-deeplinks-custom-schemes.md +++ b/src/mobile-pentesting/ios-pentesting/ios-custom-uri-handlers-deeplinks-custom-schemes.md @@ -4,7 +4,7 @@ ## Basic Information -Custom URL schemes enable apps to communicate using a custom protocol, as detailed in the [Apple Developer Documentation](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP40007072-CH6-SW1).[[1]](#references) These schemes must be declared by the app, which then handles incoming URLs following those schemes. It's crucial to **validate all URL parameters** and **discard any malformed URLs** to prevent attacks through this vector. +Custom URL schemes enable apps to communicate using a custom protocol, as detailed in the [Apple Developer Documentation](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP40007072-CH6-SW1).[[1]](#references) These schemes must be declared by the app, which then handles incoming URLs following those schemes. It's crucial to **validate all URL parameters** and **discard any malformed URLs** to prevent attacks through this vector.[[8]](#references) An example is given where the URI `myapp://hostname?data=123876123` invokes a specific application action. A noted vulnerability was in the Skype Mobile app, which allowed unpermitted call actions via the `skype://` protocol. The registered schemes can be found in the app's `Info.plist` under `CFBundleURLTypes`. Malicious applications can exploit this by re-registering URIs to intercept sensitive information. @@ -239,7 +239,6 @@ This is important because **PKCE alone does not save the flow** when the attacke - [5] [Linking - React Native Documentation](https://reactnative.dev/docs/linking.html) - [6] [Linking into your app - Expo Documentation](https://docs.expo.dev/linking/into-your-app/) - [7] [MASTG-TEST-0371: Missing Source Validation in Custom URL Scheme Handlers](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0371/) +- [8] [Apple Developer Documentation](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP40007072-CH6-SW1) {{#include ../../banners/hacktricks-training.md}} - - diff --git a/src/mobile-pentesting/ios-pentesting/ios-hooking-with-objection.md b/src/mobile-pentesting/ios-pentesting/ios-hooking-with-objection.md index bc2e13ad00c..60d60ff2d50 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-hooking-with-objection.md +++ b/src/mobile-pentesting/ios-pentesting/ios-hooking-with-objection.md @@ -2,7 +2,7 @@ {{#include ../../banners/hacktricks-training.md}} -For this section the tool [**Objection**](https://github.com/sensepost/objection) is going to be used.\ +For this section the tool [**Objection**](https://github.com/sensepost/objection) is going to be used.[[1]](#references)\ Start by getting an objection's session executing something like: ```bash @@ -260,7 +260,8 @@ Now that you have **enumerated the classes and modules** used by the application }); ``` -{{#include ../../banners/hacktricks-training.md}} - +## References +- [1] [Objection - Runtime Mobile Exploration](https://github.com/sensepost/objection) +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md b/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md index 1bd76e7f847..b07cb9c7e9f 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md +++ b/src/mobile-pentesting/ios-pentesting/ios-pentesting-without-jailbreak.md @@ -134,7 +134,7 @@ There are now several mature ways to sideload and keep re-signed IPAs up-to-date | Tool | Requirements | Strengths | Limitations | |------|--------------|-----------|-------------| -| **AltStore 2 / SideStore** | Free Apple ID + companion workflow (`AltServer`) or the on-device SideStore flow | Familiar UX, automatic refresh, practical on current devices | Free profiles still expire after **7 days**; free Apple IDs are usually limited to **3 installed apps** and roughly **10 App IDs** in a **7-day** window | +| **AltStore 2 / SideStore** | Free Apple ID + companion workflow (`AltServer`) or the on-device SideStore flow | Familiar UX, automatic refresh, practical on current devices | Free profiles still expire after **7 days**; free Apple IDs are usually limited to **3 installed apps** and roughly **10 App IDs** in a **7-day** window[[9]](#references) | | **TrollStore 1/2** | Device on a firmware officially supported by the CoreTrust bug (**14.0 beta 2 – 16.6.1**, **16.7 RC (20H18)**, and **17.0**) | *Permanent* signing (no 7-day refresh); excellent for long assessments on vulnerable devices | Firmware-specific; **17.0.1+** and most fully patched modern releases are out of scope unless a new CoreTrust bug appears | For routine pentests on current iOS versions AltStore/SideStore are usually the most practical choice, while TrollStore is the best option when the target test device happens to be on a compatible firmware. diff --git a/src/mobile-pentesting/ios-pentesting/ios-protocol-handlers.md b/src/mobile-pentesting/ios-pentesting/ios-protocol-handlers.md index b25f012d91b..4481ea1508b 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-protocol-handlers.md +++ b/src/mobile-pentesting/ios-pentesting/ios-protocol-handlers.md @@ -4,7 +4,7 @@ ## Basic Information -In this page, **protocol handlers** are the URL schemes or URL-like handoffs that make iOS leave the current web context or resolve content through a non-standard path. During a pentest, treat every transition from **web content** to **`UIApplication.open`**, **`canOpenURL`**, or a **`WKURLSchemeHandler`** as a trust boundary. +In this page, **protocol handlers** are the URL schemes or URL-like handoffs that make iOS leave the current web context or resolve content through a non-standard path. During a pentest, treat every transition from **web content** to **`UIApplication.open`**, **`canOpenURL`**, or a **`WKURLSchemeHandler`** as a trust boundary.[[1]](#references) This page focuses on **WebView / browser-driven scheme abuse**. For app registration, deeplink hijacking, and callback stealing, see [iOS Custom URI Handlers / Deeplinks / Custom Schemes](ios-custom-uri-handlers-deeplinks-custom-schemes.md). For the file-origin / `loadFileURL:allowingReadAccessTo:` angle, see [iOS WebViews](ios-webviews.md). For claimed `https` handlers, see [iOS Universal Links](ios-universal-links.md). diff --git a/src/mobile-pentesting/ios-pentesting/ios-serialisation-and-encoding.md b/src/mobile-pentesting/ios-pentesting/ios-serialisation-and-encoding.md index b6005e6d59d..640d5509349 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-serialisation-and-encoding.md +++ b/src/mobile-pentesting/ios-pentesting/ios-serialisation-and-encoding.md @@ -76,6 +76,3 @@ When serializing data, especially to the file system, it's essential to be vigil - [1] [iOS Platform APIs](https://mas.owasp.org/MASTG/iOS/0x06h-Testing-Platform-Interaction/#object-persistence) {{#include ../../banners/hacktricks-training.md}} - - - diff --git a/src/mobile-pentesting/ios-pentesting/ios-testing-environment.md b/src/mobile-pentesting/ios-pentesting/ios-testing-environment.md index e774118e07d..f02ba6e1c0c 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-testing-environment.md +++ b/src/mobile-pentesting/ios-pentesting/ios-testing-environment.md @@ -161,7 +161,7 @@ basic-ios-testing-operations.md ### **Jailbreak Detection** -**Several applications will try to detect if the mobile is jailbroken and in that case the application won't run** +**Several applications will try to detect if the mobile is jailbroken and in that case the application won't run**[[1]](#references) - After jailbreaking an iOS **files and folders are usually installed**, these can be searched to determine if the device is jailbroken. - In modern **rootless** jailbreaks, those files may appear under **`/var/jb`** or resolve through symlinks into `/private/preboot/...` instead of only in classic rootful locations. @@ -187,4 +187,3 @@ You can try to avoid this detections using **objection's** `ios jailbreak disabl - [4] [Jailbreak Detection Methods](https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/jailbreak-detection-methods/) {{#include ../../banners/hacktricks-training.md}} - diff --git a/src/mobile-pentesting/ios-pentesting/ios-uiactivity-sharing.md b/src/mobile-pentesting/ios-pentesting/ios-uiactivity-sharing.md index 1bdce634b07..1aacf4be544 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-uiactivity-sharing.md +++ b/src/mobile-pentesting/ios-pentesting/ios-uiactivity-sharing.md @@ -55,6 +55,3 @@ For **receiving items**, it involves:[[1]](#references) - [1] [OWASP MSTG - Testing Platform Interaction (iOS)](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction) {{#include ../../banners/hacktricks-training.md}} - - - diff --git a/src/mobile-pentesting/ios-pentesting/ios-uipasteboard.md b/src/mobile-pentesting/ios-pentesting/ios-uipasteboard.md index 066495dfb93..8c84654bb84 100644 --- a/src/mobile-pentesting/ios-pentesting/ios-uipasteboard.md +++ b/src/mobile-pentesting/ios-pentesting/ios-uipasteboard.md @@ -3,19 +3,19 @@ {{#include ../../banners/hacktricks-training.md}} -Data sharing within and across applications on iOS devices is facilitated by the [`UIPasteboard`](https://developer.apple.com/documentation/uikit/uipasteboard) mechanism, which is divided into two primary categories: +Data sharing within and across applications on iOS devices is facilitated by the [`UIPasteboard`](https://developer.apple.com/documentation/uikit/uipasteboard) mechanism, which is divided into two primary categories:[[1]](#references)[[2]](#references) - **Systemwide general pasteboard**: This is used for sharing data with **any application** and is designed to persist data across device restarts and app uninstallations, a feature that has been available since iOS 10. - **Custom / Named pasteboards**: These are specifically for data sharing **within an app or with another app** that shares the same team ID, and are not designed to persist beyond the life of the application process that creates them, following changes introduced in iOS 10. -**Security considerations** play a significant role when utilizing pasteboards. For instance: +**Security considerations** play a significant role when utilizing pasteboards. For instance:[[1]](#references)[[2]](#references) - There is no mechanism for users to manage app permissions to access the **pasteboard**. - To mitigate the risk of unauthorized background monitoring of the pasteboard, access is restricted to when the application is in the foreground (since iOS 9). - The use of persistent named pasteboards is discouraged in favor of shared containers due to privacy concerns. - The **Universal Clipboard** feature introduced with iOS 10, allowing content to be shared across devices via the general pasteboard, can be managed by developers to set data expiration and disable automatic content transfer. -Ensuring that **sensitive information is not inadvertently stored** on the global pasteboard is crucial. Additionally, applications should be designed to prevent the misuse of global pasteboard data for unintended actions, and developers are encouraged to implement measures to prevent copying of sensitive information to the clipboard. +Ensuring that **sensitive information is not inadvertently stored** on the global pasteboard is crucial. Additionally, applications should be designed to prevent the misuse of global pasteboard data for unintended actions, and developers are encouraged to implement measures to prevent copying of sensitive information to the clipboard.[[2]](#references) ### Static Analysis @@ -79,8 +79,4 @@ setInterval(function () { - [2] [OWASP iOS Exercise notes (iGoat-Swift)](https://hackmd.io/@robihamanto/owasp-robi) - [3] [MASTG-TEST-0073: Testing UIPasteboard](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0073/) - {{#include ../../banners/hacktricks-training.md}} - - - diff --git a/src/network-services-pentesting/11211-memcache/memcache-commands.md b/src/network-services-pentesting/11211-memcache/memcache-commands.md index 7d64dfdb22d..ce5b5c955ad 100644 --- a/src/network-services-pentesting/11211-memcache/memcache-commands.md +++ b/src/network-services-pentesting/11211-memcache/memcache-commands.md @@ -105,7 +105,7 @@ STAT total_malloced 3145436 END ``` -If you are unsure if you have enough memory for your memcached instance always look out for the “evictions” counters given by the “stats” command. If you have enough memory for the instance the “evictions” counter should be 0 or at least not increasing.[[1]](#references) +If you are unsure if you have enough memory for your memcached instance always look out for the “evictions” counters given by the “stats” command. If you have enough memory for the instance the “evictions” counter should be 0 or at least not increasing. #### Which Keys Are Used? @@ -127,13 +127,11 @@ STAT items:2:age 1405 END ``` -This at least helps to see if any keys are used. To dump the key names from a PHP script that already does the memcache access you can use the PHP code from [100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html).[[1]](#references) +This at least helps to see if any keys are used. To dump the key names from a PHP script that already does the memcache access you can use the PHP code from [100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html).[[2]](#references) ## References -- [1] [memcached cheat sheet](https://lzone.de/cheat-sheet/memcached) +- [1] [Memcached Cheat Sheet - lzone.de](https://lzone.de/cheat-sheet/memcached) +- [2] [Dumping MemcacheD Content Keys with PHP - 100days.de](http://100days.de/serendipity/archives/55-Dumping-MemcacheD-Content-Keys-with-PHP.html) {{#include ../../banners/hacktricks-training.md}} - - - diff --git a/src/network-services-pentesting/113-pentesting-ident.md b/src/network-services-pentesting/113-pentesting-ident.md index 16a4834876c..835bb855a8c 100644 --- a/src/network-services-pentesting/113-pentesting-ident.md +++ b/src/network-services-pentesting/113-pentesting-ident.md @@ -52,7 +52,7 @@ PORT STATE SERVICE VERSION ### Ident-user-enum -[**Ident-user-enum**](https://github.com/pentestmonkey/ident-user-enum) is a simple PERL script to query the ident service (113/TCP) in order to determine the owner of the process listening on each TCP port of a target system. The list of usernames gathered can be used for password guessing attacks on other network services. It can be installed with `apt install ident-user-enum`. +[**Ident-user-enum**](https://github.com/pentestmonkey/ident-user-enum) is a simple PERL script to query the ident service (113/TCP) in order to determine the owner of the process listening on each TCP port of a target system. The list of usernames gathered can be used for password guessing attacks on other network services. It can be installed with `apt install ident-user-enum`.[[1]](#references) ``` root@kali:/opt/local/recon/192.168.1.100# ident-user-enum 192.168.1.100 22 113 139 445 @@ -93,7 +93,8 @@ Entry_2: Note: apt install ident-user-enum ident-user-enum {IP} 22 23 139 445 (try all open ports) ``` -{{#include ../banners/hacktricks-training.md}} - +## References +- [1] [ident-user-enum - pentestmonkey](https://github.com/pentestmonkey/ident-user-enum) +{{#include ../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/135-pentesting-msrpc.md b/src/network-services-pentesting/135-pentesting-msrpc.md index c6df5076af8..012a292cc31 100644 --- a/src/network-services-pentesting/135-pentesting-msrpc.md +++ b/src/network-services-pentesting/135-pentesting-msrpc.md @@ -107,7 +107,7 @@ This method has been used to get interface information as **IPv6** address from ### Executing a RCE with valid credentials -It is possible to execute remote code on a machine, if the credentials of a valid user are available using [dcomexec.py](https://github.com/fortra/impacket/blob/master/examples/dcomexec.py) from impacket framework. +It is possible to execute remote code on a machine, if the credentials of a valid user are available using [dcomexec.py](https://github.com/fortra/impacket/blob/master/examples/dcomexec.py) from impacket framework.[[7]](#references) **Remember to try with the different objects available** @@ -267,6 +267,3 @@ A single out-of-bounds write or unexpected exception will be surfaced immediatel - [9] [HTB: APT writeup (0xdf)](https://0xdf.gitlab.io/2021/04/10/htb-apt.html) {{#include ../banners/hacktricks-training.md}} - - -