绕过 Android P以上非公开API限制的办法

ualXposed 和 太极 中得到了较为广泛的验证，从未收到过由于反射失败而导致问题的反馈。而且据我所知，有若干用户量不少的 APP 在线上使用了我提供的 FreeReflection 库，想来应该也是没有问题的吧。

不过今天，我打算给出另外一种绕过限制的办法。这个办法目前来说是***方案，我个人使用了一个多月，不存在任何问题。

上次分析系统是如何施加这个限制 的时候，我们提到了几种方式，最终给出了一种修改 runtime flag 的办法;其中我们提到，系统有一个 fn_caller_is_trusted 条件：如果调用者是系统类，那么就允许被调用。这是显而易见的，毕竟这些私有 API 就是给系统用的，如果系统自己都被拒绝了，这是在玩锤子呢?

也就是说，如果我们能以系统类的身份去反射，那么就能畅通无阻。问题是，我们如何以「系统的身份去反射」呢?一种最常见的办法是，我们自己写一个类，然后通过某种途径把这个类的 ClassLoader 设置为系统的 ClassLoader，再借助这个类去反射其他类。但是这里的「通过某种途径」依然要使用一些黑科技才能实现，与修改 flags / inline hook 无本质区别。

以系统类的身份去反射 有两个意思，1. 直接把我们自己变成系统类;2. 借助系统类去调用反射。我们一个个分析。

「直接把我们自己变成系统类」这个方式有童鞋可能觉得天方夜谭，APP 的类怎么可能成为系统类?但是，一定不要被自己的固有思维给局限，一切皆有可能!我们知道，对APP来说，所谓的系统类就是被 BootstrapClassLoader 加载的类，这个 ClassLoader 并非普通的 DexClassLoader，因此我们无法通过插入 dex path的方式注入类。但是，Android 的 ART 在 Android O 上引入了 JVMTI，JVMTI 提供了将某一个类转换为 BootstrapClassLoader 中的类的方法!具体来说，我们写一个类暴露反射相关的接口，然后通过 JVMTI 提供的 AddToBootstrapClassLoaderSearch将此类加入 BootstrapClassLoader 就实现目的了。不过，JVMTI 要在 release 版本的 APP 上运行依然需要 Hack，所以这种途径与其他的黑科技无本质区别。

第二种方法，「借助系统的类去反射」也就是说，如果系统有一个方法systemMethod，这个systemMethod 去调用反射相反的方法，那么systemMethod毋庸置疑会反射成功。但是，我们从哪去找到这么一个方法给我们用?事实上，我们不仅能找到这样的方法，而且这个方法能帮助我们调用任意的函数，那就是反射本身!可能你已经绕晕了，我解释一下：

首先，我们通过反射 API 拿到 getDeclaredMethod 方法。getDeclaredMethod 是 public 的，不存在问题;这个通过反射拿到的方法我们称之为元反射方法。

然后，我们通过刚刚反射拿到元反射方法去反射调用 getDeclardMethod。这里我们就实现了以系统身份去反射的目的——反射相关的 API 都是系统类

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!