张建新
摘 要： 通过加密dex文件和SO库文件的方法可以很好地保护安卓平台软件的安全性，但是将密钥信息保留在本地文件又将留下安全隐患。为解决这一问题，本文提出不将关键信息硬编码于程序中，而是置于远程服务器，通过与远程服务通信进行关键信息的确认，从而达到保护安卓软件的目的。试验结果表明，该方法可以有效地保护安卓软件的安全性，具有较高的可靠性。
关键词： 安卓软件安全； 远程校验； 加壳技术； 软件加密； AES算法
中图分类号：TP393 文献标志码：A 文章编号：1006-8228（2017）05-30-04
An Android software protection scheme based on remote verification
Zhang Jianxin
（College of software，North university of China， Taiyuan， Shanxi 030051， China）
Abstract： Encrypting DEX files and SO library files can be a good way to protect the security of Android software， but the key information will remain in the local file and will leave a security risk. In order to solve this problem， this paper proposes that the key information is not hard coded in the program， but is placed on the remote server， and the critical information is confirmed by communicating with the remote service， to achieve the purpose of protecting Android software. The experimental results show that this method can effectively protect the security of Android software and has high reliability.
Key words： Android software security； remote verification； packer technology； software encryption； AES algorithm
0 引言
安卓系統占据了智能终端市场接近90%占有率[1]，它的开源和内核的可移植性，既可以吸引爱好者的关注也给不法分子留下了机会。攻击者可以利用各种手段对原始应用进行破解和篡改，随着越来越多的受害者出现，人们开始重视安卓平台应用软件的保护。
文献[2]阐述了安卓各个层面的细节和攻击方法。文献[3-4]通过自定义加载的方法实现在内存中加载核心代码（SMC代码字修改）。文献[5]在设计安卓代码保护方案时将MVC的概念引入到方案的设计中。文献[6-8]提出的代码保护方法都主要依赖于加密和加壳技术。文献[9]是比较有代表性的一种方案，它通过AES加密算法加密DEX文件并将解密功能放到“傀儡class”文件中来增强其保密信息的安全性。但是上述方案在加密算法的选择或者密钥信息的保护方面都有漏洞。所以本文采用了一种文件保护和和远程校验相结合的安卓软件保护方案。
1 方案设计思路
本文提出一种基于远程校验的安卓软件保护方案，同时也用到了关键文件变形和加密的技术。
在apk包的所有文件中，最重要的是classes.dex文件。了解smali语法的人可以通过反编译和静态分析技术来破解软件。除了dex文件之外 SO文件也是攻击的目标之一，本文对SO文件也进行相应的处理。
对dex文件和so文件进行变形和加密，这样对关键文件进行保护，具体的功能模块示意图如图1。
加密模块通过AES算法加密需要保护的文件，并取得需要保护的信息部署到远程服务器，然后再重新打包；解密模块执行的时候通过壳程序调用远程服务器上的固定方法完成完整性校验，然后返回密钥信息对文件进行解密，再执行正常流程。本方案采用的方法虽然会在远程通信中耗费一定的资源，主要是对网络传输的要求比较高，但其他方面都能做到用最少的资源最大限度地增加软件的安全性。
2 关键技术阐述
保护方案主要技术点包括dex文件保护技术、SO文件保护技术和远程服务实现技术。
2.1 dex文件保护
本文提出一种自定义代码替换集的代码混淆方法用于加密前处理dex文件。自定义代码替换集可以由软件使用者自己定义，自己掌控需要替换的代码及相应位置，而替换的规则只有开发者知道，这就大大增加了分析者的破解难度，而且恢复替换所消耗的资源也少于大规模的替换，在资源的占用方面有优势，主要的工作难度都集中在前期自定义阶段。这就使得分析人员即使得到了dex文件也不能充分的了解其中代码的意义，无法顺利的进行分析。具体实现中可以把代码替换集置于远程服务器中，使规则对程序透明化。当然，为了进一步增加获得dex文件的难度，在打包之前还需要通过加密等其他手段对其进行处理。具体实现流程如图2所示。
2.2 SO文件保护
以现行的分析技术，如果我们将SO文件直接放在jni目录下打包发出，攻击者可以轻而易举地破解开发人员写出来的代码。本文在研究前人加固方案的基础上，采用一种核心文件替代的方法。通过分析java调用动态链接库的函数System.loadLibrary（）发现接口中调用本地库的关键语句为nativeLoad（name，loader，ldLibraryPath），该方法执行的时候调用路径为ldLibraryPath下名字为name的SO文件，由此系统可以自己定义一个核心SO文件，对其他SO文件进行统一处理，而动态链接库中的主要实现逻辑文件则统一置于文件夹中并对其进行变形操作，最后将它放入assets文件夹。密钥信息并不在本地文件中，而保存在远程服务器中。具体处理与运行流程如图3所示。
2.3 Axis2简介
本文基于远程获取校验信息和密钥信息的功能将通过Axis2引擎来实现。
Apache Axis2项目是一个基于java的包括服务端和客户端的webservice框架。它适合轻量级的数据处理。客户端可以通过Axis2接口调用特定服务端发布出来的指定方法来实现某些特定的功能，用户只需要发送请求的参数，它就可以返回最后的结果。
在手机端发送密钥或者校验请求到服务端，服务端根据请求信息找到对应的方法处理数据并返回结果。服务器端的主要代码非常简单，就是通过soap消息传递当前META-INF文件夹签名或者直接发送需要的密钥请求到事先部署到服务器配置文件中的初始签名参数对比，如果判断失败则返回失败指令，让App停止运行，代码如表1所示，客户端发送请求代码如表2所示。
代码中，RPCServiceClient对象是可以处理发送与接收数据业务的专用对象；Options对象用来携带可选参数；EndpointReference对象装载服务端的URL；Object数组用来存放需要校验的数据，即META-INF文件夹的数字签名；Class数组用来指定返回值数据对应的类；Qname对象限定要调用的方法和WSDL文件的命名空间。最后通过业务处理对象调用接口中的invokeBlocking（）方法实现与服务端的通信。
3 方案的实现流程
本文提出的方案包括PC端处理和远程服务。PC端处理用到代码集替换、加壳技术、MD5算法提取哈希值等。本方案将校验信息和加密算法的密钥都放在远程服务端，运行的过程中通过壳程序的指令和远程服务端进行通信，最终确定软件是否安全。
3.1 PC端处理
文件保护主要工作包括代码集标识符的定义和具体代码集的选取以及加密功能的实现。代码集标识符的定义需要遵循一定的原则，不能使用Dalvik字节码的语法指令关键字，也不能选用能够见文知义的标识符。系统根据用户输入的标识符和代码集位置，在dex文件中替换相应的代码并创建惟一标识，将一一对应的标识和代码存储在一个资源文件中生成代码集，然后用AES算法对替换后的dex文件进行加密并将密钥保留备用。
当程序中存在jni代码时，apk包中有一个lib文件夹用来存放所有的库文件，核心文件替换会先将所有的SO文件用AES算法加密，产生的密钥会部署在远程服务端供运行时调用。然后将lib文件夹压缩并修改文件名和扩展名来混淆破解者的判断，最后将其放在资源文件目录下。为了执行调用，在原位置创建一个同名的lib文件夹并在里面编写一个恢复源文件并执行具体调用的”代理文件”，最后在壳程序中调用该代理文件处理具体的操作。
3.2 远程校验
综合上述可以知道远程服务端的实现机制，在具体的实现中，校验META-INF完整性的功能可以在整个安卓应用的任何流程之前均执行调用，此功能与前面的文件加密处在软件运行的一前一后进行交叉保护，使得保护方案更加可靠。在性能方面，该手段对于资源的要求并不高，整个过程中只需要传送一个字符串接收一个字符串，或者发送一个请求获取一个字符串，对程序性能的影响基本可以忽略不计，只要在网络畅通的情况下均可执行。
4 实验验证与分析
为了验证本方案的有效性和实用性，在win7系统下对本文实现的系统Xpro v1.0进行效果测试和功能对比实验。
4.1 方案效果测试
系统加固处理发生在PC端，运行环境采用win7旗舰版系统和常用的反编译工具。首先进行整体的运行，打开该系统，选择源文件路径，把功能模块都选中，并设置好替换代码集，点击开始，执行结束后界面如图4所示。
本文从不同的应用市场的200多个应用中随机筛选出了50个没有经过外部加固手段处理的，具有代表性的应用，通过本系统的处理之后，再进行安装和使用。结果发现，它的正常使用率达到93%，并且不受Android系统版本的影响，在不同的版本上测试，结果基本一致。剩余的7%，经过进一步分析发现是程序内部已经存在签名校验机制或其他的代码保护机制，所以导致了二次打包之后无法运行，去除这部分之后，用自己新开发出来的测试程序去测，可用率都达到了100%。可见本系统是一个很可靠的加固系统。
4.2 运行效率分析
本系统对空间的消耗在一个正常的范围内，虽然会随着原始文件的大小变化出现小的波动但并不会出现加固后容量超过应用本身的状况出现，这是由加固的手段决定的，所以，本文只对加固后应用启动时间和未加固时的启动时间做一个统计分析。作为对比本文还使用了网易易盾的免费试用版和应用乐固的体验版以及本文的Xpro V1.0版分别对相同的应用进行加固，并记录其启动时间。
找出文件大小处于不同区间的十个应用的apk文件，分别在不加固、本系统加固和两个免费的商业加固系统试用版本进行加固和启动，记录应用启动时间，统计分析结果如图5所示。
从图5中可以看出，无论是哪种加固系统处理之后的apk启动时间都会有一定的延长，这是因为保护措施在正式的源程序加载之前需要一定的时间和资源来处理前面的加载工作，在本系统中，无论是对dex文件的解密还是SO文件恢复，这一系列操作都需要占用一定时间。不过，通过延长一定的初始化时间，仍在用户可以接受的范围之内的话就是值得的。本系统的效率虽然达不到商业加固应用的顶级水平，但跟它们的试用版本在效率方面也在伯仲之间，很好的完成了加固的任務。
5 结束语
本文提出基于远程校验和本地关键文件加密的安卓软件保护方案，很好的平衡了安全性和软件工作效率之间的矛盾，将校验及解密信息存放于远程服务器中，并选择了效率及安全性都很优秀的加密算法。实验证明，本方案能够有效抵抗静态，有效地保护了APK文件，在实际的应用中，本方案往往会与其他保护手段结合使用，使其发挥更大的作用。本方案的不足之处是未能考虑到远程服务器交互过程中的信息安全问题及远程服务器本身的安全问题，这也将是下一步优化的方向。
参考文献（References）：
[1] 腾讯移动安全实验室.腾讯安全实验室2016年上半年手机安全报告，2016.7.
[2] 丰生强.Android软件安全与逆向分析[M].人民邮电出版社，2013.
[3] 董航.移动应用程序检测与防护技术研究[D].北京邮电大学博士学位论文，2014.
[4] 张晓，李林，许家乐等.基于SMC的Android软件保护研究与实现[J].信息网络安全，2014.11：74-78
[5] 史成洁.Android平台应用软件保护技术的研究与实现[D].北京邮电大学硕士学位论文，2015.
[6] 徐剑，武爽，孙琦等.面向Android应用程序的代码保护方法研究[J].信息网络安全，2014.10：11-17
[7] 朱洪军，陈灏，华保健等.移动应用代码保护现状与技术研究[J].计算机应用与软件，2016.33（3）：314-319，333
[8] 张译恬，王纯.基于安卓系统JNI机制的SO库加固方案设计[J].电信技术，2014.10：90-93
[9] 钱海龙.移动终端应用安全加固关键技术研究[D].北京邮电大学硕士学位论文，2014.
