pimterry
commented
11 months ago To be clear, if the old script is easier, you can keep using it! It's all in the git history - the final version is available here.
why is config.js even needed?
Config.js itself doesn't really do anything - it just defines variables used by the other scripts.
It's needed because the scripts now do lots of things they didn't used to. Most notably:
- They can do proxy setup & low-level packet capture - so you don't need to configure your device's proxy settings at all, and you can capture traffic that manual proxy configuration cannot (similar to HTTP Toolkit's VPN-based app, but without the app).
- They can install the system certificate directly, so you don't need to do any certificate setup at all.
- They do unpinning much more effectively. The previous script mostly just skipped all TLS verification completely. That works, but effectively makes all your traffic public. Anybody else on your network could potentially see what you were intercepting and modify it, and that approach is less effective than closely integrating with how TLS APIs are supposed to work (and potentially less representative of normal app behaviour too). The new script instead injects settings to trust a specific additional CA certificate: so all logic works as normal and traffic is correctly validated, but as if your CA is an extra magically trusted CA everywhere. More complicated and needs to know your CA certificate, but much more effective.
The end goal is that you can take a totally fresh device or emulator, install Frida, run these scripts, and immediately see all the traffic - no other setup required.
For these, it needs two settings (the proxy host+port, and the CA certificate) and there's also a new DEBUG_MODE boolean that makes it much easier to debug how this setup is working (or not) so you can tweak it for your specific target. Those settings are all defined in config.js.
why are we ALSO needing to supply an ADDITIONAL 5 scripts on top of config.js? I think it would be helpful to explain what people are getting using all 6 scripts versus just one or two.
What each of the scripts does is documented in the big comment at the top of each one.
I think they also have quite clear names to be honest, but PRs for improvements to any of this are welcome of course.
what is the absolute minimum needed to have some form of unpinning support?
To do just Android unpinning alone, on a device that's otherwise fully setup for interception, you want just config.js (really just the CERT_PEM variable) and android/android-certificate-unpinning.js.
You might also want android/android-certificate-unpinning-fallback.js, which adds some more experimental unpinning that can help to handle unrecognized weird cases (it attempts to patch unknown failures by pattern matching, to handle fully obfuscated cases).
Does that make sense?
ghost
the new setup seems to be really complicated, which I don't like. I guess if the end result is better unpinning that is good, but I think it would help explain the extra complexity. for example:
why is config.js even needed? the previous script did not need to know this information. Note I am using Android Studio with MITM Proxy and not HTTP Toolkit, not sure if that makes a difference.
why are we ALSO needing to supply an ADDITIONAL 5 scripts on top of config.js? I think it would be helpful to explain what people are getting using all 6 scripts versus just one or two.
what is the absolute minimum needed to have some form of unpinning support? just config.js and one other JS file? if so which one?