Android Binder Hook的实现

Posted 2023-03-31

参考技术A

Binder Hook可以Hook掉 当前App 用到的系统Service服务。
以LocationManager为例，在获取一个LocationManager时分为两步。第一，获取IBinder对象；第二：IBinder对象通过asInterface()转化为LocationMangerService对象。最后初始化LocationManager，application层用到的都是LocationManager。
Hook的大致原理是：ServiceManager在获取某个Binder时，如果本地有缓存的Binder，就不再跨进程请求Binder了。我们可以在缓存中加入自己的Binder，使得ServiceManager查询本地缓存时得到一个自定义的CustomBinder对象，不再跨进程向系统请求。并且ILocationManager.Stub.asInterface(CustomBinder)方法返回我们自定义的Service对象。
这里面有两个地方需要用到自定义的对象。由于我们只Hook其中一部分的功能，其他功能还需要保留，所以用动态代理的方式创建自定义的Binder和自定义的Service。

在理解后面的内容前你需要了解这些知识点：

Activity等类在获取系统Service时，都是调用getSystemService(serviceName)方法获取的。

Context 的 getSystemService() 方法调用了 SystemServiceRegistry 的 getSystemService() 方法。
SystemServiceRegistry 中有一个常量 SYSTEM_SERVICE_FETCHERS，这是一个Map。保存了ServiceName和对应的ServiceFetcher。ServicFetcher是用于创建具体Service的类。ServiceFetcher 的关键方法是 createService() 方法。
在 ServiceFetcher 的 createService() 方法中，调用了 ServiceManager.getService(name) 方法。以 LocationManager 对应的 ServiceFetcher 为例，它的createService()方法源码如下：

假如我们要修改 LocationManager 的 getLastKnownLocation() 方法（下文都是）。我们要做的就是让ServiceManager.getService("location")返回我们自定义的Binder。先看一下这个方法简化后的源码：

sCache是一个Map，缓存了已经向系统请求过的Binder。如果我们需要让这个方法返回我们我们自己的binder，只需要事先往sCache中put一个自定义的Binder就行了。
在put之前，需要先创建出一个自定义的Binder。这个Binder在被 ILocationManager.Stub.asInterface 处理后，可以返回一个自定义的 LocationManagerService。
先看一下Binder的 asInterface() 的实现：

如果把 queryLocalInterface()方法返回一个自定义的Service，使得走if语句内部，不走else，那就算是Hook成功了。

假设我们想让系统的LocationManager返回的位置信息全是在天安门(116.23, 39.54)。那我们需要使得 LocatitionManagerService 的 getLastLocation() 方法 返回的全是 (116.23, 39.54)。
由于我们不能直接拿到系统的这个Service对象，可以先用反射的方式拿到系统的LocationManagerService。然后拦截getLastLocation()方法。

原生的Binder对象在调用 queryLocalInterface() 方法时会返回原生的Service对象。我们希望返回3.1中的自定义Service。所以这里拦截 queryLocalInterface() 方法。

有了自定义的Binder后，将它注入到ServiceManger的sCache变量中就完成Hook了~

当onClick被调用的时候，Toast和Log都会显示天安门的坐标(116.23, 39.54)。证明Hook成功！

你甚至可以用Binder Hook的方式Hook掉 ActivityManager 。

Android系统篇之----免root实现Hook系统服务拦截方法

技术概念来源：[ 360开源插件框架，项目地址：https://github.com/DroidPluginTeam/DroidPlugin ]

一、Binder机制回顾

在之前一篇文章中介绍了 Android中的Binder机制和系统远程服务调用机制，本文将继续借助上一篇的内容来实现Hook系统服务拦截指定方法的逻辑，了解了上一篇文章之后，知道系统的服务其实都是一个远程Binder对象，而这个对象都是由ServiceManager大管家管理的，用户在使用系统服务的时候，会通过指定服务的Stub方法的asInterface把远程的Binder对象转化成本地化对象即可使用，而在这个过程中，我们也知道因为系统服务是在system_server进程中的，所以这个系统服务使用过程中属于跨进程调用，那么返回的对象其实就是Proxy代理对象。

二、系统中服务使用流程

本文主要就是借助这个知识点，通过Hook系统的服务来拦截服务方法，下面我们就通过系统剪切板服务案例作为分析

这里看到了，使用系统服务的时候都是用了getSystemService方法，通过定义在Context中的服务描述符常量来获取服务对象，而getSystemService方法定义在ComtextImpl.java类中：

这里维护了一个ServiceFetcher的Map结构，看看这个结构在哪里填充数据的：

在registerService方法中添加一个服务名称和一个ServiceFetcher对象，而这个方法在静态代码块中进行调用的：

我们找到了ClipboardManager这个服务：

这里其实是一个ClipboardManager对象，其实这个对象是内部封装了IClipboard.Stub功能，可以看看其他的服务：

比如这里的联网服务，直接调用了IConnectivityManager.Stub类的asInterface方法获取Proxy对象。

下面就进去ClipboardManager.java中看看究竟：

看到这里的设置剪切板内容的方法，其实内部是调用了getService方法获取对象然后在调用指定方法，那么可以大概知道了这个getService方法返回的应该就是IClipboard.Stub通过asInterface方法返回的Proxy对象：

好吧，果然是这样，这里通过ServiceManager获取到Clipboard的远端IBinder对象，然后通过asInterface方法返回一个Proxy对象即可。

到这里我们就简单的分析完了系统中的获取剪切板的服务，其实系统中的服务都是这么个逻辑，只是有的可能会在外面包装一层罢了，下面总结一下流程：

现在只要记住一点：每次获取系统服务的流程都是一样的，先通过ServiceManager的getService方法获取远端服务的IBinder对象，然后在通过指定服务的Stub类的asInterface方法转化成本地可使用对象，而这个对象其实就是一个Proxy对象，在这个过程中，Stub类继承了Binder对象和实现了AIDL接口类型，Proxy对象实现了AIDL接口类型，而AIDL接口类型实现了IInterface接口类型。

三、Hook系统服务

上面分析完了Android中系统服务的使用流程以及原理解析，下面在来看一下Android中实现Hook机制的方法和原理解析，我们知道其实在很多系统中都存在这样一个Hook技术，有的也叫作钩子，但是不管任何系统，Hook技术的核心点都是一样的，只有两点即可完成Hook技术：

1、找到Hook点，即你想Hook哪个对象，那么得先找到这个对象定义的地方，然后使用反射获取到这个对象实例。所以这里可以看到，一般Hook点都是一个类的单例方法或者是静态变量，因为这样的话Hook起来就非常方便，都是static类型，反射调用都比较方便无需具体的实例对象即可。而关于这个点也是整个Hook过程中最难的点，因为很难找到这个点。Android中主要是依靠分析系统源码类来做到的。

2、构造一个Hook原始对象的代理类，关于这个代理其实在Java中有两种方式，一种是静态代理，一种是动态代理。

静态代理：代理类中维护一个原始对象的成员变量，每个方法调用之前调用原始对象的方法即可。无需任何条件限制

动态代理：比静态代理复杂点就是有一个规则：就是原始对象必须要实现接口才可以操作，原理是因为动态代理其实是自动生成一个代理类的字节码，类名一般都是Proxy$0啥的，这个类会自动实现原始类实现的接口方法，然后在使用反射机制调用接口中的所有方法。

案例使用就很简单了，下面我们通过源码分析这个原理：

主要调用了getProxyClass0方法生成代理类的字节码：

然后生成代理类：

看到这里，其实这里的生成字节码不是很复杂的，我们可以借助asm等工具包就可以手动的生成一个字节码，然后在使用类加载器加载即可，所以会发现需要传递类加载器。

当上面生成代理类之后，我们可以把这个类反编译看一下，看一下方法的调用，在代理类中的静态代码块：

会使用反射获取到类的所有方法。

然后在指定方法中调用传递进来的InvocationHandler的回调接口的invoke方法，就是这么实现的。

从源码角度分析完动态代理之后，发现其实没什么复杂的，就是手动的生成一个代理类，然后用反射获取类中所有的方法，在指定方法中用反射调用，同时回调InvocationHandler的invoke方法即可，所以这里看到InvocationHandler中的invoke方法的第一个参数对象是代理类对象。

注意：

在JavaWeb开发中我们会用到Spring框架中的AOP编程，其实他就是利用了Java中动态代理技术，但是他依赖的是CGlib的功能，不是采用Java原生的这种自动产生代理类，从上面可以看到能够做动态代理的类必须要实现一个接口，而这一个规则有时候要求非常高，很多类都没有实现接口，导致无法实现代理功能，所以Spring采用了cglib，原理其实差不多，他采用asm工具包也是手动生成一个类，但是这个类是原始对象的子类，这样也可以实现代理功能，但是这样一来也有一个限制了，那就是代理对象不能是final类型，同时一些主要方法最好不能是final类型的，当然这个限制和上面的那个接口实现限制比起来还是好点的。

到此我们了解了Java中的Hook技术的核心知识点了，下面就用开始的剪切板服务来做实验，我们Hook系统的剪切板服务功能，拦截其方法，上面也说道了，既然要Hook服务，首先得找到Hook点，通过开始对Android中系统服务的调用流程分析知道，其实这些服务都是一些保存在ServiceManager中的远端IBinder对象，这其实是一个Hook点：

其实ServiceManager中每次在获取服务的时候，其实是先从一个缓存池中查找，如果有就直接返回了：

而这个缓存池正好是全局的static类型，所以就可以很好的使用反射机制获取到他了，然后进行操作了。

接下来，我们就需要构造一个剪切板的服务IBinder对象了，然后在把这个对象放到上面得到的池子中即可。那么按照上面的动态代理的流程，

第一、原始对象必须实现一个接口，这里也正好符合这个规则，每个远程服务其实是实现了IBinder接口的。

第二、其次是要有原始对象，这个也可以，通过上面的缓存池即可获取

有了这两个条件那么接下来就可以使用动态代理构造一个代理类了：

通过反射去获取ServiceManager中的缓存池Binder对象就不多说了，完全反射机制即可，我们先获取到缓存池，然后得到剪切板服务Binder对象，构造一个代理类，最后在设置回去即可。下面主要来看一下构造了代理类之后，如何拦截哪些方法？

这里一定要注意了，有的同学可能想直接在这里拦截setPrimaryClip这样的剪切板方法不就可以了吗？想想是肯定不可以的，为什么呢？因为我们现在代理的是远端服务的Binder对象，他还没有转化成本地对象呢？如何会有这些方法呢，而我们真正要拦截的方法是IClipboardManager，其实就是Proxy类，而这个对象也是Stub类的asInterface方法得到的，所以我们现在的思路是有了远端服务的代理对象，拦截肯定是拦截这个代理对象Binder的一些方法，那么这个远端服务有哪些方法会在这个过程中被调用呢？我们再看看之前的一个简单AIDL的例子：

在asInterface方法中可以看到，传递进来的就是一个远端服务IBinder对象，这里会先调用它的queryLocalInerface方法获取本进程的本地化对象，那么这个方法就是拦截的目标了。

然后在想，我们如果想拦截IClipboardManager的setPrimaryClip方法，其实就是要拦截ClipboardManager$Proxy的这些方法，那么还需要做一次代理，代理ClipboardManager$Proxy类对象

第一、ClipboardManager$Proxy类实现了AIDL接口类型，符合规则。

第二、我们可以直接使用反射获取到IClipboardManager$Stub类，然后反射调用它的asInterface方法就可以得到了IClipboardManager$Proxy对象了，符合规则。

到这里，看来这个对象也符合了代理的条件，那么就简单了，继续使用动态代理机制产生一个代理类即可：

这个代理类的InvocationHandler中，先需要通过反射获取到Proxy原始对象：

最后才开始实现拦截操作。

下面来看一个实验结果：

我们调用系统的剪切板服务，但是返回的结果却是：

看到了，这里的剪切板的内容已经被之前拦截，内容也被替换了。

上面就全部介绍了如何Hook系统的剪切板服务功能，流程如下：

1、我们的目的就是拦截系统的服务功能，那么最开始的入口就是服务大管家ServiceManager对象，而在他内部也正好有一个远端服务对象的IBinder缓存池，那么这个变量就是我们操作的对象了，可以先使用反射机制去获取到他，然后在获取到指定的剪切板服务IBinder对象实例。

2、下一步肯定是Hook这个剪切板服务的Binder对象，这里采用动态代理方式产生一个Binder对象代理类，符合两个规则：

1》这个Binder对象实现了IBinder接口类型

2》我们已经得到了原始的Binder对象实例

构造完代理类之后，我们拦截的方法是queryLocalInterface方法，为什么是这个方法呢？因为在整个服务使用过程中之后在Stub类中使用到了这个方法，很多同学会认为为什么不在这里直接拦截系统方法呢？这是一个误区，要想清楚，这里的代理对象是远程服务的Binder，还不是本地化对象，不能会有哪些系统方法的，所以得再做一次Hook，去Hook住系统的本地化对象。

3、在拦截了Binder对象的queryLocalInterface方法之后，再一次做一下本地化服务对象的代理生成操作，而这个本地化对象一般都是IClipboard$Proxy，那么动态代理的规则：

1》本地化服务对象都会实现AIDL接口类型(这里才有哪些我们想拦截的系统方法)

2》通过反射调用IClipboard$Stub类的asInterface方法得到IClipboard$Proxy类对象实例

符合这两个规则那么就可以产生代理对象了，然后开始拦截服务的指定方法即可。

上面总结的这个流程是可以完全用于其他系统服务的Hook工作的，因为系统服务的机制都是一致的，所以这个流程一定要理解清楚，后面的工作才好进行。

四、补充说明

有的同学可能会好奇询问，这个Hook系统服务貌似只对本应用有效吧？哈哈，的确是这样的，上面的拦截只会对本应用有效，那有的同学会问，只对本应用有效意义就不是很大的，其实这个要看个人需求了，后面会介绍一些开发中遇到的问题，就需要借助这个技术去解决了，但是真正能够拦截系统的服务对所有的应用有效，其实想想实现也不难，因为应用都会请求服务，而所有的服务都在system_server进程中，那么就可以采用root之后，注入system_server进程，那时候在开始Hook工作即可完成真正意义上的拦截操作，这个用途就大了，比如我们可以修改系统的经纬度信息，伪造假的当前位置信息，篡改设备的IMEI值，让有的游戏识别唯一设备无效等。但是这个就需要root了之后才可以操作了，具体方案感兴趣的同学可以去这里看看：Android中注入系统进程实现拦截

五、总结

到这里我们就介绍完了Android中Hook系统服务的流程，本文中主要介绍了Hook系统剪切板服务，拦截指定方法，其实后面还会继续介绍拦截AMS和PMS服务，实现应用启动的拦截操作，达到我们想要的效果。

更多内容：点击这里

关注微信公众号，最新技术干货实时推送