Another way to bypass the non-public API restrictions on Android P and above

Last year, Android P introduced restrictions on non-public APIs, which is definitely one of the most significant changes for developers. The day before yesterday, Google released the Beta version of Android Q. More and more APIs have been added to the blacklist, and Google requires that apps must target 28 in the second half of the year, which means that the current dark gray list will also take effect; it is foreseeable that in the near future, we will have to say goodbye to a large number of APIs.

[[259665]]

Last year, I provided a simple method to bypass Android P's restrictions on non-SDK interfaces. It has been verified that this method still works on the Beta version of Android Q. Although this method requires memory search and may fail in theory, it has actually been widely verified in VirtualXposed and Tai Chi, and has never received feedback on problems caused by reflection failure. And as far as I know, there are several apps with a large number of users online that use the FreeReflection library I provided, so I think there should be no problem.

But today, I am going to give you another way to bypass the restrictions. This method is currently the best solution. I have used it for more than a month and there are no problems.

Last time when we analyzed how the system imposes this restriction, we mentioned several ways and finally gave a way to modify the runtime flag; we mentioned that the system has a fn_caller_is_trusted condition: if the caller is a system class, then the call is allowed. This is obvious, after all, these private APIs are for the system to use. If the system itself is rejected, what is the point of playing with hammers?

In other words, if we can reflect as a system class, then we can do it without any obstacles. The question is, how can we "reflect as a system"? One of the most common ways is to write a class ourselves, and then set the ClassLoader of this class to the system ClassLoader through some means, and then use this class to reflect other classes. However, the "through some means" here still requires some black technology to achieve, which is essentially the same as modifying flags / inline hooks.

There are two meanings of reflecting as a system class: 1. directly turning ourselves into a system class; 2. using the system class to call reflection. Let's analyze them one by one.

Some people may think that "directly turning ourselves into system classes" is a fantasy. How can an APP class become a system class? However, you must not be limited by your own inherent thinking. Everything is possible! We know that for APP, the so-called system class is the class loaded by BootstrapClassLoader. This ClassLoader is not an ordinary DexClassLoader, so we cannot inject classes by inserting dex path. However, Android's ART introduced JVMTI on Android O. JVMTI provides a method to convert a class into a class in BootstrapClassLoader! Specifically, we write a class to expose reflection-related interfaces, and then add this class to BootstrapClassLoader through AddToBootstrapClassLoaderSearch provided by JVMTI to achieve the purpose. However, JVMTI still needs Hack to run on the release version of APP, so this approach is essentially no different from other black technologies.

The second method is "reflection with the help of system classes". That is to say, if the system has a method systemMethod, and this systemMethod calls the opposite method of reflection, then systemMethod will undoubtedly reflect successfully. But where can we find such a method for us to use? In fact, we can not only find such a method, but also this method can help us call any function, that is, reflection itself! Maybe you are confused, let me explain:

First, we use the reflection API to get the getDeclaredMethod method. getDeclaredMethod is public, so there is no problem; this method obtained through reflection is called a meta-reflection method.

Then, we use the meta-reflection method just reflected to reflect and call getDeclardMethod. Here we have achieved the purpose of reflecting as a system - the reflection-related APIs are all system classes, so our meta-reflection method is also a method loaded by the system class; therefore, the getDeclardMethod called by our meta-reflection method will be considered a system call and can reflect any method.

The pseudo code is as follows:

 Method metaGetDeclaredMethod =
 Class.class.getDeclaredMethod( "getDeclardMethod" ); // Public API, no problem
 Method hiddenMethod = metaGetDeclaredMethod.invoke(hiddenClass,
 "hiddenMethod" , "hiddenMethod parameter list" ); // System classes use hidden APIs through reflection, and the check passes directly.
 hiddenMethod.invoke // Correctly find the Method and call it directly through reflection

At this point, we can use "meta reflection" to get any hidden method or hidden field. However, if we have to do this for all the hidden methods we use, it will be a little troublesome. In the above, we later found that there are "exemption" conditions for hiding API calls. The specific code is as follows:

 if (shouldWarn || action == kDeny) {
    if (member_signature.IsExempted(runtime->GetHiddenApiExemptions())) {
 action = kAllow;
      // Avoid re-examining the exemption list next   time .
 // Note this results in   no warning for the member, which seems like what one would expect.
      // Exemptions effectively adds new members to the whitelist.
      MaybeWhitelistMember(runtime, member);
 return kAllow;
 }
 // Omitted
 }

As long as the IsExempted method returns true, even if the method is in the blacklist, it will still be released and allowed to be called. Let's take a look at the IsExempted method again:

 bool MemberSignature::IsExempted(const std::vector<std::string>& exemptions) {
 for (const std::string& exemptions : exemptions) {
    if (DoesPrefixMatch(exemption)) {
 return   true ;
 }
 }
 return   false ;
 }

We continue to track the parameter runtime->GetHiddenApiExemptions() passed in and find that this thing is also a parameter in runtime. In this case, we can go all out and modify hidden_api_exemptions_ directly in the same way as modifying runtime flag to bypass it. But if we continue to track, we will find an interesting discovery: this API is actually exposed to the Java layer, and there is a corresponding VMRuntime.setHiddenApiExemptions Java method; that is, as long as we set the exemption conditions through VMRuntime.setHiddenApiExemptions, we can happily use reflection.

Combined with the above method, we only need to reflectively call VMRuntime.setHiddenApiExemptions through "meta-reflection" to exempt all the hidden APIs we want to use. Furthermore, if we observe the DoesPrefixMatch called in the IsExempted method above, we will find that this thing is matching the prefix of the method signature; friends, the signatures of all our Java method classes start with L! If we pass L directly, all hidden APIs will be exempted!

The detailed code is here: https://github.com/tiann/FreeReflection

Theoretically, this solution has no compatibility issues. Even if the ROM deletes the setHiddenApiExemptions method, we can still use "meta-reflection" to reflect the hidden API, and all the code does not exceed 30 lines! Of course, if Google continues to improve the method of verifying hidden API calls, this method may become invalid; but there is no problem with the current mechanism.

At the end of the article, I want to say that the purpose of this article is not to deliberately circumvent limitations. If you don't set limits on your thinking and life, there will be more possibilities.