[arsome]

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.

[gligorot]

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.

[powvans]

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

[arsome]

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.

[saagarjha]

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

[feanaro]

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.