I've set up Burp+Genymotion like this: https://linuxsuperuser.com/configure-burp-suite-proxy-genymotion/ to do some penetration testing on Android apps for work.

The Genymotion (Android 6.0.0, API 23) Wifi settings are:

proxy:, port: 8080, and the Portswigger CA certificate is properly installed.

Burp (v1.7.21) settings: Proxy listeners listening to 'loopback only' for

My machine is a Windows 10 Pro (1703) Desktop PC.

This setup works to intercept almost all traffic from browsers and apps, also https.

But somehow some apps still manage to tunnel some traffic around burp.

Is there any way to intercept that traffic as well?

Thank you

2 Answers 2


There's 3 probable cases:

  1. Android application setting another proxy on its http requests hence bypassing system proxy and burpsuite.
  2. Application setting its http handlers to ignore android proxy settings and connect directly to the destination.
  3. Application is using non-http protocol.

If 1 or 2 is the case, you'll have to use wireshark or reverse engineering techniques to find the domains that the application is interacting with, lets say xxx.com and yyy.org.
You then have to use adb shell to modify /etc/hosts ,let's assume burp's listening on, add the following lines to /etc/hosts: xxx.com yyy.org

You might need to remount system partition as "rw" to be able to change /etc/hosts:

mount -o rw,remount,rw /system

Then under burp proxy, set it to listen on port 80 and 443, then under settings for each of these listeners enable "invisible proxy" option, if there's http/https traffic sent by the application you will now be able to see/intercept them in burp.

We are making the device resolve application's domain names to our burpsuite's address. We can also change device's DNS to our controlled server which returns burp's address for all requests. This solution falls short if the application directly connects to IP addresses rather than domain names. If the application is using non-http protocols burpsuite won't be able to catch the traffic.


I am thinking that those apps are using Certificate Pinning. Those apps are rejecting the Burp's certificate because they are expecting their own certificates. Since Burp needs its own certificate to MITM the connections, it fails to decrypt to connection. You can check the Alerts tab on Burp Suite to see the failed connections.

You have couple of options:

  • Portswigger released a Burp Suite Mobile Assistant. But it works for IOS 8 and 9 which is no good for you. It says on the page:

    It can attempt to circumvent SSL certificate pinning in selected apps, allowing Burp Suite to break their HTTPS connections and intercept, inspect and modify all traffic. (Supported on iOS 8 and 9).

  • You can use SSLUnpinning_Xposed app (I don't have enough reputation to post more than 2 links, just search the name on the google) which is a similar app to the above. It works only on the Android devices but it requires a rooted device and Xposed framework installed. I wasn't successful at installing Xposed framework on an emulator but you can try anyways. This app will not guarantee to work because some apps take precautions to prevent SSLUnpinning_Xposed app working properly.

  • Lastly, you can reverse engineer the app and modify the Certificate Pinning logic so that app will accept the Burp's certificate. This way is guaranteed to work but harder to do. If app is obfuscated, you may need to read and understand Smali code in order to find the Certificate Pinning logic. If you are trying to MITM banking Apps, I would recommend this options because other ways won't work most of the time. There are great articles on the internet regarding to this topic. For example, you can google Bypassing Certificate Pinning on Android for fun and profit and click the first link.

  • I think that certificate pinning would actually stop the app from working correctly (as far as I have seen so far). So I think that if the apps for which traffic is not "seen" are working as intended it is more likely that they are using protocols that Burp does not intercept. This is the case with WhatsApp for instance that uses: Noise protocol instead of HTTP(S)
    – Wealot
    May 16, 2017 at 9:38
  • I go with Wealot: apps with certificate pinning would refuse the connection. But I'm definitely going to check the alerts. Thanks! May 16, 2017 at 9:49
  • Ooops. I've never thought about that. You are right. May 16, 2017 at 10:20
  • I don't see any alerts. So I take it that Burp doesn't give any hint when it can't decode/recognize certain protocols? I'll have to use other tools like Wireshark, Fiddler or Charles? May 17, 2017 at 15:12

You must log in to answer this question.

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