Sniffing Android x86 HTTPs traffic with BurpSuite

• 21 December 2020

The task of sniffing traffic from an app on Android x86 ranges from trivial, to very complicated. The difference comes down to the various anti-sniffing techniques employed by the app and or the Android OS itself. This guide will walk you through the process starting with the most trivial scenario, all the way to the most complex.

Scenario 1: ProxyDroid

Before diving into the complexities of sniffing encrypted HTTPs traffic, it’s always good to do a sanity check to make sure that the packets are flowing into BurpSuite

1. Install ProxyDroid app on Android. In case you are wondering why not use built in proxy settings, it’s because some apps ignore the built in proxy setting. By using ProxyDroid, it eliminates the guesswork and every single request is proxied
2. Set host and port in ProxyDroid to match settings in BurpSuite
3. Sniff HTTP traffic, it should be successful
4. Sniffing HTTPs traffic will fail at this point, but you should at least see connection attempt errors showing up in BurpSuite event log. Those prove that it’s trying. See Scenario 2 on how to fix this.

Scenario 2: Simple HTTPs

When the application established HTTPs connection, the minimum it needs is a valid SSL certificate to prevent man in the middle attacks. By installing BurpSuite root certificate on Android, most applications will accept BurpSuite proxy as a trustworthy server.

1. Download BurpSuite cert to Android by visiting http://burpsuiteproxyip:8080
2. Steps to install it depend on exact Android version and sometimes the certificate has to be converted from der format to cer
3. Sniff HTTPs traffic in BurpSuite
   1. If it works, congratulations!
   2. If you get other errors try Scenario 3

Scenario 3: HTTPs protected with pinning

Some applications aren’t satisfied with any old valid certificate, they are pinned to a specific certificate. Luckily there is a way to bypass this

1. Android: Install frida-server on Android in /data/local/tmp
2. Android: Run frida-server -l IPofAndroid (ex. 192.168.1.100)
3. Windows: Run frida-ps -aiH IpofAndoid to find out application identifier ex: com.company.myapp
4. Windows: download bypass.js into current directory
5. Windows: frida -H IpofAndroid -f com.company.myapp -l bypass.js –no-pause (this will start the app)
6. Windows: Watch HTTPs requests come in in plain text into BurpSuite, if you’re still gettting errors, especially “Remote host terminated the handshake” in BurpSuite and “CERTIFICATE_VERIFY_FAILED: self signed certificate in certificate chain” in logcat chances are you need to go deeper and look at Scenario 4 (if the app is build on Flutter)

Scenario 4: HTTPs inside Flutter

• Android: find /data/ | grep libflutter.so
• Android: upload for analysis in Ghidra
• Ghidra: search for "ssl_client" string
• Ghidra: from here find the function that contains “ssl_client”,“ssl_server” and takes long,long,char* as it’s 3 arguments. In my version I had a single match, so I there was no trial and error required to narrow things down.

• Ghidra: get the function’s signature by copying the first several bytes

• Ghidra: If you have trouble, here is a more detailed write up https://blog.nviso.eu/2019/08/13/intercepting-traffic-from-android-flutter-applications/ , just note the differences between ARM and x86, but the process is very similar.
• Windows: incorporate the bytes into flutter-addr.js script
• Windows: frida -H IpOfAndroid -f com.company.myapp -l flutter-addr.js –no-pause
• Windows: you should see the application start and then as the requests are being sent you should see
  • Disabling SSL validation
  • Retval: 0x0
  • If you don’t see retval 0x0 try playing around with "add(0x1)" to address
• Windows: you should also see plan text requests coming into BurpSuite now

• ← Previous
  Isolating Untrusted Devices at Switch Level
• Next →
  Migrating ZFS backed VMs between Proxmox Clusters