Reverse-engineering the Starbucks ordering API
Solid writeup. From someone who does/did a lot of this professionally:<p>1. Android typically <i>is</i> easier for this kind of work (you don't even need a rooted/jailbroken device, and it's all Java/smali),<p>2. That said, instead of installing an entire framework like Xposed that hooks the process to bypass certificate pinning, you can <i>usually</i> just decompile the APK and nop out all the function calls in the smali related to checking if the certificate is correct, then recompile/resign it for your device (again, easier on Android than iOS),<p>3. Request signing is increasingly implemented on APIs with any sort of business value, but you can <i>almost always</i> bypass it within an hour by searching through the application for functions related to things like "HMAC", figuring out exactly which request inputs are put into the algorithm in which order, and seeing where/how the secret key is stored (or loaded, as it were),<p>4. There is no true way to protect an API on a mobile app. You can only make it more or less difficult to secure. The best you can do is a frequently rotated secret key stored in shared libraries with weird parameters attached to the signing algorithm. To make up for this savvy companies typically reduce the cover time required (i.e. change the secret key very frequently by updating the app weekly or biweekly) or by using using a secret key with several parts generated from components in .so files, which are significantly more tedious to reverse.