You can try, but you won't succeed against a dedicated reverse engineer, simply dropping a hook in on the API calls would be enough to grab the decrypted key in a case like that, if not simply statically reading the encryption keys and decrypting it. That's not to say it's useless - some reversers will simply move on to the next app when there's a list of dozens.

You can also send requests via your own server, which would allow you more control over the requests that get sent out to your 3rd party APIs and just restrict tokens as much as possible to the minimal set of features necessary for your application.

What about secure key import on Android? It's still not that widely available, but should be everywhere in a few years. The idea is:

-a keypair is generated in secure hardware

- you send the public key to a server which encrypts the secret key with it

- the server sends the encrypted key back

- then it goes inside the secure hardware where it gets decrypted

The decrypted secret key is never in the userspace.

Mobile developers can implement certificate pinning to prevent man in the middle snooping. Twitter's app does this.

That achieves nothing against someone who uses something like apktool/baksmali to do static RE, let alone inject something like Frida to perform dynamic RE. There are even Xposed modules designed to just bypass certificate pinning.

Certificate pinning is a good security measure, but not a counter-RE one.

Certificate pinning is neither a good security measure nor a good obfuscation one.

I hope you did not just assume that general purpose computing and device ownership can be subverted by mere certificate pinning.

If it's executing on my device, you can be sure I can poke it and see what it's doing.

Frontend is in the hand of enemy. There is no secret on the client side.

You could proxy requests over a server you control. This might just shift your problem, depending on the use case.

Rate-limiting works really well in most cases, though CGNATs makes that a horror nowadays too.

I believe solutions like SafetyNet on Android might help here. AFAIK no one has successfully reversed SafetyNet enough to spoof it.

Please don't legitimize SafetyNet. It is an existential threat to real ownership of your phone as any flavor of Android but that blessed by Google trips SafetyNet. It's the equivalent of barring people from running software on their laptop because they've installed a flavor of Windows that wasn't shipped from the factory. People everywhere have a right to do with their phone what they want to.

I agree with all your points, but what's the reasonable alternative? There is a reason that apps have decided to go with SafetyNet as a requirement. It dramatically reduces abuse.

Unless an API you're looking at requires/supports attestation via SafetyNet or you're willing to proxy via your own server this is likely not an option.

Additionally, while it's true (to my knowledge) that re-implementing a full safteynet spoof is not currently publicly available, a combination of Frida and MagiskHide is able to bypass SafetyNet for dynamic RE purposes, just launch the app as normal with MagiskHide enabled then attach to it with Frida as root. If they enforce full hardware attestation this may change in the future, but right now we're good.