Android APP以APK文件形式存在，APP中主要包含应用程序代码和资源文件两部分，如何有效保护Android应用中的代码、资源的安全一直是开发者最关心的话题。针对应用程序代码，目前主要有两类方案，即代码混淆和应用加密。比较常见的代码混淆有proguard、dexguard等，而应用加密近些年国内也涌现出很多安全厂商提供该服务。本文则主要针对Android apk资源文件保护方案进行分析。
Android apk中的资源主要分为assets资源和res资源两类。Assets资源存放在APP的assets目录下，该类文件是一些原始文件，APP打包时并不会对其进行编译，而是直接打包到APP中，对于这一类资源文件的访问，应用层代码需要通过文件名对其进行访问。Res资源则存放在APP的res目录下，该类资源在APP打包时大多会被编译，变成二进制文件，并会为每个该类文件赋予一个resource id。对于该类资源的访问，应用层代码则是通过resource id进行访问的。
Android apk资源文件中存放了大量的应用UI界面图片、UI布局文件、隐私数据文件等，保障这些文件的安全性一直困扰着开发者，接下来将具体分析一下目前市场上常见的资源文件保护方案。
一、 Android资源文件保护相关方案
目前对Android应用资源文件的保护主要有两类方案，一类是对资源文件混淆保护，另一种则是对资源文件加密保护。
1. 资源文件混淆保护
Android apk开发过程中公司大都提倡命名规范化，因此通过文件名称非常容易理解其含义，这样有利于开发者理解和维护应用，但是同时也给应用破解者提供了方便，破解者通过这些命名很容易便可找到他们需要的文件位置，并理解这些文件的意图。对资源文件进行重命名则可以在一定程度上提升破解者理解这些文件的难度，从而一定程度上提升资源文件的安全性。例如将原资源文件res/layout/activity_main.xml命名为res/a/a.xml，通过layout和activity_main.xml我们很容易知道该文件可能是个布局相关文件，且可能是主activity的布局文件，而被混淆变成res/a/a.xml后，破解者则很难通过名字知道a.xml文件的作用。
我们知道，Android应用在编译过程中aapt工具会对资源文件进行编译、打包，并生成一个resource.arsc文件，resource.arsc文件相当于一个文件索引表，记录了很多跟资源相关的信息。因此，如果需要对资源文件进行混淆，如何保证resource.arsc文件的正确性是个难点。至少我们可以两个方面攻克这一问题。
1） 修改aapt方案
在APP的编译打包过程中，工具aapt负责对资源文件进行编译、打包并生成resource.arsc文件，因此我们可以通过分析并修改aapt源码来实现生成正确的resource.arsc文件。
2） 修改resource.arsc文件
修改aapt源码的方案对开发者要求较高，且不同版本aapt可能有区别，直接修改打包好的APP中的resource.arsc文件可能也是一个不错的方案。
文件resource.arsc的格式可以通过分析aapt的源码获知，且目前也有很多文档介绍该文件的格式，因此，我们可以通过对APP解包、读取、解析、修改其中的资源文件和resource.arsc文件来实现对APP资源文件的混淆。
下面我们通过一个demo APP文件展示一下资源文件混淆保护的效果。
其中图1为资源文件保护前的资源文件结构图，图2为资源文件保护后的资源文件结构图。
图1 资源文件保护前res目录结构
图2 资源文件保护后res目录结构
从图1和图2可以看出，资源文件混淆后，原来的res目录变成了r目录，该目录下的目录名字都变成了没有字面意义的字母，从而一定程度上保证了res资源的安全性。
以上提出的资源文件混淆保护方案有一定技术难度，所以在开发者实际使用过程中并没有广泛运用。目前，开发者出于技术能力和精力的种种限制，越来越多的开发者选择使用第三方应用加密保护平台来实现对资源文件的保护。
1. 资源文件加密保护
资源文件加密保护，从字面来看，无非是对APP中的资源文件进行加密，在APP运行时对资源文件进行解密恢复，从而使应用正常访问资源文件。由于资源文件被加密，因此通过对APP进行反编译并不能看到真正的资源文件，从而保证资源文件的安全性。虽然资源文件加密保护大体思路如此，但是实现方案和效果则可能不同。下面以360加固保提供的资源文件加密保护方案为例分析其方案效果。
写一个demo APP文件，使用360加固保的资源文件加密保护功能，图3和图4为资源保护前的APP的assets目录和res目录文件结构，图5和图6为资源保护后的APP的assets目录和res目录文件结构。
图3 资源保护前assets目录文件结构
图4 资源保护前res目录文件结构
如图3和图4所示，原APP的assets目录下有三个文件，分别是a.log、b.log、c.log。res目录下有很多文件，如ui文件、配置文件等。目录assets下面存放的是未进行压缩的原始文件，可以很容易的被破解者修改并重打包，目录res下的文件虽然大部分是经过了压缩处理的，但是其中的图片却能直接看到，且即使是被压缩过的二进制文件也很容易被破解者修改。
接下来使用360加固保的对该APP进行资源文件保护，解压保护后的APP，得到图5和图6。图5为360加固保资源文件保护后的assets目录结构，图6为资源文件保护后的res目录结构。
图5 资源保护后asset目录文件结构
图6 资源保护后res目录文件结构
图5中可以看出，之前该目录下的a.log、b.log、c.log文件消失了，但多出了libjiagu.so、libjiagu_x84.a、libjiagu_x86_1.a、libjiagu_x86.so和resConf文件。多出的这些文件则是360加固保的APP加固和资源加密相关的文件。
图6中可以看出，之前res目录下的很多文件都不见了，查看了一下留下的几个目录的文件，里面的文件是APP的图标。
可以看到使用360加固保后，能对资源文件进行有效的加密保护效果。360加固保资源文件加密保护的大体原理如下：
1） 抽取原APP中需要加密保护的资源文件
解压抽取APP中的需要加密的资源文件，并过滤到一些不能保护的资源文件，如APP图标等；
2）加密资源文件
对抽取出来的需要加密保护的资源文件进行加密处理，并隐藏起来；
3） 实现外壳程序
要想让APP正常运行，则需要为使用资源保护后的APP实现一个外壳程序，360加固保本身具有APP加固功能，因此他们可以将资源文件保护的恢复程序集成到360加固保的加固壳程序里面，如果不使用360加固保，那么我们就需要自己实现一个外壳，外壳程序需要负责在APP使用资源前对资源文件进行恢复。例如如果保护我们自己的APP资源，那么我们就需要实现一个资源恢复程序外壳，并将该外壳的程序入口代码放到APP中，壳程序入口的运行时机应足够早，比如放到我们可以将这个外壳放在应用代码的Application类里面。
本文介绍了两种可行的资源文件混淆保护方案，一种是修改aapt工具，让aapt在编译资源时生成混淆后的正确的resource.arsc文件，同时修改资源文件名称，另一种方案则是直接修改APP中的资源文件名，同时修改其中的resource.arsc文件。
从实现难易度和工作量综合来看，第二种方案，即直接修改APP中相关文件可能更为适合，但从保护效果来看，两种方案实现的混淆效果是一样的，都是对文件进行重命名。
资源混淆保护方案优缺点：
优点：可减小APP体积。
缺点：安全强度有限：仅对资源文件进行重命名并不能有效的保护资源文件，破解者依然能可查看并修改资源文件内容，
assets文件保护难度较大：如需对assets目录下的资源进行混淆，则需要修改java程序代码或者dex文件，难度和复杂度较大，容易出错。
资源文件加密保护方案优缺点：
本文对360加固保的资源文件保护方案的效果和实现进行了分析，从效果来看该保护方案安全强度较高，资源文件加密处理后在APP中不可见，且壳程序采用native代码实现，逆向难度较大。
优点：安全强度高，破解者不能查看和修改资源文件。
缺点：由于需要运行时解密，有可能会对APP的性能有所影响，不过经过测试平台的测试，加固后对APP的兼容性在99%以上，这也是越来越多的开发者选择这种第三方应用加固平台的原因。