Interception issue with no traffic collected

[pimterry]

Originally posted by @HumairaFasih in https://github.com/httptoolkit/frida-interception-and-unpinning/issues/60#issuecomment-1809207847

Hi!

I'm running into the same "TLS error auto-patcher", with no traffic being detected in the Burp Suite interface. I have set Burp Suite to listen to all interfaces with port 8080, and have reversed the adb port.

P.S in case its relevant: The machine running Burp Suite is Linux, with ethernet cable providing it internet access. The android mobile phone is a rooted Pixel 3 with wireless connectivity (and I removed the previous burp certificate that I had installed in system/etc/security/cacerts in order to let the config.json script handle its installation in case that led to any issues)

My proxy_host is 127.0.0.1 in config file, and proxy_port is 8080. I did adb reverse tcp:8080 tcp:8080

Please let me know where the error is??

Attaching a screenshot too in case I missed any details:

[pimterry]

Hi @HumairaFasih - this issue isn't related to #60, so I've separated it out here. The TLS error auto-patcher line is just showing that the autopatcher was setup correctly, it's not an error.

If you're not seeing anything in Burp (not even failed connections) then this is probably a connection issue, not a certificate or TLS problem. Even if the certificate & unpinning setup is totally broken, TLS problems should always be visible on the proxy side (I don't use Burp myself, but I'm confident they'll show you those errors somehow too).

It's hard to know exactly what would cause this, but that's what you need to investigate. A good start would be using some kind of connection testing app to confirm that the address is accessible at all from your phone. You might also want to look at Wireshark to debug this, since that will show you all the raw packets directly, and you can use it to see if any connections are even reaching your machine at all.

[HumairaFasih]

Let me check that! Also, do I or do I not need to ensure that the certificate that I previously installed on the device are removed before running your script? Because it may be that I need to reboot the device after removal of the certificates via rm if your scripts require that no other certificates exist.

Also, previously when I had set the proxy to listen on 127.0.0.1 only (with port 8080) it was showing the following error trace:

Could you hint as to why this happened?

[HumairaFasih]

Okay, I rebooted the android phone Reran adb reverse tcp:8080 tcp:8080

Also, turns out I forgot to click checkmark button that enables the selected setting (thus allowing burp to listen to all interfaces on the network)

But after selecting it, I still get the above issue highlighted in red. Burp Suite dashboard is logging some errors related to certificate unknown too.

Do I need to insert system level certificate myself as well?

[pimterry]

Also, turns out I forgot to click checkmark button that enables the selected setting (thus allowing burp to listen to all interfaces on the network)

Haha, yes, that'll do it. The explains the previous issue then - that error simply means that the connection didn't succeed at all. I'll see what if I can make the script automatically detect and warn about that...

do I or do I not need to ensure that the certificate that I previously installed on the device are removed before running your script

You don't need to remove any certificates, it should work just fine regardless. It might be helpful to remove them just to simplify the setup or to help with debugging, but it shouldn't make a practical difference for these scripts.

I still get the above issue highlighted in red. Burp Suite dashboard is logging some errors related to certificate unknown too.

I think the verifyChain error plus the TLS errors shown in Burp here means that:

• Network capture is indeed now working (the traffic is going to Burp, instead of the real destination)
• TLS interception and certificate setup is not.
• I think that specific error implies that the certificate received from the proxy doesn't validate against the one in config.js.

My best guess for why that's happening is based on the Burp messages there: you need to enable invisible proxy support. I'm not sure what's required for that, but this implies there's some non-proxy aware traffic here (might be non-HTTP traffic, might be trying to avoid the proxy, might just be a dodgy networking implementation). By the sound of it, if you don't enable that setting, Burp won't show the right certificate for that traffic (it should use TLS SNI to do this, but https://portswigger.net/burp/documentation/desktop/tools/proxy/invisible implies it doesn't by default). That means although the certificates use a trusted CA, they won't have the right hostname, and maybe that could cause this.

Alternatively, this would happen if Burp is working correctly, but the CA certificate it's using doesn't match the CA you're using in config.js. Have you definitely included your Burp CA certificate correctly there?

I've just pushed a couple of changes that add clearer logging to the fallback script around this, which might help debug that issue if you pull the latest version.

[HumairaFasih]

The logging support you included now shows this, which means that the proxy seems to not be configured correctly. But I am not sure why that would be the case since I've exported Burp's certificate in der format and then converted it to pem using openssl.

Although probably not required, but here are screenshots that show the burp certificate in pem format, and the copied version in config.js

Also the proxy_host was 127.0.0.1 with adb reverse command ran on the device when I had those errors. That 10.103.73.31 is the PC's IP in the next test I ran to see if that worked, but that also gave the same error as shown above.

Some other ideas: 1) If I enable the burp proxy to listen on all interfaces, should the proxy host in config.json be 0.0.0.0? And do I need to do adb reverse in this case? 2) Your scripts overcome any proxy settings in the android system settings right? Although I have rebooted the phone so that shouldn't be creating this problem. 3) Do you think that the fact that the burp proxy is on a Linux machine that has internet via ethernet cable while the phone has internet via wireless is any factor here?

[pimterry]

The logging support you included now shows this, which means that the proxy seems to not be configured correctly.

That suggests some connections are failing - this isn't about TLS and certificates, those are errors related creating the connection in the first place, before any other kind of security or anything is involved on top.

It's odd though, because here while some connections are failing, many are clearly working - you can't get TLS errors if you don't have a connection first.

I think that's probably a bug in the logging. I'll get that sorted, but for now don't worry about that error.

The verifyChain errors mean there is still some kind of certificate issue though. It's not clear why, but for whatever reason Burp's certificate isn't actually being trusted.

If I enable the burp proxy to listen on all interfaces, should the proxy host in config.json be 0.0.0.0? And do I need to do adb reverse in this case?

No - 0.0.0.0 isn't a valid destination IP, it's reserved to mean "every address on the current machine", and adb reverse is only required if you want to tunnel the traffic over ADB (e.g. because it's difficult sending it over your local network, or it's just easier than fiddling with IPs). In the config, you just need to an IP address where the phone can reach the proxy. With adb reverse that's always 127.0.0.1, otherwise any accessible a remote address is fine.

Your scripts overcome any proxy settings in the android system settings right? Although I have rebooted the phone so that shouldn't be creating this problem.

Yes, the scripts will override the system proxy settings for the target app

Do you think that the fact that the burp proxy is on a Linux machine that has internet via ethernet cable while the phone has internet via wireless is any factor here?

As long as the phone can reach the proxy on the IP & port provided, everything should be fine (and as above - I think that proxy connection error is a bug on my part, so we can ignore that).

[HumairaFasih]

So just as an extra follow-up, if I were to use adb reverse tcp:8080 tcp:8080 and set burp to listen on 127.0.0.1:8080 it DOES NOT matter if the machine and the android phone have different networks? Namely, one from ethernet and the other from WiFi? Or even if the machine then has VPN turned on and gets its IP changed?

[pimterry]

adb reverse tells ADB to forward port 8080 on your local machine (the computer) to the phone, so that ADB will pass any connections through there. That means when something on your phone connects to 127.0.0.1:8080, the ADB process on your phone will receive the packet, send it via the ADB connection (e.g. down a USB or whatever) to the ADB server on your computer, which will then send it to the local 8080 port there.

As long as the ADB connection stays connected, that'll keep working - it doesn't use the wifi or ethernet or any other networking at all (unless you do so for ADB itself).

[HumairaFasih]

Using that logic, if the machine has a VPN on and I enable a global http proxy using adb shell settings put global http_proxy 127.0.0.1:8080 while burp is set to listen on 127.0.0.1:8080, the traffic should still go through to the proxy correct?

[pimterry]

Probably, although I'm not sure about the details & tradeoffs of the shell configuration approach.

One point that might cause a difference there is native-connect-hook.js, which does manual packet redirection on any connections that ignore the proxy settings. This usually doesn't matter much, but without that you'll miss traffic from apps that either intentionally (to avoid interception) or through dodgy implementations (every Flutter app) ignore the device proxy settings.