android插件化欺骗AMS-白红宇

android插件化欺骗AMS

阅读量：2345 次

发布时间：2019-05-10

本文共 1143 字，大约阅读时间需要 3 分钟。

在这里插入图片描述

反射到ActivityManagerNative—gDefault-----Singleton—mInstance ,因为mInstance是ActivityManager类型的，而ActivityManage是接口类型，所以动态构造代理替换startActivty实现目标Activity替换stubactivity绕过 AMS对activity得检查。

通过反射currentThread一路反射H类，反射hook mH父类Handler接口callback handleMessage，在其中的handleLunachactivity中替换回目标Activity，然后启动。

最后是绕过安装检测不说了。

反射目测只能hook接口类中的函数，或是直接替换字段。

在这里插入图片描述

virtualapp

我这里总结者个其实是为研究virtualapp的实现机制，研究了下发现后半部分和以上实现类似，但在前半部分替换singleton出现了差异。

这里先说下这个架构里的反射模块。

笔走龙蛇的反射hook

整个反射可谓被搞的完全变了样，

我们这里以ActivityManagerStub为例说明下，

1.类实现

public class ActivityManagerStub extends MethodInvocationProxy<MethodInvocationStub>

核心类和接口实现如图，addMethodProxy 通过两层重载，维护了一个叫做mInteralMethodProxies的Map映射，来添加对函数的hook或替换。

这里重点来了，我们怎么确定实现的是按个类里的hook。

这里我们看ActivityManagerStub构造函数

public ActivityManagerStub(){

super(new MethodInvocationStub<>(ActivityManagerNative.getDefault.call()))

}

这里是通过反射得到default构建见一个MethodInvocationStub类，而这个类里恰好是对传入参数的代理构造。也就是说我们实现了参数类的hook。

利用方式

还是以ActivityManagerStub说明，在构造类default的代理后，我们通过MethodInvocationProxy里重载的addMethodProxy添加需要hook的函数。完成AMS的服务的欺骗。

问题
问题是替换activities的操作不在这里，尴尬了。

实现自己的启动流程

在这里插入图片描述

如图，virtualApp实现了自己的AMS管理流程，只在最后hook了ActivityThreadH替换了下。估计是考虑到Android系统兼容性问题。

转载地址：http://xvjvb.baihongyu.com/

你可能感兴趣的文章