突破Android P(Preview 1)对调用隐藏API限制的方法

一.概要

本文基于对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这个隐藏方法为例，讲解绕过限制的方法。

三.绕过方法

绕过方法1

经过上面的论述结合源码分析，咱们发现只有在经过反射方式和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的。

绕过方法2

如今回头看"限制原理"中论述的两个区分，其实只要咱们可以混淆任何一个区分点都可以成功绕过此限制。混淆第一个区分点，会让系统错误地认为本来隐藏的API是公开的；混淆第二个区分点，会让系统错误地将用户代码调用识别为系统代码调用。方法二的核心思想就是混淆第二个区分点。
关注第二个区分点，能够发现，其实只要在BootStrapClassLoader加载的类中有任何一个帮助咱们进行反射的类就能绕过这个问题，那么咱们可否将咱们apk中定义的类的ClassLoader改成BootStrapClassLoader呢？答案是确定的！查看art/runtime/mirror/class.h可知SetClassLoader函数能够为一个类指定ClassLoader，用IDA查看/system/lib/libart.so确认此函数位于导出符号表中。SetClassLoader的第一个参数类型为ObjPtrmirror::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工具类完成

绕过方法3

方法三经过混淆第一个区分点突破限制。

只要修改被隐藏的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，实现难度较大

四.总结

本文提出并实现了三种在Android P上调用隐藏API的方法，分别有不一样特色和适用范围，工程中能够根据实际状况选用不一样方法。