关键词：代码加固，软件测试，原理分析，过程分析。
在大创项目的实践中，我们对市面上的一些安卓代码加固软件进行了采集，经过搜集，发现了几类代码加固方法并分组进行研究。我发现很多代码加固软件都是对java字节码进行混淆与加固，另外一些则选择对原生语言和so文件进行加固，而我打算研究的这一款软件，则是对资源文件进行加固，它就是AndResGuard。
混淆原理
大致上来说就是apk在调用资源的时候不是通过资源名来调用的，而是通过一个资源ID值来调用的，因此资源名和资源ID存在一种映射关系，保存在 resources.arsc 中。而由于资源名是一种相对独立的存在方式，仅仅是为了源码的易读性，所以可以用用更短的资源名取代，从而减少apk文件的体积；而新的代号没有任何语义上的可读性，所以可以达到混淆的目的。而且由于这种映射关系是独立于安卓编译过程的，所以我们可以在整个apk的基础上进行操作，通过实现对apk的解压并修改资源文件和 resources.arsc 进行混淆。
项目贡献者的说明文章见这里。
混淆过程
为了统一研究对象，采用的混淆软件是我第六次安卓作业后生成的apk文件:
下载完整个项目以后，最重要的文件是箭头所指的jar文件，这个其实就是源码编译以后的可执行文件了：
不过还需要输入一些参数才可以运行，包括待混淆apk，混淆配置文件，输出路径，甚至可以加入签名库的路径。
配置
输入参数前，先更改一下混淆配置文件，打开config.xml后，我根据实际研究的情况作了如下更改。
1.设置不采用7z压缩。显然，7z压缩是这个软件集成的外部功能，一方面能更加减小程序的空间，另一方面也可以提高程序表观上的复杂程度。但是需要指出的是，7z压缩在AndResGuard中是一个比较独立的组成部分，首先在技术原理和实现方式上就有很大的不同，而且7z压缩更像是对混淆后资源文件的一种打包技术，就像是把安卓源码混淆后再进行打包一样，有着独立的压缩和解压方法，并不涉及任何混淆的思想，也不需要任何的反混淆技术。而如果采用7z压缩后再进行分析，就相当于采用两种技术加固软件后和其他采用一种技术加固软件的方法进行优劣比较，这种方法是不合理的。
2.设置不采用签名。由于混淆前的软件没有采用签名技术，因此作为对照组，混淆后的软件也不应该采用签名技术。
混淆
AndResGuard的混淆是针对整个文件进行的，只需要输入如下参数即可：
耗时不到5秒即完成。
混淆效果测试
混淆后，从程序体积，代码可读性等两方面分析混淆效果，主要出现了如下变化：
1.体积变小。混淆后生成了另一个apk，把两个apk放在一起，可以明显的看到混淆后的apk文件体积变小，从2511kb变为2104kb。
2.资源文件的可读性变复杂，资源名的失去了原有的语义。采用apk-tool对混淆前后的apk文件进行反编译。这款软件的优势在于可以把apk的文件转变为smali中间代码和资源文件源码，把 resources.arsc还原为原来的res文件夹。通过Android Studio对比整个res文件夹的结构，我们可以发现如下变化：
(1)资源名称出现变化
资源文件总量不变，名称被更短的代号取代。
以Layout文件夹为例，混淆前的前四个资源文件名称如下：
而混淆后的资源文件名则被更简短的代号取代。以Layout文件夹为例，混淆后的前四个资源文件名称如下：
点击混淆前和混淆后最上方的文件，发现文件的内容已经不再对应，所以可以认为这是一种无规律的命名，打乱了各个资源文件名的对应关系。
（2）资源文件中所有的引用名都被修改
在res文件夹下所有的所有资源引用中，资源名都被更改，以res\values\attrs.xml为例，混淆前我们可以获取完整的资源名称，如图：
而混淆后，所有的资源名都变为了简短的代号。
3.值得注意的是，源代码中所有的内容都不曾被改变，这说明AndResGuard不依赖于smali代码和编译过程。首先把apk的后缀改为rar并解压，取出dex文件采用dex2jar进行反编译，再使用jd-gui打开生成的jar文件，我们可以发现，混淆前的jar包和混淆后的jar包是完全一致的，以MainActivity为例，混淆前后完全看不出任何区别。混淆前代码如下：
混淆后代码如下：
运行性能测试
首次运行混淆后的程序时，出现如下报错：
查阅资料后猜测报错原因.
但测试了一遍ARM框架的软件还是不行，那么我推测，报错的原因很有可能是因为资源文件被打乱，导致虚拟机无法识别。我尝试用华为手机下载，里面的报错是：该安装包未包含任何证书，因此我可能需要考虑一下运行参数的问题了。但是在测试了除了签名之外的参数后，发现依然无法运行。但是用.android目录下的debug.keystore签名时出现报错，报错情况如下：
目前暂不知错误，正在分析中。希望大家可以帮帮我！不知道是否需要其他什么文件呢。
总结
其实AndResGuard就是对apk包的资源 resources.arsc进行更改，使得原有的资源文件中的资源名变得更加简短而不可读。这增加了安卓逆向人员的分析难度，实现了代码混淆。
- 文章链接: https://life-extension.github.io/2020/03/13/记一次安卓代码加固研究过程/
- 版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-ND 4.0 许可协议。转载请注明出处!
-
ACTF2020密码学部分writeup
六月 5日, 2020
编写的项目文件请参考项目链接。同时欢迎大家访问ACTF2020的所有赛题。喜欢的话请多多资瓷一下，给我们实验室的项目加个Star或者Fork，谢谢。 为了保护服务器的同时不给选手带来更多困难，密码学部分的交互题开了pow算力检测，我也...
-
通过python脚本自动插入汇编反调试代码
五月 20日, 2020
研究背景在之前OLLVM项目的研究过程中，我们发现反调试技术对反混淆脚本有一定的干扰作用，如果可以在OLLVM的中间代码中自动化插入反调试代码，那么就可以给OLLVM的代码混淆增加一层保障。 方案分析探讨多种方案以后，我认为最适合在汇...
-
基于门限方案的条形码保密及容错技术
四月 30日, 2020
关键词：门限方案，条形码保密，条形码容错，条形码认证与防伪造。 经历过初期两个小项目的探索，我们项目团队积累了一定的项目研究经验，在老师和16级学长的帮助下，我们把研究方向转到了门限方案的实际应用上。结合市面上用9张合并的条形码提高条...
-
2020新年原创脚本-其中的小把戏你清楚吗
四月 26日, 2020
关键词：随机数素数生成，新年祝福小程序。 脚本创作这是我在大年三十写的一个程序，当时我正准备去伯克利交流，但由于疫情的缘故，出国变数增大，所以我就打算通过随机数“未卜先知”。以下就是我的脚本： 12345678910111213141...
-
基于CRT的物流信息安全处理方案
四月 15日, 2020
关键词：中国剩余定理，密钥分发技术，隐私保护。 引言在2018年11月份的时候，段老师在密码学课上讲到了密钥分发协议，我当时就觉得这个协议很有意思也很有应用前景。后来老师还很主动地分享了一下它的idea，其中一部分就是有关物流单上的信...
-
基于CRT的新型群文件共享系统
四月 13日, 2020
关键词：隐私保护，权限管理，身份认证，中国剩余定理，密钥分发，密钥更新。 这个项目的是在2019年寒假期间进行的，4月份在中南大学信息安全作品赛答辩，但是由于功能只实现了主体部分，加之我在台上比较胆怯紧张，所以只获得团队三等奖，但是当...
-
安卓反混淆软件探索-deobf
三月 19日, 2020
关键词：代码混淆，代码反混淆及其原理，代码反混淆软件测试与性能对比。 前言我们的大创项目其实是分两方面进行的，一方面，我们从代码混淆的角度比较各种软件对安卓程序的加固能力；另一方面，我们着重针对OLLVM进行反混淆测试。OLLVM集成...
-
-
OLLVM代码加固机制分析
二月 24日, 2020
我们通过自己编写测试代码，再用OLLVM的不同指令进行加固，并逆向查看加固效果，加深对代码加固机理的了解。OLLVM目前提供的功能包括控制流平坦化（fla指令），指令替代（sub指令），代码虚拟化（bcf指令）以及虚假控制流（obf指...
-
对音频缓存加密的探讨
二月 17日, 2020
关键词：缓存解密，批量自动执行脚本，版权保护相关建议。 前段时间，某音乐被爆其缓存文件只使用了简单的异或加密，且容易得到加密密钥为0xa3。原文链接点击这里。以下是我的延伸探讨。 1.对音频缓存的批量解密攻击抱着好奇的心理，我把手机...
