I want to capture all the traffic from an Android app for its pen-testing. How do I do that?

Here's what I've already tried:

I installed the app on an emulator and started the emulator with a http-proxy pointing to a local port. The local port had ZAP running on it. I'm able to intercept the traffic from the browser but not from the app.

Well, may be my app uses https and I thought I had some certificate problem. So I exported the OWASP ZAP's certificate and pushed it on the android emulator. Of course, Android >= ICS versions have their cert names hashed using OpenSSL. So I followed some instructions here and I managed to get my ZAP's cert on my device. Still, I'm not able to intercept the traffic.

My next line of thought was: May be this app is damaged. So I installed Facebook, Pocket and Guardian (news) apps from the app store into the emulator and tried intercepting their traffic. I can intercept the traffic from Guardian but Pocket and Facebook are unable to connect to internet (so is my app). However, I can browser the internet from my browser on the emulator.

Honestly, I'm at my wits end. I don't understand why this is happening. I haven't done a lot of pen-tests before so, I guess I lack experience. Could anyone help this poor soul?

(Of course, I can always use Wireshark, but it wouldn't be able to MiTM the requests and responsees the way ZAP or Burp does.)


After "Google-ing" like a madman, I finally found that Android doesn't have a support for global proxy (which works for, both browser AND apps). More info can be found here.

  • 2
    you might find that the application is using certificate pinning ( more info security.stackexchange.com/questions/29988/…), which would mean that traffic interception would be tricky. If that's the case you may have more luck de-compiling the app and approaching the review that way... Commented Jun 10, 2014 at 15:44
  • 1
    Interesting. Will surely see if my app is using it. Thanks!
    – Pervy Sage
    Commented Jun 10, 2014 at 15:48
  • for https i think one need to become middleman, intercept handshake request > send your public certs while send request to server and get certs for yourself. Essentially become proxy. Commented Jun 13, 2016 at 19:25

7 Answers 7


You are unable to intercept Facebook traffic because it uses SSL pinning.

On pen-testing an android application you may come across four different scenarios. I will list them down below concisely. A much more detailed article can be found here >> My Blog The article also contains videos which you can refer to.

  1. Non-SSL Application

This is the simplest Android application which you may come across. Games are examples. Much of the traffic goes over http. To intercept the traffic you only have to point the wifi proxy settings of the device/emulator to the laptop where Burp/Zap proxy is running.

  1. Applications which uses HTTPS traffic and rely on device's trusted credentials

Applications like Instagram uses HTTPS to communicate with the server however they rely on the device's trusted credentials. To intercept this traffic you can add your proxy certificate to your device's trusted credentials by adding opening the same from Settings > Security > Trusted credentials

  1. Applications which uses SSL pinning

Certain applications may use SSL pinning to ensure the application being secure even at the event of a trusted credential getting compromised. Cydia substrate module Android Trust Killer or Xposed Module JustTrustMe can be used to bypass SSL pinning control.

  1. Applications which use their own Credential Store

The Facebook Android application uses it's pwn credential store and that's why you are not able to intercept the traffic normally. To bypass this you will have to dissassemble the application to smali code. Add the certificate in desired format to the code, recompile it, sign it and install it again. The process is detailed here >> Blog by DewHurst Security.


Here are the steps I would recommend taking. Step 6 is the most direct answer, but I would recommend running through the other steps. Note that this answer is similar to other answers, but simpler in many steps.

1) Configure Proxy - Configure Burp Suite in transparent mode, listening on all interfaces any ports your application uses, such as 443.

2) Install Certificate Authority - Export certificate on desktop and then do adb push file.der /sdcard/<file>.cer (note we renamed .der to .cer) then go to Settings -> Security -> Install from Device Storage and install your certificate.

3) System Proxy - Try proxying traffic by modifying your Android proxy settings (in your wifi setup). Switch adapter on and off (turning on airplane mode for a second) can help here sometimes if this isn't working.

4) Debug Certificate Issues - Observe the Alerts tab in Burp Suite for any SSL/TLS issues. It's possible your application is using a hardcoded certificate, certificate pinning, or public key pinning to keep you from using your CA. You can try enabling SSL passthrough on the proxy options tab to see if this is an issue for some or all of your targeted domains. If certificate pinning is an issue, you will need to bypass certificate pinning protections.

5) Spoof DNS - Set /etc/dnsspoof.conf to contain an entry for your domain and/or a wildcard entry (examples below): example.com *.com

Set your DNS server to a host you control and run the following command (dnsspoof is already installed on Kali):

dnsspoof -i eth0 -f /etc/dnsspoof.conf host

If your application is not obeying system proxy settings or DNS, I would recommend using Wireshark to observe the behavior for insight before continuing. It's possible that your application is using a non-HTTP protocol.

6) Debug Network Traffic - Run your application in an emulator such as Genymotion, preferably in bridged mode, then listen on your main interface and use a display filter on your device only ip.addr eq

7) Decompile the Application - Use dex2jar to decomplie the application and review code that produces network traffic for insight.

d2j-dex2jar.bat "/path/to/the.apk" -o "/path/to/the/new.jar"

Open the jar file with JD-GUI.

8) MITM - Man in the middle the traffic using a tool like ettercap. Consider using https://github.com/summitt/Burp-Non-HTTP-Extension or other generic TCP proxies (here is one I like: dummyproxy.py) to man-in-the-middle the traffic, although this wont bypass any encryption such as TLS.


Try using mitmproxy. It lets you trace both HTTP and HTTPS traffic. You can view requests and responses as well as capture/edit them.

  • 1
    can mitmproxy capture non http/https traffic?
    – Arya
    Commented Oct 29, 2015 at 7:59
  • @Arya you have to use own certificate for that. Commented Nov 10, 2016 at 21:23

There are a few ways to intercept Android apps reliably, barring use of the Android SDK emulator's --tcpdump and --http-proxy command-line directives (also accessible in the Eclipse emulator settings).

My favorite for all mobile apps is to utilize a DNS blackhole, which can be further automated with the Android SDK emulator:

emulator -dns-server -avd <avdname>

Traffic such as HTTP/TLS could be easily intercepted by running Burp (perhaps as root) on the DNS wildcard host -- although Burp would need to be configured to listen on the appropriate ports (typically 80 and 443) in invisible-mode. Additionally, certain certificate-pinning checks could be bypassed by configuring Burp to do per-hostname CA-signed certificates with a wildcard for the top-level domain (e.g., *.google.com).

Burp can also be configured to capture server responses, which can be very useful while troubleshooting.

If you want to see file handlers along with network protocol handlers, then I suggest utilizing the strace tool via ADB. strace is included in the Android SDK emulator, and can be copied to devices using ADB or otherwise.

  • 2
    ZAP is similar to Burp (plus it has lot of extensions and its open source). So, I'm not really sure if the Burp's suggestion would work. Will try the DNS blackhole and let you know if that works.
    – Pervy Sage
    Commented Jun 10, 2014 at 15:31
  • 1
    ZAP doesn't include many of the features that Burp does, such as the per-hostname CA-signed certificate wildcarding. Both ZAP and Burp should be able to be configured to intercept on a DNS blackholing host, but I don't know how to configure ZAP to do that since I rarely use it. In my opinion, you should learn Burp, too.
    – atdre
    Commented Jun 10, 2014 at 15:33
  • True. I meant it was "similar" in the way that I have to setup both of them as the proxy to let all the traffic pass through them and intercept those requests/responses I want. "Per-hostname CA-signed certificate wildcarding" would be useful if I would be able to intercept the traffic from the app and not the browser alone. So, that's why I said "not really that sure". I think its more of an Android problem. However, as you said, I need to learn Burp too. I'll definitely give it a shot too to see if that would work.
    – Pervy Sage
    Commented Jun 10, 2014 at 15:41
  • I've been trying Burp and ProxyDroid on a rooted android with no success. Even when I use a per-hostname certificate on the Burp listener. With this Blackhole method, what does the role of the Android emulator play? Commented Nov 8, 2015 at 2:12
  • @DylanPierce You can change DNS settings however you like. See -- developer.android.com/tools/devices/emulator.html#dns -- and -- stackoverflow.com/q/2676073
    – atdre
    Commented Nov 11, 2015 at 16:29

I recently pentested an application that did not have native proxy support. The developer had not done it intentionally, so he later fixed it.

Your setup is a bit different, as I used a physical phone. It should be fairly easy for you to do something similar in your lab - but you might require an extra VM-guest running linux, if you are not using this as your host-OS.

Transparent Proxy Setup

What I did to intercept the traffic was to destination NAT all traffic on port 80 and 443 to my attack-proxy. In my setup, I use a wireless access point which the phone connects to.

This setup should work regardless if you have configured the proxy settings or not.

  • Generate and install CA certificate for the attack-proxy on phone.
  • On your Linux machine/iptables-machine, set up transparent forwarding (destination NAT'ing):

    iptables -t nat -A PREROUTING -i wlan0 -p tcp -m multiport --dports 80,443 -j DNAT --to attack-proxy-ip:8080

  • Install a wifi access point, and set the default gateway to be the iptables-machine (Kali Linux / in the example)

Now, when you connect the phone to the wireless access point, all web traffic should be redirected to your attack-proxy.


I used Burp, so I had to enable transparent proxy support. Its called "Support invisible proxying" in Burp.


Connect your Android device and your penetration testing platform to a LAN. Conduct an ARP spoof/poison attack against the Android device using ettercap (or your favorite arp spoofing tool). This will cause all packets to and from the Android device to first pass through your penetration testing platform.

ettercap -T -w dump -M ARP /xx.xx.xx.xx/ // output:

This will dump to the screen but you can configure to dump to a file and then analyze the packets using Wireshark.



  • 1
    With this method do you still have to decrypt? Commented Nov 8, 2015 at 2:08

This is how I capture all the traffic of my Android Phone.

1) I have a rooted Android phone.
2) Install FS Cert Installer and then I imported burp certificate in my phone.
3) Connect my phone and laptop in the same WiFi network.
4) Configure the proxy in the phone such that the burpsuite present in my laptop listens to all the traffic coming through my android phone.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .