一种恶意移动应用检测方法
阅读：897发布：2024-02-01
专利汇可以提供一种恶意移动应用检测方法专利检索，专利查询，专利分析的服务。并且本 发明 公开了一种恶意移动应用检测方法，包括：将待检测移动应用程序转换为可执行、可分析的apk文件；对apk文件进行静态分析，提取移动应用静态特征；根据移动应用静态特征中动态分析所依赖的相关信息对移动应用进行行为触发及行为监控，提取移动应用动态特征；综合考虑移动应用静态特征、移动应用动态特征，对待检测移动应用进行敏感行为分析，根据分析结果对恶意移动应用进行检测分类。本发明通过静态分析获取静态特征，从静态特征中提取动态执行所依赖信息，进行行为触发及行为监控，通过静态结合的方法进行特征提取，实现对恶意移动应用的自动检测，能够破解大部分恶意代码的反分析机制，实现恶意移动应用准确检测。，下面是一种恶意移动应用检测方法专利的具体信息内容。
1.一种恶意移动应用检测方法，其特征在于，包括如下步骤：
将待检测移动应用程序转换为可执行、可分析的apk文件；
对apk文件进行静态分析，提取移动应用静态特征；
根据移动应用静态特征中动态分析所依赖的相关信息对移动应用进行行为触发及行为监控，提取移动应用动态特征；
综合考虑移动应用静态特征、移动应用动态特征，对待检测移动应用进行敏感行为分析，根据分析结果对恶意移动应用进行检测分类。
2.根据权利要求1所述的恶意移动应用检测方法，其特征在于，将待检测移动应用程序转换为可执行、可分析的apk文件的方法包括如下步骤：
选取dex2oat作为脱壳点，对待检测移动应用程序进行脱壳处理，获取未加密的dex文件；
将未加密的dex文件反编译为smali伪汇编代码，修改AndroidManifest.xml，去除加固厂商插入的无效干扰信息；
将smali源码文件编译回dex文件，重打包以获取所述可执行、可分析的apk文件。
3.根据权利要求1所述的恶意移动应用检测方法，其特征在于，所述移动应用静态特征包括动态执行信息，提取移动应用静态特征中动态执行信息的方法包括如下步骤：
调用Androguard的API将移动应用真实的dex文件加载至内存；
通过递归扫描的方式获取每个dex文件中所有类的字节码，并存放在内存中的列表中；
遍历列表将所有类的类名逐行写入动态分析所需的配置文件中；
调用Androguard提供API，获取apk实例对象；
调用apk实例对象的get_activities、get_receivers以及get_services方法分别获取所有这三大组件的组件名；
将组件名逐行写入动态分析所需的配置文件中。
4.根据权利要求1所述的恶意移动应用检测方法，其特征在于，对移动应用进行行为触发的方法包括用户模拟触发，所述用户模拟触发的方法包括如下步骤：
在预设递归搜索次数范围内，通过反复递归搜索确定可点击控件；
采用Traverse UI遍历工具对可点击控件进行批量动态测试。
5.根据权利要求1所述的恶意移动应用检测方法，其特征在于，对移动应用进行行为触发的方法包括回调强制触发，所述回调强制触发的方法包括如下步骤：
根据所提取的移动应用静态特征读取所有类的类名；
利用java的RTTI机制，要求Android虚拟机按照类名加载目标类；
使用强制上转型后是否抛出转换异常的方式判断目标类是否继承自特定回调基类，如果是，则返回目标类的字节码；
根据字节码对目标类进行实例化，得到实例对象；
调用实例对象的回调方法，实现回调强制触发。
6.根据权利要求1所述的恶意移动应用检测方法，其特征在于，对移动应用进行行为触发的方法包括系统消息伪造触发，所述系统消息伪造触发的方法包括如下步骤：
采用Hook系统深层API的方式对时间进行伪造；
调用System.currentTimeMillis()获取正常返回时间值，将正常返回时间值直接加上
1年的时间，返回给被测移动应用，实现时间伪造触发；
采用native代码调用Linux系统的C语言API实现时间记录。
7.根据权利要求1所述的恶意移动应用检测方法，其特征在于，对移动应用进行行为触发的方法包括组件强制触发，所述组件强制触发的方法包括：
获取移动应用所有的Activity组件和Service组件的名字
在动态分析时，调用adb的am工具强制启动这些组件。
8.根据权利要求1所述的恶意移动应用检测方法，其特征在于，所述行为监控包括敏感API调用行为监控，所述敏感API调用行为监控选取深层API作为Hook点。
9.根据权利要求1所述的恶意移动应用检测方法，其特征在于，所述行为监控包括Android系统回调行为监控，所述Android系统回调行为监控的方法包括以下步骤：
选取异步回调类的注册API为Hook点，注册API调用时获取传入的参数并从参数中获取异步回调类的实例，通过调用实例的getClass方法获取异步回调类的字节码；根据字节码获取抽象类的抽象方法的实现，并加以Hook监控。
10.根据权利要求1所述的恶意移动应用检测方法，其特征在于，所述行为监控还包括：
API传递参数记录、用户行为和界面变化捕捉和或文件系统监控；
所述API传递参数记录的方法包括以下步骤：
获取调用API时传递的参数，将所获取的参数上转型或装箱为Object类型，使用instanceof运算符判断所获取参数的数据类型：如果经判断该参数为基本数据类型，那么直接对其进行拆箱，然后记录其真值；如果经判断该参数为引用类型，那么调用该参数toString方法，将其序列化为字符串，再记录其真值；
所述用户行为和界面变化捕捉的方法包括以下步骤：
在回调类的回调方法上下Hook，监控用户行为；
采用UI测试框架模拟UI界面的点击行为，捕捉界面变化；
所述文件系统监控的方法包括以下步骤：
用native代码实现自身文件系统操作，对java语言的文件系统操作API进行Hook监控，实现对于java层文件系统操作的API监控。
一种恶意移动应用检测方法
技术领域
背景技术
[0002] 在移动应用程序中，行为分析是发现新型恶意代码的主要途径，但是恶意代码可以通过加壳、设置复杂的触发条件、检测虚拟机、调用冷僻API等逃避行为分析。现有行为分析方法可分为静态分析和动态分析，静态分析存在代码分析的覆盖不全，分析超时等现象，动态分析很难覆盖所有的用户输入和环境变化。
发明内容
[0003] 本发明的目的在于克服现有技术中的不足，提供一种恶意移动应用检测方法，能够通过动静态检测相结合的方法来提取特征，实现对恶意移动应用的自动检测。
[0004] 为达到上述目的，本发明是采用下述技术方案实现的：一种恶意移动应用检测方法，包括如下步骤：
[0005] 将待检测移动应用程序转换为可执行、可分析的apk文件；
[0006] 对apk文件进行静态分析，提取移动应用静态特征；
[0007] 根据移动应用静态特征中动态分析所依赖的相关信息对移动应用进行行为触发及行为监控，提取移动应用动态特征；
[0008] 综合考虑移动应用静态特征、移动应用动态特征，对待检测移动应用进行敏感行为分析，根据分析结果对恶意移动应用进行检测分类。
[0009] 进一步的，将待检测移动应用程序转换为可执行、可分析的apk文件的方法包括如下步骤：
[0010] 选取dex2oat作为脱壳点，对待检测移动应用程序进行脱壳处理，获取未加密的dex文件；
[0012] 将smali源码文件编译回dex文件，重打包以获取所述可执行、可分析的apk文件。
[0013] 进一步的，所述移动应用静态特征包括动态执行信息，提取移动应用静态特征中动态执行信息的方法包括如下步骤：
[0014] 调用Androguard的API将移动应用真实的dex文件加载至内存；
[0015] 通过递归扫描的方式获取每个dex文件中所有类的字节码，并存放在内存中的列表中；
[0016] 遍历列表将所有类的类名逐行写入动态分析所需的配置文件中；
[0017] 调用Androguard提供API，获取apk实例对象；
[0018] 调用apk实例对象的get_activities、get_receivers以及get_services方法分别获取所有这三大组件的组件名；
[0019] 将组件名逐行写入动态分析所需的配置文件中。
[0020] 进一步的，对移动应用进行行为触发的方法包括用户模拟触发，所述用户模拟触发的方法包括如下步骤：
[0021] 在预设递归搜索次数范围内，通过反复递归搜索确定可点击控件；
[0022] 采用Traverse UI遍历工具对可点击控件进行批量动态测试。
[0023] 进一步的，对移动应用进行行为触发的方法包括回调强制触发，所述回调强制触发的方法包括如下步骤：
[0024] 根据所提取的移动应用静态特征读取所有类的类名；
[0025] 利用java的RTTI机制，要求Android虚拟机按照类名加载目标类；
[0026] 使用强制上转型后是否抛出转换异常的方式判断目标类是否继承自特定回调基类，如果是，则返回目标类的字节码；
[0027] 根据字节码对目标类进行实例化，得到实例对象；
[0028] 调用实例对象的回调方法，实现回调强制触发。
[0029] 进一步的，对移动应用进行行为触发的方法包括系统消息伪造触发，所述系统消息伪造触发的方法包括如下步骤：
[0030] 采用Hook系统深层API的方式对时间进行伪造；
[0031] 调用System.currentTimeMillis()获取正常返回时间值，将正常返回时间值直接加上1年的时间，返回给被测移动应用，实现时间伪造触发；
[0032] 采用native代码调用Linux系统的C语言API实现时间记录。
[0033] 进一步的，对移动应用进行行为触发的方法包括组件强制触发，所述组件强制触发的方法包括：
[0034] 获取移动应用所有的Activity组件和Service组件的名字
[0035] 在动态分析时，调用adb的am工具强制启动这些组件。
[0036] 进一步的，所述行为监控包括敏感API调用行为监控，所述敏感API调用行为监控选取深层API作为Hook点。
[0037] 进一步的，所述行为监控包括Android系统回调行为监控，所述Android系统回调行为监控的方法包括以下步骤：
[0038] 选取异步回调类的注册API为Hook点，注册API调用时获取传入的参数并从参数中获取异步回调类的实例，通过调用实例的getClass方法获取异步回调类的字节码；根据字节码获取抽象类的抽象方法的实现，并加以Hook监控。
[0039] 进一步的，所述行为监控还包括：API传递参数记录、用户行为和界面变化捕捉和或文件系统监控；
[0040] 所述API传递参数记录的方法包括以下步骤：
[0041] 获取调用API时传递的参数，将所获取的参数上转型或装箱为Object类型，使用instanceof运算符判断所获取参数的数据类型：如果经判断该参数为基本数据类型，那么直接对其进行拆箱，然后记录其真值；如果经判断该参数为引用类型，那么调用该参数toString方法，将其序列化为字符串，再记录其真值；
[0042] 所述用户行为和界面变化捕捉的方法包括以下步骤：
[0043] 在回调类的回调方法上下Hook，监控用户行为；
[0045] 所述文件系统监控的方法包括以下步骤：
[0046] 用native代码实现自身文件系统操作，对java语言的文件系统操作API进行Hook监控，实现对于java层文件系统操作的API监控。
[0047] 与现有技术相比，本发明所提供的一种恶意移动应用检测方法所达到的有益效果包括：
[0048] 通过静态分析获取静态特征，从静态特征中提取动态执行所依赖信息，进行行为触发及行为监控，以采集敏感行为信息，利用静、动态特征相结合实现对恶意移动应用的自动检测，能够破解大部分恶意代码的反分析机制，实现恶意移动应用准确检测；
[0049] 通过脱壳然后进行重打包的预处理过程，破解移动应用能够对抗静态分析的加壳行为，提高应用的可分析性；
[0050] 通过强制触发大幅度提高了动态分析的覆盖率，通过组件强制触发和回调强制触发能够直接使得分析路径跳转到目标位置，使得动态分析的覆盖率得到了大幅度增加；
[0051] 针对部分类型的应用通过安装时间检查、虚拟机检测等方法对抗动态分析的情况，本发明通过设置虚假的时间和相关的设备参数来应对；
[0054] 图2是图1中预处理的方法流程图；
[0055] 图3是图1中静态分析的方法流程图；
[0056] 图4是根据本发明实施例提供的回调类强制触发的方法流程图；
[0057] 图5是System.currentTimeMillis()的签名截图；
[0058] 图6是BroadcastReceiver的onRceive方法的代码片段截图；
[0059] 图7是静态分析类信息获取运行截图；
[0060] 图8是静态分析样本基本信息csv截图；
[0061] 图9是数据流结果截图；
[0062] 图10是动态分析运行过程中的系统截图；
[0063] 图11为动态分析行为监控的结果展示。
具体实施方式
[0064] 本发明实施例提供的一种恶意移动应用检测方法，包括：将待检测移动应用程序转换为可执行、可分析的apk文件；对apk文件进行静态分析，提取移动应用静态特征；根据移动应用静态特征中动态分析所依赖的相关信息对移动应用进行行为触发并进行行为监控，提取移动应用动态特征；综合考虑移动应用静态特征、移动应用动态特征，对待检测移动应用进行敏感行为分析，根据分析结果对恶意移动应用进行检测分类。本发明实施例通过静态分析获取静态特征，从静态特征中提取动态执行所依赖信息，进行行为触发及行为监控，以采集敏感行为信息，通过静态结合的方法进行特征提取，实现对恶意移动应用的自动检测，能够破解大部分恶意代码的反分析机制，实现恶意移动应用准确检测。
[0065] 下面结合附图对本发明作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。
[0066] 如图1所示，本发明实施例提供的恶意移动应用检测方法包括：预处理、静态分析、行为触发、行为监控、行为分析及自动分类六个部分。为提高样本的可分析性，本发明实施例首先进行预处理，即对加壳的程序进行脱壳，再将其重打包为可执行、可分析的APK文件；然后通过静态分析，获取包括移动应用的权限信息、结构信息，以及动态分析所依赖的内在内的静态特征；在静态分析的基础上，进行动态分析，动态分析主要包含行为触发和行为监控两个部分，其中，行为触发主要包括用户动作模拟、系统消息模拟、强制执行，以尽可能提高触发恶意载荷的成功率；行为监控同时对敏感行为、用户动作、界面信息、文件操作等进行监控，记录敏感行为以及执行场景；最后，根据所提取的静态特征和动态特征进行采集集中机械学习模型对被检测移动应用进行自动分类，实现恶意移动应用的检测。
[0067] 下面对本发明实施例中的预处理、静态分析、动态测试整体流程、用户模拟触发、强制触发、行为监控、特征提取和自动分类几个方面展开详细描述，具体如下：
[0068] 1.1预处理
[0069] 如图2所示，本发明实施例所述的预处理主要包括脱壳处理和重打包处理，其具体实现思路如下：
[0070] (1)脱壳点的选取：dex2oat是位于Android系统/system/bin目录下的一个系统文件，用于将dex文件编译为oat文件的可执行文件，oat文件即Android系统的可执行文件格式。dex2oat的编译基本发生在两个时期：
[0071] 首先是Android系统编译时，这种方式显然只能针对部分Android应用，例如Android系统应用与厂商预装应用；其次是应用安装时执行编译，这是所有第三方应用的方式。由于加固程序同样需要经历dex2oat环节，只不过系统在程序安装时执行dex2oat编译的是外壳的dex。之后在应用运行时，壳要解密加载真实的dex文件并运行，壳主体会以native调用的方式，再一次调用dex2oat，将应用的真实dex编译为oat文件，再提供给系统去执行。由此，选取dex2oat作为脱壳点，在dex2oat函数中加入转储应用真实dex的逻辑，就能实现绝大多数加固的通用脱壳。
[0072] (2)脱壳的实现方法：本发明实施例采用修改dex2oat函数源码，编译定制Android系统的方式实现脱壳处理。通过阅读源码，dex2oat函数的实现逻辑可大致总结如下：①通过参数输入apk文件的位置、要输出oat文件的位置等参数；②解压apk文件，获取其中的dex文件并完成dex文件合法性检验；③调用编译函数将dex文件编译为oat文件，并写入到指定位置。一个合理的脱壳逻辑插入点显然是在步骤②与③之间，此时dex文件的校验已经完成，即外壳程序提供的原应用的真实合法dex文件，利用文件中关于文件长度字段记录的合法性，根据这个长度将内存中的数据写入指定的脱壳输出文件，即可得到原应用的dex文件。这里为了对抗某些加固对于脱壳的抵抗，例如监视应用所在目录的和挂钩C库中一些敏感读写函数的，还实现了可以根据配置文件灵活调整脱壳位置以及使用系统函数进行读写操作。
[0073] (3)重打包：完成脱壳处理后，得到了未加密的dex文件，不过稍后的静态分析还需要应用包中的其他文件作为输入信息，如AndroidManifest.xml配置文件，故在样本预处理阶段，还应将解密后的dex重新打包回应用包中。本发明实施例主要使用apk-tool工具实现这一操作，首先将dex文件反编译为smali伪汇编代码，修改AndroidManifest.xml，去除加固厂商插入的无效干扰信息。然后，执行重打包命令，将smali源码文件编译回dex文件，与其他应用资源一起，打包为新的应用文件，为静态分析提供样本的去加固版本。
[0074] 1.2静态分析
[0075] 如图3所示，是本发明实施例所采用的静态分析方法流程图，得益于预处理工作，在预处理完成后，大量原本被严密保护对抗静态分析的样本被重塑为适宜进行各种静态分析的状态，此时便可以对样本进行各种精确的静态分析。
[0076] (1)获取粗粒度的静态特征
[0077] 本发明实施例通过编写脚本调用Androguard的API完成应用静态特征的提取，这些静态特征涵盖了各个级别的应用特征，主要包括：结构信息，权限信息，数据流信息，防护相关信息，动态执行信息。其中，结构信息包括移动应用的大小以及四类组件的数量；权限信息包括申请危险权限的数量以及具体申请了哪些权限；数据流信息为通过静态数据流分析所发现的source到sink的数据流，即敏感信息传到公共区域的情况；防护相关信息指加壳的情况、native代码的使用情况，反射技术的使用等；动态执行信息即程序执行过程中的方法调用序列。对于数据流信息，由于静态数据流分析过程出错概率过高，且单个应用分析得到的数据量较小，难以在缺乏上下文的情况下区分正常和恶意行为，因此只在的分析中起辅助作用。本发明实施例所编写脚本的部分代码如下所示：
[0078]
[0079] 将静态数据流分析工具IccTA集成到作品中，提供关于应用的辅助信息以便进行分析。IccTA基于其前身Flowdroid静态数据流分析工具，增加了对于组件间通信的数据流分析，相比Flowdroid，可以检测出更多隐藏的传播路径，精准地描绘出应用对于敏感数据的泄漏情况。
[0080] (2)Android应用安全防护特征提取
[0081] 搜集了大量已知加固的so文件名，然后检测被测apk中是否含有这些特征so文件，即可辨识是否被加固。反射和Native代码的检测则更为简单，直接调用Androguard的dx分析对象的is_native_Code和is_reflection_Code方法即可知晓被检测apk是否采用了这些保护技术。
[0082] (3)获取动态分析依赖的静态特征
[0083] 本发明实施例借助Androguard获取动态分析所依赖的静态特征，并输出至动态分析的配置文件，为稍后的动态分析做铺垫。
[0084] 1)获取所有类的类名。首先调用Androguard的API将样本的dex文件(考虑到在Android4.4版本之后出现的MultiDex技术，有可能是多个dex文件，因此会逐一处理这些dex文件)加载进内存；通过递归扫描的方式，获取每个dex文件中所有的类的字节码，并存放在内存中的列表中；最后遍历列表，将这些类的类名逐行写入到配置文件中提供给动态分析。这些类名数据，将是指导动态分析的重要数据。
[0085] 2)获取所有Activity名、BroadcastReceiver名和Service名。与获取所有类类名的流程不同，Activity、BroadcastReceiver与Service均属于Android系统提供的组件，它们都必须在AndroidManifest.xml配置文件中注册后才能使用。因此，获取它们的组件名只需要调用Androguard提供的基本API，获取APK实例对象，由于APK实例表示的是APK级别信息的封装，固然只有一个；然后调用这个实例对象的get_activities、get_receivers以及get_services方法分别获取所有这三大组件的组件名；最后，同样的，将它们逐行写入动态分析所需的配置文件中。
[0086] 1.3动态测试整体流程
[0087] 动态测试脚本使用Python3作为实现语言，主要通过使用ADB与UIAutomator2实现动态测试中的环境监测，应用部署，自然点击与控件遍历。同时使用Genymotion虚拟机作为测试平台，虚拟机的恢复快照采用安卓6.0系统，并已经提前部署好测试环境，可以对虚拟机的镜像进行自动化的快照与恢复来实现统一的测试环境。
[0088] 脚本支持Windows/Linux/Mac OS的系统环境，每一次运行动态测试都会留下日志文件以供查错。通过使用多线程技术以及对于错误的处理提高了容错率，每个应用在动态测试下只会运行指定的时间，每个步骤会分配一定时间防止模拟触发陷入无限递归，超过时间则会直接停止线程并开始下一项任务，保证了测试的全面性。
[0089] 测试脚本通过VBoxManage命令操作虚拟机启动，关闭与快照恢复，并使用ADB的devices与wait-for-device检测设备上线。针对虚拟设备未完全启动而一直停留在开机画面加载的问题，采用‘adb shell getprop sys.boot_completed’与‘adb shell getprop init.svc.bootanim’命令进行检测，同时设定延时来杜绝启动不完全就进行操作的问题。脚本中的命令执行多数采用subprocess的方式，并设定超时时间，防止执行命令时发生阻塞。
[0090] 动态测试基本流程如下：
[0091] 1)初始化工具类、设置项目路径并检测、重置模拟器状态
[0092] 2)遍历待测试文件夹内的所有APK文件
[0093] 3)对单个应用进行测试并初始化设备：初始化Traverse UI类(App自动化遍历工具)、检测动态测试配置文件完整性并读取
[0094] 4)启动虚拟机、通过adb安装应用、部署配置文件(class.dlist等)
[0095] 5)授予全部系统动态权限
[0096] 6)使用Traverse UI类进行模拟触发的控件遍历
[0097] 7)导出所有运行时记录的数据到外部指定文件夹
[0098] 8)重置设备到默认快照并关闭虚拟机、再次启动虚拟机、初始化并等待虚拟机启动完成
[0099] 9)通过adb安装应用、部署配置文件、授予全部系统动态权限
[0100] 10)启动应用使应用初始化，然后关闭
[0101] 11)再次启动应用并发送TIME_MACHINE_START广播，激活本系统分析系统(将在稍后章节介绍)的时间伪造功能；发送START_TEST广播，启动本系统分析系统的强制执行功能[0102] 12)关闭正在运行的应用
[0103] 13)通过配置文件强行启动应用的每一个Activity，如果存在界面则使用Traverse UI类遍历点击控件
[0104] 14)再次启动应用
[0105] 15)发送所有系统广播给应用进行系统状态模拟；尝试启动所有已注册的Service[0106] 16)导出所有运行时记录的数据到外部指定文件夹；重置设备到默认快照并关闭虚拟机
[0107] 17)单个APK测试结束
[0108] 脚本针对检测设备是否完全启动，虚拟机内外是否成功建立连接等一系列可能导致出错的问题进行了优化，在执行一些操作后会短暂的暂停1-2秒防止命令执行顺序错误的问题。对于虚拟机的成功启动检测，预留了试错时间与试错次数，极大程度上解决了由于设备问题导致的虚拟机启动失败后脚本崩溃的问题。
[0109] 在应用运行时，动态测试脚本也会批量发送系统有关敏感行为的广播，并模拟接收短信，接听电话的行为，模拟出实际使用时可能会遇到的各种状态。
[0110] 模拟触发与强制触发前都会重置测试环境防止干扰，同时两种触发在不同的线程运行，不会相互干扰。安卓6.0系统以上要求的动态权限授予也通过ADB的pm grant命令批量授予，减少授权弹窗的干扰，使适配了新系统的新应用也能够成功运行。
[0111] 通过一系列的错误防护，倒计时，以及指定次数的反复尝试措施的动态测试脚本已经基本具备了生产环境中批量测试的能力。
[0112] 在动态测试中结合了模拟触发与强制触发的操作，结合对Activity，Service，Broadcast的模拟与强制启动，尽量从各个角度各种方向对待测移动应用进行触发，通过虚拟机内外的协作可以更好的记录移动应用的所有操作并进行进一步分析。
[0113] 1.4模拟触发
[0114] 模拟触发模块通过模拟用户触发的方法来触发程序的各个功能模块，本发明实施例中设计了名为Traverse UI的模块来实现该功能。
[0115] Traverse UI类为单独的应用自动化遍历工具，支持从头开始的自然控件遍历，也支持单独UI控件界面的遍历，可以在极大程度上模拟人的操作，触发应用的各种行为。
[0116] Traverse UI主要实现的自动化功能有：
[0117] 1)指定包名和根Activity名启动应用
[0118] 2)自动重启崩溃或跳出的应用(指定最大次数)
[0119] 3)指定一个页面最大搜索的控件数量
[0120] 4)指定最大递归次数避免无限递归
[0121] 5)深层次点击每个View
[0122] 6)首次启动应用时尝试指定次数的滑动
[0123] 7)尝试跳过点击过的控件
[0124] 8)尝试跳过可能会导致崩溃或跳出应用的控件
[0125] 9)尝试输入指定的文字(也可以强制每个控件都进行输入尝试)
[0126] 10)多次点击错误后自动重启应用
[0127] 由于不同的应用开发的界面存在极大的差异，因此本遍历工具只要求能够寻找到尽量多的控件进行点击或者输入的尝试，而错误的重复点击或者记录都将被极大程度的忽视，以满足动态触发环境的要求。
[0128] Traverse UI通过多线程的方式隔离每一次测试的环境，很好地保证了测试的不间断，即遇到应用崩溃或者UIAutomator2时能够自动处理崩溃而不会影响到主程序的测试进度。也因为运用UIAutomator2进行模拟操作，目前遍历仅支持安卓系统的原生应用，通过xpath的搜索方式确定可点击的控件位置，尽量避免点击到返回上一Activity之类的控件从而避免无限递归。
[0129] 尽管如此在使用此遍历工具进行批量动态测试时应该指定规定的执行时间，避免长时间的递归。同时应对初始化参数进行调整以适合不同类型的复杂界面。
[0130] 遍历基本步骤如下：
[0131] 1)调用UIAutomator2初始化测试工具、初始化UIAutomator2监视器与输入法、远程连接启动UIAutomator2；
[0132] 2)等待5秒后启动应用，留下充足的启动时间；
[0133] 3)如果不是原生的应用就立即退出遍历工具；
[0134] 4)初始化需要使用的参数，搜索所有当前可见的控件；
[0135] 5)判断包名是否正确，不正确立即重启，等待后重新遍历；判断是否超过最大递归次数；
[0136] 6)对所有可见的控件进行遍历，如果遍历控件太多就停止；
[0137] 7)记录点击之前的Activity名与需要点击的控件的信息；如果是已被记录的可能会导致崩溃或退出的控件就不再继续；
[0138] 8)如果界面在点击后发生变化就在点击后重新搜索控件；如果不是已被记录点击过的控件就进行进一步操作；
[0139] 9)不论是否存在子控件都尝试递归搜索；不论是否是可输入的控件都进行输入尝试；尝试点击该控件；
[0140] 10)如果点击出错就记录出错次数，连续出错次数过多重启应用；
[0141] 11)等待一定时间后尝试切换到AlertDialog点击允许；
[0142] 12)尝试重新递归搜索控件；
[0143] 13)如果点击没有出错且点击前后的Activity发生变化就重新递归搜索；如果点击后应用崩溃或退出则记录出错的控件信息并重启，等待5秒重新遍历；如果点击完所有搜索的控件发现Activity发生变化则点击返回键；
[0144] 14)输出所有点击控件的数量信息。
[0145] 对于一些常见的点击选项，使用了UIAutomator2的Watcher进行监控，如果有遇到含有“允许”，“确定”，“是”，“同意”，“好”，“继续”，“Yes”等文字的按钮会直接触发。
[0146] 然而在实际使用过程中一些控件的信息是极为相似的，单纯的记录控件状态无法做到单个控件只触发一次，而有些可能会弹出列表的控件又因为已经记录触发过不能多次触发到，AlertDialog等弹窗或者系统界面无法正常识别，反复递归也会导致出错，因此存在疏漏难以避免，只能在一定的范围能对多数应用进行模拟触发，实测对于多数界面相对简单的应用能够做到很好的界面遍历。
[0147] 高容错的反复递归搜索控件后基本可以实现大部分应用的动态测试中的点击功能，从而很好的模拟人进行操作，模拟触发应用的行为。
[0148] 1.5强制触发
[0149] 1.5.1回调强制触发
[0150] 本发明实施例所述强制触发主要触发的是异步回调类的回调方法以及一些典型线程类的run方法。Android应用中往往存在着大量的回调方法调用，而在这些回调方法中，往往夹杂着对敏感行为相关的API的调用。而由于模拟触发一些情况下无法模拟出可以成功触发这些回调方法的事件，导致大量敏感行为无法被触发，严重影响了分析的准确性、可靠性。因此，本发明实施例还配备了强制触发，用以处理模拟触发失效的复杂情况，保证执行路径的完备性。
[0151] 强制触发借助了Java语言强大的RTTI机制和Xposed框架实现，强制触发不仅要获得字节码，还必须要获得目标类的实例才可以强制调用其中的目标方法，实现强制触发。
[0152] 如图4所示，得益于静态分析获取的数据，能够直接读取所有类的类名至内存中的列表，然后遍历列表，利用java的RTTI机制机制，要求Android虚拟机(ART虚拟机)按照类名加载该类，然后使用强制上转型后是否抛出转换异常的方式判断其是否继承自特定回调基类，如果是，即没有抛出异常，则返回其字节码；得到类的字节码后，就可以对其进行实例化，继而得到实例对象。
[0153] 由于获取实例对象的过程带有强制性，并非应用本来的行为，实际实现过程中同样存在大量的挑战。对于这些挑战，应对措施如下：
[0154] (1)重载构造函数
[0155] 由于需要强制触发的类多为继承自Android框架的特定回调接口和抽象类的回调类，在实际开发中，通常不需要为这样的类提供自定义构造函数。同样在实际逆向分析过程中，发现鲜有样本为这些类仅提供自定义函数，绝大多数的情况是采用了默认构造函数。因此，为了简化实现，实际实现中仅关注默认无参构造函数。
[0156] (2)普通类和静态类
[0157] 普通类是指Java定义的一般的类，绝大多数都是普通类，定义格式一般是public class ClassName{...}。
[0158] 在一个普通类的内部可以嵌套定义一个类，这个类就是内部类，如果这个内部类的定义为static class ClassName{...}格式，就是静态的内部类，静态类就是指这种定义格式，不能在普通类的class前面加static。
[0159] 在获得了目标类的字节码后，采用直接调用newInstance方法，让Android虚拟机通过调用目标类的默认无参构造函数来构建并返回实例。对于静态类，由于没有构造函数，newInstance方法会直接返回静态实例。
[0160] (3)内部类
[0161] 在Android开发中，尤其是涉及回调事件处理时，很有可能会使用到内部类。在绝大多数情况下，内部类的构造函数对于其外部类之外的外部来说，是不可访问的。需调用构造函数对象的setAccessible方法将其访问属性设置为true方可从外部强制访问内部类的构造函数。更为重要的是，内部类的实例化是一个依赖外部类的过程，在编译阶段，内部类构造函数的参数列表会被增加一项，这便是外部类的实例。这意味着在实例化某个内部类之前，必须先实例化其依赖的外部类。同样的，这里依然只关注内部类的默认无参构造函数，即仅有一个参数且类型为外部类实例的构造函数。
[0162] (4)多重内部类
[0164] 1.5.2消息伪造触发
[0165] 对于一些基本事件，恶意应用通常也会给予额外的关注。例如系统启动完毕广播BOOT_COMPLETE，恶意应用可以通过监听这个广播实现自启动。这些系统基本事件可以用adb轻易地伪造，当回调方法强制触发结束后，会调用adb模块的am模块向被测应用发送各种类型的系统广播，用以触发恶意应用的各种广播接收器，继而执行各种行为。另一方面，大量的逆向分析结果表明，除了基本事件，恶意应用通常还会主动搜集基于时间的一些信息。例如AnserverBot，在第一次安装启动时，会首先在数据库中记录下这个事件，在之后的启动过程中，会通过调用System.currentTimeMillis()获取当前时间，然后判断当前时间与第一次启动的时间差是否在24小时以上，如果是，则执行进一步的恶意行为，如果不是，则保持静默。
[0166] 为了触发这类基于时间信息的恶意行为，本发明实施例采用Hook系统深层API的方式对时间进行伪造，通过Hook较为底层且被很多其他时间相关系统API调用的System.currentTimeMillis()的返回值，将正常返回值直接加上1年的时间，返回给被测应用。
[0167] 如图5所示，是System.currentTimeMillis()的签名，从该API的签名中可以看到，该API实际的实现逻辑实际上是native代码，但是这并不影响对于这个API的Hook，同时基于这一点不难推测，该API应当是时间相关API中最为底层的API。为了不干扰分析引擎自身的时间记录，本发明实施例的时间记录是用native代码调用Linux系统的C语言API实现的。
[0168] 1.5.3组件强制触发
[0169] 为了进一步提高分析的覆盖度，基于静态分析得到的结果，首先可以获取应用所有的Activity组件和Service组件的名字，在动态分析时，调用adb的am工具强制启动这些组件。值得注意的是，除了根Activity，设置了exported＝”true”属性，即可以被外部启动，而其他的绝大多数组件，为了防止组件暴露，许多开发者都会将exported属性设置为”false”或者为组件设置启动权限，即便没有，编译器默认的该字段值也是false，这表明着，在一般情况下，无法从外部启动这些组件。不过也有例外，那就是工程版ROM，测试所用的Genymotion模拟器与自行编译的ROM均可以使用adb强制启动应用的任何组件，甚至是带有权限的组件。特殊的工程版ROM保证了所有组件都可以被强制触发，组件强制触发得以实现。
[0170] 1.6行为监控
[0171] 1.6.1敏感API调用监控
[0172] 通常情况下，通过Hook实现行为监控的方式是在一些感兴趣的系统API上下Hook，当样本调用这些API时，事先设定的回调方法被执行，API调用以及其他的一些信息被捕捉并记录。以常见的隐私保护(监控)系统Xprivacy和Smarper为例，它们通过Hook大量敏感API实现监控，据不完全统计，Smarper所Hook的敏感API超过了400项，这不仅有损系统的稳定性和性能，还会使得源代码变得非常冗杂，不利于工程扩展。
[0173] 这些系统Hook的API均为系统的“表层API”，即系统与用户之间的接口API，当用户调用这些API时，再由这些API调用更深层的系统API。而通常地，这些表层API，均有多种重载形式，但是深层API通常只有一个或两个。如下代码片段所示：
[0174]
[0175]
[0176] 系统API SQLiteDatabase.query()有如下所示的四种重载形式，而其底层实现均是调用了深层系统API queryWithFactory，再由该API调用更深层的系统API rawQueryWithFactory实现查询功能。显然，若将Hook点设在浅层API，为了监控的全面性，必然需要Hook所有重载形式的API，造成了Hook数量成倍增长。
[0177] 本发明实施例通过研究Android系统源码，找到了浅层API与深层API之间的调用关系，继而将Hook点设在了深层API上，在设置一共不到70处Hook的基础上，完成了对于系统敏感API调用的监控。Hook系统深层API的另一个副产品是相对较难绕过，由于java语言反射机制的存在，攻击者同样也可以找到并直接调用这些系统深层API，而绕过常见工具浅层API Hook的监控。
[0178] 1.6.2 Android系统回调监控
[0179] 除了传统的直接方法调用，Android应用中往往还存在大量的异步回调。图6所示，为BroadcastReceiver的onRceive方法，代码片段截取自Android系统源码。从本质上来说，这些异步回调与其他系统的异步回调并无太大区别，其底层实现都是创建回调类继承接口或抽象类，实现回调方法，然后注册这个回调类使其生效，当特定事件触发时，由系统调用其回调方法。基于这个事实，自然可以想到只需要在被继承的接口的回调方法上下Hook，那么便可以监控到所有的异步回调。然而实际上这并不可行，因为接口以及抽象类中的抽象方法是无法被Hook的，能够被Hook的只有实际实现的方法，而这些抽象方法的实际实现被编译在应用的继承自这些回调接口或抽象类的子类的字节码中。如何在运行时获取这些类的字节码，继而获取抽象方法的实现并加以Hook监控，是实现回调函数监控过程中的技术难点。
[0180] 既然直接Hook的方法受阻，那么不妨进行思路转变，即找到一个替代的方法作为Hook点进行Hook，而对于这个Hook点，必须要求其具有稳定、具有普适性、与最终的目标回调方法直接或间接相关的特点。因此，本发明实施例改变传统的Hook方案，不从回调方法本身方法出发，转而从回调类这个更大的目标出发，去寻找合适的Hook点。本发明实施例首先Hook回调类的注册API在其执行时获取传入的参数，也就是某个异步回调类的实例。有了回调类的实例，通过调用其getClass方法便可以获取回调类的字节码，而这份从实例获取的字节码中，固然存在抽象方法的实现。进一步的，调用Xposed模块提供的API，传入最终的目标回调方法名，便可以成功Hook到回调类的回调方法。
[0181] 上述的这种技术最明显的特点就是在被Hook方法的回调类中又执行了一次Hook，故被称为“双重Hook”技术。
[0182] 1.6.3 API传参获取
[0183] 调用API时传递的参数同样是重要的一类信息，这些参数包含着API调用的大量细节信息。例如恶意应用与C&C服务器通信、调用连接网络API时传入服务器的ip、域名以及端口。利用这些信息，便可以定位恶意软件所涉及到的C&C服务器。在恶意应用发布后，为追查攻击者提供便利。因此，有必要将每次API调用时传递的参数记录下来，以保证监控信息的全面性和完整性。
[0184] 无论是恶意应用还是正常应用，都会把通讯服务器地址等这类信息作为重点保护的对象，通常会使用各种加密算法将这些字符串或者数值加密，使得它们无法在静态分析时就被轻易获取。不过，无论应用前期使用了何种加密，在调用API时都会将这些参数解密，再传给API。所以在API调用时获取到的，都是参数的明文和真实值，也即应用真正意图的体现。可见，本发明实施例提供的分析引擎在API调用时获取参数与通过纯静态分析获取参数相比，具有得天独厚的优势。
[0185] 下面介绍参数获取功能的实现细节。Android应用开发所使用的java语言中，数据类型繁多，如何用一种泛化统一的方式将参数在行为记录时打包存储，然后在记录时再转化为原来的类型，是技术上的要点。注意到java语言对于RTTI机制的支持非常好，所有类型的基类都是Object类型。因此在存储参数时，先将它们上转型或装箱为Object类型，然后在记录时使用instanceof运算符判断其数据类型。如果经判断该参数为基本数据类型，那么直接对其进行拆箱，然后记录其真值，如果为引用类型，那么就调用其toString方法，将其序列化为字符串，再记录。如下所示，是参数序列化实现代码片段：
[0186]
[0187]
[0188] 1.6.4用户行为和界面变化捕捉
[0189] 用户的行为往往表征着用户期望系统做出的行为，通过在系统中记录和辨别用户行为，可以在一定程度上推测用户的意图。从原理上来看，用户行为也是一种事件，Android系统同样用回调类的回调方法来监听这些事件，继而做出响应，例如用户点击了某个按钮控件、通过虚拟键盘按键的方式输入了一段文字。同样是系统回调，本发明实施例就可以使用前文所述的“双重Hook”技术来对其进行监听。实际实现中，通过“双重Hook”技术在onClickListener类的onClick回调方法上下Hook，监控用户点击行为。
[0190] 1.6.5文件系统监控
[0191] 恶意行为的出现往往伴随着大量的文件系统操作行为。例如，恶意载荷加载，C&C服务器请求下载，隐私信息读取等等，都涉及到文件系统操作。现有隐私保护(监控)工具，如Xprivacy、Smarpr仅仅在几个文件操作相关的浅层Android系统的API上下Hook，例如getFilesDir()。对于Android应用，除了Android系统提供的经过封装的文件操作API；java语言自带的文件操作API同样可以被调用，而且Android系统所提供的API，底层实现就是java语言的文件操作API；甚至利用jni，直接调用底层的C语言函数完成文件系统操作同样是一种选择。因此，常用工具这样简单的Hook显然无法反映被监控应用文件系统操作的详细信息，甚至可以说是非常脆弱的，这对于后续的行为分析非常不利。
[0192] 本发明实施例采用native代码实现自身文件系统操作，再对java语言的文件系统操作API进行Hook监控，排除了干扰，实现了对于java层文件系统操作的API的全面监控。
[0193] 1.7特征提取
[0194] 特征提取包括静态特征提取和动态特征提取，其中，静态特征提取可以通过静态分析从移动应用中提取，静态特征的具体内容已在静态分析部分描述，在此不再赘述。对于动态特征可从行为监控结果中提取，可以概述为：首先找到所有的Hook点API(一共61个)。然后将这些API分为10大类，其中包括文件系统操作(FILE)、数据库操作(DB)、短信(SMS)、网络(INTERNET)、定位(LOCATION)、录音(RECORD)、摄像拍照(CAMERA)、系统底层命令执行(SYS)、设备信息读取(DEVICE)、用户数据操作(USER)。然后提取特定API调用次数、自发的API调用情况(用于判断特定敏感行为是否由用户触发)、敏感API调用前后的界面变化情况、同类型敏感API最高调用次数、单位时间内最多敏感API调用等作为动态特征。具体如表
1所示：
1所示：
[0195] 表1动态特征
[0196]
[0197] 1.8自动分类
[0198] 本发明实施例采用集成机器学习XGBoost(ExtremeGradientBoosting)模型，该模型由陈天奇于2015年提出，是一种Boosting算法机制的集成学习模型。其基本原理是通过多颗决策树(弱分类器)的结果进行加权作为最终的输出(强分类器)。它具有高预测准确度、允许数据缺失、可并行/多核计算、训练速度快、可进行特征排序等优点。其具体实现流程如下：
[0199] (1)导入训练集：本发明实施例的训练数据已经写入CSV文件中，所以通过data_train＝pd.read_csv(文件路径)即可导入；
[0200] (2)数据预处理：主要是进行特征因子化和数值归一化。前者是因为xgboost建模需要的是数值型特征，首先需要对类目型的特征因子化(one-hot编码)；后者是因为部分特征值的数值幅度变化太大，会对xgboost模型的收敛速度造成很大影响，甚至影响拟合结果，所有调用了scikit-learn中的preprocessing模块对特征做了归一化处理，即将所有数值规划到[-1,1]的范围内。
[0201] (3)调参：主要调整以下三个参数：1)ax_depth(树的最大深度)，这个值是用来避免过拟合的；2)max_depth越大，模型会学到更具体更局部的样本；需要使用交叉验证来进行调优；3)min_child_weight(最小叶子节点样本权重和)，XGBoost的这个参数是最小样本权重的和，这个参数用于避免过拟合，当它的值较大时，可以避免模型学习到局部的特殊样本，但是如果这个值过高，会导致欠拟合。这个参数需要使用交叉验证来调整。Learning_rate(学习速率)：通过减少每一步的权重，可以提高模型的鲁棒性，但过低的学习速率会影响模型的运行效率。调用scikit-learn中的RandomSearchCV模块来进行参数搜索。最后获得的参数为：max_depth＝8；min_child_weight＝1，learning_rate＝0.219。
[0202] 为进一步验证本发明实施例所提供方法的正确性、可用性及有效性，下面结合实验设计对本发明实施例进行论证：
[0203] 2.1实验设计
[0204] 为检验所提取的特征的正确性，首先从Flowdroid所提供的测试程序集Droidbench中选取了30个程序，选用这些程序的原因是其较为简单、容易进行人工分析且均包含了敏感行为。然后提取这30个程序的特征。最后，通过人工阅读源码检验所提取的特征的是否正确。
[0205] 为测试系统是否能够稳定可靠的分析真实移动应用，对南佛罗里达大学公布的AndroidMalware Datase、安天安全公司和从360手机助手官网下载的20762个真实的移动应用进行了分析。
[0206] 表2测试数据来源与属性
[0207] 测试对象来源 数量 是否为恶意代码Droidbench 30 22恶意，8正常
AMD 9450 全部恶意
安天 1000 全部恶意
360手机助手 10412 全部正常
AMD 9450 全部恶意
安天 1000 全部恶意
360手机助手 10412 全部正常
[0208] 此外，为详细说明本工具的原理和功能，选取了实验结果中四个具有代表性的样本结果进行阐述。它们分别为DroidKungfu、AnserverBot、DroidDream三款木马程序作为恶意样本代表，以及一款名为“PU口袋校园”的大学生成长服务互联网应用作为正常样本代表。表3总结了这四个样本的基本信息。
[0209] 表3 4个典型样本的基本信息
[0210]
[0211] 2.2正确性分析
[0212] 阅读Droidbench所提供的源代码，对其基本信息、资源申请、安全保护、敏感行为及其上下文等方面进行分析(Droidbench所提供的移动应用均未进行安全防护，所以没有进行安全防护方面的分析)，和自动化分析得到的特征进行对比，结果如表4所示。
[0213] 表4移动应用静态分析、动态分析的正确性评估
[0214] 分析内容 正确率 说明基本信息 100％ 能够正确获取组件类型、数量等信息
资源申请 100％ 能够正确获取权限等信息
敏感行为 97.25％ 动态分析中，绝大多数敏感行为能得到触发
敏感行为上下文 88.75％ 能够正确分析绝大多数敏感行为的触发因素和环境信息[0215] 2.3可用性分析
资源申请 100％ 能够正确获取权限等信息
敏感行为 97.25％ 动态分析中，绝大多数敏感行为能得到触发
敏感行为上下文 88.75％ 能够正确分析绝大多数敏感行为的触发因素和环境信息[0215] 2.3可用性分析
[0216] 表5对静态分析中不同来源应用的成功率、用时等进行了统计；
[0217] 表5静态分析情况统计
[0218]
[0219]
[0220] 如图7为静态分析类信息获取运行截图，图8为静态分析样本基本信息csv截图，图9为数据流结果截图。
[0221] 表6以不同恶意代码家族为分析对象，总结了通过动态分析的成功率。可以看出除了Geinimi外，动态分析均有较高的成功率。人工分析发现，Geinimi家族分析报错的原因是其大部分样本中只有恶意载荷，没有可执行代码。
[0222] 表6动态分析可用性评估
[0223]家族 成功分析 样本总数
ADRD 19 22
AnserverBot 186 187
Asroot 7 8
BaseBridge 120 122
BeanBot 8 8
Bgserv 9 9
DroidDream 15 16
DroidKungFu1 34 34
DroidKungFu2 30 30
DroidKungFu3 309 309
DroidKungFu4 96 96
Geinimi 7 69
GoldDream 47 47
YZHC 22 22
jSMSHider 16 16
ADRD 19 22
AnserverBot 186 187
Asroot 7 8
BaseBridge 120 122
BeanBot 8 8
Bgserv 9 9
DroidDream 15 16
DroidKungFu1 34 34
DroidKungFu2 30 30
DroidKungFu3 309 309
DroidKungFu4 96 96
Geinimi 7 69
GoldDream 47 47
YZHC 22 22
jSMSHider 16 16
[0224] 2.3有效性分析
[0225] 2.3.1预处理模块测试
[0226] 对预处理的测试结果进行分析发现：
[0227] 1)预处理可以准确的检测壳、并以较高成功率进行脱壳；
[0228] 2)重打包后的程序可以被正常静态分析，起到了解除静态分析抵抗的作用；
[0229] 3)该预处理能对测试起到非常重要的帮助作用。
[0230] 2.3.2静态分析模块测试
[0231] 对静态分析模块测试发现，该模块可以准确提取样本的大小、申请权限、注册组件、加固保护、所有类的类名等信息；能准确提取所有类的类名等信息，并自动过滤系统包中的类，为动态分析提供支持，同时过滤机制还缓解了动态分析的压力。表7对静态分析获得的基本信息进行了统计。
[0232] 表7正常和恶意软件的基本信息统计
[0233]
[0234] 权限方面，意外的发现正常应用平均会申请27个权限，而恶意样本平均只会申请15个权限。但是，恶意应用具有访问电话、短信、位置等敏感资源能力的概率并不低，低的是蓝牙、录音等容易被用户察觉或者不容易利用以直接获利的资源。表8给出了部分的统计信息。整体而言，正常应用的能力范围高于恶意应用，但恶意应用具备读写短信、读写联系人等能力的可能性更大。
[0235] 表8移动应用权限申请情况统计
[0236]
[0237] 防护措施方面，发现正常应用通过加壳、反射、动态代码加载保护自身的比例远高于恶意代码。例如，在所分析的移动应用中(含10361正常，10401恶意)，通过qihoo360进行加壳保护的正常代码有4665例，恶意代码只有一例。这很可能是应为360公司会在加壳之前进行检测，恶意代码不愿自投罗网。
[0238] 2.3.3动态分析测试
[0239] 对动态分析(主要是本系统分析引擎)的测试发现：
[0240] 1)对安全敏感行为的监控完备可靠，除了监控到恶意样本的已知恶意行为，还监控到了一些正常样本的灰色行为；
[0241] 2)能够准确监控界面信息；
[0242] 3)用户动作模拟全面合理，能够在有限的时间内最大限度地遍历样本的控件；
[0243] 4)强制触发能够触发模拟触发无法触发的行为，其中包含大量的恶意样本的恶意行为，大大提高了动态分析的全面性。
[0244] 图10为动态分析运行过程中的系统截图；图11为动态分析行为监控的结果展示。
[0245] 2.3.4自动分类测试
[0246] 尝试使用不同类型的特征去区分正常和恶意代码，其结果如表9所示。该结果证明了本发明所提取的特征在恶意代码检测方面的有效性。
[0247] 表9基于xgboost的恶意代码检测
[0248]
[0249] 本发明实施例通过动静态结合的方法来提取特征，实现对恶意移动应用的自动检测，能够破解大部分恶意代码对抗分析的机制，实现准确的移动应用行为分析；通过脱壳然后进行重打包的预处理过程，破解移动应用能够对抗静态分析的加壳行为，提高应用的可分析性；通过强制触发大幅度提高了动态分析的覆盖率。现有动态分析相关研究的一个瓶颈在于难以处理复杂的用户输入，而本发明实施例通过组件强制触发和回调强制触发能够直接使得分析路径跳转到目标位置，使得动态分析的覆盖率得到了大幅度增加；针对部分类型的应用通过安装时间检查、虚拟机检测等方法对抗动态分析的情况，本发明通过设置虚假的时间和相关的设备参数来应对；针对部分恶意应用通过调用冷僻API来逃避监控的情况，本发明Hook深层API来实现监控，确保了监控的完备性。
[0250] 本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
[0251] 本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0252] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0253] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0254] 以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 高密度管脚QFN的封装结构与方法 | 2020-05-08 | 81 |
| 一种引线框架收料机 | 2020-05-08 | 896 |
| 亥姆霍兹共振器及基于其的低频宽带吸声降噪结构 | 2020-05-08 | 796 |
| LED箱体及LED显示屏 | 2020-05-08 | 348 |
| 一种轻小型相控阵天线 | 2020-05-08 | 202 |
| 一种压电驱动音圈马达 | 2020-05-08 | 165 |
| 基于深度学习的无监督端到端的驾驶环境感知方法 | 2020-05-11 | 788 |
| 学生安全意识评估系统及方法 | 2020-05-11 | 375 |
| 分析板的置放用支架和分析套件 | 2020-05-08 | 344 |
| 液冷电池箱体 | 2020-05-08 | 982 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
框架热门专利
QQ群二维码
意见反馈
意见反馈