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

21–30 of 76 posts

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#21

Post by pilif »

xuki wrote: post #16
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.

disabling system-wide is pretty much impossible. If OSes added such a toggle, people would start using their own SSL stack and overall security would suffer (because people won't be keeping their SSL stacks up to date)

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#22

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#25

Post by abalone »

dirkdk wrote: post #12

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

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

[1] https://www.charlesproxy.com/documentation/faqs/ssl-proxying...

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#27

Post by bugmenot3 »

heinrichf wrote: post #23

Let us also mention the great mitmproxy, an open source equivalent to the Charles proxy: https://github.com/mitmproxy/mitmproxy / https://mitmproxy.org/

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#28

Post by mkagenius »

xuki wrote: post #16
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.

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#29

Post by ju-st »

isuckatcoding wrote: post #22

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.

- 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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#30

Post by cmdrfred »

mkagenius wrote: post #28
xuki wrote: post #16

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

Data generated on my phone belongs to me. By definition I cannot snoop on myself.
Post reply on HN