Bypass Android's hidden API restrictions

Question

Starting with Android Pie, access to certain hidden classes, methods and fields was restricted. Before Pie, it was pretty easy to use these hidden non-SDK components by simp

Answer 1

UPDATE 2

It seems someone has already broken Android 11's hidden API blacklist. I haven't been able to personally test it, and it isn't a pure Java solution, but here's the source: https://github.com/ChickenHook/RestrictionBypass.

And here's a description of how it works: https://androidreverse.wordpress.com/2020/05/02/android-api-restriction-bypass-for-all-android-versions/.

UPDATE

Google has hardened the API restrictions with Android 11. The methods below using JNI and Java will no longer work in apps targeting API 30 or later.

---

There are actually a few ways to do this.

---

Secure Settings

Google built in a way to disable the hidden API restrictions globally on a given Android device, for testing purposes. The section in the link in the question titled How can I enable access to non-SDK interfaces? says the following:

You can enable access to non-SDK interfaces on development devices by changing the API enforcement policy using the following adb commands:

adb shell settings put global hidden_api_policy_pre_p_apps  1
adb shell settings put global hidden_api_policy_p_apps 1

To reset the API enforcement policy to the default settings, use the following commands:

adb shell settings delete global hidden_api_policy_pre_p_apps
adb shell settings delete global hidden_api_policy_p_apps

These commands do not require a rooted device.

You can set the integer in the API enforcement policy to one of the following values:

• 0: Disable all detection of non-SDK interfaces. Using this setting disables all log messages for non-SDK interface usage and prevents you from testing your app using the StrictMode API. This setting is not recommended.
• 1: Enable access to all non-SDK interfaces, but print log messages with warnings for any non-SDK interface usage. Using this setting also allows you to test your app using the StrictMode API.
• 2: Disallow usage of non-SDK interfaces that belong to either the blacklist or the greylist and are restricted for your target API level.
• 3: Disallow usage of non-SDK interfaces that belong to the blacklist, but allow usage of interfaces that belong to the greylist and are restricted for your target API level.

(On the Q betas, there seems to be only one key now: hidden_api_policy.)

(In my testing, after changing this setting, your app needs to be fully restarted—process killed–for it to take effect.)

You can even change this from inside an app with Settings.Global.putInt(ContentResolver, String, Int). However, it requires the app to hold the WRITE_SECURE_SETTINGS permission, which is only automatically granted to signature-level or privileged apps. It can be manually granted through ADB.

---

JNI

The secure settings method is good for testing or for personal apps, but if your app is meant to be distributed to devices you don't control, trying to instruct end users on how to use ADB can be a nightmare, and even if they already know what to do, it's inconvenient.

Luckily, there is actually a way to disable the API restrictions for your app, using some clever tricks in native code.

Inside your JNI_OnLoad() method, you can do the following:

static art::Runtime* runtime = nullptr;

extern "C" jint JNI_OnLoad(JavaVM *vm, void *reserved) {
  ...

  runtime = reinterpret_cast<art::JavaVMExt*>(vm)->GetRuntime();
  runtime->SetHiddenApiEnforcementPolicy(art::hiddenapi::EnforcementPolicy::kNoChecks);

  ...
}

This will disable the hidden API checks for you, without any special permissions.

Source

There's also a library you can use that will do this for you: https://github.com/tiann/FreeReflection/

---

Pure Java/Kotlin

JNI isn't for everyone (including me). It also needs you to have separate versions of your app for different architectures. Luckily, there is also a pure-Java solution.

Android's hidden API restrictions only apply to third party apps that aren't signed by the platform signature and aren't manually whitelisted in /system/etc/sysconfig/. What this means is that the framework (obviously) can access any hidden methods it wants, which is what this method takes advantage of.

The solution here is to use double-reflection (or "meta-reflection," as the translated source calls it). Here's an example, retrieving a hidden method (in Kotlin):

val getDeclaredMethod = Class::class.java.getDeclaredMethod("getDeclaredMethod", String::class.java, arrayOf<Class<*>>()::class.java)

val someHiddenMethod = getDeclaredMethod.invoke(SomeClass::class.java, "someHiddenMethod", Param1::class.java, Param2::class.java)

val result = someHiddenMethod.invoke(someClassInstance, param1, param2)

Now, this could stand as a good enough solution on its own, but it can be taken a step further. The class dalvik.system.VMRuntime has a method: setHiddenApiExemptions(vararg methods: String). Simply passing "L" to this method will exempt all hidden APIs, and we can do that with double-reflection.

val forName = Class::class.java.getDeclaredMethod("forName", String::class.java)
val getDeclaredMethod = Class::class.java.getDeclaredMethod("getDeclaredMethod", String::class.java, arrayOf<Class<*>>()::class.java)

val vmRuntimeClass = forName.invoke(null, "dalvik.system.VMRuntime") as Class<*>
val getRuntime = getDeclaredMethod.invoke(vmRuntimeClass, "getRuntime", null) as Method
val setHiddenApiExemptions = getDeclaredMethod.invoke(vmRuntimeClass, "setHiddenApiExemptions", arrayOf(arrayOf<String>()::class.java)) as Method

val vmRuntime = getRuntime.invoke(null)

setHiddenApiExemptions.invoke(vmRuntime, arrayOf("L"))

Put that code in your Application class' onCreate() method, for example, and then you'll be able to use hidden APIs like normal.

For a full Java example of this, check out the FreeReflection library linked in the JNI section, or follow through the source below.

Source

Answer 2

Just to simplify TheWanderer's answer in a way that incorporated the linked package and worked for me:

Add dependency to your build.gradle...

implementation 'me.weishu:free_reflection:2.2.0'

Add attachBaseContext to your MainActivity (e.g.):

@Override
  protected void attachBaseContext(Context base) {
  super.attachBaseContext(base);
  Reflection.unseal(base);
}

Or, in Kotlin:

override fun attachBaseContext(base: Context?) {
  super.attachBaseContext(base)
  Reflection.unseal(base)
}

And, if your imports weren't added automatically,

import me.weishu.reflection.Reflection
import android.content.Context

Hope it helps!

Answer 3

I'm adding the java implementation for @TheWanderer amazing answer:

Method forName = Class.class.getDeclaredMethod("forName", String.class);
Method getDeclaredMethod = Class.class.getDeclaredMethod("getDeclaredMethod", String.class, Class[].class);

Class vmRuntimeClass = (Class) forName.invoke(null, "dalvik.system.VMRuntime");
Method getRuntime = (Method) getDeclaredMethod.invoke(vmRuntimeClass, "getRuntime", null);
Method setHiddenApiExemptions = (Method) getDeclaredMethod.invoke(vmRuntimeClass, "setHiddenApiExemptions", new Class[] {String[].class});

Object vmRuntime = getRuntime.invoke(null);
setHiddenApiExemptions.invoke(vmRuntime, new String[][]{new String[]{"L"}});

Answer 4

How does the restiction work?

The new way how the VM (maynly in java_lang_Class.cc) identifies the caller and if he's allowed to access hidden field or hidden method is to walk through the Stacktrace until a frame appears not Matching kind of a "whitelist for skipping frames" (let's call it "skipping list" for now). Means if you just do "Reflection via Reflection" the Method.invoke(...) is in "skipping list" and will be skipped. Next frame will be your method and the VM will check whether you're a system library or not. If not access will be denied.

Ok so far?

Now the Workaround:

What happens if the Stacktrace doesn't contain any Frame except of the getMethod() / getDeclaredMethod()?

Answer: The VM will not be able to verify because there is nothing to verify...

Ok but how can we achive that?

Well, if we spawn a new thread the stacktrace will be "empty" except of the frame calling the Method.invoke(...). Means we reduced the stacktrace to one frame that belongs to our code.

And here is where native comes into the game:

In general there are three interfaces where the VM checks API restrictions:

• linkage - VM verifies during "Classloading" ? (didn't research much here yet).
• Reflection - VM walks through the Java stacktrace (like described aboth)
• JNI - VM checks if ClassLoader that loaded the Class calling the loadLibrary(...) has framework.jar in ClassPath.

Means the JNI verifier doesn't walk through the Java stack and the Reflection verifier doesn't care about native.

Ok let's combine those.

We create an "empty" stacktrace by calling std::async(...).get() method and call the Reflection API via JNI (yes we call java.lang.reflect.Class.get*) via JNI because it's not a restricted method the jni call will succeed. And now the Reflection verifier walks through the stack and won't find any Java Frame because there was no Java Frame in this thread (except of the Class.get* call).

Hope I matched the requirements to not be that detailed but also beeing accurate and telling correctly.

See also:

Github

Description