I'll give mitmproxy a try. Thanks!
I should be able to see what data an app is sending, and certificate pinning (and ATS according to another comment) kills that. That's not a good thing.
The obligatory related link: https://www.gnu.org/philosophy/right-to-read.en.html
I think some applications use certificate pinning when validating a certificate provided by a default certificate authority, but, if you manually install a root certificate onto your device, the app will accept the override. That's one possible middle ground.
Reverse engineering isn't inherently good or bad, it's just a tool. That tool can be used for both good and bad.
I always recommend certificate pinning in order to prevent MITM attacks. I also recommend it if you're backend API gives out a lot of information about your product's "secret ingredient".
That said - certificate pinning can often be bypassed: http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-...
The argument of the European Court of Justice was that car manufacturers also buy cars from competitors, take them apart, and use the gained knowledge on their own products. The same happens in every industry — but in Software Engineering, it should now be forbidden? That's not possible.
If you want to protect yourself from that, publish your secret sauce and patent it.
And you can. There are many ways. Something as simple as 2 socat instances and netsed works great as a quick and dirty but very robust solution. See also sslsplit which will generate certificates on the fly.
Anyone who is telling you that you can place complete trust in the use of x509 certificates on the open internet is either naive or dishonest.
I think you have the right attitude.
If you don't want to use OSes, devices and software that's designed to protect the average user from being hacked, then pick a system which gives you root.
SSL pinned is not an protection for reverse engineering anymore, you may want to add this info on your post.
More info at
I don't think it's FOSS, but hopefully a FOSS alternative will come along and use this approach.
I recommend the experience highly. Just be warned, you may not like what you see.
Disclosure: I'm the developer.
Just a suggestion: I know you mention it in one of the marketing lines, but it might be worth stating that it's for Mac in the headline (or in the download button). Otherwise people like me, who just breeze past the marketing material to the download link, will waste 6.8MB of your bandwidth (sorry about that...)
One terrible idea I just had was creating only one publicly accessible API and then encrypting the actual endpoint in the payload which the server would decrypt and then redirect.
You just reinvented the TLS socket connection.
[1] https://www.charlesproxy.com/documentation/faqs/ssl-proxying...
However, if the phone app uses certificate pinning and SSL it doesn't work. (yes, that means my alarm company doesn't use certificate pinning).
