> Once that's bypassed
Do you mean that you trick the app into accepting a wrong cert? How does one do that, apart from decompilation?
Do you mean that you trick the app into accepting a wrong cert? How does one do that, apart from decompilation?
Some apps package their own crypto helpers (often with big crypto problems) to make this harder and require actual reverse engineering, but those are a pain to maintain and it's only a matter of time before someone finds a way around them. If you can extract the symbols (so if the app has not been obfuscated well) you can use Frida's API to hook those as well through any language you like. There's even an interactive Javascript console you can hook into the apps you're hooking!
Certificate pinning is a great way to protect users' security and privacy, especially in countries with questionable governments or ISPs, but it won't protect your app's secrets.
[1]: https://github.com/nabla-c0d3/ssl-kill-switch2 [2]: https://techblog.mediaservice.net/2020/08/ios-13-certificate...
Not sure if older iPhones would come with older versions too, I assume used ones would normally be up to date - though iPhone X and earlier are jailbreakable on all versions via checkm8
https://www.reddit.com/r/jailbreak/comments/mm0g3f/news_new_...
Jailbreaking iOS 14 with checkra1n breaks faceID because it requires an additional SepOS exploit
Didn't even know that mobile OSes have APIs for cert validation, since that's not a part of the OS in my books. Though the motivation for shared libs is understandable (Facebook being an example of what not to do).
I guess one drunken evening I'm gonna read through lists of the APIs just to see what kinds of stuff are crammed there.
Mobile operating systems provide a very broad API so that access management and sandboxing is made easy. I'm not sure how things are done on the iOS side, but on Android you can enable certificate pinning application-wide by just putting an XML file with the right name in the right place and adding a key/value pair for the hostname and the pinned public key (anywhere in the validation chain, AFAIK). The same XML file also allows disabling plain text requests from your application runtime, preventing accidental data leaks to insecure networks.
Because adding security is so easy, there's loads of apps enforcing a security setting that otherwise would be considered obscure to most application developers. Exposing an optional, application-wide API is a pretty solid idea in my book; I'm not aware of any Linux system API that can easily enforce certificate pinning on an application-wide level.
https://www.raywenderlich.com/1484288-preventing-man-in-the-...
But considering how the API is documented now (and alternative third party apps exist), it might not even be necessary.