apk-mitm

First up: this isn't criticism of the original post in the slightest, it's a wonderful journey through figuring out how a weird device that wants to be on your wifi works. If you have a device that speaks to an Android app, you want https://github.com/niklashigi/apk-mitm - it'll strip pretty much every known certificate pinning implementation from an apk, and it'll also rewrite the manifest so it'll trust the user-installed certs without having to root your device to modify the system store. Uninstall the original app, sideload the output of apk-mitm, and then you can use mitmproxy on a stock device. The other thing is that if a device is providing encrypted data to an app, and the app is displaying the decrypted data, then the app inherently either contains the decryption key somewhere or downloads it from somewhere. https://github.com/s

It reminds me of the expression "locks are to keep honest people out," in that code which runs on a device you control is code that you control: https://github.com/shroudedcode/apk-mitm#readme

> For example, Chrome Desktop, Firefox, and IE did not enforce HPKP if they encountered a cert from a user-added CA. Why does Android do the opposite? Your examples are all browsers. I understood that Chrome on Android will continue to support using a user-added CA added to the user store. Android and desktops behave exactly the same for web browsers. Non-browser apps are where the differences exist. On Android you must opt-in each app to trust the user store. I'd imagine that the next step is automating https://github.com/shroudedcode/apk-mitm to bulk replace all installed apps with modified apks.

It doesn't break Charles Proxy unless you installed your CA cert in a method that is typically used by httptoolkit (installing in the system store). What is broken is installing a custom CA into the system store on a rooted phone and making it work with all apps (apks) and Chrome. If you install the custom CA into the user store it'll still work with Chrome. If you want to use Charles to inspect the HTTPS traffic of an app you are developing then you continue to follow the instructions from https://www.charlesproxy.com/documentation/using-charles/ssl... to configure your test build to use the user store CA certs. If you want to use Charles to inspect apps from other developers then you need to rebuild them to trust the user store just like you would if you were developing the app yourself. Use https://github.com/shroudedcode/apk-mitm to a

On the other hand if the app does use cert pinning, it's much easier on Android because we have https://github.com/shroudedcode/apk-mitm

https://github.com/shroudedcode/apk-mitm Removes certificate pinning from apk files for mitm inspection.

In short: * By default, all modern Android apps only trust CA system certificates, and on a normal device you cannot change those. * You can change system certificates on rooted devices and most (but not all) emulators. * Apps can opt-in to trusting user-installed CA certificates within their manifest config, but almost all don't. If you're on a non-rooted device, the only way to MITM traffic is by modifying the application itself, so that it opts into trusting your cert. You can either inject Frida-Gadget to do that, do it manually, or use https://github.com/shroudedcode/apk-mitm which tries to do it automatically (but it's a bit hit & miss whether it works). If you're on an emulator/rooted device, it's totally possible, see https://httptoolkit.tech/blog/intercepting-android-https/#in... for how that works. That's separate to explicit ce