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

61–70 of 76 posts

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#61

Post by mavhc »

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…

A million times as many people are being spied on without their knowledge than want to check their own data though. Not like these things were invented because of users, they were added to stop MITM by governments etc.

If you don't want to use OSes, devices and software that's designed to protect the average user from being hacked, then pick a system which gives you root.

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#62

Post by _pmf_ »

bugmenot3 wrote: post #27
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

Fiddler is amazing!

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#64

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#65

Post by __b__ »

tokenizerrr wrote: post #60
__b__ wrote: post #43

Earlier quoted context omitted.

"I should be able to see what data an app is sending..." And you can. There are many ways. Something as simple as 2 socat instances and netsed works great as a quick and dirty but very robust solution. See also sslsplit which will generate certificates on the fly. Anyone who is telling you that you can place complete trust in the use of x509 certificates on the open internet is either naive or dishonest. I think you…

You should read up on how certificate pinning works. Obviously you can still decompile and recompile the app with different certificates baked in but it's a bit more difficult than what you're implying.

Any device that prevents a user from installing their own CA root cert is not one I would use. I'm not sure if they have started to do this or not.

In terms of protecting users, there's no valid reason the owner of the hardware should not be able to control the list of endpoints that she has already authenticated and is willing to trust.

It would be like if SSH did not allow the user any control over known_hosts or to decide that she will accept or not accept a connection.

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#66

Post by tokenizerrr »

__b__ wrote: post #65
tokenizerrr wrote: post #60

Earlier quoted context omitted.

You should read up on how certificate pinning works. Obviously you can still decompile and recompile the app with different certificates baked in but it's a bit more difficult than what you're implying.

Any device that prevents a user from installing their own CA root cert is not one I would use. I'm not sure if they have started to do this or not. In terms of protecting users, there's no valid reason the owner of the hardware should not be able to control the list of endpoints that she has already authenticated and is willing to trust. It would be like if SSH did not allow the user any control over known_hosts or t…

The entire point of certificate pinning is to ignore the certificates the user installs... Nothing to do with the operating system at all. If the software doesn't want to connect because the wrong certificate is presented to it that's where it ends. You can install as many local roots as you want, it won't change a thing.

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#67

Post by __b__ »

tokenizerrr wrote: post #66
__b__ wrote: post #65

Earlier quoted context omitted.

Any device that prevents a user from installing their own CA root cert is not one I would use. I'm not sure if they have started to do this or not. In terms of protecting users, there's no valid reason the owner of the hardware should not be able to control the list of endpoints that she has already authenticated and is willing to trust. It would be like if SSH did not allow the user any control over known_hosts or t…

The entire point of certificate pinning is to ignore the certificates the user installs... Nothing to do with the operating system at all. If the software doesn't want to connect because the wrong certificate is presented to it that's where it ends. You can install as many local roots as you want, it won't change a thing.

"... it won't change a thing."

So if the user does not want to trust a certificate installed by someone else on the device, she can "revoke" it?

And by the same token if she wants to explicitly trust a certificate, regardless of who installed it, she can do so?

Does the user have control of the process of "trust" or not? The entire point of the device, OS and apps is to benefit the user, not some third party trying to hide data being sent from the device... from the user.

Do you believe a user should be able to "MITM" her own traffic or not?

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#68

Post by tokenizerrr »

__b__ wrote: post #67
tokenizerrr wrote: post #66

Earlier quoted context omitted.

The entire point of certificate pinning is to ignore the certificates the user installs... Nothing to do with the operating system at all. If the software doesn't want to connect because the wrong certificate is presented to it that's where it ends. You can install as many local roots as you want, it won't change a thing.

"... it won't change a thing." So if the user does not want to trust a certificate installed by someone else on the device, she can "revoke" it? And by the same token if she wants to explicitly trust a certificate, regardless of who installed it, she can do so? Does the user have control of the process of "trust" or not? The entire point of the device, OS and apps is to benefit the user, not some third party trying t…

> Do you believe a user should be able to "MITM" her own traffic or not?

I do, but that is utterly irrelevant to this discussion. We are discussing what certificate pinning is and how it works.

You can currently perform certificate pinning on every single operating system you can imagine. You can do this in a way that completely ignores the trust store of that operating system, and anything the user does to this is ignored by the application.

This has been possible for years on Android. This has been possible for years on Windows. This has been possible for years on Linux.

All the developer has to do is include the certificate of their own CA with the application, restrict the SSL's trust store to this one certificate, and then also check the fingerprint of the resulting certificate offered by the server. Then if the application notices this fingerprint is incorrect, it bails.

This is reality. This is how it works. Nothing I believe or want will change this. No amount of certificates I install in my operating system's trust store will change this either.

What android is doing is making MITMing yourself harder. But it's always been 100% possible for developers to make MITMing impossible without first reverse engineering the app and replacing the baked in certificate.

That's just the way it works.

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#69

Post by pki »

fdsaaf wrote: post #18
MichaelGG wrote: post #11

Earlier quoted context omitted.

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

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

Re: Reverse Engineering Native Apps by Intercepting Network Traffic

#70

Post by __b__ »

tokenizerrr wrote: post #68
__b__ wrote: post #67

Earlier quoted context omitted.

"... it won't change a thing." So if the user does not want to trust a certificate installed by someone else on the device, she can "revoke" it? And by the same token if she wants to explicitly trust a certificate, regardless of who installed it, she can do so? Does the user have control of the process of "trust" or not? The entire point of the device, OS and apps is to benefit the user, not some third party trying t…

> Do you believe a user should be able to "MITM" her own traffic or not? I do, but that is utterly irrelevant to this discussion. We are discussing what certificate pinning is and how it works. You can currently perform certificate pinning on every single operating system you can imagine. You can do this in a way that completely ignores the trust store of that operating system, and anything the user does to this is i…

"What android is doing is making MITMing yourself harder."

That's not good for users.

I do not rely on Android, Windows or Linux. Not really much an app user either.

But if I were a user of these systems I would avoid apps where the user is not allowed to see what is being sent. Irrespective of any justifications put forth. By a company that relies on collecting personal information and selling advertising to make money.

Post reply on HN