1

I do check sum of classes.dex in native code as indicated here: Check .apk-signature in C/native Code

  1. Calculate checksum of classes.dex
  2. compare with hardcoded value - xxx
  3. if it's true, pass and go on
  4. if it's not true, exit the app

What I do is log the checksum value for the first build, then change the if (checksum == xxx) in native code to be the same as the logged value.

However, with using Dexguard, the checksum is different for every different build, means that if I change xxx, and generate the signed apk again, the check will always be false. I think Dexguard generate something random into the classes.dex that makes every build different.

Any ideas to get around this problem ? Thanks

Community
  • 1
  • 1
John
  • 2,672
  • 2
  • 23
  • 29

1 Answers1

0

Every DEX file includes two checksums: an Adler32 and a SHA-1 signature. The former is used as a quick check for file corruption, the latter to uniquely identify the file contents. IIRC, the optimized (.odex) file updates the file checksum but retains the SHA-1 signature.

If your goal is to identify when the classes.dex contents have been changed by the build system, you should use the SHA-1. If you are attempting to create some sort of tamper-resistance, then you may need to change the way you go about embedding the checksum. For example, you could store it in an array of bytes that begins with a unique pattern, and just edit the file directly (recomputing the Adler32 afterward).

fadden
  • 51,356
  • 5
  • 116
  • 166
  • Thanks fadden. By editing the file directly, you mean editing the generated signed apk file directly? Converting the file into byte array, iterate through the bytes, look for the unique pattern, after seeing the unique pattern, embed the bytes that matches the checksum? Is that what you mean? – John Jul 15 '15 at 18:16
  • You would need to make changes *before* signing it, but yes, that's the basic idea. – fadden Jul 15 '15 at 20:14