Let us also mention the great mitmproxy, an open source equivalent to the Charles proxy: <a href="https://github.com/mitmproxy/mitmproxy" rel="nofollow">https://github.com/mitmproxy/mitmproxy</a> / <a href="https://mitmproxy.org/" rel="nofollow">https://mitmproxy.org/</a>
Wow, this guy has the completely opposite attitude of me. He seems to think it's a bad thing, an attack!, for users to see just what the hell data you're pulling off someone's phone. And, bizarrely, uses an example of an app that essentially stole data from its users.<p>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.
There is also a way, on rooted Androids, to sniff SSL pinned Apps.<p>SSL pinned is not an protection for reverse engineering anymore, you may want to add this info on your post.<p>More info at<p><a href="https://github.com/ac-pm/SSLUnpinning_Xposed" rel="nofollow">https://github.com/ac-pm/SSLUnpinning_Xposed</a>
I had to do this recently and found a great tool for Android for sniffing traffic on the device called Packet Capture. It can even sniff SSL without root permissions by installing a self-signed certificate and running an in-app local VPN proxy. It also had a bunch of other nice features like parsing common protocols, showing the good bits of HTTP, etc. Much nicer than the approach described here (this article is from 2013), although it's certainly only for Android folk.<p>I don't think it's FOSS, but hopefully a FOSS alternative will come along and use this approach.
For those looking for a fully native experience, give <a href="https://interceptapp.xyz" rel="nofollow">https://interceptapp.xyz</a> a try. Currently in alpha. Feedback is welcome and appreciated.<p>Disclosure: I'm the developer.
This article is from 2013. The ssl vulnerability mentioned is no longer present: <a href="https://www.charlesproxy.com/documentation/using-charles/ssl-certificates/" rel="nofollow">https://www.charlesproxy.com/documentation/using-charles/ssl...</a>
What are some other ways to prevent people from discovering your API endpoints?<p>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.
Isn't it possible for apps for ignore the OS's proxy settings and make a direct TCP connection? In that case the proxy man-in-the-middle trick won't work.
I'm pretty heavy into home automation and I use this technique all the time to learn how to control various walled garden home automation systems. Even worked with my Alarm company's system.<p>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).
Is there any scenario where snooping on the upstream network connection can give you valuable reverse engineering information? Because of latency/reliability issues, most mobile apps have pretty simple and stateless protocols with the server.
On android, this only works when the app is using http urlconnection provided by java. If the app uses apache http stack, the request is not routed through the proxy settings. Such traffic will not showup in charles or <i>the great MITM</i>.
Even on iOS it's possible to bypass certificate pinning by using a jailbroken device and tool. I wouldn't say that's a good meassure against reverse engineering.