Hacker News Reader

Comment by amatecha | Hacker News Reader

If you've ever worked on an online service, you might realize that what you ship for the client is almost irrelevant -- it can all be reverse engineered and an unofficial client can _always_ be created. This happens for all online services, even if it's just someone's data-mining app running on a local machine. The number one rule is "never trust what comes from the client", because it's trivial to create carefully-crafted network calls to basically do whatever the API allows (and sometimes more than what was supposed to be allowed).

So, obviously 3rd party clients are thus able to perform malicious acts, but existing laws already forbid this.

My suggestion to ensure 3rd party clients are always legally permitted isn't mutually exclusive with existing laws protecting the creators of services and software. :)

View on HN

You should check out Apple App Attest —- this just isn’t true any more for mobile.

https://developer.apple.com/documentation/devicecheck/valida...

I haven't read it thoroughly, but given the App Attest service runs on the OS, why can't someone just find the certificate for it hidden somewhere and use that to sign fake attests in userland? This is just an extra layer of obfuscation. It doesn't prevent someone from faking api calls with no app (or phone) involved.

Given that this only runs on certain Apple hardware, I wouldn’t be surprised if the Secure Enclave holds that certificate and can confirm at an extremely low level that it is being used only to sign a hash of of the app code itself and a shared secret with the app developer.

Brilliant, in a scary way. In a way it makes data portability regulations all the more important.

From my quick reading of the docs:

It generates a public-private key pair that is stored in the secure enclave, then it sends that public key (or the hash maybe) to Apple for them to sign. The rest of the stuff is as you expect.

One could simply figure out how the request to apple is made to get them to sign a key, and that's that. Get them to sign a key and pretend to be the app from now on.

I guess this prevents spam from someone signing thousands of keys using a specific phone's serial number, though. Assuming there's an unique public-private key for each phone apple makes, one can't simply get them to sign keys with random serial numbers.

The way these schemes usually work is that the pairing is done at the factory. Apple switch the iPhone on for the first time as it's being made, it generates a private key that never leaves the secure chip and then presents the public key. The public key is then signed to create a certificate chain and the certs handed back to the device for storage.

So, there's no way to beat it except by extracting a private key, or by using some software exploit to confuse it into signing the wrong thing.

You don't need to extract the private key though, just use it to sign things. So if you have shell access on the phone, you can tell the SE to sign the request you want.

Only to some extent. Apple work very hard to prevent that from being possible, and it's not necessarily signing just anything the app processor sends. Usually this stuff is integrated with the bootup process.

It isn't true for iOS devices, perhaps. I refuse to run an OS that supports such nonsense. Right now a custom Android rom is sufficient. In the future I expect I'll be moving to one of the Linux distros once they have better support for mobile.

Does still this work on jailbroken phones where you can let apps modify the memory of other running apps (ala CheatEngine)?

"Never trust the client" is true, but in practice, some control over the client still helps reduce abuse if you make third party clients a lot harder (eg remote attestation.)

back when MechWarrior Online was still pretty new, I reversed the login app (100% .Net, very little obfuscation) which allowed me to access test servers that were testing an unreleased map. Fun times

Reply on news.ycombinator.com