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.

2 Answers 2


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.

  • 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, 2013 at 13:00
  • 2
    @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. Mar 10, 2013 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.

  • 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, 2013 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. Mar 10, 2013 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. Mar 10, 2013 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, 2013 at 22:33
  • 1
    @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. Mar 10, 2013 at 22:55

You must log in to answer this question.

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