Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a way to somehow 'protect' a native shared library (.so) for the Android platform against binary changing? E.g. someone could overwrite a JMP instruction with a NOP after reverse engineering the application, and distribute that library to rooted devices.

Is there anything someone can do?

What I'm looking for here is ideas about implementing a series of checks (e.g. encryption, checksumming etc). Of course since the platform does not look like it offers support for this (correct me if I'm wrong) it would have to be all 'client-side'. Thus the whole thing is a bit futile, but at least will hinder reverse engineering some.

share|improve this question

No. There's no way to do this securely, in a way that will resist serious dedicated attack: the owner of the phone will be able to modify the copy of the library that is stored on their phone. Once rooted, it's their phone, after all.

You're basically asking for software that is resistant to reverse engineering. We have extensive experience (based upon copy protection, digital rights management, and other schemes) showing that while you can make reverse engineering a little harder, you can't prevent it.

Why do you want to prevent the owner of the phone from modifying their own code? Maybe there are other solutions to your problem.

share|improve this answer
Thank you for your answer D.W., but this is not what I'm looking for. As is evident by the question, I understand the limitations of this approach, and I'm not looking at something that is 'resistant' to reverse engineer the way DRM might be. I'm looking to hinder it, to stall it, to make it harder. This is achievable by consuming the reverse engineer's time, making him bypass one more check before he can do anything else useful. – AnroidSec Mar 10 '13 at 13:00
@D.W.: "it's their phone, after all": that's the gist of the thing, but I would alter that into: "once rooted, it's their phone, after all". A non-rooted phone is more like shared guardianship, or a rented flat. – Thomas Pornin Mar 10 '13 at 15:51

If someone has root access to the Android device, they can not only install alternate versions of libraries, but also install alternate versions of your integrity protection system.

(Not unless it becomes common to leverage TPMs (which don't exist on ARM platforms at the moment) or TrustZone (which is present on almost all mobile phones but rarely used), and Android becomes a closed system like iOS and Windows RT.)

If you're worried about users unwittingly installing malicious third-party add-ons that would replace system libraries, the only real defense is user education. Nonetheless, you can install your own add-on requiring root permissions that checks the integrity of the kernel and of libraries you depend on. This is by no means a real protection. It's a form of anti-virus: it protects only against known attacks, not against unknown implementations of the threat.

share|improve this answer
This answer is on a completely different threat model than the one I described, isn't it? What I am interested is protecting my library against tampering from reverse engineer. I know it is futile, but any step taken to make reverse engineering slower is a step towards the right direction. So, what I am interested is how to go about implementing a checksum of the library by the library itself - or if something like that is already offered by the OS or if there are instructions on how to do it or even better ideas. That's all :) – AnroidSec Mar 10 '13 at 21:14
@AnroidSec Oh, then I misread your question. On second reading, I still think your question is about protecting the integrity of the shared library, with the possibilty of its reverse engineering not in question. Verifying a checksum does not do anything to protect against reverse engineering: all it does is protect against the replacement by another version. – Gilles Mar 10 '13 at 22:07
@AnroidSec If you want to protect against reverse engineering, you need to either make the code confidential (not possible, it'll be distributed in cleartext, because the device needs to be able to execute it) or obfuscate it (which almost always costs far more than it could ever gain you). And obfuscating the code doesn't protect against someone replacing the library with one that's good enough to run your application, albeit with a different behavior — which is what you seem concerned about. – Gilles Mar 10 '13 at 22:07
the code is already obfuscated. As I mentioned before, I'm looking to implement some kind of integrity protection so that the library cannot be patched e.g. using a hex editor. I fully understand that this is futile in the end - an I fully understand that the best I can do is hinder the process. I am looking to maximize this, hinder the reversing process as long as possible. The threat scenario you describe (replacing the library with another) is something different, and something I am not interested in at all. I own the library, not the application. – AnroidSec Mar 10 '13 at 22:33
@AnroidSec If someone overwrites a JMP with a NOP, and the library still does anything useful, then your obfuscation isn't good enough. Integrity prevents people from using the modified library, but not from modifying it and using the modified version elsewhere. Obfuscation prevents people from modifying the library and having it still do something useful. Confidentiality would prevent people from getting your code, let alone modify it, but your only option there is not to distribute the library. – Gilles Mar 10 '13 at 22:55

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.