How to Capture Android HTTPS Without a User Cert
To capture Android HTTPS without installing a user certificate, Trace Eagle offers three methods on a rooted physical device or emulator: NIC key, NIC capture and app-layer capture. The first two capture the whole device and decrypt HTTPS automatically, with no certificate on the phone at any point. The third reads one app’s plaintext from inside it, so SSL pinning and custom encryption cannot block it. If you are not sure how new the device is, start with NIC key.
Why can’t I capture Android HTTPS even with a certificate installed?
Section titled “Why can’t I capture Android HTTPS even with a certificate installed?”Proxy capture on Android often gets stuck at “the certificate is installed but the app will not accept it”: since Android 7, apps do not trust user-installed CA certificates by default (see Android’s Network Security Config documentation), and apps with certificate pinning cannot be captured at all.
None of the three methods here are man-in-the-middle proxies, so there is no certificate to install on the phone, and the problem goes away. When a certificate is needed, a rooted device can also install the trusted certificate automatically.
Does Android capture require root?
Section titled “Does Android capture require root?”Yes, all three methods require a rooted device. The rest of the setup is simple:
- Connect the device: connect it to the computer with a data cable and enable USB debugging; emulators are usually detected automatically.
- 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.
Can I capture traffic from an Android emulator?
Section titled “Can I capture traffic from an Android emulator?”Yes. It is almost the same as a physical device, and often 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 satisfies the capture requirement.
- Prefer “NIC key”: an emulator’s system kernel is often older and may not support “NIC capture,” so choose NIC key, which has the best compatibility with emulators.
Everything else is the same as with a physical device: select the emulator and capture using the methods below.
Which of the three Android capture methods should I use?
Section titled “Which of the three Android capture methods should I use?”| 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 handles even heavily fortified ones.
NIC key (recommended default)
Section titled “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, 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: apps that bundle non-standard encryption components may have traffic that cannot be decrypted; switch to app-layer capture below for those.
How to use: select the device → select the NIC (Wi-Fi by default) → start capturing.
NIC capture
Section titled “NIC capture”Also captures all traffic on the device’s NIC and decrypts it automatically. 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, you will get a clear “NIC capture not supported” message when you start; switch to NIC key then.
How to use: select the device → select the NIC (Wi-Fi by default) → start capturing.
How do I get plaintext from an app with SSL pinning?
Section titled “How do I get plaintext from an app with SSL pinning?”Use app-layer capture: it targets a single app and reads plaintext directly from inside it, so neither certificate pinning nor custom encryption can stop it. It does not act as a man-in-the-middle or rely on NIC decryption, so apps that NIC mode cannot decrypt work here too.
- Turn on “socket traffic” as a fallback: for apps that statically link / use a custom library and from which the usual methods cannot obtain plaintext, this switch takes a lower-level path to the data.
- Restart the target program: close and relaunch the app to capture its early-startup traffic.
- Only targets the app you selected (not whole-device traffic).
How to use: choose the target app (from the list of installed apps, or by package name / process name; leave it blank to capture the foreground app) → check “restart target program” if you need startup traffic → start capturing.
Can Android also use proxy capture?
Section titled “Can Android also use proxy capture?”Yes. Besides the three methods above, an Android device can 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, with the full set of rewriting and replay capabilities. It suits apps that go through the system proxy, or rule-based rewriting / replay of mobile requests.
- Install the certificate: scan the QR code on the phone for one-tap installation → install the capture certificate
- Capture and rewriting capabilities: → Proxy Capture
- If an app loses its connection as soon as the proxy is on, bypass SSL pinning first, then decrypt through the proxy.
Which Android method fits which scenario?
Section titled “Which Android method fits which scenario?”- 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, use proxy capture; see how to rewrite requests.
Do I need to install a certificate on the phone?
Section titled “Do I need to install a certificate on the phone?”No. NIC key, NIC capture and app-layer capture are not man-in-the-middle methods, so nothing is installed on the phone; only proxy capture needs the root certificate.
What if I see “NIC capture not supported”?
Section titled “What if I see “NIC capture not supported”?”The device’s kernel is too old for NIC capture. Switch to NIC key, which is not picky about the kernel.
What does app-layer capture record if I leave the target blank?
Section titled “What does app-layer capture record if I leave the target blank?”It captures the app currently in the foreground.
Why do a few apps show only ciphertext under NIC key?
Section titled “Why do a few apps show only ciphertext under NIC key?”Those apps bundle their own or non-standard encryption components that cannot be decrypted at the NIC layer. Use app-layer capture to read their plaintext from inside the app.
Back to Proxy Capture · Related: capture iOS traffic · Data Viewing and Decoding · Certificate Management and Installation