看新闻很累? 看技术新闻更累? 试试 下载 InfoQ 手机客户端 https://time.geekbang.org/?utm_source=website&utm_medium=infoq&utm_campaign=news&utm_content=app , 每天上下班路上听新闻, 有趣还有料!
首先需要强调的是, 为什么要突破限制, 因为安卓中许多技术需求需要使用系统隐藏 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, 至少要做以下两个区分:
必须区分一个 Method(或 Field)对用户代码是隐藏的还是公开的. 只有隐藏的才需要进行限制.
必须区分调用者的身份: 是用户代码调用的还是系统代码 (例如 Activity 类) 调用的. 只有用户代码调用时才需要进行限制.
具体到 Android P 的代码实现, 它会在所有通过反射方式和 JNI 方式获取 Method 和 Field 的地方调用以下函数判断是否用户代码调用了系统的隐藏 API(位于
art/runtime/hidden_api.h
), 如果这个函数返回 true, 那么说明用户代码调用了系统的隐藏 API,Android P(Preview1)会通过 log 发出警告, 用户代码仍然能够获取到正确的 Method 或 Field, 在后续版本中获取到的 Method 或 Field 极有可能为空.
那么它是如何进行上述两个区分的呢?
每个 Method(或 Field)都有一个对应的 access_flags_(uint32_t 类型), 原本这个值通过一些特定位 (bit) 表明其属性 (public,private,static 等), 但是还有一些保留的未定义的位, Android P 就利用未定义的几个位, 表明这个 Method(或 Field) 是对用户代码隐藏的还是公开的.
通过回溯调用栈找到调用者所在的 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, 实现难度较大
四, 总结
本文提出并实现了三种在 Android P 上调用隐藏 API 的方法, 分别有不同特点和适用范围, 工程中可以根据实际情况选用不同方法.
来源: http://www.tuicool.com/articles/rY7NJjz