关于droidbox的笔记

Droidbox是一款Android病毒的动态分析工具，使用它可以对病毒的行为有一个直观的表现，它的主要功能如下：1.监控网络数据，2.监控文件读写操作，3.监控网络、文件、短信泄露的信息，4.启动服务和列出通过DexClassLoader加载的类，5监控发送短信和打电话，6.列出广播接收者等等

基本上能传播的方式都可以污染，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的标记依然不会被清除。

先mark，感觉介绍droidbox的东西太少了。引用自