I 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.
Aha, much more sensible.
Reverse Engineering Native Apps by Intercepting Network Traffic
41–50 of 76 posts
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#42Earlier quoted context omitted.
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.
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?
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#43Wow, 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 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 have the right attitude.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#44Earlier quoted context omitted.
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.
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?
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.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#45Wow, 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…
It's not an uncommon attitude, and it's also one I detest --- many articles about "security" have some authoritarian/paternalistic aspects to them. Then again, encouraging ignorant users is the easiest way to monetise, analyse, and otherwise manipulate them... and if this ignorance is a convenient byproduct of arranging things so "it's for your security" ostensibly, all the better.
The obligatory related link: https://www.gnu.org/philosophy/right-to-read.en.html
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#46What 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.
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.
You just reinvented the TLS socket connection.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#47Earlier 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.
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)
This is already a reality. There are at least 5 banking apps I can think of that statically link OpenSSL and use that instead of OS crypto.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#48What 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
Don't use a static key. At least use DHE or ECDH to negotiate the key.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#49Earlier quoted context omitted.
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?
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.
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.
Re: Reverse Engineering Native Apps by Intercepting Network Traffic
#50Is 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.