Jakob Bjerre Jensen
Jakob Bjerre Jensen

Reputation: 429

Verifying Android odex-file programmatically

Is it possible to verify the integrity/checksum of the system-generated odex-file programmatically?

I wonder how to detect, if an attacker on a rooted Android phone installs his own version of the odex file for an application.

Upvotes: 3

Views: 3705

Answers (1)

fadden
fadden

Reputation: 52343

The assumption is that, if an attacker is able to replace a .odex file, they have sufficient permission to do any number of other things.

The build-generated odex files live in a protected directory on /system, which is mounted read-only. Anyone able to modify those files could simply hack the VM or replace major parts of the system.

The installd-generated odex files live in /data/dalvik-cache, and are protected by filesystem permissions. Anyone with permission to modify a .odex file would be able to do all sorts of things, like reinstall applications while you're not looking. This would be a better approach for an attacker, since it would survive an OTA update (which causes a re-dexopt).

Modifying optimized DEX data in place is doable but kind of a pain. The advantage of doing so over replacing an app is that it's more subtle -- to reinstall an app you either need the original signing key, or hope that the user doesn't realize they're now running an app with the same name but a different signer.

So, the .odex file has a checksum you can look at in case you doubt the integrity of the filesystem, but no provision to check for tampering other than re-executing dexopt and comparing before & after.

General info about dexopt and odex is available in the Android sources in dalvik/docs/dexopt.html; a nicely formatted version is available here.

Edit: I should mention that the DEX and ODEX files do have checksums stored in the file headers. These are usually ignored because, for performance reasons, you don't want to go scanning through the entire file every time you launch an app. You can enable mandatory checksum verification by setting the dalvik.vm.check-dex-sum property to true (or pass -Xchecksum on the command line).

The checksums are intended to detect file corruption, not deliberate alterations. (You can use dexdump -c to scan manually.) Someone tampering with the file could just recompute a valid checksum and store it, so you'd need to save a known good copy elsewhere. And you'd want to use SHA1 or similar rather than adler32 to make it harder to manipulate the binary to get the same checksum value.

Upvotes: 6

Related Questions