We have a client that runs some native (C++) code on both Android and iOS, to mitigate MITM attacks we use certificate pinning.

This means that the binary includes some strings (const char * const bla = "XXXXXXXXXX") that identify the allowed certs to enable HPKP.

Some are worried that nefarious users will easily identify those strings because they look like SHA256 and are passed to relevant functions, replace them and analyze the traffic.

  • Would it make it objectively harder if we obfuscated those strings in compile-time and then de-obfuscate them at run-time?
  • Would it make it worse because now instead of being in R/O memory (Speculation... I know... it's not required by the standard but it makes a lot of sense) we just read it at run-time from some regular object?
  • 2
    If you do that, what's to stop an attacker from dumping it out of memory? Or hooking the functions used to verify certificates? There are frameworks out there to do this on Android. Basically, this goes back to the issue that once you distribute something in an app, everything on the client side will be available to the attacker. Aug 8, 2019 at 0:04
  • @multithr3at3d By "that" you refer to obfuscation ? Aug 8, 2019 at 0:26
  • yes, basically whatever you do Aug 8, 2019 at 0:34
  • 2
    Ask Niantic how they managed to deter people deobfuscating hidden data on Pokemon-Go... They couldn't... You give some secret to an enemy, it's not secret anymore...
    – ThoriumBR
    Aug 8, 2019 at 1:00
  • 2
    You're trying to solve the wrong problem. If someone has enough access to the device to edit your app's memory, they don't need to MITM the connection, as they can just steal the secrets directly that way. Instead of chasing this red herring, you should re-architect your app to not store any data on the client that you don't want the user to have full control over. Aug 8, 2019 at 20:25

1 Answer 1


I would like to extend Joseph Sible's comment and build upon it.

There is a rule in Information Security, called "Never trust the client!", and it holds true so far. In your case, the client is the application on the phone of the attacker. The attacker has full access to the phone, and can modify it in any way they would like. This includes, but is not limited to:

  • Debugging the application at runtime
  • Analyzing the memory of the application
  • Modifying the executable
  • Emulating a runtime for the executable to see the System Calls the application does
  • Analyzing the network traffic

Basically, as soon as any data is sent to the client, you have to assume that the user will find it and get access to it in some way. How do we know? Because what you are trying to replicate is some form of DRM - also known as "Digital Restrictions Management". DRM essentially aims at giving users some form of access to content, but not any form the user likes.

This has proven, time and again, to fail. In fact, the most enthusiastic and restrictive forms of DRM are those that hurt customers the most, and are those that get cracked the quickest.

You still have not answered why exactly users getting access to the internals of your application is bad, but I am going to assume that your application stores some data there that you don't want them to access, or only want to access in limited amounts.

If it's information they don't need access to, then move them onto a server and not the app. And if it's information that you want your users to have access to, then give it to them. Sooner or later, they'll take it anyways.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .