If you’re writing native / JNI code for Android, it’s probably as native method of an Android app. These methods are always passed the Dalvik VM instance of the app as the first parameter. You need this to create
jstrings and other Java objects, lookup classes and fields, etc. It’s not normal for you to have to instantiate a VM from native code because most of the time, if you’re using the Java Native Interface (JNI), you started in Java land and are only dipping into native code land for them sweet, sweet performance benefits. However, if you’re reverse engineering or writing an exploit, you’re likely always delving int all kinds of unusual trouble which the developers reasonably believed would never happen or at least would only be a theoretical edge case.
I recently needed to create a VM from native code to pass Java object arguments to a JNI function. In this post, I want to share what I came up with and why I finally settled on this particular method.
The official, standard method is documented here: How to Create a JVM Instance in JNI. Unfortunately, this won’t work in Android because
jint JNI_CreateJavaVM(JavaVM**, JNIEnv**, void*) isn’t exported. Even if you’re not familiar with this function, it’s name should be a clue that it’s important. If you want to check if it’s not exported yourself, look at
jni.h from your Android NDK directory. In my case, it’s in
android-sdk/android-ndk-r13b/platforms/android-9/arch-x86/usr/include/jni.h. The relevant code is:
If you try to compile the code, you’ll probably get an error like this:
The official documentation is still useful for understanding the API and what all those options and arguments do. But if we want to use this on Android, we’re going to have to explicitly load the necessary methods from some library.
One useful detail this code shows is how to set the VM’s class path. Here’s how it’s done:
This sets the class path to the current directory (
.). This is needed if you want your VM to access system or app classes. Some early experiments show that setting to a directory doesn’t seem to work. I tried setting to
/data/local/tmp and pushing naked DEX files, as well as a JAR containing DEX files and the app’s APK. The only option that worked was setting the full path to either the JAR, DEX, or the APK. What was odd is that system classes (i.e.
java.lang.String) were not accessible without having at least one valid file in the class path. In other words,
(*env)->FindClass(env, "java.lang.String") returns
0 unless there’s at least one file on the class path, even though
java.lant.String is defined in the framework.
To test yourself, push an APK to the emulator or device:
Use this for your
You should now be able to use
FindClass to load system and app classes.
And if you need to load native libraries in your VM, such as if you load a class which loads a library in it’s static initilzer, you can see that path as well with
optionString = "-Djava.library.path=/data/local/tmp". There’s an example here.
I won’t claim to fully understand what it’s doing, but the interesting part to me is in
get_transation_code. Here’s what it does:
- creates a Java VM
- use the VM to get reference to
- get the
- destroy the VM
- return field value
It looks like the field value is used to check if the device is already unlocked or perhaps to check if the unlock method will work. I’m not sure. I just wanted to rip out the code to create the VM.
The approach seemed sound: load the relevant VM creation functions by through
libdvm.so as a backup. However, there were a few lines in there that looked weird:
I couldn’t find these functions documented anywhere. Someone really clever figured these out (kudos!). Without calling these functions, you get some weird errors:
Despite these weird functions, this approach totally worked for me. But I wanted to understand what the
_ZN13JniInvocationC1Ev functions did and if they were portable between Android versions. My gut told me that hardcoding that many function names which also included numbers could lead to incompatibilities in some devices or in later Android versions.
I eventually found code from Google’s Surfaceflinger service: DdmConnection.cpp.
This defaults to looking for
libdvm.so. Instead of calling
_ZN13JniInvocation* methods, it looks like it calls
libandroid_runtime.so. The behavior of
registerNatives is described well here.
Also interesting are the options used to create the VM:
These options are well documented here and according to the documentation, this just allows for debugging of the JVM. Seems pretty standard.
I noticed the JNI version was 1_4, but I bumped it up to 1_6 because that’s what’s used in the example code here. Here are the supported versions from
I ended up using this approach since I figured it’s the most robust and future-proof because it comes from Google.
Here’s the final code to create the VM:
Here’s how it’s used:
Now you have everything you need to instantiate a Java VM from native code. You should also have a decent understanding (or at least links to documentation) about some of the options available to you. To see a practical application of this technique, check out Calling JNI Functions with Java Object Arguments from the Command Line.