
Reverse Engineering Native Apps by Intercepting Network Traffic - andrewrice
http://nickfishman.com/post/50557873036/reverse-engineering-native-apps-by-intercepting-network
======
heinrichf
Let us also mention the great mitmproxy, an open source equivalent to the
Charles proxy:
[https://github.com/mitmproxy/mitmproxy](https://github.com/mitmproxy/mitmproxy)
/ [https://mitmproxy.org/](https://mitmproxy.org/)

~~~
bugmenot3
My go-to has always been Fiddler[1] (for windows). I wish it were open-source
though.

I'll give mitmproxy a try. Thanks!

[1] [http://www.telerik.com/fiddler](http://www.telerik.com/fiddler)

~~~
_pmf_
Fiddler is amazing!

------
shawkinaw
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.

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.

~~~
xuki
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.

~~~
mkagenius
That would pretty much beat the purpose, the author of the app doesn't anyone
to snoop.

~~~
cmdrfred
Data generated on my phone belongs to me. By definition I cannot snoop on
myself.

~~~
joosters
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.

~~~
__b__
OK, then how do we separate the data that is his versus data that belongs to
somene else? Maybe we would have to look at what is being sent from the app?

~~~
joosters
Who knows? The two things are unrelated. My comment wasn't anti-reverse
engineering, just stating a fact: just because something is in your phone
doesn't mean it's yours.

~~~
__b__
The parent stated "Data generated on my phone belongs to me."

I interpreted this as "Data generated _by me_ on my phone belongs to me."

The user could agree to license her rights to the data, e.g. via terms and
conditions. But it's still her data. That's why the agreement is necessary.

None of this has anything to do with "reverse engineering".

The scenario I am thinking of is a user looking at her data being sent from
her hardware over an internet connection that she is paying for.

------
bruno2223
There is also a way, on rooted Androids, to sniff SSL pinned Apps.

SSL pinned is not an protection for reverse engineering anymore, you may want
to add this info on your post.

More info at

[https://github.com/ac-pm/SSLUnpinning_Xposed](https://github.com/ac-
pm/SSLUnpinning_Xposed)

~~~
Drdrdrq
+1. Thanks for the link, I didn't know bypassing certificate pinning became so
easy.

~~~
dkopi
Here's a few other ways as well:
[http://blog.dewhurstsecurity.com/2015/11/10/mobile-
security-...](http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-
certificate-pining.html)

------
Mizza
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.

I don't think it's FOSS, but hopefully a FOSS alternative will come along and
use this approach.

~~~
TeMPOraL
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.

~~~
nitrogen
Usually it's just usage analytics, but the potential for abuse is great
because individual data is still sent.

------
aggregator-ios
For those looking for a fully native experience, give
[https://interceptapp.xyz](https://interceptapp.xyz) a try. Currently in
alpha. Feedback is welcome and appreciated.

Disclosure: I'm the developer.

~~~
spangry
Nice, I reckon you're targeting the primary 'benefit' sought by MITM'ers. Most
of my Android MiTM'ing is because I want to get at the data behind the app.
Trying to comprehend some of the crazy, ultra-nested JSON schemas that some
app devs use is a PITA.

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...)

------
ec109685
This article is from 2013. The ssl vulnerability mentioned is no longer
present: [https://www.charlesproxy.com/documentation/using-
charles/ssl...](https://www.charlesproxy.com/documentation/using-charles/ssl-
certificates/)

------
isuckatcoding
What 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.

~~~
ju-st
\- 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

~~~
danielrhodes
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.

------
chillydawg
I wonder how many techies could be silently MITM'd using the Charles root.

~~~
benmanns
I worried about the same thing. Modern versions of Charles use a per-user root
CA that is generated in the client.

~~~
chillydawg
Aha, much more sensible.

------
coin
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.

~~~
pki
At least on Android you can generate a fake VPN-esque connection locally that
passes everything through a proxy, so the proxy isn't exposed to the
application

~~~
MichaelGG
Sure but then the verification will fail since you won't be able to sign the
handshake with the "pin'd" cert. (Assuming they implement TLS or other crypto
in their own code.) If you aren't modifying the execution environment then
it's possible for an app to be "safe".

~~~
fdsaaf
An clever-enough emulator can just lie to an application and say, "You're
running on a stock device. Everything is fine".

~~~
pki
Clever-enough is the key word, with Safetynet involved, which dynamically
executes signed classes and you don't know what checks will be done

------
dirkdk
this doesn't work anymore on iOS apps that use ATS. ATS is enabled by default
and will be required by Apple by the end of 2016

~~~
abalone
Sounds like Charles can work with ATS, just not pinned certs.[1]

[1] [https://www.charlesproxy.com/documentation/faqs/ssl-
proxying...](https://www.charlesproxy.com/documentation/faqs/ssl-proxying-
with-ios-9/)

------
throwaway2016a
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.

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).

------
qq66
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.

------
bytesandbots
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 _the great
MITM_.

------
filleokus
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.

------
msoad
That's what I call debug mode enabled in production. RESTful JSON APIs are
truly in debug mode in production

~~~
Grimes23
What would you recommend in place of RESTful JSON API's?

------
homero
Seems ignorant not to have a unique Charles certificate

~~~
brokenmachine
Apparently modern Charles versions have a unique CA generated by each client.

------
blin17
Did someone just post this guys blog from 2013 up?

