Android Runtime Restrictions Bypass

The soinfo structure

All loaded libraries are tied to a structure that contains metadata regarding the context in which the library has been loaded. This structure — named soinfo — registers various information like:

• The name of the library (e.g. libc.so)

• The path to the library (e.g. /system/lib64/libc.so)

• The base address choose by the ASLR (e.g. 0x7f13e09a5000)

• The Namespace(s) associated with the library.

• ...

This structure is defined in linker/linker_soinfo.h as a part of the Android Bionic module. From this structure, we can notice two fields that are related to the Android namespace implementation:

struct soinfo {
  ...
  android_namespace_t* primary_namespace_;
  android_namespace_list_t secondary_namespaces_;
  ...
};

If somehow, the application manages to access and modify these fields, it can add its own namespaces and load libraries from directories that were not allowed.

soinfo and library mapping

As explained in the previous section, all loaded libraries are tied to the soinfo structure. It turns out that such mapping is performed using an std::unordered_map whose the key is a unique id [9] and whose the value is a pointer on the soinfo structure.

This mapping is stored in an exported static variable named g_soinfo_handles_map (see linker/linker_globals.cpp) which is located in linker module (/system/bin/linker).

From an application point of view, it means that the relative virtual address of this variable can be resolved using the ELF dynamic symbol table. The absolute address can then be computed using dl_iterate_phdr() and looking for the base address of /system/bin/linker.

Once the application resolved the absolute virtual address of g_soinfo_handles_map, it can iterate over the std::unordered_map and look for the soinfo associated with its JNI library.

static const std::string JNI_LIBRARY_NAME = "...";

for (auto&& [hdl, info] : *g_soinfo_handles_map) {
  const char* name = get_soname(info);
  if (name == JNI_LIBRARY_NAME) {
    return info;
  }
}
return nullptr; // Not found

Now that the library has a pointer on the soinfo structure, it can access to the library namespaces using get_primary_namespace():

android_namespace_t* ns = get_primary_namespace(soinfo_ptr);

On this pointer, the application can call the set_ld_library_paths() and set_isolated() functions to extend the list of allowed directories:

ns->set_ld_library_paths({"/system/lib64", "/sytem/lib"});
ns->set_isolated(false);

Finally, the loader will not complain about loading a library in /system/lib64.

Summary

To disable the library loading restriction, we took advantage of the fact that the implementation is based on exported static variable that can be access in read / write in the memory space of applications.

Implementation

This restriction is implemented in the Android runtime (ART) known as hiddenapi. By looking at the source code of GetStaticMethodID() — located in jni_internal.cc — we can see that the function calls FindMethodID() which performs checks to allow or deny access to the method:

static jmethodID FindMethodID(...) {
  ...
  if (... && ShouldBlockAccessToMember(method, soa.Self())) {
    ...
  }
}

ShouldBlockAccessToMember() eventually calls hiddenapi::GetMemberAction() that ends up with a call to Runtime::GetHiddenApiEnforcement().

Here is an overview of the call stack:

This function can return four values depending on how the restriction is configured:

• No Checks: Enable access without restriction.

• Warning: Show warning but allow access.

• Dark Grey and Black list: Deny access to a dark grey list and a black list.

• Black list: Deny access to a black list only.

By default, the runtime is configured with the Dark Grey and Black list parameter. A library can trigger the restriction by trying to resolve the Java method android.os.Debug.getVmFeatureList():

jboolean Java_re_android_hiddenapi_MainActivity_isHiddenApiEnabled(...) {
  jclass Debug  = env->FindClass("android/os/Debug");
  jmethodID mid = env->GetStaticMethodID(Debug, "getVmFeatureList", "()[Ljava/lang/String;");

  if (mid == nullptr) {
    __android_log_write(ANDROID_LOG_VERBOSE, "hiddenapi", "Can't load method!");
    return true;
  }
  return false;
}

When this JNI function is executed, we get the following error on the logcat output:

W droid.hiddenap: Accessing hidden method Landroid/os/Debug;->getVmFeatureList()[Ljava/lang/String; (dark greylist, JNI)
V hiddenapi: Can't load method!

The JNI function is not allowed to access to the internal Java method.

Turning-off the restriction

In the previous part, we explained that the main check eventually ends-up with a call to GetHiddenApiEnforcementPolicy() which is defined in the art::Runtime class.

One way to disable the restriction is to force the runtime with a permissive configuration such as EnforcementPolicy::kNoChecks

To change the runtime configuration, the application needs to get an handle on the current instance of the Android Runtime. It can be done by calling the static method art::Runtime::Current():

#include <runtime/runtime.h>
art::Runtime* current = art::Runtime::Current();

However, the downside of this function call is that it requires to import the symbol art::Runtime::instance_ (actually _ZN3art7Runtime9instance_E) from libart.so. Consequently, it makes the JNI library linked against the libart.so library. As we explained in the previous part, we will get an error unless we update namespaces.

Another way to get the handle on the Runtime is to use the fact that the first parameter given to JNI_OnLoad(...) is an opaque pointer — JavaVM* — that is actually a pointer on the internal class art::JavaVMExt.

This class is defined in art/runtime/java_vm_ext.h and provides an accessor on the Runtime:

namespace art {
class JavaVMExt : public JavaVM {
  ...
  Runtime* GetRuntime() const {
    return runtime_;
  }
}

Both functions art::JavaVMExt::GetRuntime() and art::Runtime::Current() are inlined but the first one returns a class attribute whereas the former uses a static variable.

By using a class attribute, the compiler does not have to import symbols as it just need to compute the offset of the attribute within the class instance:

static art::Runtime* my_runtime = nullptr;

jint JNI_OnLoad(JavaVM *vm, void *reserved) {
  my_runtime = reinterpret_cast<art::JavaVMExt*>(vm)->GetRuntime();
  return JNI_VERSION_1_4;
}

Once the application got the pointer on the art::Runtime object, it can change the current enforcement policy by calling SetHiddenApiEnforcementPolicy():

#include <runtime/hidden_api.h> // Expose EnforcementPolicy enum class
...
my_runtime->SetHiddenApiEnforcementPolicy(hiddenapi::EnforcementPolicy::kNoChecks);

Moreover, the function SetHiddenApiEnforcementPolicy() is inlined so this call does not trigger an import and a dependency against libart.so.

We now have access to the whole Android framework without restrictions.

Recent commits [7], [8] on the ART repository let us suggest that further versions of Android will probably come with an update of the DEX format to enable Android developers to protect their methods and fields using the hiddenapi feature.