Targeted automatic Android app unpinning & interception

[pimterry]

It would be great to have a "Android app via Frida" interception option, to go with the existing "Android device via ADB/QR code" options, but providing more targeted interception and doing cert unpinning totally automatically.

Using Frida this should be possible, without needing the VPN app. This could automatically configure the proxy for that app specifically (via ProxySelector.setDefault - both built-in APIs and OkHttp seem to observe this correctly) and then handle certificate trust within the app itself, just extending the existing script which already hooks into most standard cert trust logic implementations. This wouldn't work for all apps (e.g. Chrome's cert logic is wayyyy out of scope) but there's still many valuable use cases.

Initially this would probably work by detecting already running instances of Frida Server (scan for port 27042, find a way to ping it to test). Later on we could pull and install the latest release for the given architecture automatically.

We would need some UI to parse the output from the script to catch errors too, since in most cases that don't work out of the box the errors tend to be extremely illuminating. This is very important as there will be cases that cannot be handled automatically, and managing the support load from that requires good feedback that leads into useful documentation here (i.e. the manual reverse engineering post).

This would be helpful for many reverse engineering use cases, very very convenient, and leaves some nice space for extension to support interception via Frida in other cases too (most notably iOS, summarized here).

---

Does this affect you too? Click below and add a 👍 to vote for this and help decide where HTTP Toolkit goes next, or go vote on the other most popular ideas so far.

[pimterry]

One challenge is that this definitely requires the Frida node bindings, which is a 60MB prebuilt binary. Gzips to 22MB, but that still nearly doubles the size of the server download. I've previously fiddled with basic ideas around this, and discussed with the Frida team, there's some suggestions here: frida/frida#1760 (comment). More ideas here: https://frida.re/docs/footprint/. Needs investigation to see how small we can go.

We could defer this somewhat though, by initially scanning for an existing Frida server without using the bindings, and downloading them async on demand only if that succeeds, for the first release. Bit messy though for UX long-term, and annoying e.g. if Frida is detected but unusable because you're offline.

...Or, since it's just the bindings (not too bothered by the server etc that we can pull async) and there's some kind of network bindings to server protocol, we could reverse engineer and use that directly? That assumes the logic we need mostly runs in the server though, hard to say.

[pimterry]

Frida 15+ exposes its entire API via websockets, and has a demo JS implementation here where the only real dependency is dbus-next, which weighs about 50kb gzipped. Much more manageable.

(Looks like maybe it uses WebRTC too? Not clear if that's strictly required. That'd be mildly more awkward, but no huge problem)

Did a quick test, I can connect to Frida directly, creating a browser websocket to an Android device, as long as you run a tunnel with adb forward tcp:27042 tcp:27042. Bingo 🚀

Not going to get too carried away with this right now, but I think this very definitely looks doable through that route, could probably get a usable prototype given a week or so. Something to look at once WebRTC debugging etc is shipped.