《StateDroid: Stateful Detection of Stealthy Attacks in Android Apps via Horn-Clause Verification》
来源：ACSAC 2018 (CCF C)
关键词：Android Malware; State transition; Automata; Horn-Clause
摘要：
本文针对恶意软件的隐秘行为，使用霍恩语句自动生成apk的行为状态，并构建有限状态自动机进行恶意性的判断。
针对问题： Android app中的隐秘攻击的检测
与传统的恶意行为相比，隐秘攻击通常会采取多余的措施来隐藏自身。
隐秘攻击的三个特征：
1.malware的attack会经历多个state
2.state的转换是由一系列的有序action组成
3.action包含对object的API操作，可能依赖API调用的特定顺序或者输入值
Challenge
1.很多因素影响action的执行，比如object的API调用，API调用顺序和特定的输入值。
2.object可以被传递到多个class或者method中，因此不易追溯。需要基于调用的API来不断更新object状态。
3.攻击行为和API调用的结合并不固定
文章方法
传统的控制流和数据流模型都无法捕获到此类攻击。由于隐秘攻击是按照一定顺序执行一系列action来完成的，而有限状态自动机可以描述攻击行为的顺序。因此本文针对隐秘攻击的状态转换 采用了两层有限状态自动机StateDroid 来实现攻击的自动化静态检测。
（1）在StateDroid的顶层状态机ASM(Attack State Mechine)中，节点代表状态（基于很多action的攻击状态），边代表状态的转换（action）。当攻击action链中的最后一个action被执行的时候，状态机就达到了终态。
（2）为追溯object的状态，提出了有限状态自动机的另一个层OSM(Object State Mechine)。如果API调用完成了action的功能，OSM会报告action的检测。本文又提取122个相关API语义，42个action的影响和恶意intent作为Horn clauses(合取范式)，来自动生成状态机。
contribution
（1）为检测隐秘攻击，设计了基于attack-action的两层有限状态自动机
（2）将安全问题与自动机等形式化语言相结合
（3）开源
Backgroud
Motivating example：Hehe malware的恶意行为：自动屏蔽来电，并设置设备响铃为静音模式，达到隐藏自身的目的。
（1）设置静音模式
（2）屏蔽来电。注册broadcast Receiver，一旦有来电，系统触发onReceive的回调来执行攻击行为
（3）恢复设备响铃模式
StateDroid
三个步骤及其主要对象：回调中的API call（包括输入参数值和object的状态）—— action（基于object状态的OSM）——attack(基于action的ASM)
1.API Call Detector
生命周期模型——事件链——callback链——API调用链
（1）通过从生命周期模型中分析callback，根据callback的顺序（onCreate-onStart-onPostCreate-onResume-onPostResume），来检测可能触发attack的API调用序列
（2）将object或者primitive装入lookup table（stack）中作为OSM的初始状态。若API涉及action，则进入action detector中
每个生命周期模型都是一个状态机，状态代表组件的状态，转换代表生命周期callback
Android注册一系列的callback来管理组件的生命周期，并触发callback来回应UI事件和系统事件。这些callback会以特定顺序被触发。而attack会通过回调函数的API来触发。
2.Action Detector
输入：API调用链
目的：识别出可能实施攻击的action（设置静音模式，触发电话，屏蔽电话等）
利用合取范式来格式化API和ACTION
（1）通过解析API手册提取出attack相关功能API，并生成合取范式。
（2）生成API 调用链的合取范式
（3）构建OSM:将action和API放入stack上，自动生成状态机
3.Attack Detector
state代表攻击状态
transition代表检测到的action（从action detector中获取）
终结状态表示存在attack
利用合取范式来格式化ACTION-effect和attack
评估
数据集：1369个恶意软件和1505个Google Play软件
1.Action Detector的有效性
提取出604个action，无false positive
但是对混淆程度高，代码重排序，加入垃圾代码和对静态字符串做反射的无法检测。也无法检测动态加载的恶意代码。
2.Attack Detector的有效性
对于12个已知恶意行为的app，无false positive和false negative
对于135个隐秘攻击，30%是基于action链的攻击
对于1505个良性app，有117个有隐秘攻击行为
3.与其他工具的对比
49个恶意样本
与AsDroid相比，检测到的action更多，检测到的泄露信息的样本更多
statedroid与flowdroid和dexteroid相比，分别检测出114,28,112个attack提醒。其中，dexteroid含有11个false positive,statedroid找到了6个新攻击。
4.overhead
检测一个app平均需要214秒，主要用于API CALL DETETCTOR中
本文的启发在于从Android的生命周期和回调机制出发，由一系列action推导出存在的attack。首先该文章从1275个已知的恶意软件中提取action和attack，构成集合，再去在有限自动机中检测恶意action的存在。