《“Jekyll and Hyde” is Risky: Shared-Everything Threat Mitigation in Dual-Instance Apps》
Publication：Mobisys 2019
Notes：“Jekyll and Hyde” is a metaphorical term to describe someone with two-sided personalities - one good and one evil. Here we use this term to indicate that the popular dual-instance apps have posed significant security risks.

Abstract：
Recent developed application-level virtualization brings a groundbreaking innovation to Android ecosystem: a host app is able to load and launch arbitrary guest APK files without the hassle of installation. Powered by this technology, the so-called “dual-instance apps” are becoming increasingly popular as they can run dual copies of the same app on a single device (e.g., login Facebook simultaneously with two different accounts). Given the large demand from smartphone users, it is imperative to understand how secure dualinstance apps are. However, little work investigates their potential security risks. Even worse, new Android malware variants have been accused of skimming the cream off application-level virtualization. They abuse legitimate virtualization engines to launch phishing attacks or even thwart static detection.
We first demonstrate that, current dual-instance apps design introduces serious “shared-everything” threats to users, and severe attacks such as permission escalation and privacy leak have become tremendously easier. Unfortunately, we find that most critical apps cannot discriminate between host app and Android system. In addition, traditional fingerprinting features targeting Android sandboxes are futile as well. To inform users that an app is running in an untrusted environment, we study the inherent features of dual-instance app environment and propose six robust fingerprinting features to detect whether an app is being launched by the host app. We test our approach, called DiPrint, with a set of dual-instance apps collected from popular app stores, Android systems, and virtualization-based malware. Our evaluation shows that DiPrint is able to accurately identify dual-instance apps with negligible overhead.

If you are interested in my paper, you can find it here
And welcome to contact me if you have any questions. skylinelulu[at]163[dot]com

Attach some photos of Mobisys2019 Conference and Seoul.

1.市场上手机分身的情况

如今市场上的手机厂商都逐渐增加了应用双开的功能，如小米，华为，OPPO。
而在一个Android手机设备实现多个系统空间，即系统分身，系统之间互相隔离。有该功能的厂商有小米和华为。
下面三张图是小米的系统分身和应用双开的截图。图2中的红框分别是应用双开和系统分身入口图标，图3是通过切换分身图标进入新系统中，没有任何原系统中的应用及数据。



系统层虚拟化方案主要有Linux内核层和Android framework层两种方案。小米和OPPO都在Linux内核层做的。其中，小米用的应该是加拿大软件公司Graphite Software的Secure Spaces技术，以下是官网截图。小米，酷派，联想，blackphone等手机都使用了Graphite的产品。


接下来介绍Linux内核层和Android framework层两种方案的具体实现。

2.2. Linux内核层解决方案

《Cells: A Virtual Mobile Smartphone Architecture》
SOSP 2011 (ACM Symposium on Operating Systems Principles)
哥伦比亚大学 Jeremy Andrus, Christoffer Dall, Alexander Van’t Hof

应用场景：

哥伦比亚大学虚拟化研究室的这篇论文DEMO后来被以色列公司cellrox在2014年进行了商业化
哥伦比亚论文地址
Cellrox官网
2016年电子科技大学的一篇硕士毕业论文和这篇文章很相像，《基于安全容器的Android虚拟化技术研究》孙超群&杨霞

Background

关于namespace：
Linux Namespace是一种Linux Kernel提供的资源隔离方案，提供PID，Network，IPC，UTS，Mount，User六种资源的隔离，每个Namespace下的这些资源对于其他Namespace是不可见的。
一个进程可以同时属于多个Namespace。Linux Kernel、Namespace、Process之间的关系可以用下图描述。

Design

在Linux kernel层利用namespace + device proxy来实现虚拟android系统（VP）
每个VP都有私有的虚拟namespace
虚拟化标识符、内核接口和硬件资源，并将OS资源标识符映射到虚拟标识符上
虚拟化 文件系统路径、PID、IPC、网络接口和UID等，保证VP隔离

foreground VP独占屏幕资源
background VP依然在后方运行，能够接受系统事件，并执行任务。
VP在电脑端生成和配置，通过USB线下载到手机上

三种访问配置：
（1）no access：VP可限制某些权限，即使用户同意使用
（2）shared access：foreground VP和background VP可共享
（3）exclusive access：当foreground VP运行时，它独占所有资源，可防止信息泄露

1.共享可读的系统文件，减少内存使用
2.隔离VP以及root namespace
（1）利用UID namespace虚拟化用户凭证
（2）在内核层用namespace隔离VP及其数据
（3）使用mount namespace隔离VP文件
（4）去除VP内创建设备节点的能力

1. Kernel-level Device Virtualization

提供 隔离+硬件资源多样化
kernel device namespace：在驱动层表示数据结构并注册回调函数。当device namespace状态转变的时候回调函数被调用
每个VP都有一个device namespace
（1）虚拟化内核接口
创建device driver wrapper，用于接收foreground VP的请求，并更新设备状态。如屏幕显示的Framebuffer
（2）修改设备子系统使其能感知device namespace，如图7的输入子系统
（3）修改设备驱动使其能感知device namespace，如Binder driver

2. User-level Device Virtualization

user device namespace proxy：虚拟化设备配置，比如wifi和电话配置。
root namespace用于管理VP及两种namespace，可访问整个文件系统。

VP的启动：
CellD将挂载VP文件系统，将自己克隆到一个具有单独namespace的新进程中，并启动VP的init进程以启动用户空间环境。
CellD设置了一组IPC套接字，供VP中的进程与root namespace通信。
Cells利用LXC进行资源控制，以防止单个VP的资源不足。

A. Graphics

Android的屏幕显示依赖于Linux framebuffer (FB)来实现
进程和GPU硬件可以读写屏幕内存

1. Framebuffer
   创建新的FB device driver mux_fb
   进程通过ioctl控制FB硬件状态
   foreground VP可访问屏幕内存和显示硬件，而background VP维持着虚拟硬件状态，并将输出保存到内存中的backing buffer中。
   当foreground VP mmap一个打开的FB device，mux_fb驱动时，mux_fb驱动会将相关的屏幕内存映射到进程内存中
   当background VP mmap一个打开的FB device，mux_fb驱动时，mux_fb驱动会将backing buffer映射到进程内存中

foreground VP与background VP的切换过程：
交换屏幕内存和backing buffer，将backing buffer中的信息重新映射到FB，同步硬件状态，并将内存地址转换通知给GPU，以便它能更新内部图像内存映射。

2.GPU
GPU独立图像内容+ FB屏幕内存虚拟化
当foreground VP使用GPU时，会导致屏幕内存的直接变化
当background VP使用GPU时，会导致backing buffer的变化

B. Power Management

Cells通过namespace来虚拟化这个子系统
Android有三种电池管理的接口
（1）early suspend：允许驱动在设备suspend之前和resume之后接收通知
Cells通过禁止background VP初始化suspend操作来虚拟化这个子系统。
（2）frame buffer early suspend：将设备的suspend和resume状态展示到用户空间
Cells通过namespace来虚拟化这个子系统。background VP会一直认为设备在睡眠。当转换VP时，原来的background VP会感知到设备苏醒。降低电池使用度
（3）wake locks：有两种状态active和inactive，当inactive时，系统进入低电量模式或暂停。

C. Telephony

虚拟化radio stack（射频协议栈），实现VP的电话隔离
由于Vendor RIL是闭源库，无法直接修改源码加入namespace，因此利用user device namespace proxy在原来的Radio Interface Layer上加了一个RIL Proxy，包括Cells RIL和CellD。
用于控制拨打和接收电话，使得可以接收background VP的来电
利用VoIP服务实现SIM卡复用

D. Networking

内核层+用户层虚拟化
（1）核心网络资源虚拟化 network namespace
如IP地址，网络适配器，路由表和端口号
VP的虚拟标识符被转换成物理标识符
内核层实现网络和VP端Ethernet对的NAT转换，实现VP之间的网络隔离
（2）无线配置管理虚拟化
和Telephony一样，利用user device namespace proxy加入了一层代理，代替原有的无线网络配置库和RIL库。

3.Android framework层解决方案

《Condroid: A Container-based Virtualization Solution Adapted for Android Devices》
MobileCloud 2015
浙江大学 Lei Xu, Guoxi Li, Chuan Li, Weijie Sun, Wenzhi Chen, Zonghui Wang
项⽬本来有源码的后来取消掉了，剩下⽂档了。文档地址：http://condroid.github.io/

两种应用场景：

（1）公司监控员工设备，但是员工想保护隐私
（2）攻击需要支持员工的工作环境，在工作后Destroy，下一个工作日又进行恢复

方式

（1）修改Android framework层，构建独立、安全、隔离的一个Android手机设备的多系统
（2）替代了Boionic库（Android的内核库）中不支持的函数
（3）由于安卓系统版本的不同替代了一些系统调用
（4）使用Android NDK toochain交叉编译
（5）重编译内核，融入namespace和cgroup

4个特征

（1）基于namespace特征的资源隔离
namespace的目的：将一个特定的全局系统资源包装在一个抽象中，使命名空间中的进程觉得它们拥有自己的全局资源的独立实例。每个容器都感知不到其他容器。
（2）基于cgroup特征的资源控制
限制、说明和隔离流程组的资源使用
每个容器都有自己的资源区，不会被其他容器访问
（3）系统服务共享机制
/proc 文件系统
（4）文件系统共享机制
/system分区

与Cells的不同

Cells修改linux kernel层，Condroid主要修改Android framework层，更多虚拟化Binder子系统

Design

基于容器的结构
内核层和用户层设备虚拟化结合
（1）每个容器都是一个独立的安卓系统
（2）Linux容器技术（Linux Container, LXC）是一种操作系统层的轻量级虚拟化技术，LXC的实现依赖Linux 内核中的NameSpace和Cgroups 机制， NameSpace机制为不同容器间提供了隔离性，Cgroups实现了对容器的资源进行配额。
（3）虚拟化 标识符和硬件资源
（4）host android是控制中心，不会安装任何下载的app

Implementation Details

A. Binder System Virtualization

一个Android手机设备的多系统 Binder driver是ServiceManager, Service和apps的桥梁，他们通过在/dev/binder上使用syscall来传递request和response。
Condroid在内核初始化阶段注册一系列的virtual Binder devices。如Figure 2所示，Host提供主要的IPC组件（Binder Driver， ServiceManager），而在容器中的app通过virtual Binder Device与host的Binder进行通信。
Virtual Binder Driver主要有两个功能：
（1）将app在virtual binder driver上做的操作转给real binder driver
（2）如果操作是注册或请求服务，virtual driver会将service名改为Hash值，解决了命名冲突的问题

B. Display System Virtualization

Foreground container独占显示屏，但是background container的显示图像需要被及时更新和保存，以便切换系统时能及时显示实时图像。
Cells：在Linux kernel层虚拟化framebuffer device
ConDroid：在Android framework层修改WindowManager（控制window生命周期、输入时间、位置等参数的系统服务），WindowManager会将所有的window元数据发送给SurfaceFlinger，由SurfaceFlinger进行图形显示。

WindowManager的window stack决定了SurfaceFlinger会将哪个window显示在屏幕上。ConDroid通过修改container的偏移来进行屏幕切换。

C. Input System Virtualization

拦截非当前系统的event事件，只有foreground container才能感知到用户输入
input manager有两个对象：mInputDisaptcher和mInputReader（修改对象）。mInputDisaptcher负责将输入事件分配到现在激活的窗口中，mInputReader负责监控输入事件。

D. Service Sharing Mechanism

有些服务是可以在多个container之间共享的，比如电池、wifi等，Condroid允许用户通过/proc文件系统定制共享服务。

E. Filesystem Sharing Mechanism

host共享只读文件及目录给各个container

《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的存在。

《PIAnalyzer: A Precise Approach for PendingIntent Vulnerability Analysis》
来源：ESORICS 2018 (CCF B)
关键词：Android, PendingIntent, Information flow control, Static analysis
摘要：
本文总结归纳了不安全的PendingIntent的相关攻击，并对其进行静态检测。

1.针对问题：

不安全的PendingIntent使用会导致拒绝服务、identity窃取和提权（获取系统权限以删除设备上的用户数据）等攻击，文章是第一个静态检测不安全的PendingIntent的。

PendingIntent：PendingIntent是Android组件间通信的一个特征。PendingIntent主要用来在某个事件完成后执行特定的Action。它持有一个base intent(已定义action)，由另一个应用程序执行，而却拥有原app的权限和identity。此时原app进程不一定在运行，但是PendingIntent运行起来就好像是原app在运行一样。

PendingIntent与Intent之间的区别：PendingIntent就是一个可以在特定事件触发后执行的Intent，运行在新的task中，它相比于Intent的优势在于自己携带有Context对象，这样它就不必依赖于某个activity和原进程才可以存在。

PendingIntent应用场景：PendingIntent一般用于设置闹铃或者通知栏提醒。比如，一个应用想要在未来的某个时间点得到系统的通知，它就将自己创建的一个PendingIntent发送给Notification Manager，之后Notification Manager会触发该PendingIntent，使得一个预先定义好的组件可以得到通知和执行。

安全问题：隐式Intent可以被接受端app更改到任意组件上，并且拥有原app的权限，则会导致在原app的context中任意代码执行。

2.Contribution

（1） PendingIntent分析（PIAnalyzer工具）：基于程序切片检测PendingIntent相关不安全代码
（2） PIAnalyzer评估及其有效性：发现了至少435个app在PendingIntent中包裹了至少一个隐式base intent，找到了1358个PendingIntent的不安全使用，包括70个严重的漏洞。平均一个app 13秒

3.Motivation

前提：原app有打电话的权限，而恶意app没有。
Listing 1.3中，任意一个定义了相应Intent filter的app都可以接受Listing 1.2中的implicitWrappingIntent，提取出PendingIntent并控制base intent，使其向收费短信发送短信。

（1） 钓鱼攻击：如果PendingIntent包裹的base intent是隐式的，那么定义了相应intent filter的多个app都可以接收，这就需要用户选择一个app来接收。这种场景就可能被钓鱼app利用。
（2） 拒绝服务攻击：一般地，PendingIntent并不会被wrapping intent包裹起来，而是直接传递到系统组件中，这些组件会调用PendingIntent的send方法来触发base intent。恶意app可以注册一个组件来接收这个base intent执行拒绝服务攻击（这些Intent就不会被传递到目标组件中）
（3） 提权攻击：（Android 4所有版本都存在这个攻击,原因是在PendingIntent中使用了隐式base intent）

Listing 1.4是 Android源码中addAccount的代码，一旦有app添加账户就会调用这里的addAccount函数，mPendingIntent会返回给注册了相应action的app，而这个app就可以在Android Setting的context下重写空的base intent，从而执行恶意行为。

恶意应用请求添加账户类型，Android Setting 一旦接收到这个intent，就会执行addAccount函数，返回vulnerable PendingIntent。Listing 1.6是恶意应用的一个Activity，由于恶意软件注册成为AccountAuthenticator，所以接收到这个PendingIntent。随后，在第3行，它创建了一个vunlnintent来执行恢复出厂设置的操作，在第5行用vunlnintent作为更新后的base intent来触发PendingIntent，手机恢复出厂设置。

4.检测方法——PIAnalyzer

从smali代码中，采用程序切片方法寻找相关的不安全代码
（1）提取PendingIntent
寻找包裹base intent的函数：getActivity，getActivities，getBroadcast，getService。
（2）分析base intent
使用后向切片来找到base intent，并确定其是隐式的还是显式的，这篇文章只关注隐式base intent。
注：有6个函数可以使隐式intent变成显式的，setClass(), setClassName(), setComponent(), setPackage() and setSelector()
（3）分析PendingIntent
使用前向切片来寻找PendingIntent的使用方式：发送到系统组件中还是被包裹成另外一个intent。由于系统组件不会执行攻击，因此主要关注wrappingIntent
（4）wrappingIntent分析
使用后向切片来分析这个wrappingIntent是否是隐式的
（5）生成调用图
intent的整个调用链
（6）报告：有三种安全级别
secure: pendingIntent + 显式base intent
warning: pendingIntent + 隐式base intent + 发送给系统组件
vulnerablity: pendingIntent + 隐式base intent + 隐式wrappingIntent

5.Evaluation

数据集：Google Play上任选1000个应用
发现：435个app在PendingIntent中包裹了至少一个隐式base intent，找到了1358个PendingIntent的不安全使用，包括70个严重的漏洞。平均一个app 13秒。80%的 vulnerabilities和98%的warnings发生在第三方库中。
这些app申请权限的情况：279危险权限和273个普通权限
检查精确性：手工检查70中的10个，9个可以精确检查出来

6.Limitation

静态分析的固有缺陷：无法检测反射、naive层以及运行时决定Intent是显式还是隐式的

《Resolving the predicament of Android custom permissions》
来源：NDSS 2018 (CCF B)
关键词：Android, Custom Permission

1.针对问题：

自定义权限的不安全性

2.Contribution

（1） 提出Android现有的自定义权限存在的漏洞以及根据漏洞实施了两大攻击

• 恶意app可绕过用户交互需求直接获取危险权限，窃取高危险级的系统资源（Android6.0及以上）
• 恶意app可提升自己的权限以访问其他app受保护的组件
  （2） 建立了第一套Android下运行时权限模型，提出了Cusper，解决上述存在的漏洞

3.Inroduction

Android权限模型：Normal，Signature，Dangerous
Android 6.0之前：安装时权限
Android 6.0之后：运行时权限（仅针对dangerous权限）
Android不允许两个同名权限同时存在于一个设备上。
系统权限：保护系统资源
自定义权限：第三方应用程序可自己定义新的权限。 保护不同app之间或者系统组件间的IPC资源
然而！
（1）安卓对待自定义权限和系统权限没有区别
（2）没有对自定义权限的命名规则约束，可以随便取自定义权限名称

自定义权限的使用情况如图所示：

4.Attack

利用自定义权限获取未授权的平台和app资源

两种攻击：custom permission upgrade，confused deputy
攻击前准备：
抓取应用市场（例如Google Play Store）下载感兴趣的目标应用，并进行逆向，分析Android Manifest文件和源代码，以观察自定义权限用于保护应用程序组件的情况。
攻击者可以在应用市场上构建和分发一系列恶意应用，利用Android的自定义权限漏洞对被攻击应用和平台发起攻击。

A legacy application (legacy app) is a software program that is outdated or obsolete. Although a legacy app still works, it may be unstable because of compatibility issues with current operating systems (OSes), browsers and information technology (IT) infrastructures.

1.custom permission upgrade attack
原理：系统权限和自定义权限没有隔离
效果：攻击者可在未经过用户交互的情况下，直接获取dangerous级别的系统权限。
概述：
（1）首先攻击者创建一个app，声明一个自定义权限，级别为normal或signature，并且将自定义权限设置为系统权限组的一部分（如存储，或照相机）
（2）更新此自定义权限的定义，将保护级别更改为dangerous，并继续在相应的应用市场上推送其应用的更新，此时攻击者app将自动获取授权，同时自动获取同组其他危险权限，而不会告知用户

左边：已获取该system permission group的权限
右边：可获取该dangerous权限及该权限组的所有权限

分析：
（1）Android处理自定义权限的方式与系统权限相同
（2）normal和signature权限在安装时授予。对于传统应用程序（SDK<23），dangerous权限也在安装时授予;而对于新应用程序，则在运行时被授予。

当system权限从安装时授予变成运行时授予，意味着 这个app升级到了SDK 23以上
当custom 权限升级，暗示着 这个app有可能升级了，也有可能权限级别从normal/signature变成了dangerous
但是系统并不具备区分这两种情况的能力

如果传统应用程序升级到SDK 23或更高，则系统还将授予的危险权限从安装时 “升级”到运行时权限，并在用户未通过权限设置手动撤销它们时自动授予它们（由FLAG_PERMISSION REVOKE_ON_UPGRADE标志被设置为允许）。
PackageManager.FLAG_PERMISSION_REVOKE_ON_UPGRADE：如果permission被标记了这个flag，那么表示，app升级后被deny的permission,会依然是deny的状态。这个flag会在下面的情况中用到。适用于L以前版本的app,安装得到M的device上，如果它的dangerous permission被撤销了，比如通过settings里面的permission管理撤销或者device policy中设定，那么该APP升级到适用于M新的permission模式后，那么升级后这个permission依然是撤销的状态。也就是dangerous permission如果在升级之前被撤销过，升级后依然是撤销的状态。

2.confused deputy attack
原理：利用自定义权限不严格的命名约定
效果：使操作系统向攻击应用授予被攻击应用的签名级自定义权限（俩应用为不同证书签名），以此获取对被攻击应用组件的未经授权的访问。
概述：
假定被攻击应用自定义权限名为N

1. 攻击者创建两个app，definer app A自定义一个名称为N的权限，但将保护级别设置为dangerous，attack app仅在清单中请求该权限N
2. Definer app需要先由用户安装，然后安装attack app。在运行时将definer app的欺骗权限授予attack app后，definer app可由用户卸载或由应用程序开发人员更新，以便事后安装被攻击应用。
3. 安装被攻击app后，attack app能够向受害者发起攻击，以便自由访问被攻击app的受到签名保护的组件，即使它未使用与被攻击app相同的应用程序证书进行签名。
   
   Google承认这是高度严重的攻击，因为它绕过了隔离应用程序数据与其他应用程序的操作系统保护。

分析：
（1）在更新或卸载app时，系统并不立即更新原有的自定义权限，而是在重新声明具有相同名称的新权限时撤销。
（2）由于Android在权限执行期间仅使用权限名称，因此无法区分具有相同声明名称的两个不同权限。因此，持有“暂时休眠”危险权限的应用程序会以未授权的方式访问受同名signature权限保护的组件。

目标app：
（1）CareZone
所有的隐私数据都存在一个被signature级别的自定义权限保护的content provider中

1
2
3

<permission android:label="@string/permission_access_provider_label" android:name="com.carezone.caredroid.careapp.permission.CZ_CONTENT_PROVIDER" android:protectionLevel="signature|signatureOrSystem" android:description="@string/permission_access_provider_desc" />

<provider android:name="com.carezone.caredroid.careapp.content.provider.CareAppProvider" android:permission="com.carezone.caredroid.careapp.permission.CZ_CONTENT_PROVIDER" android:exported="true" android:authorities="@string/cz_authority_content" android:syncable="true" />

（2）Skype
有一个被signature级别的权限保护的Activity，该Activity的功能是拨打电话

5.Cusper

修改Android源码BasePermission等class文件

A. 隔离系统权限和自定义权限

• sourcePackage（权限的始发包名）无法可靠的标记权限是系统还是自定义
• 使用额外的成员变量来扩展权限的对象表示，以指示此权限是否为自定义权限
• 应用程序声明自定义权限组时，禁止使用系统权限组前缀（android.permission-group）
• 区分系统和自定义权限后，设置FLAG_PERMISSION_REVOKE_ON_UPGRADE标志位，攻击者将应用更新为dangerous权限时，系统不会自动授予

B.系统级的自定义权限命名约束
设想解决：
1.将app包名作为源id，强制所有自定义权限名称都内部添加声明它的app的id为前缀：source_id:permission_name，以此解决不同app的同名权限欺骗攻击
2.系统只允许签名相同的app申请同名自定义权限

但是存在两个问题：
1.恶意应用刻意伪造包名与被攻击者包名一致？
2.同一开发者开发的多个应用之间若要互相申请使用权限？
解决：使用app的signature作为source_id

6.Android Permissions Alloy Model

Alloy：一种轻量级的formal语言

（1）构建权限，applications，组件，设备的相关数据结构体
Permissions {name, package, protection level, permission group}
Applications {packageName, signature, declaredPerms, usesPerms, guard, components, targetSDK, permissionState}
Components {app, guard} //guard是指protected permission
Device {apps, builtinPerms, customPerms, platform PackageName, platformSignature, builtinPermGroups}
（2）与权限相关的系统操作 {install, uninstall, update}
（3）实现效果：可以防止以上提出来的两种攻击

《An Empirical Study of Web Resource Manipulation in Real-world Mobile Applications》
来源：USENIX 2018 (CCF A)
关键词：Android, Static Analysis, Web Resource Manipulation, Malicious intent
摘要：由于Android和IOS都允许应用程序注入JavaScript到WEB页面中，且web资源缺少同源访问控制，因此会导致XPM攻击(cross-principal manipulation)。此文章针对XPM攻击进行了研究，一方面定义并在现实app中研究了该威胁，另一方面设计了XPM的自动检测方案，其中在检测中引入了搜索引擎和自然语言处理部分。但此文章的重点不在于检测，而在于大规模的研究，最终提出了14个Finding。

1.针对问题：

静态检测Android与IOS中的WebView存在的attack——XPM (cross-principal manipulation)
研究点：现实中的app到底有多少存在这个attack

XPM (cross-principal manipulation)：Android和iOS都有evaluateJavascript的API，允许host app注入JavaScript代码到Web页面中并得到结果。但是，这些web资源控制缺少同源访问控制，因此导致WebView的app的代码。例如，如果一个Host app通过webview加载“www.facebook.com”，那么它就可以使用evaluateJavascript API来在facebook页面中运行Javascript，从而得到facebook的数据。

XPM如图所示，manipulating code（控制代码）通过Web Resource manipulate point（web资源控制点，即相关API）来控制Manipulated Web Resource。

Treat Model：如图所示是两个app之间通过web资源窃取cookie。App A是Facebook软件， App B是一个嵌入了facebook SDK登录功能的软件三个class, C1, C2和C3都会通过webview访问www.facebook.com，前两个都属于正常的，第三个则是app B恶意收集facebook的cookie信息

两种攻击者：一是host app本身，二是host app使用的第三方库
Web Resource Manipulation APIs：作者列举了四个方面的13个API（包括Android和IOS），如表所示。

2.Contribution

（1）将在Web资源控制中存在的威胁定义为XPM，并大规模地研究这种威胁在现实app中的存在
（2）设计了一个自动工具来检测Android中的XPM
（3）对80694个app进行了研究，说明XPM在现实app（Android和IOS）中的严重性

3.Chanllenge

（1）一个app中存在多个principal
（2）字符串的混淆与缩写
main ideas:
（1）使用代码特征来识别AP
（2）使用搜索引擎来对比AP与WP，并加入自然语言处理部分

4.检测方法——XPMChecker

（1）静态分析模块：使用flowdroid和soot构建ICFG，并寻找Web Resource Manipulation API及相关的context等信息
包含URL的提取（前向数据流分析）、string的分析（后向切片）、代码块的signature
（2）Principal识别模块：WP与AP的识别（判断是Host app代码还是Lib代码，寻找其是否出现在多个Lib中）
（3）XPMClassifier模块：根据相似性计算（图3所示公式）来判断AP与WP <AP,WP> 是否属于同一来源，判断标准是某个阈值ϴ。步骤如下：
A. 去除<AP,WP>中的噪声词汇，如后缀或者停止词汇（get.appdog.com中的com），得到<AP’,WP’>
B. 将AP’和WP’作为关键字在Google搜索引擎上搜索，并得到结果Rap和Rwp
C. 使用词袋模型进行结果分段（忽略语法和词序），并转换成向量A和W
D. 最后根据公式计算相似性，以阈值ϴ作为界限来判断是否存在XPM。相似性的计算公式如下所示：

5.Evaluation

由于此文章重点在于分析现实app中存在的XPM，而不是检测方法，因此评估是以findings为主体。
（1）XPMChecker的评估
.静态分析模块：人工选择50个app并标注了36个web资源控制点，XPMChecker可自动识别其中的33个，另外3个是因为字符串加密或调用链太深
. Principal识别和分类模块：人工选择1000个app，并通过误报率和漏报率的交点得到阈值ϴ，结果如表4所示。

（2） XPM行为的普遍性
Finding 1：49.2%的控制点都存在跨域（principal）
Finding 2：16.9%的app都有web控制资源，4.8%存在XPM
Finding 3：63.6%的XPM点来源于库
Finding 4：多于70%的XPM点都是控制流行web服务的
Finding 5：web contents和web addresses是最普遍的

（3）XPM的Breakdown
Finding 6：大多数XPM行为对用户体验都是必要的
Finding 7：一些XPM行为部署认证模块的方式不安全
Finding 8：第一次确定了带有恶意intent的web资源控制行为，包含模仿认证模块、窃取用户账户及密码、窃取滥用cookie
Finding 9：恶意XPM行为在Android和IOS上都存在
Finding 10：大多数恶意XPM行为旨在攻击认证模块
Finding 11：恶意XPM行为已经影响了大量用户

缓解方案：
完全的webview隔离是不适用于大多数app的，但是可以采用细粒度的访问控制策略。

6.Limitation

（1）XPMChecker并不能防止逃逸行为，如可以通过使用Java反射和混淆字符串来逃避检测
（2）静态分析工具固有的缺陷

最近洗心革面，好像新学期伊始就能给人很大的力量，希望可以坚持~
今天看到一篇分析QQ表情bug的博客，记录一下学习过程，原博戳这里

1. bug

Android 7.6.0-7.6.3版本的QQ发送[菜刀]+数字+[表情]就会转换成脏话发出去.

2. 分析

（1）下载三个版本中任意一个版本，这里下载的是7.6.0。测试一下，[菜刀]+”1”+[心] 被转换为死胖子， [菜刀]+” “+[心] 被转换为 [跳舞]AmN you
（2）通过字符串搜索定位到com.tencent.mobilqq.lovelanguage.LoveLanguageConfig.class

（3）f9982a脏话的引用处：
a. public static String a(String str)，将前6个char改变大小写，这也是为什么”damn you”被转为了”[跳舞]AmN you” 的一个原因。这个暂时没理清。
b. public static boolean m1991a(char c) ，看是否下标越界
c. public static String a(String str)中if (str4.equals(substring.toLowerCase())) 判断是否收到骂人的话，是的话就换成友好的表情
d. public int a(EditText editText) 似乎是判断是否发出骂人的话，是的话就换成友好的表情
e. public void m1994a(EditText editText) 判断是否输入0x11,a,b,c，是的话就替换为脏话
（4）LoveLanguageConfig中有两个对 char 的运算

分析一下， [菜刀]+”1”+[心] 被转换为死胖子， [菜刀]+” “+[心] 被转换为 [跳舞]AmN you 。而 “1”的ASCII码为49，” “的ASCII码是32，两者的差是 17，在数组中，死胖子和 damn you 的间隔也是 17。而 “ “与(char)30的差是2，2在数组中是”damn you”。所以这个运算就是将char和数组对应起来。
（5）LoveLanguageManager中的public int a(EditText editText)判断发出的话是否是脏话。

如果输入框内容发现有 ‘\x11’ + charA + charB + charC 这种格式的，调用 LoveLanguageConfig.a函数，进行转化后替换掉原来的文本，之后发出去。
绝大部分情况下，用户肯定不会输入 \x11 这个字符，所以猜测是[菜刀]表情编码中带有 \x11，然后拼接了后面的几个任意的 char，就会被替换成脏话。【后来发现菜刀确实是 \x14\x11组成的】
（6）LoveLanguageManager中的public void a(EditText editText)判断收到的话是否是脏话。验证一下猜想，输入 [菜刀]+”111” ，触发；输入 [菜刀]+1234567 ，发现123消失了。
（7）这里顺便贴一下原作者的xposed实验

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

ClassLoader loader = loadPackageParam.classLoader;
Log.d(TAG, "start hook");
XposedHelpers.findAndHookMethod("com.tencent.qphone.base.util.QLog", loader, "d", String.class, int.class, String.class, new XC_MethodHook() {
    @Override
    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
        super.beforeHookedMethod(param);
        Log.d(TAG, param.args[0] + "\t" + param.args[2]);
    }

    @Override
    protected void afterHookedMethod(MethodHookParam param) throws Throwable {
        super.afterHookedMethod(param);
    }
});
XposedHelpers.findAndHookMethod("com.tencent.qphone.base.util.QLog", loader, "isColorLevel", new XC_MethodReplacement() {

    @Override
    protected Object replaceHookedMethod(MethodHookParam methodHookParam) throws Throwable {
        return true;
    }
});

XposedHelpers.findAndHookMethod("com.tencent.mobileqq.lovelanguage.LoveLanguageManager", loader, "a", EditText.class, new XC_MethodReplacement() {
    @Override
    protected Object replaceHookedMethod(MethodHookParam methodHookParam) throws Throwable {
        return 0;
    }
});


XposedHelpers.findAndHookMethod("com.tencent.mobileqq.lovelanguage.LoveLanguageManager", loader, "a",  EditText.class, new XC_MethodHook() {
    @Override
    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {
        super.beforeHookedMethod(param);

        Object obj = param.thisObject;
        Method[] methods = obj.getClass().getDeclaredMethods();
        for (Method m : methods) {
            Log.e(TAG, m.toGenericString() + "===" + printHexString(m.getName()));
        }

        EditText editText = (EditText) param.args[0];
        String s = editText.getText().toString();
        Log.d(TAG, "input=" + s);
        Log.d(TAG, "input=" + printHexString(s));
    }

    @Override
    protected void afterHookedMethod(MethodHookParam param) throws Throwable {
        super.afterHookedMethod(param);
        EditText editText = (EditText) param.args[0];
        String s = editText.getText().toString();
        Log.d(TAG, "after=" + s);
        Log.d(TAG, "after=" + printHexString(s));
    }
});


Log.d(TAG, "end hook");

我们输入：[菜刀]1[心]的时候
输入输出的Log:

1
2
3
4
5

05-28 04:24:03.716 1511-1511/com.tencent.mobileqq D/LDB: input=1J
05-28 04:24:03.716 1511-1511/com.tencent.mobileqq D/LDB: input=141131144a
05-28 04:24:03.866 1511-1511/com.tencent.mobileqq D/LDB: LoveLanguageManager love language report 0X8009167
05-28 04:24:03.866 1511-1511/com.tencent.mobileqq D/LDB: after=死胖子
05-28 04:24:03.866 1511-1511/com.tencent.mobileqq D/LDB: after=14e6adbbe88396e5ad90

我们输入：[菜刀]123的时候

1
2
3
4

05-28 05:04:28.338 1511-1511/com.tencent.mobileqq D/LDB: input=123
05-28 05:04:28.338 1511-1511/com.tencent.mobileqq D/LDB: input=1411313233
05-28 05:04:28.347 1511-1511/com.tencent.mobileqq D/LDB: after=死胖子
05-28 05:04:28.347 1511-1511/com.tencent.mobileqq D/LDB: after=14e6adbbe88396e5ad90

我们输入：[菜刀]空格[心]的时候

1
2
3
4

05-28 05:11:06.107 1511-1511/com.tencent.mobileqq D/LDB: input= J
05-28 05:11:06.107 1511-1511/com.tencent.mobileqq D/LDB: input=141120144a
05-28 05:11:06.120 1511-1511/com.tencent.mobileqq D/LDB: after=dAmN you
05-28 05:11:06.120 1511-1511/com.tencent.mobileqq D/LDB: after=1464416d4e20796f75

（8）[菜刀]表情包含2个 char，是 \x14\x11 ，既然如此，这里又有一个细节，其实转化为脏话以后，第一个 char 还是保留着的，当它与字母拼接时，是可以组合成 QQ 快捷表情发出去的，比如[菜刀]+”9”+“gh”发出去就是[加油拳头]dIot。

《Intersection Automata based model for Android Application Collusion》
来源：AINA 2016 (CCF B)
关键词：automata, Android, ICC Collusion Attack
摘要：
本文针对安卓中存在的基于intent的ICC Collusion Attack，使用有限状态自动机方法从组件层面进行检测。

1.针对问题：

Android 多个应用之间的互相调用和交互时存在ICC Collusion Attack

ICC Collusion Attack：两个应用之间的组件调用，但是两个应用所拥有的权限不同，因此应用A可以通过应用B可以获取不属于应用A的权限，导致权限提升问题。可以称之为组件间通信合谋攻击。

Treat Model：如下图(msgRead与msgSend应用之间存在提权攻击)所示，msgRead拥有接收短信和读取短信的权限，msgSend拥有写短信和发短信的权限，msgRead通过Intent与msgSend交互时，可能存在将短信内容通过intent发送给msgSend，导致隐私泄露。

2.contribution

（1） 第一个使用非确定性有限状态自动机来标识基于ICC的Intent,使用app之间的通讯和相关策略的制定来检测攻击
（2） 在组件层面分析（传统工作都基于应用或方法层面分析，不精确且应用范围小）
（3） 对21个app组合成的210对进行测试，成功检测
（4） 时间和内存都是线性的

3.Challenge

（1） App之间的ICC Collusion Attack检测比较难
（2） ICC Collusion Attack与隐式intent相关联，如何将intent与隐私泄露结合，实际上需要考虑intent-component-permission这条链。
（3） 将app行为与定制的策略相结合

4.文章方法

由于intent的发送者和接收者组件权限不相等，因此ICC Collusion Attack检测问题可以被视为字符串搜索和模式匹配问题。所以本文提出了组件层面的自动机检测方案。
该交叉自动机由两个自动机组成。提取两个app(A和B)中的调用图，如果A的组件发送一个Intent给应用B符合intent-filter的组件，则A和B之间使用边连接起来（application自动机）。检测这些边是否破坏了我们定义的安全权限策略（policy自动机）。
(1)application自动机
第一个是对app进行分析得到的Application自动机，描述函数和权限之间的关系，如图2(application自动机示意图)所示。
（1）首先提取app中的图，顶点代表所有的组件，定义intent的源组件和目标组件，边即连接源组件和目标组件。
（2）将两个app的顶点和边形成的图进行联合。
（3）减少与权限无关的边
（4）将图转换成自动机，该自动机大小为n（n是app中组件数量）。

(2)policy自动机
第二个自动机描述权限和隐私泄露之间的关系，Collusion attack发生是因为危险权限以一定的顺序被使用，policy自动机如图3所示。

最终的自动机结合了权限，函数调用和隐私泄露的policy，最终检测出ICC Collusion Attack，如图4(交叉自动机示意图)所示。

5.evaluation

数据来源：21个app（14app(自己设计)+ 3 app(DroidBench)+ 4app(Google Play)）
两两app进行组合，总210对app组
结果：21个app之间存在发送短信，泄露位置等隐私泄露现象。实验证明自动机状态数与分析的app组件数是线性关系。

《Achicving accuracy and scalability simultaneously in detetcing application clone on Android markets》
来源：ICSE 2014
关键词：Software analysis, Android, clone detection, centroid
摘要：
本文针对安卓市场上的重打包问题，提出了基于opcode相似性的检测方案。参考物理学中的“质心”（centroid）概念，此文定义了一个图的几何特征， 构建了基于权重的3D-CFG图，用于测量两个APP的methods的相似度，根据相似度得出是否为APP克隆的结论，有较高的精确度(accuracy)及较大的应用规模(scalability)。
参考官方讲解

1. 背景简介

App Clones的特征：

（1）A billion opcode problem：opcode量大
（2) code fragment clones and app clones： code fragment相似不代表是克隆APP，可能是相同三方库。只有核心代码相同才算克隆
(3) Type 2 and Type 3 clones are prevalent on Android markets： 目前市场的APP clone大多是2,3类型的。

四种克隆类型：

（1）大部分代码完全相同
（2）大部分代码语义完全相同
（3）代码有改动，增添或删减部分代码
（4）相同的算法，但应用的形式有变化

2. 现状分析

很多方法只能区分1类型，对于2,3类型的分析准确度不足,例如String-based, token-basedand AST (Abstract Syntax Tree)-based等等
PDG（program dependence graph）等依靠图的同态来分析的方法，对于2,3类型的准确度足够，但存在效率不足的问题。
table 1是对之前的检测方法的对比，之前的方法都是对code fragment的相似性进行检测，并不能保证代码是克隆的。

结论：

（1）依靠图来分析方法，如果能够避免利用图的同态性（graph isomorphism）来分析，会大大提高效率
（2）分辨app clone需要比较不同市场中的APP，代码量巨大。一对一比较的复杂度为C（2，M），M为method个数。需要降低这个复杂度

特点：

（1）在保证针对2,3类型的准确率的同时，不用同态性比较，大大提高了效率。
（2）在比较之前进行分类，不需要一对一的比较，复杂度降低，提升效率。
（3）只比较core functionalities，可以有效针对添加库和广告的克隆

3. 文章方法centroid

PDG（program dependence graph） -> CFG(control flow graph) -> 3D-CFG -> centroid(重心坐标)
centroid相同，method一定相同，同时具有单调性，centroid相差大，method相差一定大。

*定义了Application Similarity Degree(ASD)

*定义了可能是克隆的分组规则Clone Group，将centroid相近的分在一起，用于比较。

主要思想：

*3D-CFG：CFG的每一个节点都有唯一的一个坐标(x,y,z)。x代表CFG中的序列号，y代表出度，z代表参与的loop个数。
序列号x的选择：从1开始，按照更多statement->更大binary值 来给分支中的节点标号，最后的return语句代表stop节点。

*centroid的定义：

其中wp代表在基本块p中的statement数量

*method级别的相似性度量Centroid Difference Degree(CDD)：

若两个method相同，则CDD=0

*通过去除同一作者的app，和公开的framework和第三方库，来集中寻找cloned apps。

流程：

（1）在不同市场下载APP，转化为smali
（2）转化为centroid，存入数据库，包含market name,app file name, class name, method name and centroid
（3）将每个method只与Clone Group中的method相比较，复杂度为 M*c, c << M

4.实验评估

第三方Android应用市场（apk数据来源）：

2 American markets (Pandaapp and Slideme)
2 Chinese markets (Anzhi and Dangle)
1 European market (Opera).

结果：

误报率：<1%
漏报率：0.4—0.7%
同时具有较高的效率，一个小时可以处理150145个APP,每个method只需同组内小于8个其他的method进行比较。
如果有新的APP与数据库中已有数据比较，效率也是很快。。

limitations

(1)不能检测到Type 4的app clone，但实际上没有在应用市场中找到第四种类型的app
(2)在较小的CFG中添加一个节点会很大的改变centroid，但实际上小CFG只占2.3%。
(3)app clone通过值克隆一小部分method而逃逸检测
(4)若app clone的opcode比原始app多，则可能不会检测到。

小白在发博客时遇到了好多问题，就在这里记录一下吧~

1.如何在博客中插入图片？参考文章

（1）把主页配置文件_config.yml 里的post_asset_folder选项设置为true
（2）在hexo目录下执行命令：npm install hexo-asset-image –save，即下载安装可以上传本地图片的插件hexo-asset-image
（3）再运行hexo n “xxx”来生成md博文时，/source/_posts文件夹内除了xxx.md文件还有一个同名的文件夹
（4）最后在xxx.md中想引入图片时，先把图片复制到xxx这个文件夹中，然后只需要在xxx.md中按照markdown的格式引入图片：

(5)检查一下，hexo g生成页面后，进入public\2018\06\24\index.html文件中查看相关字段，可以发现，html标签内的语句是

而不是

(6)最后, hexo d上传，OK！