pimterry
commented
1 year ago Yes - it's very neat, but unfortunately like other similar solutions, it's difficult to use this approach to modify traffic, which really limits the possibilities for developer tooling like HTTP Toolkit.
It's technically possible in that model, but basically requires building an entire HTTP proxy on top of the whole thing (you need to be able to parse, modify and then send on HTTP traffic) so to be honest I think it's usually cleaner to just use a real proxy to start with, and then use hooks like this to redirect & manage trust, instead of trying to implement everything within those. I've got a somewhat similar approach in the works doing exactly that with Frida, patching syscalls & cert trust APIs to forcibly redirect traffic (i.e. still using an HTTP proxy, so you can do full rewriting/redirection/etc) for a given target process. More details here: https://httptoolkit.com/blog/frida-mobile-interception-funding/.
That said - this does have a real advantage when trying to look at traffic from processes that use completely unusual APIs & interfaces, because it can cover other TLS libraries easily, and you're much better placed to add custom patches to go further with that. For 99% of cases that won't be worthwhile, but if you're trying to intercept Facebook or something similarly weird (where they use their own internal cert pinning setup, avoiding all the standard APIs) then it can certainly help.
hey do you know about this:
https://github.com/gojue/ecapture
I know this seems spammy, but I have no relation to that project, just seems cool. I know you have had trouble recently with the new Android and certificates, so might be a good option. here is a video and images too:
https://medium.com/@cfc4ncs/ecapture-capture-https-traffic-without-ca-certificates-on-android-linux-a1f6f6ab782b