10

One of the things that makes Java bytecode (.class) so easy to reverse engineer is that the JVM's verifier ensures that bytecode can always be disassembled via linear sweep. Instructions have to be consecutive starting at offset 0, and you can't jump into the middle of an instruction.

However this post implies that Dalvik does not do such bytecode verification. The authors do all the usual x86 shenanigans like jumping into the middle of an instruction, which is apparently allowed. Is this true? Do Android VMs actually perform any kind of loadtime bytecode verification? If not, why?

11

this is not entirely true. Dalvik bytecode will also be verified on the device, but this happens during installation time, not runtime. A verified and optimized version of the dex file will be stored on the system, protected by file system permission (you cannot change it afterwards unless you have rooted your device).

The trick that was used in the blog post is that you can set a specific flag within the class header which tells the verifier to skip this class.

9

Android also contains bytecode verification but this step is moved from class loading on the device to the dex compiler (as it is similarily done in J2ME).

Alter dexing your class files (and before packaging to an .apk file) you can modify the files and introduce the referenced obfuscation.

So at loading time no further verifcation is done.

Specification of the dex compiler.

The verification of the bytecode at load time is removed to enhance the loading time (the same reason as this is done in J2ME).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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