一种基于Dex加载器的Android应用软件加固保护方法与流程

文档序号：11156078阅读：370来源：国知局

本发明属于信息安全领域，涉及移动应用软件安全保护技术，具体涉及一种Android平台下基于Dex加载器的一种改进优化的应用软件加固保护方法。

背景技术：

Android应用有Java语言编译而成，而Java语言编译成的二进制代码后很容易被反编译，代码的安全性受到极大威胁，同时也为盗版提供了可乘之机。攻击者下载合法应用，通过反编译修改配置文件甚至植入恶意代码，然后利用打包工具对应用进行重打包，最后使用自己的密钥对应用进行重签名并发布到应用市场。对于普通手机用户，这种重打包的应用很难辨别，盗版或恶意应用很容易被安装到用户手机上，任意获取用户隐私信息，偷跑流量，恶意扣费等，给用户带了很大的损失。

针对这种恶意攻击，传统的防护措施如代码混淆，数字水印技术，Android签名机制等保护方式安全性非常有限。无论采用上述哪种方式，最终攻击者都能在适当地时机获取到程序源码，攻击者可以使用静态的分析工具或者将应用程序置于动态分析的模拟器中获得代码，这些保护措施的效果不佳。

Android应用加固是针对应用重打包的有效防范措施，应用加固是对Android应用程序源代码的加密保护过程，通过利用Android开放的加载机制，动态启动被加密后的代码文件。通过加固的应用，源代码以密文方式保存在Apk中，攻击者在不知道加密算法和密钥的前提下，无从直接获取源码。到目前为止，Android应用加固已经有了一定的技术积累，但是随着Android系统版本一直在迭代更新，现有的Android加固技术也面临着一些挑战：加固应用的启动速度有待优化；加固流程效率低下有待提升；加固程序自身的安全尚未得到重视等。

传统的基于Dex加载器(DexClassLoader)的加固技术是近期使用最广泛的加固方法，该方法需要将Apk中的classes.dex文件加密隐藏，将原Dex文件保存在assets文件夹中，assets文件夹中可以存放不限类型的文件，这样能避免Dex嵌入加固技术对Art虚拟机加固不兼容的问题。如图3所示，其加固流程大致如下：

1)使用反编译软件对目标Apk进行解包，获取其中的classes.dex文件以及AndroidManifest.xml；

2)加密压缩classes.dex文件，存放到assets目录中；

3)将自定义的DexClassLoader编译成壳classes.dex文件放在应用的根目录中以替换目标应用的classes.dex；

4)修改Manifest，将程序入口改为壳程序；

5)打包签名发布。

相应的，如图4所示，系统运行加固后的流程分析如下：

1)系统运行时首先从Manifest文件中读取程序入口，加载并启动壳程序；

2)壳程序对assets中的密文Dex进行解密和完整性校验；

3)壳程序动态加载解密生成的Dex明文文件，将程序的控制权交还给原程序。

技术实现要素：

为解决上述技术问题，本发明提供了一种基于Dex加载器的Android应用软件加固保护方法，其包括以下步骤：

S1：解包原应用Apk文件，得到AndroidManifest.xml，classes.dex文件以及assets，META_INF，libs文件夹；

S2：生成随机密钥KEY，使用随机密钥KEY对Apk中的Dex文件使用128bit的AES算法加密，生成密文文件Reinforce.dex；

S3：将Reinforce.dex移动到在assets文件夹中保存，图示删除classes.dex明文文件；

S4:替换加密核心库libcorn.so中Key密钥区域，并将库文件libcorn.so并保存在libs文件夹中；

S5:将壳源码编译成classes.dex文件，并将壳文件dex放在根目录下替代原程序的classes.dex；

S6:将Manifest中程序入口修改为壳程序具体修改方法为：

a)<application>标签下的android:name属性值改为壳程序名称；

b)建立标签<meta-data>，在<meta-data>标签下添加属性android:name和android:value；

c)将android:name的值设置为APPLICATION_CLASS_NAME；后者的值设置为原<application>标签下android:name属性的值，若该原始值不存在，则取系统的缺省程序入口android.app.Application；若该原始值以“.”开头，则在其前加上包名取完成路径；

S7:删除原apk签名信息META-INF；

S8:用apktool打包文件夹，用自己的密钥对新打包的apk进行签名；

经过以上的步骤，加固完毕，生成了一个全新的apk文件，加固后的应用和加固前的应用相比，asssts文件家中多了加密Dex文件，classes.dex是替换的壳文件，并且在lib库中多了用于加载解密的核心so库。

较佳地，还包括以下步骤：

S9:加固壳应用启动，壳程序中加载核心so库文件libcorn.so；

S10:从libcorn.so的密钥区域恢复出密钥KEY。

S11：调用libcorn.so的解密函数解密assets文件夹中的Dex文件到内存，得到一个字节数组byte[]；

S12：使用自定义的Native层的DexClassLoader调用libdvm.so中接口Dalvik_dalvik_system_DexFile_openDexFile_bytearray()装载上一步得到的byte数组并得到一个标记dex的cookie值；

S13：调用libdvm.so中接口

Dalvik_dalvik_system_DexFile_defineClassNative，根据上一步得到的cookie值加载原程序；

S14：将系统中运行的应用信息状态信息替换为原应用，将程序的控制全交还给原应用，实现原应用程序的正常启动。

本发明具有以下有益效果：

本发明提供的基于Dex加载器的Android应用软件加固保护方法在加固后的dex结构和传统dex文件的结构完全不同，不能被成功反编译为具有可读性的源文件。加固方案成功保护了关键数据的机密性，起到了防反编译的效果。利用ZjDroid脱壳工具对加固后的apk进行脱壳操作，不能获取到任何原apk的源码文件和dex碎片，说明我们的内存加载过程对防止java层Hook有很好的效果，同时也避免了dex明文出现在磁盘上被攻击者劫取。相对于传统的磁盘加载方式安全性有很大的提高。

针对Android的不同版本，不同的系统架构对传统dex加固方式和本文实现的加固方式做一个横向的对比。传统磁盘加载由于各种因素，只能在一定时间段完成加固任务，在Android5.0系统以后，传统的方法将彻底失效。采用我们提出的dex加载方式加固的应用，能在当前所有主流版本，主流架构的终端上正常运行，适配性强。

此外经过本文实现的加固处理后的应用启动时间明显比传统加固处理后应用的启动时间要短。相比原应用，加载时间增量完全在可接受的范围内。加载效率相比传统加固方法有明显提高。

当然，实施本发明的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为传统DexClassLoader加固流程图；

图2为传统DexClassLoader加固程序执行流程图；

图3为本发明实施例提供的加固流程示意图；

图4为本发明实施例提供的加固应用启动流程示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

如图1所示，本发明实施例提供了一种基于Dex加载器的Android应用软件加固保护方法，其包括以下步骤：