突破Android P的非公开API限制

参见 前端,

最近，Android 开发者估计比较不爽，因为尚在开发阶段的 Android P 已经明确表示要封杀非公开 API 的调用，没法像以前一样愉快地玩黑科技，来自 360 的刘洪凯经过研究，发现了绕过限制的三种方法，在此分享出来。

首先需要强调的是，为什么要突破限制，因为安卓中许多技术需求需要使用系统隐藏 API 完成。目前大量的安卓应用都会通过反射或 JNI 方式使用到系统隐藏 API, 这其中包括几乎全部插件化框架，典型的是对 AssetManager 中隐藏 API 的使用。开发新的项目也不可避免地会使用到系统隐藏 API。Android P 的这一限制会导致许多安卓应用以及开源框架在 Android P 上运行出现崩溃。因此突破此限制有很重要的意义。

另外，目前的几个方法均已在 Android P(Preview 1) 的手机上测试通过，均为有效。只要将来放出的 Android P 源码依然使用此限制原理，那么这些方法就保证有效。

最后，文中的几种方法均不会产生副作用。

一、概要

本文基于对 Android P(Preview 1) 的源码分析, 实现了三种绕过对调用隐藏 API 限制的方法, 有效性均已得到验证，能够成功调用系统隐藏 API。

二、限制原理

首先抛开 Android P 的具体实现过程，安卓系统要实现限制用户代码调用系统隐藏 API，至少要做以下两个区分：

1. 必须区分一个 Method（或 Field）对用户代码是隐藏的还是公开的。只有隐藏的才需要进行限制。
2. 必须区分调用者的身份：是用户代码调用的还是系统代码（例如 Activity 类）调用的。只有用户代码调用时才需要进行限制。

具体到 Android P 的代码实现，它会在所有通过反射方式和 JNI 方式获取 Method 和 Field 的地方调用以下函数判断是否用户代码调用了系统的隐藏 API(位于art/runtime/hidden_api.h），如果这个函数返回 true，那么说明用户代码调用了系统的隐藏 API，Android P（Preview1）会通过 log 发出警告，用户代码仍然能够获取到正确的 Method 或 Field，在后续版本中获取到的 Method 或 Field 极有可能为空。

那么它是如何进行上述两个区分的呢？

1. 每个 Method（或 Field）都有一个对应的access_flags（uint32_t类型），原本这个值通过一些特定位（bit）表明其属性（public，private，static 等），但是还有一些保留的未定义的位，Android P 就利用未定义的几个位，表明这个 Method（或 Field）是对用户代码隐藏的还是公开的。
2. 通过回溯调用栈找到调用者所在的 Class，然后判断这个 Class 的 ClassLoader 是否为 BootStrapClassLoader，如果是 BoootStrapClassLoader 那么就认为调用者是系统代码，否则就认为调用者是用户代码。fn_caller_in_boot就是一个函数指针，它用来判断调用者是否是 BootStrapClassLoader，反射调用和 JNI 调用时fn_caller_in_boot指向不同的函数，具体细节可查看源码。

下面我们以调用android.app.ActivityThread类的currentActivityThread这个隐藏方法为例，讲解绕过限制的方法。

三、绕过方法

方法一

通过上面的论述结合源码分析，我们发现只有在通过反射方式和 JNI 方式获取 Method 和 Field 时，系统才有可能拦截对隐藏 API 的获取，也就是说直接调用是可以的！因此 方法一的核心思想就是想方设法直接调用系统隐藏 API。

具体实现时需要用 Provided 方式提供 Module 或自定义 android.jar。下面以一个例子说明实现过程。

我们新建一个普通的 android 工程，在其 MainActivity 中直接调用ActivityThread.currentActivityThread()；发现 IDE 提示找不到类 ActivityThread，这是因为在 sdk 的 android.jar（位于SDK/platforms/android-XX目录下）中并没有这个类的声明，但是在实际运行时这个类是存在于系统中的。我们的解决方法是以 Provided 方式提供一个 Module，在此 Module 中提供需要的类（Provided 方式是为了编译通过，这样的 Module 的代码并不会编译到最终的 apk 中）。具体操作如下：

新建一个 Module，其类型为 Java Library，命名为 libfakeandroid，然后在 app 的 build.gradle 中以 Provided 方式依赖 libfakeandroid

之后在 libfakeandroid 中新建一个类 android.app.ActivityThread，并添加需要调用的隐藏 API，

完成以上操作之后，MainActivity 中就能直接调用ActivityThread.currentActivityThread()方法了。在 Android P（Preview1）系统上运行不会出现警告 log，成功！

注意：如果需要调用的隐藏 API 所在的类已经位于 android.jar 中，Provided 方式不再适用，此时需要自定义 android.jar, 将需要的 Method 或 Field 添加到 android.jar 中。

• 优点：实现起来非常简单方便，并且稳定性很好。
• 缺点：只能调用访问权限为 public 和 default 的 Method 和 Field，不能直接调用 protected 和 private 的。

方法二

现在回头看”限制原理”中论述的两个区分，其实只要我们能够混淆任何一个区分点都能够成功绕过此限制。混淆第一个区分点，会让系统错误地认为原本隐藏的 API 是公开的；混淆第二个区分点，会让系统错误地将用户代码调用识别为系统代码调用。方法二的核心思想就是混淆第二个区分点。

关注第二个区分点，可以发现，其实只要在 BootStrapClassLoader 加载的类中有任何一个帮助我们进行反射的类就能绕过这个问题，那么我们能否将我们 apk 中定义的类的 ClassLoader 改为 BootStrapClassLoader 呢？答案是肯定的！查看art/runtime/mirror/class.h可知 SetClassLoader 函数可以为一个类指定 ClassLoader，用 IDA 查看/system/lib/libart.so确认此函数位于导出符号表中。SetClassLoader 的第一个参数类型为ObjPtr<mirror::Class>，如何将 jclass 转化为此类型呢？通过在 Android 源码中查找，在art/runtime/well_known_classes.h中有一个非常合适的函数ToClass能够完成此任务，其声明如下

查看 libart.so 可知，ToClass 函数也在其导出符号表中，因此 ToClass 函数是一个恰当的函数。方法二的具体实现代码见下图

其中，my_dlsym与 dlsym 类似，其功能是根据函数的导出符号寻找函数在进程中的地址。my_dlsym是我们自定义的一个函数。

makeHiddenApiAccessable调用成功之后，使用com.test.hidefix.ReflectionHelper类反射寻找隐藏 API，不会再出现 log 警告，成功！

实际工程中使用时可以将 ReflectionHelper 类作为一个工具类，代码中所有反射寻找 Method 和 Field 的地方均使用 ReflectionHelper 处理。

注意：ReflectionHelper 类只能调用系统类，不能调用自己 app 代码中的任何类！否则会因为 ClassLoader 的全盘委托机制出现问题！

• 优点：能够调用所有隐藏 API；仅需要寻找两个导出函数，适配性较好；没有使用 Hook，稳定性好
• 缺点：JNI 方式获取 Method 和 Field 时也需要转到 ReflectionHelper 工具类完成

方法三

方法三通过混淆第一个区分点突破限制。只要修改被隐藏的 Method 或 Field 对应的access_flags，去掉其隐藏属性即可，下文为了论述方便，只以获取隐藏的 Method 为例进行说明，Field 同理。实际上，只要获取到一个jmethodID，将其强转为ArtMethod*类型，然后修改其access_flags即可。但是后续版本中应用代码无法获取隐藏 Method 的jmethodID，貌似陷入一个死循环了。但是查看源码，我们是有方法获取ArtMethod*的：art/runtime/native/java_lang_Class.cc有以下函数：

此函数是Class.getDeclaredMethod方法在 native 的实现，注意到这里是先获取的 result 然后才判断ShouldBlockAccessToMember，因此我们可以 hook 获取 result 的mirror::Class::GetDeclaredMethodInternal这个函数，将得到的ObjPtr<mirror::Method>类型的 result 想办法转换为ArtMethod*类型即可。方法三具体实现代码如下：

应用到实际工程中时还需要 Hook 另外的类似函数，这里不再一一列举。

• 优点：原有代码无需修改，适用于原有代码量较多的情况。
• 缺点：需要使用 Hook，实现难度较大