[发明专利]基于Dex2C与LLVM的Android应用程序保护方法

说明书

本发明公开了基于Dex2C与LLVM的Android应用程序保护方法，包括：解压APK获取并解析Dex文件，得到每条汇编指令的能够恢复C代码的所有必要信息，根据评估模型选择是否进行Dex2C的转换，若超过阈值，则进行Dex2C的转换：转换预处理操作，包括查找待保护方法、插入汇编指令语句、建立指令的邻接关系等，逐个根据汇编指令类型选择三套转换逻辑中的一种进行转换；基于LLVM实现编译时虚拟化，若未超过阈值，则直接执行LLVM编译虚拟化模块；通过该框架生成So文件后，进行重打包、签名，生成功能等效的APK。本发明结合了Dex层和本地层的防护方法，一方面能够提高APK的执行效率，另一方面极大的提升了恶意攻击者攻击的难度和成本。

技术领域

本发明属于Android应用程序中Dex文件加密与So文件编译时虚拟化的技术领域，具体涉及到Dex文件到C文件的转换与基于LLVM编译时虚拟的 Android应用程序保护方法。

背景技术

近年来，随着移动互联网生态系统的蓬勃发展，移动应用程序的数量呈指数级增长。根据Statista的一项调查，截至2019年3月，Google Play共提供了260 万个Android应用程序。但是，由于逆向工具链的成熟，攻击者使用逆向工具很容易获取到合法应用程序中So(shared object)文件或classes.dex文件的核心逻辑，然后进行篡改，譬如添加恶意代码或替换原始广告等，最终进行重打包签名，通过非法渠道流入市场。这不仅损害了应用开发者的利益，而且也对用户财产与隐私构成了威胁，严重影响了移动应用行业的健康发展。

市场上大多数APP是由Java语言和C语言开发的，Java代码在编译过程中生成Dex文件，C代码在编译的过程中生成So文件。目前Dex文件的主要防护方式有以下几种：整体加密、部分类加载加密及Dex文件虚拟化，但相应的， DexExtractor、ZjDroid及PackGrind工具能够对这三种Dex层的保护方案进行有效的攻击。Dex文件目前主流的防护方式还有一个最主要的缺陷是加壳的方法并不会提高Dex文件的执行效率。目前So文件的主要防护方式有：OLLVM与Upx 加壳。但相应的攻击工具或方案有DecLLVM与Upx Shell Tools。由此可见，一方面，目前的保护方案存在着保护能力不足和保护后效率降低的问题，另一方面，目前市面上还没有一种能够同时对Dex文件和So文件同时进行防护的系统。

发明内容

本发明提出了一种基于Dex2C与LLVM(Low Level Virtual Machine)的 Android应用程序保护方法，能够同时对Dex文件和So文件进行防护，以有效抵御恶意攻击者的静态分析和动态分析。

为了实现上述任务，本发明采用以下技术方案：

基于Dex2C与LLVM的Android应用程序保护方法，包括以下步骤：

从待保护的应用程序安装包中获取Dex文件，按照文件格式对其进行逐层解析，得到Dex文件中的每一条汇编指令的能够恢复到C语言代码的所有必要信息并存储于数据结构中；确定待保护的方法并将其修改为本地层类型方法然后重写Dex文件，进行转换前预处理工作；建立评估模型，将待保护方法运行时的核心调用时间占比作为评估模型的决策依据，通过设置阈值，来判定是否将待保护的方法进行Dex2C转换，从而尽可能避免频繁的反射调用和冗余的循环操作；

如待保护的方法进行Dex2C转换，则将存储在所述数据结构中对应于待保护方法的必要信息转换为C语言代码，转换过程中针对于不同的汇编指令建立不同的转换逻辑，并恢复汇编指令前驱、后继之间的连接关系，同时保证汇编指令类型正确恢复、数据传递的一致性；将转换后的C代码作为待保护对象；

如待保护的方法不进行Dex2C转换，则将待保护的应用程序安装包中的So 文件里的入口函数作为待保护对象；

将待保护对象进行编译的同时虚拟化，生成虚拟化后的二进制So文件，进行重打包、签名，生成保护后的应用程序。