移动终端侧的恶意软件检测概述

​一、移动发展背景及意义

Android系统是终端由Google公司于2007年发布的一种基于Linux内核的操作系统。作为全球最受欢迎的恶意移动端操作系统 ，Android拥有来自190多个国家超过25亿的软件活跃用户，所占市场份额超过85%[1]  。检测由于其高度的概述开源性及自由性，许多开发人员纷纷投身于应用软件开发工作 。移动截至2020年  ，终端Google Play商店中存在290万个应用程序
，恶意下载次数高达1080亿次[1]。软件但与此同时，亿华云检测大量恶意软件利用第三方应用市场的概述审查漏洞趁虚而入，为智能手机用户带来了巨大的移动危害，包括隐私泄露、终端资费消耗等。恶意近年来，恶意软件检测已经成为热门研究领域，各大安全厂商也开发出了各自的安全检测软件，如AVG Antivirus、Norton Mobile Security等 。但随着Android版本的更新，恶意软件的攻击方法不断升级 ，源码下载现有的安全检测软件效果有待进一步的提升。

二、Android系统安全机制

Android 系统是基于Linux 内核实现的 ，同时在Linux 原有的安全机制基础上结合移动端的特性，设计了应用程序签名机制、权限机制
、进程沙箱隔离机制等安全机制，保证了应用程序在发布 、安装和运行过程中的安全[2] 。高防服务器

1. 应用程序签名机制

应用程序签名机制指的是在应用程序发布时，由开发者采用私钥进行签名，在安装程序时 ，Android系统使用公钥对应用程序进行验证溯源，从而与开发者间建立信任关系。通过数字签名，系统一方面可以实现对程序的版本控制
，另一方面也可以对应用程序安装包的完整性进行验证  ，同时可以有效检测重打包攻击 、应用篡改等恶意行为
，从而过滤恶意应用 。但攻击者有时也会伪造第三方应用签名，服务器租用逃过系统检测。签名机制按照签名对象可以分为两类：对程序安装包解压后的非目录和非过滤文件进行签名验证，以及对压缩安装包整体进行签名验证。

2. 权限机制

权限机制指的是应用程序在安装时和运行过程中，向系统申请所需服务的权限，并根据获取的权限运行相应服务，其定义信息包括包名
、标签、描述和保护级别等[3]  。

3. 进程沙箱隔离机制

图1

进程沙箱隔离机制指的是模板下载应用程序始终运行于系统为其开辟的独立Dalvik虚拟机中，拥有独立的运行空间和系统资源空间，从而保证应用程序间的独立，限制不可信程序的权限。具体来说，每个应用程序在安装时都被系统赋予了唯一的UID ，在程序运行期间，系统隔离非同一UID的应用程序及资源
，使其互不干扰 ，进而使各个应用程序的建站模板资源都得到安全保护 。

三 、常见的恶意软件攻击方法

1. 重打包攻击

重打包攻击指的是攻击者对原始应用程序进行反编译，将恶意代码植入应用程序中，然后通过伪造应用签名通过系统检测，重新打包为第三方应用进行发布。

2. 提权攻击

提权攻击是指攻击者利用Android系统漏洞或第三方代理软件等，提升普通应用程序的系统服务权限，从而获得其所需权限。一旦恶意应用拥有较高的系统权限，就会对系统造成巨大的安全威胁
。

3. 其他攻击

随着Android系统的更新与发展，市场上出现了许多其他的恶意软件攻击方法 。比如利用剪切板功能简单且无需申请额外权限的特点，恶意篡改剪切板内容，危害系统安全；植入抓取代码，窃取用户隐私信息
，进行电子诈骗；利用调试接口传播恶意软件等 。

四、恶意软件检测的基本方法

恶意软件检测问题本质上是一个分类问题，对给定的应用程序，判断其为恶意软件还是正常软件。根据解决分类问题的一般性方法 ，恶意软件检测的大致流程如图2所示。

图2

首先获取谷歌应用市场和第三方应用市场中的正常软件程序包，以及恶意软件程序包，构成数据集；然后从中抽取特征信息
，并进行特征预处理；最后根据特征值信息，基于规则或分类算法完成分类任务 。

Android应用程序安装包是一个后缀为.apk的压缩文件 ，解压后可得如下文件：

表1

常见的恶意软件检测方法，主要是基于AndroidManifest.xml文件和classes.dex文件进行特征抽取 。

AndroidManifest.xml文件是Android应用程序的全局配置文件，提供了在程序运行前系统所需的各种必要信息，包括应用的包名 、版本号 、权限信息
、硬件信息等。

classes.dex文件是应用程序的二进制可执行文件，java代码首先会被编译为.class文件，得到的类文件被翻译成Dalvik字节码，最终合并为一个或多个可执行dex文件[4]。在恶意软件检测方法中 ，有的研究者会首先对其进行反编译 ，然后再抽取特征，有的研究者则会直接利用原始字节码序列或对其进行截取、处理 。

五 、Android恶意软件检测方法

1. 按照不同的特征抽取方法 ，可以分为静态检测、动态检测和混合检测[5]。

（1）静态检测方法

静态检测方法是指在应用程序不运行的情况下，基于应用程序特征进行系统检测分析[6-7]。其常用的特征包括应用权限 、Java代码 、网络地址
、硬件组件等
。静态检测方法优点是检测速度快，缺点是无法有效识别利用了静态检测对抗技术（如代码混淆）的恶意应用程序。常见的静态检测方法包括基于应用程序安装包文件特征的检测、基于应用程序代码分析的检测、基于应用布局特征的检测等。

基于应用程序安装包文件特征的检测方法，关注表1所示的签名文件、清单文件
、资源文件及代码文件等
，从中抽取特征表示，通过相似性比较或模型训练的方法完成恶意应用检测 。比如Zhou等[8]提出DroidMoss模型抽取应用的代码特征，采用模糊哈希的方法生成应用程序特定的指纹信息，然后进行相似度比较，从而判断是否为恶意应用程序 ，但该方法无法有效应对代码混淆等对抗攻击 。Nicheporuk等[9]基于API方法调用和权限信息 ，采用卷积神经网络训练模型完成分类。

基于应用程序代码分析的检测方法 ，更加关注代码文件，将应用程序代码抽象为控制流图 、API函数图或程序依赖图
，然后再进行相似性比较。比如Crussell等[10]提出DNADroid模型基于应用程序依赖图完成相似性计算 ，有效应对重打包攻击。为了提升对重打包应用的检测效率 ，同时有效对抗代码混淆攻击，汪润等[11]提出可以进行粗细两个粒度的检测并抽取代码的深层语义信息。该模型首先进行粗粒度检测
，将应用程序依赖图抽象为程序语义特征，计算程序语义特征间相似性，实现快速检测；对于细粒度检测，则是将程序依赖图作为特征，实现更为准确的恶意应用检测 。

基于应用布局特征的检测方法 ，关注应用程序的UI界面，从中抽取特征信息作为分类依据。比如Zhang等[12] 提出可以根据应用界面生成界面图，然后计算图间的相似性。该方法检测速度快 ，但检测精度有限
，因此可以将其与代码特征相结合 ，兼顾检测速度与精度 。

（2）动态检测方法

动态检测方法是在沙盒环境中运行程序，并跟踪程序的API调用序列、系统调用 、网络流量和CPU数据 ，以监视程序运行期间的数据流[5] ，获取程序运行过程中的动态特征。动态检测方法的关键点在于如何对程序的全部功能进行检测，如何保证测试用例的真实性及全面性
。该方法在实际应用中通常需要占用一定的系统资源且检测速度较慢，但对于未知恶意软件的检测通常具有较好的表现 。常见的动态检测方法分为两类：基于应用行为分析的检测和基于污点跟踪的检测
。

对应用行为的分析目标，可以选择应用程序对系统服务的调用信息，也可以选择非系统调用信息，如实时交互信息或应用运行信息等。Tam等[13]设计了CopperDroid模型，结合系统调用和Binder通信行为数据，重构了恶意应用程序的高级语义信息
，最终输出恶意行为，包括系统相关行为和Android相关行为两种 。该方法可以有效抵抗代码混淆攻击，且无需修改系统源码，部署方便
。Gianazza等[14] 提出PuppetDroid模型 ，基于用户与应用程序的实时交互行为获取特征信息 ，进行恶意应用检测 ，与普通的自动UI方法相比达到了更高的代码覆盖率  。

基于应用行为数据获取的特征表示，忽视了数据间的关联性信息
，且无法刻画程序的全流程行为。为解决该问题 ，Enck等[15]提出基于污点跟踪的恶意软件检测方法——TaintDroid。该方法从污染源标记敏感信息，动态追踪数据流和系统调用，实现了变量级、信息级 、方法级和文件级的污点跟踪。

（3）混合检测方法

无论是静态检测方法还是动态检测方法
，都具有一定的局限性。静态检测无法捕获应用程序在运行时的行为信息
，而动态检测无法实现完整的代码覆盖范围 。因此
，有研究者提出混合检测方法，即静态和动态分析组合的方法 ，可以使Android恶意软件检测更加准确和高效。Onwuzurike等[16]在静态检测和动态检测中使用了相同的建模方法，都基于API调用序列构建马尔科夫链，最终比较两种方法的检测性能。结果表明
，混合检测的方法具有更好的性能表现  。

参考文献

[1]     Android Statistics (2022) https://www.businessofapps.com/data/android-statistics/

[2]     Google Inc. Android security［EB/OL］. (2013－06－26)［2019－10－07］. https://source.android.com/tech/security/．

[3]     王思远, 张仰森, 曾健荣, 等. Android 恶意软件检测方法综述[J]. 计算机应用与软件, 2021, 38: 9.

[4]     李佳琳, 王雅哲, 罗吕根, 等. 面向安卓恶意软件检测的对抗攻击技术综述[J]. 信息安全学报, 2021, 6(4): 28-43.

[5]     Meijin L, Zhiyang F, Junfeng W, et al. A Systematic Overview of Android Malware Detection[J]. Applied Artificial Intelligence, 2022, 36(1): 2007327.

[6]     孙伟，孙雅杰 ，夏孟友． 一种静态Android 重打包恶意应用检测方法［J］． 信息安全研究， 2017，3( 8) : 692 － 700．

[7]     蒋煦，张长胜  ，戴大蒙 ，等． Android 平台恶意应用程序静态检测方法［J］． 计算机系统应用 ， 2016， 25( 4) : 1 － 7．

[8]     Zhou W, Zhou Y, Jiang X, et al. Detecting repackaged smartphone applications in third-party android marketplaces[C]//Proceedings of the second ACM conference on Data and Application Security and Privacy. 2012: 317-326.

[9]     Nicheporuk A, Savenko O, Nicheporuk A, et al. An Android Malware Detection Method Based on CNN Mixed-Data Model[C]//ICTERI Workshops. 2020: 198-213.

[10]  Crussell J, Gibler C, Chen H. Attack of the clones: Detecting cloned applications on android markets[C]//European Symposium on Research in Computer Security. Springer, Berlin, Heidelberg, 2012: 37-54.

[11]  汪润, 唐奔宵, 王丽娜. DroidFAR: 一种基于程序语义的 Android 重打包应用抗混淆检测方法[J]. 武汉大学学报: 理学版, 2018, 64(5): 407-414.

[12]  Zhang F, Huang H, Zhu S, et al. ViewDroid: Towards obfuscation-resilient mobile application repackaging detection[C]//Proceedings of the 2014 ACM conference on Security and privacy in wireless & mobile networks. 2014: 25-36.

[13]  Tam K, Fattori A, Khan S, et al. Copperdroid: Automatic reconstruction of android malware behaviors[C]//NDSS Symposium 2015. 2015: 1-15.

[14]  Gianazza A, Maggi F, Fattori A, et al. Puppetdroid: A user-centric ui exerciser for automatic dynamic analysis of similar android applications[J]. arXiv preprint arXiv:1402.4826, 2014.

[15]  Enck W, Gilbert P, Han S, et al. Taintdroid: an information-flow tracking system for realtime privacy monitoring on smartphones[J]. ACM Transactions on Computer Systems (TOCS), 2014, 32(2): 1-29.

[16]  Onwuzurike L, Almeida M, Mariconti E, et al. A family of droids-Android malware detection via behavioral modeling: Static vs dynamic analysis[C]//2018 16th Annual Conference on Privacy, Security and Trust (PST). IEEE, 2018: 1-10.​