Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse Engineering Native Apps by Intercepting Network Traffic

nickfishman.com

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#11

Post by MichaelGG »

pki wrote: post #4
coin wrote: post #2

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.

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

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#13

Post by 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.

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#15

Post by Drdrdrq »

bruno2223 wrote: post #7

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

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#16

Post by xuki »

shawkinaw wrote: post #13

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…

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.

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#17

Post by matchu »

shawkinaw wrote: post #13

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…

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.

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#18

Post by fdsaaf »

MichaelGG wrote: post #11
pki wrote: post #4

Earlier quoted context omitted.

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

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

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#19

Post by dkopi »

shawkinaw wrote: post #13

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…

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

That said - certificate pinning can often be bypassed: http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-...

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#20

Post by dkopi »

Drdrdrq wrote: post #15
bruno2223 wrote: post #7

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

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

Here's a few other ways as well: http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-...
Post reply on HN