4 ms·

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

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

xvector 4y ago
"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.)
dangero 4y ago
You should check out Apple App Attest —- this just isn’t true any more for mobile. https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server https://developer.apple.com/documentation/devicecheck/valida...
- Matheus28 4y ago
  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.
  - btown 4y ago
    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.
    - Matheus28 4y ago
      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.
      - origin_path 4y ago
        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.
        Nextgrid 4y ago
        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.
        origin_path 4y ago
- a_t48 4y ago
  Does still this work on jailbroken phones where you can let apps modify the memory of other running apps (ala CheatEngine)?
- d110af5ccf 4y ago
  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.
rootw0rm 4y ago
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

xvector 4y ago

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

dangero 4y ago

You should check out Apple App Attest —- this just isn’t true any more for mobile. https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server https://developer.apple.com/documentation/devicecheck/valida...

Matheus28 4y ago
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.
- btown 4y ago
  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.
  - Matheus28 4y ago
    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.
    - origin_path 4y ago
      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.
      - Nextgrid 4y ago
        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.
        origin_path 4y ago
a_t48 4y ago
Does still this work on jailbroken phones where you can let apps modify the memory of other running apps (ala CheatEngine)?
d110af5ccf 4y ago
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.

rootw0rm 4y ago

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