Android应用程序拍照行为C层拦截实现
一、Binder简介
Android平台的进程之间需要频繁的通信，比如打开一个应用便需要Home应用程序进程和运行在system_server进程里的AcitivityManagerService通信才能打开。故此对进程间通信机制要求比较高，速度要快，还要能进行复杂数据的交换，应用开发时应尽可能简单，并能提供同步调用。Android中进程间通信用binder机制来实现。
Binder是一种高效且易用的IPC机制。
(1) Client/Server通信模型
(2) 用驱动程序来推进进程间的通信方式
(3) 通过共享内存来提高性能
(4) 为进程请求分配每个进程的线程池，每个应用进程默认启动两个binder服务线程
(5) 进程间同步调用
Binder通信模型如图1所示，Client和Server存在于用户空间。Client与Server通信的实现，是由Binder驱动在内核空间实现。Service Manager作为守护进程，处理客户端请求，管理所有服务项。
Server进程启动时，将在本进程内运行的Service注册到Service Manager中，并且启动一个Binder线程池，用来接收Client进程请求。
Client进程向Service Manager查询所需要的Service，并且获得相应Binder句柄，通过该句柄即可向Service发送请求。
图1 Binder进程间通信模型
统观binder中的各个组成元素，就会发现它和TCP/IP网络有很多相似之处。
Binder驱动 ----> 路由器
Service Manager ----> DNS
Binder Client ----> 客户端
Binder Server ----> 服务器
图2 一个典型的TCP/IP访问过程
Client向DNS查询google.com的IP地址，DNS将查询结果返回client，client在得到google.com的IP地址后就可以据此向google服务器发起连接了。在这一系列流程中，router所担负的责任是将数据包投递到用户设定的目标IP中，即router是整个通信结构中的基础。对于IP层及以上的用户来说，IP地址是他们彼此沟通的凭证——任何用户在整个互联网中的IP标志符都是唯一的。而DNS角色并不是必需的，它的出现是为了帮助人们使复杂难记的IP地址与可读性更强的域名建立关联，并提供查询功能。客户端能使用DNS的前提是它已经正确配置了DNS服务器的IP地址。
将网络通信中各个功能模块与binder做对比。
和TCP/IP网络类似，binder中的“DNS”也并不是必需的——前提是客户端能记住它要访问的进程的binder句柄（IP地址）；而且要特别注意这个句柄是“动态IP”，这就意味着即使客户端记住了本次通信过程中目标进程的唯一句柄，下一次访问仍然需要重新获取，这无疑加大了客户端的难度。“DNS”的出现可以完美解决这个问题，用于管理binder句柄与可读性更强的“域名”间的对应关系，并向用户提供查询功能。
Binder机制中的DNS角色就是service manager，其在binder通信过程中的唯一句柄永远都是0。
前文所述Binder为进程请求分配每个进程的线程池，每个应用进程默认启动两个binder服务线程。如下图所示。
图3 EclipseDDMS视图
ID：虚拟机分配的唯一线程ID
Tid：linux的线程ID号
Status：线程状态
native：正在执行native代码
wait：等待被其他线程唤醒
vmwait ：正在等待一个虚拟机资源
utime：执行用户代码的累计时间
stime： 执行系统代码的累计时间
每个应用进程最多只能创建15个binder线程。
二、Binder驱动原理
Binder用驱动程序来推进进程间的通信方式。
(1) 将自己注册成一个misc device，并向上层提供一个设备文件节点/dev/binder，其实现遵循Linux设备驱动模型。
(2) 目的：将内核内存的一块作为字符设备，用户可通过这些调用来读写这段内存。
1、 Binder_open
打开/dev/binder节点，binder驱动会在/proc系统目录下生成各种管理信息(如/proc/binder/proc,/proc/binder/state,/proc/binder/stats)，其中proc对象就是管理数据的记录体（每个进程都有独立记录）。
binder_proc：用于描述当前操作Binder的进程的上下文状态，比如内存信息、线程信息、进程优先级等。Binder驱动的open()函数被调用后就会创建一个binder_proc结构，这样的结构针对于每个进程都是唯一的。
2、 Binder_mmap
Binder的设备内存是在mmap操作时分配的，分配的方法是先在内核虚拟映射表上获取一个可以使用的区域，然后分配物理页，并把物理页映射到获取的虚拟空间上。
Binder设备最大能映射4M的内存区域，但它并没有全部分配物理内存，其实只是分配了一个页的物理内存。如图4所示，进程B执行mmap()后，Binder和应用程序拥有了若干共用的物理内存块。
图4 进程B执行mmap()后
如图5所示，Binder驱动通过copy_from_user()把进程A中的某段数据复制到其binder_proc->buffer所指向的内存空间中。进程B就能够读取数据。可知，Binder驱动只用了一次复制。
图5 进程A复制数据到进程B中
3、 Binder_ioctl
binder_write_read bwr;
if(ioctl(mProcess->mDriverFD, BINDER_WRITE_READ, &bwr) >= 0)
err = NO_ERROR;
参数1是用户程序打开设备时使用open函数返回的文件标识符。
参数2是用户程序对设备的控制命令。
参数3是用户态与内核态进行交互的数据结构。
Binder IOCTL码
作用
BINDER_WRITE_READ
完成对/dev/binder的读写操作，这会是最频繁的Binder IOCTL操作
BINDER_SET_IDLE_TIMEOUT
设置IDLE超时
BINDER_SET_MAX_THREADS
设置当前Binder实例可用的最大线程数
BINDER_SET_IDLE_PRIORITY
设置Binder在进程处于IDLE时的进程优先级
BINDER_SET_CONTEXT_MGR
让自己成为Binder的管理者，只有servicemanager会用到
BINDER_THREAD_EXIT
退出Binder处理的内核线程
BINDER_VERSION
返回Binder驱动的当前版本
binder_write_read结构体中的read_buffer和write_buffer字段分别指向将要读取或者写入的缓冲区。这两个缓冲区中的数据都是以“数据类型+数据内容”的格式顺序存放的，而且多条不同类型的数据连续存放。数据类型分为BC_*系列和BR_*系列。
BC_*系列，Binder Command的简称，说明用户态给Binder驱动发出的命令；
BR_*系列，Binder Return的简称，说明是Binder驱动给用户态发回的操作结果反馈。
在binder_write_read操作时，无论是读还是写，都可以使用同一个BINDER_WRITE_READ的ioctl()，同时处理多个命令，同时包装多个BC_命令发多个命令到Binder驱动，或是通过一次ioctl()读出来多个返回结果，这样也节约了系统调用时的开销。
无论是TRANSACTION还是REPLY，通过ioctl()来操作时，使用的参数都会是一个叫binder_transaction_data的数据结构的指针。binder_transaction_data结构体描述Binder传输时的特征信息。
struct binder_transaction_data {
union {
size_t handle;
void *ptr;
} target;
void *cookie;
unsigned int code;
unsigned int flags;
pid_t sender_pid;
uid_t sender_euid;
size_t data_size;
size_t offsets_size;
union {
struct {
const void *buffer;
const void *offsets;
} ptr;
uint8_t buf[8];
} data;
};
通过BC_系列命令向Binder驱动发出操作请求时，需要target.handle指定到需要访问的Binder对象。
通过BR_系列命令从Binder驱动里读回返回值时，需要指定返回的一段地址，target.ptr则会指向这个地址空间。
code便是编写AIDL和Native Service的IBinder命令，由IBinder::FIRST_CALL_TRANSACTION开始的命令序列。
sender_euid和sender_pid是在内核中由Binder驱动填入的，无法被伪造，保证了身份标记的可靠性。
当需要包含额外的数据负载时，由data来保存缓冲区的首地址与偏移。data.ptr.buffer指向首地址，data.ptr.offsets指向具体的偏移量。
通过这样的binder_transaction_data，就可以很精确地描述在某一次Binder IPC传递过程里需要做什么操作（target定位到对象、code定位到方法），操作的数据在什么地方（data_size、data_size、offsets_size定位作为参数的对象）。在这些信息里还会包含发起请求的pid、euid等信息，可进一步用于权限控制。
三、应用拍照行为C层拦截实现
Mediaserver进程提供了Android上的多媒体服务，这个进程通过binder的进程间通信方式来完成其他进程（如音乐播放器、录音、拍照）的请求。实现应用拍照行为的C层拦截，其主要技术难点有进程注入技术、binder通信拦截、binder通信数据包解析。前两个技术网上已有好多源码提供（见参考资料），现对应用程序拍照过程中的binder通信数据包进行解析。
int ioctl_hooked (int __fd, unsigned longint __request, void * arg)
{
if( __request == BINDER_WRITE_READ )
{
struct binder_write_read* tmp = (structbinder_write_read*) arg;
signed long read_size = tmp->read_size;
if(read_size > 0)
{
int already_got_size = 0;
unsigned long *pret = 0;
while(already_got_size < read_size) //循环处理buffer中的每一个命令
{
pret = (unsigned long*)(tmp->read_buffer + already_got_size); //指针后移
int code = pret[0];
int size = _IOC_SIZE(code);
struct binder_transaction_data*pdata = (structbinder_transaction_data*)(&pret[1]);
char process_name[256];
if (get_process_name_of_pid(pdata->sender_pid, process_name) <0)
{
process_name[0] = ' ';
}
struct binder_txn txn;
struct binder_io msg;
unsigned len;
uint16_t *s;
const char * descriptor;
txn.data = malloc(pdata->data_size);
memcpy(txn.data, pdata->data.ptr.buffer,pdata->data_size);
txn.offs = NULL;
init_txn(pdata, &txn);
bio_init_from_txn(&msg, &txn);
s = bio_get_string16(&msg, &len);
descriptor = str8(s);
switch (code)
{
case BR_TRANSACTION:
LOGV("pid:%d, BR_TRANSACTION, euid:%d, code:%d, size:%dn", pdata->sender_pid,pdata->sender_euid, pdata->code, size);
LOGV("process%d:%s--string:%s", pdata->sender_pid, process_name, descriptor);
break;
}
already_got_size += (size+4);//数据内容加上命令码
}
}
}
return (*ioctl)(__fd,__request, arg);
}
首先向已运行的系统进程/system/bin/mediaserver中注入自己开发的动态库libhook.so，用于替换系统的ioctl函数为上述的ioctl_hooked函数。然后打开三星自带的照相机，得到如下的log信息。
在/frameworks/av/camera/ICamera.cpp文件中找到code对应的函数。
enum {
DISCONNECT = IBinder::FIRST_CALL_TRANSACTION,
SET_PREVIEW_TARGET,
SET_PREVIEW_CALLBACK_FLAG,
SET_PREVIEW_CALLBACK_TARGET,
START_PREVIEW,
STOP_PREVIEW,
AUTO_FOCUS,
CANCEL_AUTO_FOCUS,
TAKE_PICTURE,
SET_PARAMETERS,
GET_PARAMETERS,
SEND_COMMAND,
CONNECT,
LOCK,
UNLOCK,
PREVIEW_ENABLED,
START_RECORDING,
STOP_RECORDING,
RECORDING_ENABLED,
RELEASE_RECORDING_FRAME,
STORE_META_DATA_IN_BUFFERS,
};
可得，code=9,data.ptr.buffer里的数据为”android.hardware.ICamera”时，表示某个应用程序调用了takePicture()函数，即发生了拍照行为。将调用部分函数的进程都记录下来，代码如下所示：
time_t rawtime;
struct tm*timeinfo;
time (&rawtime );
timeinfo =localtime ( &rawtime );
int ppid =getPPidByPid(pdata->sender_pid);
if(pdata->code== 5 && strcmp(descriptor, "android.hardware.ICamera") == 0)
{
LOGV("%s,%d,%s,%d,START_PREVIEW",asctime(timeinfo), pdata->sender_pid, process_name, ppid);
}
if(pdata->code== 9 && strcmp(descriptor, "android.hardware.ICamera") == 0)
{
LOGV("%s,%d,%s,%d,TAKE_PICTURE",asctime(timeinfo), pdata->sender_pid, process_name, ppid);
}
if(pdata->code== 6 && strcmp(descriptor, "android.hardware.ICamera") == 0)
{
LOGV("%s,%d,%s,%d,STOP_PREVIEW",asctime(timeinfo), pdata->sender_pid, process_name, ppid);
}
if(pdata->code== 1&& strcmp(descriptor, "android.hardware.ICamera") == 0)
{
LOGV("%s,%d,%s,%d,DISCONNECT",asctime(timeinfo), pdata->sender_pid, process_name, ppid);
}
在程序中添加上述代码，分别开启美图秀秀的照相功能和三星手机自带的照相机并按下拍照键，可得如下的log信息。
log信息中已记录了美图秀秀（com.mt.mtxx.mtxx）和三星手机自带的照相机（com.sec.android.app.camera）拍照的时间、pid、ppid和进程名。
同时也发现system_server进程隔一段时间就会打开摄像头。这是因为三星打开了智能屏幕的功能。
四、参考资料
[1] Android下通过root实现对system_server中binder的ioctl调用拦截 http://bbs.pediy.com/showthread.php?t=157419
[2] Android利用ptrace实现Hook API http://blog.csdn.net/u013234805/article/details/24796515
[3] Andrdoid中对应用程序的行为拦截实现方式之----从底层C进行拦截http://blog.csdn.net/jiangwei0910410003/article/details/39346151
[4] Service与Android系统设计（7）--- Binder驱动http://blog.csdn.net/21cnbao/article/details/8087354
[5] AndroidXRef：http://androidxref.com/