I wonder how many techies could be silently MITM'd using the Charles root.
Reverse Engineering Native Apps by Intercepting Network Traffic
31–40 of 76 posts
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#32Did someone just post this guys blog from 2013 up?
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#33Wow, 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. 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…
While the privacy concerns are more than valid, reverse engineering is common practice in trying to copy your product. 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".…
Reverse Engineering to copy is even considered a legal tool in the EU.
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.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#34Wow, 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. 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…
Certificate pinning does prevent an important class of MitM attacks, though. 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.
Android Nougat disabled that — now it will not accept user-added CAs anymore, anywhere, ever.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#35Earlier quoted context omitted.
I agree. Cert pinning is fine but there should be an option to disable it (maybe system-wide) for people who want to analyze traffic.
That would pretty much beat the purpose, the author of the app doesn't anyone to snoop.
Except you can with a jailbroken phone. Never trust the client, ever.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#36That's what I call debug mode enabled in production. RESTful JSON APIs are truly in debug mode in production
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#37I 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…
I've been using Packet Capture to get some data I wanted out of an app recently and in the process I started generally snooping around. What I saw disgusts me. First, just how much waste there is in communication - so many requests with so much JSON traffic for no real reason (except maybe laziness). Second - just how much various apps report on you. I've seen everything I could possibly imagine the phone could know about me and my operator sent to the various "motherships", sans actually transcribing my contact lists and messages. I'm not even going to ask what they do with this data.
I recommend the experience highly. Just be warned, you may not like what you see.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#38What are some other ways to prevent people from discovering your API endpoints? 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.
- encrypt everything using AES and pray that nobody will find the key in the apk - use your own crooked Http implementation that violates the official specs (e.g. missing \r\n's or introducing random whitespace characters...). Simple http parsing tools won't work anymore and the attacker will get grey hairs when he tries to test/use your endpoints
Just a heads up that changing the HTTP protocol can break a load balancer. Experienced this one time while using Amazon's ELB: the response had invalid HTTP and the ELB instances would silently lock up and stop responding, eventually draining the pool. Was not fun to debug.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#39Earlier quoted context omitted.
That would pretty much beat the purpose, the author of the app doesn't anyone to snoop.
Data generated on my phone belongs to me. By definition I cannot snoop on myself.
That's what you'd like to think, but the numerous terms & conditions that you've agreed to for your apps means that you're wrong, some data isn't yours.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#40I wonder how many techies could be silently MITM'd using the Charles root.
I worried about the same thing. Modern versions of Charles use a per-user root CA that is generated in the client.