Android Capture
Capturing HTTPS on Android with a proxy often gets stuck at “the certificate is installed but the app still will not accept it.” On newer systems, apps do not trust user certificates by default, and apps with certificate pinning cannot be captured at all. Android capture takes a different approach: whole-device capture with automatic decryption, and no certificate to install on the phone at any point. Physical devices and emulators are both supported, and even apps with certificate pinning or custom encryption have their plaintext read from inside.
1. Common preparation
Section titled “1. Common preparation”- Connect the device: connect it to the computer with a data cable and enable USB debugging; emulators are usually detected automatically.
- Root required: all three methods require a rooted device.
- No certificate to install: none of them are man-in-the-middle proxy methods, so there is no certificate to install on the phone, which is exactly why they are more hassle-free than proxy capture on Android. When a certificate is needed, a rooted device can also install the trusted certificate automatically, saving you the manual steps.
- Works out of the box: the helper components needed for capture are downloaded and cached automatically based on the device architecture, with no manual environment setup on your part.
2. Emulator capture
Section titled “2. Emulator capture”Capturing traffic inside an Android emulator on the computer is almost the same as capturing a physical device, and often even simpler:
- Auto-detected: emulators from common brands are discovered automatically, with no data cable and no manual connection (only physical devices need USB).
- Usually already rooted: emulators generally come rooted or can be rooted with one click, which conveniently satisfies the capture requirement.
- Prefer “NIC key”: an emulator’s system kernel is often older and may not support “NIC capture,” so just choose NIC key, which has the best compatibility with emulators.
Everything else is the same as with a physical device: select the emulator device and capture using the methods below.
3. How to choose among the three methods
Section titled “3. How to choose among the three methods”| Your situation | Which to use | Notes |
|---|---|---|
| Older device / emulator / not sure how new | NIC key (recommended default) | Best compatibility; works on almost any rooted device |
| A newer rooted physical device | NIC capture | Easiest, self-contained |
| Only care about one app, or it cannot be decrypted in NIC mode | App-layer capture | Reads plaintext from inside the app, working around certificate pinning / custom encryption |
The first two are whole-device capture with automatic decryption and no certificate to install; the third targets a single app and can handle even the most heavily fortified ones.
4. NIC key (recommended default)
Section titled “4. NIC key (recommended default)”Capture all traffic on the device’s NIC (Wi-Fi by default) and decrypt it automatically, with no need to pick a specific app and no certificate to install.
- Best compatibility: it is not picky about the kernel, and older devices and various emulators all work, which is its biggest advantage over NIC capture. When you are not sure how new the device is, this is the safest choice.
- A few apps may show only ciphertext: individual apps that bundle non-standard encryption components may have traffic that cannot be decrypted; in that case switch to app-layer capture below to handle it precisely.
How to use: select the device → select the NIC (Wi-Fi by default) → start capturing.
5. NIC capture
Section titled “5. NIC capture”Also captures all traffic on the device’s NIC and decrypts it automatically. What sets it apart is that it is self-contained and the easiest to use (the data and the information needed to decrypt it are packaged together).
- Prerequisite: requires a newer device (newer kernel). If the device is too old to qualify, you will get a clear “NIC capture not supported” message when you start capturing; just switch to NIC key then.
How to use: select the device → select the NIC (Wi-Fi by default) → start capturing.
6. App-layer capture
Section titled “6. App-layer capture”Targeting a single app, it reads plaintext directly from inside it, and neither certificate pinning nor custom encryption can stop it.
- Not limited by the shortcomings of NIC mode: apps that cannot be decrypted in NIC mode (certificate pinning, custom encryption) have their plaintext read here too, because it reads from inside the app, without acting as a man-in-the-middle and without relying on NIC decryption.
- Turn on “socket traffic” as a fallback when it cannot be decoded: for apps that statically link / use a custom library and from which the usual methods cannot obtain plaintext, turn on this switch to take a lower-level path to the data.
- Restart the target program: you can close and relaunch the app first to capture its early-startup traffic.
- Only targets the app you selected (not whole-device traffic).
How to use: choose the target app (select it from the list of installed apps, or fill in a package name / process name; leave it blank to capture the foreground app) → check “restart target program” if you need to capture startup traffic → start capturing.
7. You can also use proxy capture
Section titled “7. You can also use proxy capture”Besides the three methods above, an Android device can also use proxy capture: point the device’s Wi-Fi proxy at this machine, install the root certificate, and you can capture HTTPS plaintext just like on a computer and use the full set of rewriting and replay capabilities. It suits debugging apps that go through the system proxy, or scenarios that need rule-based rewriting / replay of mobile requests.
- Install the certificate: scan the QR code on the phone for one-tap installation → Certificate Management and Installation
- Capture and rewriting capabilities: → Proxy Capture
8. When to use Android capture
Section titled “8. When to use Android capture”- Analyzing a phone app’s network requests and investigating endpoint issues, with whole-device automatic decryption and no fiddling with certificates.
- Seeing, from a whole-device view, which endpoints a device or an app actually connected to and what it sent.
- When an app uses certificate pinning and NIC mode cannot decrypt it, use app-layer capture to obtain the plaintext precisely.
- To view and edit at the same time (rewrite / replay), use proxy capture.
Back to Proxy Capture · Related: Data Viewing and Decoding · Certificate Management and Installation