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

阅读 663
收藏 41
2018-09-19
原文链接:mp.weixin.qq.com

奇技指南

在之前的文章《Android P 调用隐藏API限制原理》中,我们分析了Android P Preview 1版本对隐藏API调用限制的原理,这次我们带来了绕过限制的的方法。

本文首发于公众号奇卓社,已授权转载。

概要

本文基于对AndroidP(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,其类型为JavaLibrary ,命名为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的第一个参数类型为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 工具类完成

绕过方法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 ,实现难度较大

总结

本文提出并实现了三种在AndroidP上调用隐藏API的方法,分别有不同特点和适用范围,工程中可以根据实际情况选用不同方法。

相关阅读

Android P 调用隐藏API限制原理

界世的你当不

只作你的肩膀

 360官方技术公众号 

技术干货|一手资讯|精彩活动

空·

评论