5 ms·

Note that while certificate pinning does make reverse-engineering harder, it's also a legitimate security feature; without it, anyone who controlled a CA (inclu

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.

bby 9y ago
CA?
Drdrdrq 9y ago
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).
- jimmies 9y ago
  Would something like this work as a method to authenticate authentic clients? http://www.cnn.com/TECH/computing/9908/20/aolbug.idg/index.html http://www.cnn.com/TECH/computing/9908/20/aolbug.idg/index.h...
  - dschuler 9y ago
    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.
- saagarjha 9y ago
  On jailbroken devices such an effort would be about as trivial.
- 3pt14159 9y ago
  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.
- adrianmonk 9y ago
  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.
  - userbinator 9y ago
    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."
  - crpatino 9y ago
    > 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.
  - 9y ago
guelo 9y ago
It's funny how all the security measures for "your safety" always seem to reduce user's transparency and control.
- TeMPOraL 9y ago
  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.
- drdaeman 9y ago
  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.
- fjsolwmv 9y ago
  It's the same problem posed by child-proof lids of drug bottles.
bergie 9y ago
I think Android has features for detecting whether the device is rooted. Facebook could then disable spying, in effect Volkswagening the situation
- mscrivo 9y ago
  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.
  - joncrane 9y ago
    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.
- code_duck 9y ago
  If I’m not mistaken, it is common for windows malware to act differently if it is running inside a VM, to avoid analysis.
- pnutjam 9y ago
  Yeah, then you'd be <a href=https://www.urbandictionary.com/define.php?term=munsoned>munsoned.</a> https://www.urbandictionary.com/define.php?term=munsoned>mun...

bby 9y ago

CA?

Drdrdrq 9y ago

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

jimmies 9y ago
Would something like this work as a method to authenticate authentic clients? http://www.cnn.com/TECH/computing/9908/20/aolbug.idg/index.html http://www.cnn.com/TECH/computing/9908/20/aolbug.idg/index.h...
- dschuler 9y ago
  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.
saagarjha 9y ago
On jailbroken devices such an effort would be about as trivial.
3pt14159 9y ago
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.
adrianmonk 9y ago
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.
- userbinator 9y ago
  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."
- crpatino 9y ago
  > 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.
- 9y ago

guelo 9y ago

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

TeMPOraL 9y ago
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.
drdaeman 9y ago
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.
fjsolwmv 9y ago
It's the same problem posed by child-proof lids of drug bottles.

bergie 9y ago

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

mscrivo 9y ago
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.
- joncrane 9y ago
  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.
code_duck 9y ago
If I’m not mistaken, it is common for windows malware to act differently if it is running inside a VM, to avoid analysis.
pnutjam 9y ago
Yeah, then you'd be <a href=https://www.urbandictionary.com/define.php?term=munsoned>munsoned.</a> https://www.urbandictionary.com/define.php?term=munsoned>mun...