-
-
[原创]【Android】深入底层Binder拦截
-
发表于: 2023-11-30 20:05
-
Android平台进程Binder通信的动态分析和拦截。
说明
Binder作为Android系统跨进程通信的核心机制。网上也有很多深度讲解该机制的文章，如：
这些文章和系统源码可以很好帮助我们理解Binder的实现原理和设计理念，为拦截做准备。借助Binder拦截可以我们可以扩展出那些能力呢：
- 虚拟化的能力，多年前就出现的应用免安装运行类产品如：
VirtualApp/DroidPlugin/平行空间/双开大师/应用分身等。 - 测试验证的能力，通常为
Framework层功能开发。 - 检测第三方
SDK或模块系统服务调用访问情况（特别是敏感API调用）。 - 逆向分析应用底层服务接口调用实现。
- 第三方
ROM扩展Framework服务。
现有方案
一直以来实时分析和拦截进程的Binder通信是通过Java层的AIDL接口代理来实现的。借助于Android系统Binder服务接口设计的规范，上层的接口均继承于IBinder。
如一下为代理目标对象的所有的接口API的方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Proxy;
private static void getInterface(Class cls, final HashSet
Class[] ii;
do {
ii = cls.getInterfaces();
for (final Class i : ii) {
if (ss.add(i)) {
getInterface(i, ss);
}
}
cls = cls.getSuperclass();
} while (cls != null);
}private static Class[] getInterfaces(Class cls) {
final HashSetnew LinkedHashSet
getInterface(cls, ss);
if (0 < ss.size()) {
return ss.toArray(new Class[ss.size()]);
}
return null;
}public static Object createProxy(Object org, InvocationHandler cb) {
try {
Class cls = org.getClass();
Class[] cc = getInterfaces(cls);
return Proxy.newProxyInstance(cls.getClassLoader(), cc, cb);
} catch (Throwable e) {
Logger.e(e);
} finally {
// TODO release fix proxy name
}
return null;
} |
1、对于已经生成的Binder服务对象，在应用进程可参与实现逻辑之前就已经缓存了，我们需要找到并且进行替换（AMS、PMS、WMS等），如AMS在Android 8.0之后的缓存如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
// source code: http://aospxref.com/android-9.0.0_r61/xref/frameworks/base/core/java/android/app/ActivityManager.javapackage android.app;
public class ActivityManager {
public static IActivityManager getService() {
return IActivityManagerSingleton.get();
}
private static final Singleton
new Singleton
@Override
protected IActivityManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_SERVICE);
final IActivityManager am = IActivityManager.Stub.asInterface(b);
return am;
}
};
} |
因此我们需要找到并且替换它，如：
|
1
2
3
4
5
6
7
8
|
Object obj;if (Build.VERSION.SDK_INT < 26) {// <= 7.0
obj = ReflectUtils.getStaticFieldValue("android.app.ActivityManagerNative", "gDefault");
} else {// 8.0 <=
obj = ReflectUtils.getStaticFieldValue("android.app.ActivityManager", "IActivityManagerSingleton");
}Object inst = ReflectUtils.getFieldValue(obj, "mInstance");
ReflectUtils.setFieldValue(obj, "mInstance", createProxy(inst));
|
2、对于后续运行过程中才获取的Binder服务，则需要代理ServiceManager，源码如下：
|
1
2
3
4
5
6
7
8
|
// source code: http://aospxref.com/android-9.0.0_r61/xref/frameworks/base/core/java/android/os/ServiceManager.javapackage android.os;
public final class ServiceManager {
private static final String TAG = "ServiceManager";
private static IServiceManager sServiceManager;
} |
因此我们的代理如下：
|
1
2
3
4
5
6
|
Class cls = ReflectUtils.findClass("android.os.ServiceManager");
Object org = ReflectUtils.getStaticFieldValue(cls, "sServiceManager");
Object pxy = new createProxy(org);
if (null != pxy) {
ReflectUtils.setStaticFieldValue(getGlobalClass(), "sServiceManager", pxy);
} |
这样每次在第一次访问该服务时，就会调用IServiceManager中的getService的方法，而该方法已经被我们代理拦截，我们可以通过参数可以识别当前获取的是哪个服务，然后将获取的服务对象代理后在继续返回即可。
但是：这样的方案并不能拦截进程中所有的Binder服务。我们面临几大问题：
-
首先，Android源码越来越庞大，了解所有的服务工作量很大，因此有哪些服务已经被缓存排查非常困难。
-
其次，厂商越来越钟情于扩展自定义服务，这些服务不开源，识别和适配更加耗时。
-
再次，有一部分服务只有
native实现，并不能通过Java层的接口代理进行拦截（如：Sensor/Audio/Video/Camera服务等）。1234567891011121314151617181920// source code: http://aospxref.com/android-13.0.0_r3/xref/frameworks/av/camera/ICamera.cppclassBpCamera:publicBpInterface{public:explicitBpCamera(constsp& impl) : BpInterface(impl) {}// start recording mode, must call setPreviewTarget firststatus_t startRecording(){ALOGV("startRecording");Parcel data, reply;data.writeInterfaceToken(ICamera::getInterfaceDescriptor());remote()->transact(START_RECORDING, data, &reply);returnreply.readInt32();}}
新方案：基于底层拦截
原理
我们都知道Binder在应用进程运行原理如下图：
不管是Java层还是native层的接口调用，最后都会通过ioctl函数访问共享内存空间，达到跨进程访问数据交换的目的。因此我们只要拦截ioctl函数，即可完成对所有Binder通信数据的拦截。底层拦截有以下优势：
1）可以拦截所有的Binder通信。
2）底层拦截稳定，高兼容性。从Android 4.x至Android 14，近10年的系统版本演进，涉及到Binder底层通信适配仅两次；一次是支持64位进程（当时需要同时兼容32位和64位进程访问Binder服务）。另一次是华为鸿蒙系统的诞生，华为ROM在Binder通信协议中增加了新的标识字段。
要解决的问题
如何拦截
C/C++层的函数拦截，并不像Java层一样系统提供了较为稳定的代理工具，在这里不是我们本期讨论的重点，可以直接采用网上开源的Hook框架：
- https://github.com/bytedance/android-inline-hook
- https://github.com/bytedance/bhook
- https://github.com/asLody/whale
如何过滤
ioctl函数为系统底层设备访问函数，调用及其频繁，而Binder通信调用只是其中调用者之一，因此需要快速识别非Binder通信调用，不影响程序性能。
函数定义：
|
1
2
3
|
#include int ioctl(int fildes, unsigned long request, ...);
|
request的参数定义：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
// source code: http://aospxref.com/android-14.0.0_r2/xref/bionic/libc/kernel/uapi/linux/android/binder.h#define BINDER_WRITE_READ _IOWR('b', 1, struct binder_write_read)#define BINDER_SET_IDLE_TIMEOUT _IOW('b', 3, __s64)#define BINDER_SET_MAX_THREADS _IOW('b', 5, __u32)#define BINDER_SET_IDLE_PRIORITY _IOW('b', 6, __s32)#define BINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)#define BINDER_THREAD_EXIT _IOW('b', 8, __s32)#define BINDER_VERSION _IOWR('b', 9, struct binder_version)#define BINDER_GET_NODE_DEBUG_INFO _IOWR('b', 11, struct binder_node_debug_info)#define BINDER_GET_NODE_INFO_FOR_REF _IOWR('b', 12, struct binder_node_info_for_ref)#define BINDER_SET_CONTEXT_MGR_EXT _IOW('b', 13, struct flat_binder_object)#define BINDER_FREEZE _IOW('b', 14, struct binder_freeze_info)#define BINDER_GET_FROZEN_INFO _IOWR('b', 15, struct binder_frozen_status_info)#define BINDER_ENABLE_ONEWAY_SPAM_DETECTION _IOW('b', 16, __u32)#define BINDER_GET_EXTENDED_ERROR _IOWR('b', 17, struct binder_extended_error) |
对应的源码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
// source code: http://aospxref.com/android-14.0.0_r2/xref/frameworks/native/libs/binder/IPCThreadState.cppvoid IPCThreadState::threadDestructor(void *st) {
ioctl(self->mProcess->mDriverFD, BINDER_THREAD_EXIT, 0);
}status_t IPCThreadState::getProcessFreezeInfo(pid_t pid, uint32_t *sync_received, uint32_t *async_received) { return ioctl(self()->mProcess->mDriverFD, BINDER_GET_FROZEN_INFO, &info);
}status_t IPCThreadState::freeze(pid_t pid, bool enable, uint32_t timeout_ms) {
return ioctl(self()->mProcess->mDriverFD, BINDER_FREEZE, &info) < 0);
}void IPCThreadState::logExtendedError() {
ioctl(self()->mProcess->mDriverFD, BINDER_GET_EXTENDED_ERROR, &ee) < 0);
}status_t IPCThreadState::talkWithDriver(bool doReceive) {
// 实际Binder调用通信
return ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr);
} |
快速过滤：
|
1
2
3
4
5
|
static int ioctl_hook(int fd, int cmd, void* arg) {
if (cmd != BINDER_WRITE_READ || !arg || g_ioctl_disabled) {
return g_ioctl_func(fd, cmd, arg);
}
} |
如何解析
目标源码：http://aospxref.com/android-14.0.0_r2/xref/frameworks/native/libs/binder
重点解析发送（即BC_TRANSACTION和BC_REPLY）和接收（即BR_TRANSACTION和BR_REPLY）的类型数据。
如何修改数据
修改数据分为以下几种：
1）修复调用时参数数据。
2）修复调用后返回的结果数据。
如果数据修复不改变当前数据的长度，只是内容的变化，则可以直接通过地址进行修改。否则需要创建新的内存进行修改后将新的数据地址设置到BINDER_WRITE_READ结构的buffer成员。此时处理好内存的释放问题。
3）直接拦截本次调用。
为了保障稳定性，不打断Binder的调用流程（通常这也是拦截和逆向方案保障稳定的最重要原则之一）。我们可以将目标函数code修改成父类处理的通用方法，然后通过修复调用的返回值即可完成拦截。
方案实现
[招生]科锐逆向工程师培训(2025年3月11日实地，远程教学同时开班, 第52期)！
最后于 2023-12-1 09:42
被Tiony.bo编辑
，原因：
赞赏记录
参与人
雪币
留言
时间
东方玻璃
为你点赞！
2025-1-16 23:05
养只猫不好么
+2
感谢你的积极参与，期待更多精彩内容！
2024-9-18 13:41
sinker_
非常支持你的观点！
2024-8-20 02:17
[軍]
为你点赞~
2024-5-14 10:18
slcn
为你点赞~
2024-3-14 08:17
不吃早饭
为你点赞~
2024-2-23 13:54
jilay
为你点赞~
2024-2-20 10:08
PLEBFE
为你点赞~
2024-1-3 03:41
简单的简单
为你点赞~
2023-12-27 11:17
zhczf
为你点赞~
2023-12-20 00:56
初恒
为你点赞~
2023-12-11 10:52
狄人3
为你点赞~
2023-12-4 14:01
你瞒我瞒
为你点赞~
2023-12-4 11:18
mb_rjdrqvpa
为你点赞~
2023-12-4 10:39
Yuan!
为你点赞~
2023-12-4 09:27
vay
为你点赞~
2023-12-3 09:16
小旺不正经
为你点赞~
2023-12-3 08:57
jiavjiav
为你点赞~
2023-12-1 09:50
zhuzhu_biu
为你点赞~
2023-12-1 08:06
神逗士
为你点赞~
2023-11-30 20:22
Tiony.bo
为你点赞~
2023-11-30 20:07
|
|
|---|---|
|
|
|
|
|
学习了
|
|
|
|
|
|
学习了
|
|
|
|
|
|
|
|
|
|
|
|
学习了
|
|
|
正如文中所说，Java层的HOOK无法拦截native层的Binder通信 |
|
|
|
|
|
|
|
|
|
|
|
感谢您的关注，就像文中所说，在Server端拦截实现的确可以达到目的，但是只能采用开源的AOSP的ROM定制，或者ROOT系统，方案量，没办法通用，同样面临厂商定制的服务无法识别的问题。 |
|
|
第三方ROM可以通过本框架拦截后找到对应的类和方法（仅Java层方法）。 适用场景并不太多，就像文中所说的，插件化方案的开发和适配，应用或SDK的服务端访问监测，免安装运行方案的开发和适配，应用运行时动态分析等。本方案的优势就是轻量，且兼容性好。 后面会上线应用重封装项目，免安装项目，都会用到，届时再和大家一起分享。 |
|
|
好的。感觉simple输出的太过于简单。希望后期优化。感觉用的上。 |
|
|
不需要那么麻烦，用magisk模块，实现热插拔，编译个驱动内核注入就行了。 |
|
|
|
|
|
酷，已Star |
|
|
哈哈，支持 |
|
|
确实牛逼
|
|
|
你好大牛，有已实现好的获取小米oaid吗？qq：876529930 |
|
|
|
|
|
确实，非常详细，学习了 |
|
|
|
