Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Mobile-Sandbox:Having a Deeper Look Into Android Applications

论文下载

Abstract

文章的主要贡献在于立足于已有的Andorid应用程序静态&动态分析技术,解决了原有技术无法分析native code的缺陷。

Introduction

主要是分析了一下现有的Android应用程序分析工具,普遍存在的问题是无法处理native code,其中CrowDroid和AASandBox这样的工具仅仅记录system call。和本文工作最为类似的是Andrubis,作者提到Andrubis是基于Android API level7的,而本文的工具可以支持level11。只要想找,总是有缺陷的。

Architecture&Implementation

总体架构:

Fig

  • 静态方面没有什么亮点,先过一遍VirusTotal,再过一遍卡巴斯基。然后解析manifest和dex文件,找出敏感的API,找到会触发应用程序特殊行为的广播事件,这些数据会帮助之后的动态分析覆盖尽可能多的代码。
  • 动态分析是用DroidBox和MonkeyRunner做的,也很普通,主要是看tracking native code的部分。native code的追踪使用的是修改过的ltrace,通过ltrace到Dalvik进程上,把所有的native call全部记录下来。最后还附加一个网络流量的pcap trace。总的来说动态分析结果一共三部分:
    1. DroidBox记录下的java方法调用和数据。
    2. ltrace记录下的通过JNI实现的native方法调用。
    3. 网络流量pcap包。

最后还给了一个操作流程,感觉非常工程化。

Examples

分析了一些样本程序,识别密码算法啊,识别发送短信的行为啊,识别写文件操作啊之类的,很普通。

Evaluation&Performance

  • evaluation做的非常奇怪,作者找了一些有名的恶意程序,然后放到Mobile-sandbox里跑,然后把结果和网上的安全公司出的检测报告相比较,发现少了很多恶意行为,经过人工分析,发现是因为没有收到外部的刺激,有很多恶意行为没有触发,所以没记录下来,然后作者以此认为他们的系统运行的非常正确,只记录发生过的恶意行为。
  • Performance起始挺差的,平均一个应用程序,事先的virus check需要3s,静态分析需要8-15s,然后需要2min来重启模拟器,然后需要2-6min来安装应用程序,然后需要6-10min来动态分析应用程序,最后要10s来提取各种文件,总的来说需要约10-20min来跑一个程序,实在是太久了。之后讨论了一下恶意程序检测模拟器的问题,主要还是两个方面,一个是有关模拟器的系统信息,比如Build.device这样的信息。还有一方面就是qemu自身的弱点。
  • 最后一部分是作者的分析结果,作者分析了80000个app,当然基于这个玩意的性能,我觉得这是在扯淡。结论也很普通,和我们之前看过的一样,恶意程序使用jni反而比正常程序要少。