突破Android P非SDK API限制的几种代码实现

方案解释的很清楚，已经采用，原文转载

前言

Android P对非SDK API的使用做了限制，导致在Android P上会出现一些状况。在很早前预览版本刚出来的时候，360团队就出了两篇文章。 Android P 调用隐藏API限制原理以及突破Android P(Preview 1)对调用隐藏API限制的方法

限制方式三种：

反射
直接调用
jni调用

这一篇文章就是根据上面的文章来的。

方法一(不建议)

使用Provided(CompileOnly)的方式去解决调用限制，只能解决反射调用的问题，而无法解决直接调用或者jni调用的方式。不建议使用

方法二(不建议)

这个方法二对应的是360文章中的方法三。主要代码如下。

class ObjPtr {
 public:
  uintptr_t reference_;
};

ObjPtr
(*sys_GetDeclaredMethodInternal)(void *self, jobject kclass, jstring name, jobjectArray args);

void *(*executableGetArtMethod)(void *ex);

ObjPtr myGetDeclaredMethodInternal(void *self, jobject kclass, jstring name, jobjectArray args) {
  ObjPtr res = sys_GetDeclaredMethodInternal(self, kclass, name, args);
  if (res.reference_ != 0) {
    void *pMethod = executableGetArtMethod((void *) (res.reference_));
    reinterpret_cast<uint32_t *>(pMethod)[1] &= 0xcfffffff;
  }
  return res;
}


extern "C" int hookForPMethod() {
  void *libc = fake_dlopen("/system/lib/libart.so", RTLD_NOW);
  if (libc != NULL) {
    void *p = fake_dlsym(libc, "_ZN3art6mirror5Class25GetDeclaredMethodInternalILNS_11Poin"
        "terSizeE4ELb0EEENS_6ObjPtrINS0_6MethodEEEPNS_6ThreadENS4_IS1_EENS4_INS0_6StringEEEN"
        "S4_INS0_11ObjectArrayIS1_EEEE");
    if (p != NULL) {
      MSHookFunction(p,
                     reinterpret_cast<void *>(myGetDeclaredMethodInternal),
                     reinterpret_cast<void **>(&sys_GetDeclaredMethodInternal));
    }
    *(void **) (&executableGetArtMethod) =
        fake_dlsym(libc, "_ZN3art6mirror10Executable12GetArtMethodEv");
    fake_dlclose(libc);

  } //if

  return 1;
}
复制代码

其中，fake_dlopen、fake_dlsym 使用的是Nougat_dlfunctions,主要是Android 7.0以上对dlopen、dlsym等函数做了限制。因此用这个库。而MSHookFunction，则是大名鼎鼎的cydiasubstrate。

上面的代码只解决了反射方法的问题。我按照这种思路去解决字段问题的时候发现。

GetDeclaredField是inline的，无法切入。而CreateFromArtField又是hidden的，也不好切入。

因此，放弃了这种方法。

方法三(可用，但是有更好的)

这里对应的方法三，对应的是360文章中的方法二，也就是修改classloader的方式。代码如下。

void (*setClassLoader)(void *pClass, void *new_cl);
ObjPtr (*toClass)(jclass global_jclss);

extern "C" void makeHiddenApiAccessable(JNIEnv *env) {
  void *libart = fake_dlopen("/system/lib/libart.so", RTLD_NOW);
  if (libart != NULL) {
    *(void **) (&toClass) = fake_dlsym(libart, "_ZN3art16WellKnownClasses7ToClassEP7_jclass");
    *(void **) (&setClassLoader) =
        fake_dlsym(libart, "_ZN3art6mirror5Class14SetClassLoaderENS_6ObjPtrINS0_11ClassLoaderEEE");
    jclass cls = env->FindClass("com/example/support_p/ReflectionHelper");
    ObjPtr op = toClass(cls);
    setClassLoader((void *) op.reference_, NULL);
  }
}

复制代码

没错，代码就是这么点。这样，我们就可以在ReflectionHelper中调用非公开API了。但是这里会依赖Nougat_dlfunctions这个库。

方法四(超级好)

既然是修改classloader，那么我们为什么不在java层修改呢。代码如下。

  private void testJavaPojie() {
    try {
      Class reflectionHelperClz = Class.forName("com.example.support_p.ReflectionHelper");
      Class classClz = Class.class;
      Field classLoaderField = classClz.getDeclaredField("classLoader");
      classLoaderField.setAccessible(true);
      classLoaderField.set(reflectionHelperClz, null);
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
复制代码

而这里用的相关反射只是light级别的，没有什么影响。反而代码量超小，也不依赖其他。

方法五(超级好+1)

这个方案来自 @区长大神

方法四还是存在一点问题。如果以后把classloader加入到深灰或者黑名单，那就僵硬了。所以，我们不用反射，直接用unsafe去修改。代码这就不贴了。为了得到classloader的偏移量，我们写一个和Class结构一样的类，用这个类得到的classLoader的偏移量和Class是一样的。

注意：

如果我们用修改ClassLoader的方式的话，那么ReflectionHelper类中只能反射调用非公开API，注意了。

代码在这里，觉得好的给个star吧

Android P 调用隐藏API限制原理

随着Android P预览版的发布，谷歌在改进系统稳定性的措施上又增加了新的限制,即应用程序引用非SDK接口，无论采用直接、反射、JNI获取等手段都将受到限制。在谷歌提供的预览版文档&&App Compatibility Changes一节中，我们可以知道如下信息：

在Framework documented中列出了能访问的sdk
Android P. DP1提供了测试非SDK接口调用日志输出
保留非SDK调用将会触发的异常类型
DP1限制效果预览

在官方提供的镜像环境下，当运行app时, 其调用非SDK Methods/ Fields(函数/字段) 则会触发保护机制而输出如下日志信息：

Log Format：

Log header + Method/Field + API signatures+ （Greylist, Callers）

Log Header 日志头部输出标识 (Accessinghidden)

Method/Field 表示当前是方法还是字段

API signatures 与文件中内容格式等价

Methods

class_descriptor>method_name(parameter_types)return_type
Field编码

class_descriptor->field_name:field_type

Greylist 3个限制等级，分别由3个文件列表提供。

a) Light greylist
b) Dark greylist
c) blacklist

Callers JNI、reflection

实现原理

Greylist所列出的三个限制等级，其数据来源于3个文本文件，包含了要被限制的函数或者字段。它们位于系统源码目录，在系统源码编译阶段完成从文本文件数据解析合并到dex格式文件的过程。 (Dex文件中函数/字段被标记阶段，影响其access_flags_)
在art虚拟机内部存在一个转换过程。即将Dex格式中函数/字段被标记的值再次转换并存入art runtime访问标志（access_flags_）。
App运行时触发任意系统函数调用，进入art虚拟机内部时根据art的访问标志的值(access_flags_)识别出限制等级，从而达到限制非SDK调用的目的。

基于其上所描述，将分别从两个维度(编译阶段, 类初始化阶段(art) )进行详细介绍。

编译阶段

由编译脚本控制3个文本文件

(hiddenapi-light-greylist.txt、hiddenapi-dark-greylist.txt、hiddenapi-blacklist.txt)

编译脚本路径：Framework/base/Android.mk

由编译脚本可知道：

hiddenapi-blacklist.txt，hiddenapi-dark-greylist.txt来源于Framework/base/config目录
hiddenapi-light-greylist.txt为private-dex.txt减去blacklist.txt与dark-greylist.txt的集合

（其中private-dex.txt位于目录Out/target/common/obj/PACKAGING/）

注：

APIsignatures(函数/字段)在3个文件中具备唯一性
位于config目录下的blacklist.txt、dark-greylist.txt内容为0。（用官方提供的镜像测试发现存在dark-greylist数据，应该是DP1源码中末提供此数据）、
private-dex.txt为声明私有方式的集合数据 (此处待验证)

\2. 编译阶段生成hiddenapi

源码位于: art/tools/hiddenapi

生成host可执行程序： out/host/linux-x86/bin/hiddenapi

Linux-x86: 编译平台和生成目录对应

\3. 处理dex、jar

在满足1、2的前提下，在对应的目录下将会包含所需文件与程序，此时即可对dex进行处理。经过hiddenapi处理后，将完成对指定Dex文件中所有函数/字段重新标记，通过修改其access_flags_字段值实现。

hiddenapi运行参数：–light-greylist=out/target/common/obj/PACKAGING/hiddenapi-light-greylist.txt–dark-greylist=out/target/common/obj/PACKAGING/hiddenapi-dark-greylist.txt –blacklist=out/target/common/obj/PACKAGING/hiddenapi-blacklist.txt
编译时脚本

路径：build/core/definitions.mk

在源码编译后，请自行查阅编译日志build-aosp_walleye.ninja（设备pixel 2）。

\4. Hiddenapi解析

1）遍历class.dex中的函数或者字段列表

2）IsOnApiList 函数验证当前Method/Field是否存在文件中，且能得到以下值中一种

HiddenApiAccessFlags::kWhitelist => 0b00

hiddenapi-light-greylist.txt=> HiddenApiAccessFlags::kLightGreylist => 0b01

hiddenapi-dark-greylist.txt => HiddenApiAccessFlags::kDarkGreylist=> 0b10

hiddenapi-blacklist.txt => HiddenApiAccessFlags::kBlacklist => 0b11

3）SetHidden 函数将2)中得到的二进制数据与ClassDataMethod/ClassDataField结构体中成员access_flags_原始值进行处理后重新写入(注意leb128格式保存)

ClassDataMethod/ClassDataField结构体成员access_flags_

b.其中access_flags_字段按bit存储表示不同含义

Bit(2:0) 表示存储内容为public(0b001)、private（0b010）、protect(0b100)

Bit(8) 表示当前method是native

算法原理：由2)步骤中得到值0bxx(低位)

如果值的低位为1，则原值与kAccVisibilityFlags进行异或(^)操作

注：

access_flags_ 原值低3位有且只有一位标记为1，其表示的意义为函数属于(private、protect、public)中一种，当经过异或运算后，新值低3位中有2位标记为1. 则表示低位已经被写入。后续通过IsPowerOfTwo函数来校验access_flags_是否被修改。（校验思路：原值是否为2的幂次方，因为如果是2的幂次方只能存在一个1）

算法原理：由2)步骤中得到值0bxx(高位)

如果值的高位为1，则根据access_flags_中第8位的原始值来决定与kAccDexHiddenBit/kAccDexHiddenBitNative进行或(

)操作。

access_flags_ 第8位(bit8)表示native。

0：非native：则取值为kAccDexHiddenBit

1: native 则取值为kAccDexHiddenBitNative

4) 完成access_flags_值的读取和写入，主要涉及以下函数

5) 最后一步，重新校验dex头部签名

\5. Hiddenapi处理后，完成从3个文本文件数据与原始dex格式文件的合并，即生成新的dex。

类初始化阶段(art)

前面已经分析过在编译阶段hiddenapi程序是如何将3个配置文件中每个函数/字段重新写入dex文件，在这个阶段我们从ClassLinker中Loadfield/LoadMethod来分析如何将Dex结构体中的access_flags_值转换为Art Runtime时所需的值（art结构体中access_flags_）。

以LoadField为例

文件位于art/runtime/class_liner.cc

\1. 此处校验是否是bootclassloader后，直接调用DecodeHiddenAccessFlags读取Dex缓存中access_flag_的值。

\2. DecodeHiddenAccessFlags调用的是HiddenApiAccessFlags中的DecodeFromDex函数

DecodeFromDex功能和EncodeFromDex是一个相反的过程。

EncodeFromDex 将二进制数据(0bXX)按格式存入dex结构体中的access_flags_

DecodeFromDex 读取Dex结构体中的access_flags_中的值。并将2位bit转换为0~3的整数。等价于前面提到的

0b01 HiddenApiAccessFlags::kLightGreylist

0b10 HiddenApiAccessFlags::kDarkGreylist

0b11 HiddenApiAccessFlags::kBlacklist

那么对应关系如下：

hiddenapi-light-greylist.txt (0b01)、

hiddenapi-dark-greylist.txt (0b10)、

hiddenapi-blacklist.txt (0b11)

\3. 最后进入到EncodeForRuntime函数中，此函数的功能是将重新获取的2位二进制数据写入artmethod结构体中access_flags_中。以方便在art运行时进行最后校验。

不同于dex文件中access_flags_的存储方式，由上述代码可知，此处通过左移的方式将这2位二进制数据存储到art结构体中成员access_flags_的最高位。

\4. 在app运行时，会校验artmethod结构体中access_flags_最高2位的值

\5. 校验的手段包括直接调用、反射、JNI获取

1) 关键调用过程

运行阶段请自行查阅GetMethodID/GetFieldID调用流程，最终会进入到ShouldBlockAccessToMember这个函数进行校验

2) 校验过程

其校验函数： ShouldBlockAccessToMember

源码位于： Art/runtime/hidden_api.h

其中，GetMemberAction调用HiddenApiAccessFlags中DecodeFromRuntime获取其返回值

通过返回值，就可以清楚的看到当前调用的函数或者字段是属于哪个属性。

kAllow = 0; 此处对应关系：

0(0b00)： =>HiddenApiAccessFlags::kWhitelist

1(0b01)：hiddenapi-light-greylist.txt =>HiddenApiAccessFlags::kLightGreylist

2(0b10): hiddenapi-dark-greylist.txt =>HiddenApiAccessFlags::kDarkGreylist

3(0b11): hiddenapi-blacklist.txt =>HiddenApiAccessFlags::kBlacklist

AndroidP. DP1中通过Action的行为来判断：

0(0b00) kAllow 直接放过

1(0b01) kAllowButWarn 放过，但日志警告

2(0b10) kAllowButWarnAndToast 放过，且日志警告和弹窗

3(0b11) kDeny 拒绝

日志输出函数

总结

本文基于Android P. DP1研究非sdk限制机制的核心思路，其中忽略了一些细节。限于篇幅后续根据稳定版的改动再补充。如果有问题，欢迎大家在留言区指出与探讨！

快手APP分析

突破Android P非SDK API限制的几种代码实现

前言

方法一(不建议)

方法二(不建议)

方法三(可用，但是有更好的)

方法四(超级好)

方法五(超级好+1)

注意：

Android P 调用隐藏API限制原理

编译阶段

类初始化阶段(art)

总结

CATALOG

FEATURED TAGS

FRIENDS