目前Android系统最大的问题是什么？安全，这也是Android总是进不了企业的主要原因。如果问主要的安全问题是什么？我想应该是吸费、流量消耗和隐私泄漏。针对于隐私泄漏的侦测，目前有一个开源软件叫做DroidBox，算是做的不错的了。今天我们就来分析一下DroidBox是如何侦测隐私泄漏的。
DroidBox的核心技术称作TaintDroid,从字面上理解就是污染机器。我们都知道标识隐私数据并不难，只要牢牢卡住相关的API调用就可以了，问题是如何知道这些隐私数据被泄漏出去了？恶意程序拿到隐私数据后往往会做一系列的操作，包括截取，拼装，加密甚至是进程间传递，这使得隐私数据的跟踪变得相当困难。所以关键技术就演变成了：如何跟踪数据。TaintDroid的思想就是将所有隐私数据变成污染源，在程序运行的过程中如果你想对污染源进行截取，拼装，加密，传递等等操作，那么你新生成的数据也会被污染。如果有被污染的数据被泄漏出去，那么就发生了隐私泄漏。好，到这里问题变成了如何标记数据和如何进行污染。
先说比较好搞定的问题，如何进行污染。对于java操作(dex)的污染规则基本上可以用下图表示：
可以看出污染的三大途径：赋值，参数传递，返回值。目前在dex里面无论怎么对隐私数据操作，都会被污染。而对于native的code, 污染会相对复杂一些，尤其是第三方的native code，但基本的理念还是一样的，这里就不详细介绍了。至于在Android里面具体污染的层次，可以用下面这张图来理解：
基本上能传播的方式都可以污染，Dalvik之上是变量级的污染，Native是调用级的污染，存储是文件级的污染，IPC还有消息级别的污染。
污染跟踪的问题解决了，另一个问题是如何标记，换句话说，就是在什么地方存储每块数据是否被污染的标记。对于不同的层次有不同的存储方式。最容易搞定的依然是Dalvik以上的部分，系统Native库较为难搞，最不好搞的是第三方Native库。基本上存储的方式可以用下面这张图表示：
对于Dalvik以上的部分，利用修改Dalvik来搞定，因为Android里面的java是32bit的，所以所有引用的大小也都是32bit，TaintDroid为每个引用多申请了一倍的空间，即64bit。程序自身还是用前32bit, 而TaintDroid就可以利用剩下的32bit, 采用bitmap的方式可以标注32种不同的隐私类型。这种方式带来的副作用不言而喻，会导致程序引用占用的内存增加一倍，而优点是可以精确定位到每个对象是否被污染。
对于Native的模块就不这么简单了，因为无法修改指针长度（改kernel应该可以，但影响面太大了）。所以TaintDroid的污染是基于调用级的，利用增加调用参数的方式来放污染标记。例如上图第三列，有一个调用的参数有两个：arg0和arg1, TaintDroid再多加3个参数，第3个参数是输出参数，调用完成后return值的标记就放在这里，第4和第5个参数是输入参数分别是arg0和arg1的污染标记。通过这种方式，在做完一次Native调用后就可以得到return值的污染标记（注意，仅仅是return值），所以这种方式被称为面向调用的污染。
应该说DroidBox最核心的东西就这么多了，那么TaintDroid是否就完美了呢？显然不是的，它依然存在FP和FN。FN主要存在于Native Code的调用，尤其是第三方Native Code的调用。对于这个问题TaintDroid有个坑爹的对策：不允许调用第三方的动态库。这就意味着所有调用第三方库的程序都不能在TaintDroid的Image上运行。坑爹吧，因为我们知道尤其在中国很多热门应用都要用到第三方库的。而FP的情况也并不乐观，FP出现问题的地方主要包括：自身设计问题和先天条件限制。我们在实际使用的过程中发现TaintDroid会吧所有的pipe操作误认为是文件操作，只要有隐私数据参与pipe操作，就会有FP发生。而TaintDroid对于Array的策略也是另外一个FP的来源，由于Array在Dalvik中只有一个引用，所以TaintDroid只有一个标记的位置，因而策略是宁可错杀一千，不可放过一个。即使未来Array里面的那个污染源已经被移走了，Array的标记依然不会被清除。
针对于这些问题，我们team已经做了很多改动和修补，也许在未来我们会公开我们的源码。
