Towards Dynamically Monitoring Android Applications on Non-rooted Devices in the Wild
主要解决什么问题
目前动态分析技术需要在实验室环境中运行状态下触发代码级和系统级事件，以窥探app的敏感性为。这种严格的运行环境阻碍了此类动态分析技术的大规模部署。此外现存的Android应用程序动态分析利用输入生成器激发程序行为，这种方法并不能达到很好的代码覆盖率。
做出的主要贡献：
- 提出了一个动态分析系统UpDroid，它适用于公众使用的非root且未定制系统的设备。
- 提出了几种基于设备上公共资源的状态变化来监控不同类型敏感行为的方法。
- 提出使用机器学习技术-learning to rank，建立运行的app和检测到的事件之间的关系。此方法解决了未定制系统的设备上识别应用程序的问题。
使用的方法
UpDroid通过监视设备上公共资源的变化来检测敏感事件，而不是访问需要root或干预系统的底层事件。为了识别触发检测的app，UpDroid将身份标识转为ranking problem，并采用learning to rank技术来解决该问题。
Framework of UpDroid
UpDroid的结构图如下，主要包含两部分：用户设备上的监控器，远端服务器上的分析器
用户设备上的监控器有两个分别负责监控敏感信息（eg access camera）和收集运行时信息（eg cpu usage of running app）即上图Event Monitor 和 Runtime Info Monitor。
要解决的重要问题是，在不渗透到app或system的情况下，无法识别为了检测而启动的app。为了识别目标app，用真实用户数据通过机器学习（算法：learning to rank）构建了一个判别模型。
但是我觉得这个判别模型可用性也不会很好，一方面运行app的设备不同产生的信息也不同所以精准度不可能是百分百，另一方面，你必须有目标app的数据才可以，后期需要加入新的app，动态训练模型本身就是一个问题。
EVENT MONITORING
Content Observer
Content Observer仅报告Content Provider是否变化，并非描述何种变化。受限于开销UpDroid仅检测四种常见的content provider：SMS, call log, contacts and calendar events
File Observer
UpDroid使用File-Observer API监视外部存储中的文件和目录。Android官方提供了此API，以捕获对单个文件或目录的更改。此API进支持对单个文件和目录的监控所以本文递归的为每个要监控的文件和目录创建监控。注意，File Observer仅报告事件，但不报告更改的内容。
Interrupt Observer
Android继承了Linux的中断机制，中断表示CPU中断了正在运行的程序以处理外部硬件设备提出的中断请求的情况。
Interrupt Observer具体做法是每100ms对/proc/interrupts取样一次，比较变化。由于大多数硬件设备都有一条对应的中断请求行，因此我们可以通过监控中断号的变化来推断硬件的运行状态。
一个重要的问题是：在/proc/interrupts中显示的大多数设备名称都是用硬件型号名称或缩写表示的（且不同手机中使用的映射也不一样），因此很难识别。我们只能手动标识具体硬件和interrupts中的代号映射，本文分析了19种Android 设备。
Network Observer
借助TUN虚拟网络设备捕捉应用发出的TCP和UDP数据包。使用了MopEye的技术从以下proc文件/proc/net/tcp6|tcp|udp|udp6 中识别目标程序的数据包。
NITIATOR IDENTIFYING
尽管MopEye [35]为network event提供了一种智能的应用程序识别解决方案，但它不适用于其他事件，例如基于中断的事件。因此，UpDroid利用机器学习技术（learning to rank）来构建适用于所有事件的应用程序识别模型。该识别模型的结构图如下所示：
App Status Monitoring
设备上的运行时信息监视器收集运行时信息（如CPU usage, memory usage）。这些信息将用作判断一个被检测到的事件是否是某个app导致的。UpDroid 使用ps命令获取app的运行时信息。但ps命令得到的是进程信息，而辨识一个事件是那个进程导致的是比较难的，所以我们把来自一个app的进程的运行时信息进行整合，得到了目标的真实运行时信息，关于整合的更多细节参考原文5.3节。
Data Collecting
数据包含每个app在events发生时的events + runtime information。我们招募Android用户，帮助收集数据并实时标记应用程序。
Data Pre-processing
为了得到用于最终模型训练的数据我们做了以下预处理工作：
-
获取检测到event前后的app runtime information
-
然后，我们结合了同一app不同进程的运行时信息，下表2是runtime information的结合规则（这就是上述提到的整合进程信息的方法）
Here is an example of extracting feature f1 for an app. App a has two processes: p1 and p2. Event e is observed at time t. The process sampling provides the nearest process info logs at time t1 and t2, while t1≤t≤ t2. The f1 value of p1 is v1 at t1 and v2 at t2. The f1 value of p2 is u1 at t1 and u2 at t2. Hence, the processed feature f1 of app a for e is:
-
最后，我们根据用户的回应，识别触发某事件的应用程序，并标记所有正在运行的应用程序。1标识app被selected（与触发事件有关），0标识app没有selected
Modelling and Precision
上面说过了我们的问题转换为了排名问题，就是说运行中的app中那个最有可能是是invoke event的app，按照可能性排名。使用RankLib（该库包含几个流行的learning to rank算法）进行建模和测试。
三分之二的数据作为训练资料，剩下的作为测试数据集。
top 123的意思是，在模型预测结果中排名前几的，也就是模型认为最有可能是invoke event的app，它们之中是否包含观察者（用户）人工指明的invoke event的app。
在我看来，app识别器模型的结果还是不错的。
结果评估
总的来说，实验结果表明，UpDroid可以成功检测到Android官方文档中标记为危险的26个权限中的15个权限。我们还将Up-Droid与API hooking技术进行了比较，该API hooking在理论上可以捕获所有敏感行为，但需要root和修改系统。结果表明，即使没有root和任何系统修改，UpDroid仍然可以实现API hooking技术的70％。
下面是在各个方面UpDroid和API Hooking的比较
权限覆盖率
为了比较，我们使用了Google官方文档中声明的26个dangerous permission和44个normal permission。如果列表中的任何敏感API使用了特定权限，则我们认为API Hooking技术涵盖了此权限。此外，如果UpDroid可以捕获某权限所保护的一种行为，则我们认为UpDroid涵盖了此权限。两者对危险权限的覆盖情况的比较结果如下图所示：
Event Details Comparison
API Hooking可以根据API的参数和返回值提供有关每个事件或行为的详细信息，而UpDroid则提供了揭露每个事件详细信息的不同方法。
- 监控Content Provider，可以提供较general的信息，比API Hooking能提供的信息差一些。
- 监控Interrupt，提供事件发生的时间和发生改变的方式（changing pattern）
- 监控External Storage，比API Hooking能提供的信息差，前者只能提供谁改变的信息，后者可以提供读写内容。
- 监控Network，UpDroid提供的信息比API Hooking更底层
Behavior Outcome Comparison
UpDroid更加强调应用程序行为的结果，而API Hooking则更多地强调应用程序行为的意图。
对我有什么启发
一种新的在非root设备上动态监测的思路，涉及了Android系统运行原理和Linux运行机制。
这项研究的未来方向
我感觉本文的方法还是由很多限制，并不能成为主流的app检测方式。