Hacker News Reader

Comment by jimrandomh | Hacker News Reader

Note that while certificate pinning does make reverse-engineering harder, it's also a legitimate security feature; without it, anyone who controlled a CA (including most major governments) would be able to forge a certificate and use it to spy on users.

Certificate pinning is a hurdle to reverse engineering, but a surmountable one, at least on Android. Since the app is running on a phone where you may potentially have root, you can pick it apart with a debugger and see the traffic before it leaves the phone. This is technically challenging, but it is something that people do sometimes.

View on HN

Or you can find and replace CA file/string with your own and then do mitm. There is virtually no way app developers can defend against such hacks on any platform owned by user (so, everywhere except on Apple devices).

Would something like this work as a method to authenticate authentic clients?

http://www.cnn.com/TECH/computing/9908/20/aolbug.idg/index.h...

Paraphrasing the article, it would be for the server to use undefined behavior in the _authentic_ clients to determine that they were in fact authentic. In this case, a buffer overflow doesn't appear to crash the client, but lets the server know that it's talking to a legitimate client. That's quite clever.

On jailbroken devices such an effort would be about as trivial.

It's more annoying than you'd think if your adversary anticipates this and designs around it. Fragments of the CA can be used within the codebase, effectively making you need to pull everything apart and with security canaries and embedded interpreted scripts even if you're getting close you never know if you're still black and if you're still seeing the same thing as everyone else.

Well, it turns into a reverse engineering arms race at that point. There's no way they can guarantee anything, but they can throw resources at obfuscating things more.

If you're the reverse engineer and I'm the app author, you find/replace my CA file. Then I respond (or anticipate!) by checksumming the file to detect tampering. Then you respond by find/replace on the checksum.

Then I obfuscate the checksum string. Then you respond by faking out the platform's checksum API so that it always returns true. Then I respond by computing a checksum that I know should fail and verifying that the checksum API isn't just always returning true. Then you respond by faking out the platform checksum API with a whitelist of blobs whose checksum it should lie about.

Then I respond by statically linking my own checksum verification code into my binary instead of calling the platform's. Then you respond by patching my binary to jump around the code. Then I respond by using code obfuscation techniques.

And on and on. Given enough time and resources, any implementation I create can be subverted. But if I'm a huge tech company, I can afford a lot of time and resources too, if I want to. I can't eliminate it, but maybe I can make it something that rarely happens.

But if I'm a huge tech company, I can afford a lot of time and resources too, if I want to. I can't eliminate it, but maybe I can make it something that rarely happens

The whole cracking scene can afford far more time and resources than any one tech company. All adding protections does is make a more valuable target, because crackers love a good challenge.

"There's always a crack in everything. It's how the light gets in."

> But if I'm a huge tech company, I can afford a lot of time and resources too,

Can? Sure! Would?

Security is one of those things that most people say they care about, but they are really not willing to pay for. Big companies have resources, but they are also in the business of making money, so they will put most of those resources to work on features that produce a ROI. Security is a huge cost center, and even when taken seriously it will be pursued only to the degree that it addresses/mitigates risks enough to conduct business.

Not really. A skilled reverse engineer does not find/replace any certificates, or anything like that. They just debug the app, stepping over all the code, instruction by instruction. There's no way you can beat that. I'm a malware reverse engineer - I work with this kind of stuff every day. And I'm pretty sure there's no 'game': once the binary is in my disassembler, it's over.

I think Android has features for detecting whether the device is rooted. Facebook could then disable spying, in effect Volkswagening the situation

Magisk (Android root utility) has the ability to hide itself very well. Google Pay and most, if not all, banking apps are not able to detect it. It is a cat and mouse game for sure, but so far the Magisk developers are keeping ahead of that curve.

Wasn't the most active development on Magisk from when Pokemon Go was really big? I remember there being an arms race with Niantic at some point.

If I’m not mistaken, it is common for windows malware to act differently if it is running inside a VM, to avoid analysis.

Yeah, then you'd be <a href=https://www.urbandictionary.com/define.php?term=munsoned>mun...

It's funny how all the security measures for "your safety" always seem to reduce user's transparency and control.

It's an unfortunate feature of reality.

From the point of view of software, it's impossible in principle to tell whether or not the code being executed does what the user wants it to, and only what the user wants it to. Half of that is the halting problem, the other half is that "what user wants" is an General-AI-complete problem. Moreover, the software can't even tell the difference between "the user" and "a malicious third party".

In meatspace we solve this problem with rules and laws. Software, for better or worse, moves around too fast.

Not really.

I gave it a thought, and decided I don't need apps to be able to obtain highly elevated privileges, root or similar. This is, indeed, dangerous, esp. regarding ADB root access (a rogue "charger" + an accidental wrong tap[1] = totally compromised device that can be only fixed by full re-flashing). I needed my own firmware that does things my way, signed with the keys I control.

So I did. Now all the "secure" apps are happy, and I still have the control over my device's behavior.

( Okay, I've cheated - I had to sanitize androidboot.verifiedbootstate when kernel initializes, because I can't control the bootloader :( )

[1] Hm, maybe password-authenticated root access is okay, though... But not a typical "tap to allow" dialog.

It's the same problem posed by child-proof lids of drug bottles.

Reply on news.ycombinator.com