菜单

微信公众号:Android安全中文站

文章

Home 安卓漏洞攻防 彻底理解Android Binder通信架构
Home 安卓漏洞攻防 彻底理解Android Binder通信架构

彻底理解Android Binder通信架构

安卓漏洞攻防, 安卓逆向分析 by

基于Android 6.0的源码剖析, 本文深度剖析Binder IPC过程, 这绝对是一篇匠心巨作,从Java framework到Native,再到Linux Kernel,带你全程看Binder通信过程.

一. 引言

1.1 Binder架构的思考

Android内核是基于Linux系统, 而Linux现存多种进程间IPC方式:管道, 消息队列, 共享内存, 套接字, 信号量, 信号. 为什么Android非要用Binder来进行进程间通信呢. 从我个人的理解角度, 曾尝试着在知乎回答同样一个问题 为什么Android要采用Binder作为IPC机制?. 这是我第一次认认真真地在知乎上回答问题, 收到很多网友的点赞与回复, 让我很受鼓舞, 也决心分享更多优先地文章回报读者和粉丝, 为Android圈贡献自己的微薄之力. (当然,如果你愿意点击文章最后打赏支持我,我会更高兴.^_^)

在说到Binder架构之前, 先简单说说大家熟悉的TCP/IP的五层通信体系结构:

彻底理解Android Binder通信架构

  • 应用层: 直接为用户提供服务;
  • 传输层: 传输的是报文(TCP数据)或者用户数据报(UDP数据)
  • 网络层: 传输的是包(Packet), 例如路由器
  • 数据链路层: 传输的是帧(Frame), 例如以太网交换机
  • 物理层: 相邻节点间传输bit, 例如集线器,双绞线等

这是经典的五层TPC/IP协议体系, 这样分层设计的思想, 让每一个子问题都设计成一个独立的协议, 这协议的设计/分析/实现/测试都变得更加简单:

  • 层与层具有独立性, 例如应用层可以使用传输层提供的功能而无需知晓其实现原理;
  • 设计灵活, 层与层之间都定义好接口, 即便层内方法发生变化,只有接口不变, 对这个系统便毫无影响;
  • 结构的解耦合, 让每一层可以用更适合的技术方案, 更合适的语言;
  • 方便维护, 可分层调试和定位问题;

Binder架构也是采用分层架构设计, 每一层都有其不同的功能:

彻底理解Android Binder通信架构

  • Java应用层: 对于上层应用通过调用AMP.startService, 完全可以不用关心底层,经过层层调用,最终必然会调用到AMS.startService.
  • Java IPC层: Binder通信是采用C/S架构, Android系统的基础架构便已设计好Binder在Java framework层的Binder客户类BinderProxy和服务类Binder;
  • Native IPC层: 对于Native层,如果需要直接使用Binder(比如media相关), 则可以直接使用BpBinder和BBinder(当然这里还有JavaBBinder)即可, 对于上一层Java IPC的通信也是基于这个层面.
  • Kernel物理层: 这里是Binder Driver, 前面3层都跑在用户空间,对于用户空间的内存资源是不共享的,每个Android的进程只能运行在自己进程所拥有的虚拟地址空间, 而内核空间却是可共享的. 真正通信的核心环节还是在Binder Driver.

1.2 分析起点

前面通过一个Binder系列-开篇来从源码讲解了Binder的各个层面, 但是Binder牵涉颇为广泛, 几乎是整个Android架构的顶梁柱, 虽说用了十几篇文章来阐述Binder的各个过程. 但依然还是没有将Binder IPC(进程间通信)的过程彻底说透.

Binder系统如此庞大, 那么这里需要寻求一个出发点来穿针引线, 一窥视Binder全貌. 那么本文将从全新的视角,以startService流程分析为例子来说说Binder所其作用. 首先在发起方进程调用AMP.startService,经过binder驱动,最终调用系统进程AMS.startService,如下图:

彻底理解Android Binder通信架构

AMP和AMN都是实现了IActivityManager接口,AMS继承于AMN. 其中AMP作为Binder的客户端,运行在各个app所在进程, AMN(或AMS)运行在系统进程system_server.

1.3 Binder IPC原理

Binder通信采用C/S架构,从组件视角来说,包含Client、Server、ServiceManager以及binder驱动,其中ServiceManager用于管理系统中的各种服务。下面说说startService过程所涉及的Binder对象的架构图:

彻底理解Android Binder通信架构

可以看出无论是注册服务和获取服务的过程都需要ServiceManager,需要注意的是此处的Service Manager是指Native层的ServiceManager(C++),并非指framework层的ServiceManager(Java)。ServiceManager是整个Binder通信机制的大管家,是Android进程间通信机制Binder的守护进程,Client端和Server端通信时都需要先获取Service Manager接口,才能开始通信服务, 当然查找懂啊目标信息可以缓存起来则不需要每次都向ServiceManager请求。

图中Client/Server/ServiceManage之间的相互通信都是基于Binder机制。既然基于Binder机制通信,那么同样也是C/S架构,则图中的3大步骤都有相应的Client端与Server端。

  1. 注册服务:首先AMS注册到ServiceManager。该过程:AMS所在进程(system_server)是客户端,ServiceManager是服务端。
  2. 获取服务:Client进程使用AMS前,须先向ServiceManager中获取AMS的代理类AMP。该过程:AMP所在进程(app process)是客户端,ServiceManager是服务端。
  3. 使用服务: app进程根据得到的代理类AMP,便可以直接与AMS所在进程交互。该过程:AMP所在进程(app process)是客户端,AMS所在进程(system_server)是服务端。

图中的Client,Server,Service Manager之间交互都是虚线表示,是由于它们彼此之间不是直接交互的,而是都通过与Binder Driver进行交互的,从而实现IPC通信方式。其中Binder驱动位于内核空间,Client,Server,Service Manager位于用户空间。Binder驱动和Service Manager可以看做是Android平台的基础架构,而Client和Server是Android的应用层.

这3大过程每一次都是一个完整的Binder IPC过程, 接下来从源码角度, 仅介绍第3过程使用服务, 即展开AMP.startService是如何调用到AMS.startService的过程.

Tips: 如果你只想了解大致过程,并不打算细扣源码, 那么你可以略过通信过程源码分析, 仅看本文第一段落和最后段落也能对Binder所有理解.

二. 通信过程

2.1 AMP.startService

[-> ActivityManagerNative.java ::ActivityManagerProxy]


 

主要功能:

  • 获取或创建两个Parcel对象,data用于发送数据,reply用于接收应答数据.
  • 将startService相关数据都封装到Parcel对象data, 其中descriptor = “android.app.IActivityManager”;
  • 通过Binder传递数据,并将应答消息写入reply;
  • 读取reply应答消息的异常情况和组件对象;

2.2 Parcel.obtain

[-> Parcel.java]


 

sOwnedPool是一个大小为6,存放着parcel对象的缓存池,这样设计的目标是用于节省每次都创建Parcel对象的开销。obtain()方法的作用:

  1. 先尝试从缓存池sOwnedPool中查询是否存在缓存Parcel对象,当存在则直接返回该对象;
  2. 如果没有可用的Parcel对象,则直接创建Parcel对象。

2.2.1 new Parcel

[-> Parcel.java]


 

nativeCreate这是native方法,经过JNI进入native层, 调用android_os_Parcel_create()方法.

2.2.2 android_os_Parcel_create

[-> android_os_Parcel.cpp]


 

创建C++层的Parcel对象, 该对象指针强制转换为long型, 并保存到Java层的mNativePtr对象. 创建完Parcel对象利用Parcel对象写数据. 接下来以writeString为例.

2.2.3 Parcel.recycle


 

将不再使用的Parcel对象放入缓存池,可回收重复利用,当缓存池已满则不再加入缓存池。这里有两个Parcel线程池,mOwnsNativeParcelObject变量来决定:

  • mOwnsNativeParcelObject=true, 即调用不带参数obtain()方法获取的对象, 回收时会放入sOwnedPool对象池;
  • mOwnsNativeParcelObject=false, 即调用带nativePtr参数的obtain(long)方法获取的对象, 回收时会放入sHolderPool对象池;

2.3 writeString

[-> Parcel.java]


 

2.3.1 nativeWriteString

[-> android_os_Parcel.cpp]


 

2.3.2 writeString16

[-> Parcel.cpp]


 

Tips: 除了writeString(),在Parcel.java中大量的native方法, 都是调用android_os_Parcel.cpp相对应的方法, 该方法再调用Parcel.cpp中对应的方法.
调用流程: Parcel.java –> android_os_Parcel.cpp –> Parcel.cpp.


 

简单说,就是

2.4 mRemote究竟为何物

mRemote的出生,要出先说说ActivityManagerProxy对象(简称AMP)创建说起, AMP是通过ActivityManagerNative.getDefault()来获取的.

2.4.1 AMN.getDefault

[-> ActivityManagerNative.java]


 

gDefault的数据类型为Singleton<IActivityManager>, 这是一个单例模式, 接下来看看Singleto.get()的过程

2.4.2 gDefault.get


 

首次调用时需要创建,创建完之后保持到mInstance对象,之后可直接使用.

2.4.3 gDefault.create


 

文章Binder系列7—framework层分析,可知ServiceManager.getService(“activity”)返回的是指向目标服务AMS的代理对象BinderProxy对象,由该代理对象可以找到目标服务AMS所在进程

2.4.4 AMN.asInterface

[-> ActivityManagerNative.java]


 

此时obj为BinderProxy对象, 记录着远程进程system_server中AMS服务的binder线程的handle.

2.4.5 queryLocalInterface

[Binder.java]


 

对于Binder IPC的过程中, 同一个进程的调用则会是asInterface()方法返回的便是本地的Binder对象;对于不同进程的调用则会是远程代理对象BinderProxy.

2.4.6 创建AMP

[-> ActivityManagerNative.java :: AMP]


 

可知mRemote便是指向AMS服务的BinderProxy对象。

2.5 mRemote.transact

[-> Binder.java ::BinderProxy]


 

mRemote.transact()方法中的code=START_SERVICE_TRANSACTION, data保存了descriptorcaller, intent, resolvedType, callingPackage, userId这6项信息。

transactNative是native方法,经过jni调用android_os_BinderProxy_transact方法。

2.6 android_os_BinderProxy_transact

[-> android_util_Binder.cpp]


 

gBinderProxyOffsets.mObject中保存的是BpBinder对象, 这是开机时Zygote调用AndroidRuntime::startReg方法来完成jni方法的注册.

其中register_android_os_Binder()过程就有一个初始并注册BinderProxy的操作,完成gBinderProxyOffsets的赋值过程. 接下来就进入该方法.

2.7 BpBinder.transact

[-> BpBinder.cpp]


 

IPCThreadState::self()采用单例模式,保证每个线程只有一个实例对象。

2.8 IPC.transact

[-> IPCThreadState.cpp]


 

transact主要过程:

  • 先执行writeTransactionData()已向Parcel数据类型的mOut写入数据,此时mIn还没有数据;
  • 然后执行waitForResponse()方法,循环执行,直到收到应答消息. 调用talkWithDriver()跟驱动交互,收到应答消息,便会写入mIn, 则根据收到的不同响应吗,执行相应的操作。

此处调用waitForResponse根据是否有设置TF_ONE_WAY的标记:

  • 当已设置oneway时, 则调用waitForResponse(NULL, NULL);
  • 当未设置oneway时, 则调用waitForResponse(reply) 或 waitForResponse(&fakeReply)

2.9 IPC.writeTransactionData

[-> IPCThreadState.cpp]


 

将数据写入mOut

2.10 IPC.waitForResponse


 

在这个过程中, 常见的几个BR_命令:

  • BR_TRANSACTION_COMPLETE: binder驱动收到BC_TRANSACTION事件后的应答消息; 对于oneway transaction,当收到该消息,则完成了本次Binder通信;
  • BR_DEAD_REPLY: 回复失败,往往是线程或节点为空. 则结束本次通信Binder;
  • BR_FAILED_REPLY:回复失败,往往是transaction出错导致. 则结束本次通信Binder;
  • BR_REPLY: Binder驱动向Client端发送回应消息; 对于非oneway transaction时,当收到该消息,则完整地完成本次Binder通信;

规律: BC_TRANSACTION + BC_REPLY = BR_TRANSACTION_COMPLETE + BR_DEAD_REPLY + BR_FAILED_REPLY

2.10.1 IPC.executeCommand


 

处于剩余的BR_命令.

2.11 IPC.talkWithDriver


 

binder_write_read结构体用来与Binder设备交换数据的结构, 通过ioctl与mDriverFD通信,是真正与Binder驱动进行数据读写交互的过程。 ioctl()方法经过syscall最终调用到Binder_ioctl()方法.

三、Binder driver

3.1 binder_ioctl

[-> Binder.c]

由【小节2.11】传递过出来的参数 cmd=BINDER_WRITE_READ


 

首先,根据传递过来的文件句柄指针获取相应的binder_proc结构体, 再从中查找binder_thread,如果当前线程已经加入到proc的线程队列则直接返回, 如果不存在则创建binder_thread,并将当前线程添加到当前的proc.

  • 当返回值为-ENOMEM,则意味着内存不足,往往会出现创建binder_thread对象失败;
  • 当返回值为-EINVAL,则意味着CMD命令参数无效;

3.2 binder_ioctl_write_read


 

此时arg是一个binder_write_read结构体,mOut数据保存在write_buffer,所以write_size>0,但此时read_size=0。首先,将用户空间bwr结构体拷贝到内核空间,然后执行binder_thread_write()操作.

3.3 binder_thread_write


 

不断从binder_buffer所指向的地址获取cmd, 当只有BC_TRANSACTION或者BC_REPLY时, 则调用binder_transaction()来处理事务.

3.4 binder_transaction

发送的是BC_TRANSACTION时,此时reply=0。


 

主要功能:

  1. 查询目标进程的过程: handle -> binder_ref -> binder_node -> binder_proc
  2. BINDER_WORK_TRANSACTION添加到目标队列target_list, 首次发起事务则目标队列为target_proc->todo, reply事务时则为target_thread->todo; oneway的非reply事务,则为target_node->async_todo.
  3. BINDER_WORK_TRANSACTION_COMPLETE添加到当前线程的todo队列

此时当前线程的todo队列已经有事务, 接下来便会进入binder_thread_read()来处理相关的事务.

3.5 binder_thread_read


 

  • 当收到的是BINDER_WORK_TRANSACTION_COMPLETE, 则将命令BR_TRANSACTION_COMPLETE写回用户空间.
  • 当收到的是BINDER_WORK_TRANSACTION命令, 则将命令BR_TRANSACTION或BR_TRANSACTION写回用户空间.

四. 回到用户空间

4.1 何去何从

  1. 执行完binder_thread_write方法后, 通过binder_transaction()首先写入BINDER_WORK_TRANSACTION_COMPLETE写入当前线程.
  2. 这时bwr.read_size > 0, 回到binder_ioctl_write_read方法, 便开始执行binder_thread_read();
  3. 在binder_thread_read()方法, 将获取cmd=BR_TRANSACTION_COMPLETE, 再将cmd和数据写回用户空间;
  4. 一次Binder_ioctl完成,接着回调用户空间方法talkWithDriver(),并且刚才的数据写入mIn.
  5. 这时mIn有可读数据, 回到waitForResponse()方法,完成BR_TRANSACTION_COMPLETE过程.
  6. 再回退到transact()方法, 对于oneway的操作, 这次Binder通信便完成, 否则还是要等待Binder服务端的返回.

对于startService过程, 显然没有指定oneway的方式,那么发起者进程还会继续停留在waitForResponse()方法,等待收到BR_REPLY消息. 由于在前面binder_transaction过程中,除了向自己所在线程写入了BINDER_WORK_TRANSACTION_COMPLETE, 还向目标进程(此处为system_server)写入了BINDER_WORK_TRANSACTION命令. 而此时system_server进程的binder线程一旦空闲便是停留在binder_thread_read()方法来处理进程/线程新的事务, 收到的是BINDER_WORK_TRANSACTION命令, 经过binder_thread_read()后生成命令BR_TRANSACTION.同样的流程.

接下来,从system_server的binder线程一直的执行流: IPC.joinThreadPool –> IPC.getAndExecuteCommand() -> IPC.talkWithDriver() ,但talkWithDriver收到事务之后, 便进入IPC.executeCommand(), 接下来,从executeCommand说起.

4.2 IPC.executeCommand


 

  • 对于oneway的场景, 则到此全部结束.
  • 对于非oneway, 也就是需要reply的通信过程,则向Binder驱动发送BC_REPLY命令

4.3 BBinder.transact

[-> Binder.cpp ::BBinder ]

4.4 JavaBBinder.onTransact

[-> android_util_Binder.cpp]


 

还记得AndroidRuntime::startReg过程吗, 其中有一个过程便是register_android_os_Binder(),该过程会把gBinderOffsets.mExecTransact便是Binder.java中的execTransact()方法.详见见Binder系列7—framework层分析文章中的第二节初始化的过程.

另外,此处mObject是在服务注册addService过程,会调用writeStrongBinder方法, 将Binder对象传入了JavaBBinder构造函数的参数, 最终赋值给mObject. 在本次通信过程中Object为ActivityManagerNative对象.

此处斗转星移, 从C++代码回到了Java代码. 进入AMN.execTransact, 由于AMN继续于Binder对象, 接下来进入Binder.execTransact

4.5 Binder.execTransact

[Binder.java]


 

当发生RemoteException, RuntimeException, OutOfMemoryError, 对于非oneway的情况下都会把异常传递给调用者.

4.6 AMN.onTransact

[-> ActivityManagerNative.java]


 

4.7 AMS.startService


 

历经千山万水, 总算是进入了AMS.startService. 当system_server收到BR_TRANSACTION的过程后, 再经历一个类似的过程,将事件告知app所在进程service启动完成.过程基本一致,此处就不再展开.

五. 总结

本文详细地介绍如何从AMP.startService是如何通过Binder一步步调用进入到system_server进程的AMS.startService. 整个过程涉及Java framework, native, kernel driver各个层面知识. 仅仅一个Binder IPC调用, 就花费了如此大篇幅来讲解, 可见系统之庞大. 整个过程的调用流程:

5.1 通信流程

从通信流程角度来看整个过程:彻底理解Android Binder通信架构

前面第二至第四段落,主要讲解过程 BC_TRANSACTION –> BR_TRANSACTION_COMPLETE –> BR_TRANSACTION. 有兴趣的同学可以再看看后面3个事务的处理:BC_REPLY –> BR_TRANSACTION_COMPLETE –> BR_REPLY,这两个流程基本是一致的.

5.2 通信协议

从通信协议的角度来看这个过程:

彻底理解Android Binder通信架构

  • Binder客户端或者服务端向Binder Driver发送的命令都是以BC_开头,例如本文的BC_TRANSACTIONBC_REPLY, 所有Binder Driver向Binder客户端或者服务端发送的命令则都是以BR_开头, 例如本文中的BR_TRANSACTIONBR_REPLY.
  • 只有当BC_TRANSACTION或者BC_REPLY时, 才调用binder_transaction()来处理事务. 并且都会回应调用者一个BINDER_WORK_TRANSACTION_COMPLETE事务, 经过binder_thread_read()会转变成BR_TRANSACTION_COMPLETE.
  • startService过程便是一个非oneway的过程, 那么oneway的通信过程如下所述.

5.3 说一说oneway

上图是非oneway通信过程的协议图, 下图则是对于oneway场景下的通信协议图:

彻底理解Android Binder通信架构

当收到BR_TRANSACTION_COMPLETE则程序返回,有人可能觉得好奇,为何oneway怎么还要等待回应消息? 我举个例子,你就明白了.

你(app进程)要给远方的家人(system_server进程)邮寄一封信(transaction), 你需要通过邮寄员(Binder Driver)来完成.整个过程如下:

  1. 你把信交给邮寄员(BC_TRANSACTION);
  2. 邮寄员收到信后, 填一张单子给你作为一份回执(BR_TRANSACTION_COMPLETE). 这样你才放心知道邮递员已确定接收信, 否则就这样走了,信到底有没有交到邮递员手里都不知道,这样的通信实在太让人不省心, 长时间收不到远方家人的回信, 无法得知是在路的中途信件丢失呢,还是压根就没有交到邮递员的手里. 所以说oneway也得知道信是投递状态是否成功.
  3. 邮递员利用交通工具(Binder Driver),将信交给了你的家人(BR_TRANSACTION);

当你收到回执(BR_TRANSACTION_COMPLETE)时心里也不期待家人回信, 那么这便是一次oneway的通信过程.

如果你希望家人回信, 那便是非oneway的过程,在上述步骤2后并不是直接返回,而是继续等待着收到家人的回信, 经历前3个步骤之后继续执行:

  1. 家人收到信后, 立马写了个回信交给邮递员BC_REPLY;
  2. 同样,邮递员要写一个回执(BR_TRANSACTION_COMPLETE)给你家人;
  3. 邮递员再次利用交通工具(Binder Driver), 将回信成功交到你的手上(BR_REPLY)

这便是一次完成的非oneway通信过程.

oneway与非oneway: 都是需要等待Binder Driver的回应消息BR_TRANSACTION_COMPLETE. 主要区别在于oneway的通信收到BR_TRANSACTION_COMPLETE则返回,而不会再等待BR_REPLY消息的到来.

 

转载自:http://gityuan.com/2016/09/04/binder-start-service/    原文作者:gityuan

 

28 2016-10