Android应用安全隐患现状,资源文件加密/安全防护进化史

前言

有安全数据显示，2014全年，Android用户感染恶意程序3.19亿人次，平均每天恶意程序感染量达到了87.5万人次。同时，Android应用被破解和盗版等事件也层出不穷。很明显，Android平台已经成为恶意程序和破解者攻击的众矢之的，于是越来越多的Android开发者开始意识到应用安全的重要性。

一、什么是“打包党”

他们专门对最热门或新秀APP下手，先将其破解，然后再以植入木马、插入广告、篡改支付链接等形式封装成新的APP，这个过程也叫做二次打包。更有开发者爆料，专业“打包党”的月收入超过百万，这简直是对正版开发者最赤裸的攻击和挑衅。

尼玛！一寸代码一寸血，一寸光阴一寸金，全白费了！

二、“打包党”一般都做些什么

植入木马，恶意扣费

“打包党”谋取暴利的形式多样，如在APP中植入木马程序，用户下载后，通过恶意扣费、窃取用户账号和密码等方式来获取利益。为了蒙蔽用户和节约成本，二次打包的APP通常和正版基本没有差异，用户在毫不知情的情况下使用后，一旦遭遇经济损失，最终开发者就要为此背黑锅，还会使正版APP的品牌形象受损。

植入广告，赚取广告费

当一个团队辛辛苦苦开发的APP，有了几十万、上百万的用户时，可能已经成为了“打包党”捕猎的对象。他们会在二次打包的过程中以植入或替换广告的形式来赚取广告收入，广告有按展示次数、点击次数、安装激活量等不同的计费形式。以展示次数为例，为了谋取更多利益，二次打包的APP会频繁的对用户进行广告提醒，给用户造成骚扰，体验感极差，但“打包党”并不care，他们只关心怎样尽可能多的赚到钱。
可以想象，一边是团队拼命的开发和推广，另一边则坐收渔翁之利，不劳而获。APP越火爆，给“打包党”带来的利益就越多，完全沦为了“打包党”赚钱的工具。

直接截取开发者的财路

除了游戏和软件类APP，随着移动支付类应用的火热，“打包党”还瞄准了支付类APP。“打包党”破解正版APP后，再修改App的付费链接参数，用户支付的费用直接进入“打包党”的口袋，完全切断了开发者的财路。

辛辛苦苦一整年，转眼回到解放前！

三、安卓apk的文件结构

   AndroidManifest.xml：Android主配置文件，编译过程中由文本格式转化为二进制AXML文件格式。
   Classes.dex:java代码编译后产生的一种类似字节码的文件。
   res：资源文件，其中的.xml文件在编译过程中由文本格式转化为二进制AXML文件格式。
   META-INF：签名文件。
   lib: native代码编译后的so。
   其他文件夹：由开发者自己添加的文件

Android apk的核心逻辑主要存在于classes.dex中，通常破解者在进行破解和二次打包时，会对classes.dex和AndroidManifest.xml文件进行操作，所以对这两个文件进行保护尤为重要。

四、apk二次打包的四个步骤

1.反编译

反编译java：classes.dex反编译成中间文件(smali、jar)。
反编译布局文件：Axml文件反编译成xml文件。

2.修改

修改smali文件。
修改xml文件。

3.重新编译

修改后的smali编译成classes.dex。
修改后的xml编译成Axml。

4.重签名

一款山寨版APP由此诞生!

五、Android APP 防破解进化史

原始社会时期——代码混淆

最早的应用保护当属代码混淆，谷歌官方发布的sdk中就包含ProGuard这种混淆工具。混淆工具会把你用java语言编写的代码的类名、变量名混淆为自己定义的格式，这样可以增加破解者在破解时阅读难度。但代码混淆只是简单的改变类名或者变量的名，只要能找dex，反编译为smali或者java，花些时间还是可以轻松破解的。如果说不用混淆工具我们破解一个apk需要2两天，那么用了这个工具，破解者可能需要4天，只是时间成本增加了。

奴隶社会时期——自我校验

经过漫长的混淆时期，开发者发现他们的应用还是照常被破解。于是新的保护方式又出现了——自我校验。
简单说，自我校验就是在程序中加一些对自己应用的完整性校验，可以借助签名、或计算自己应用dex的md5值等等来完成。有些开发者直接把校验功能加入到dex中，有些则是通过http协议请求相关服务来得到校验。有了这种校验，应用在被二次打包的时候会无法运行。
那这种方法的弊端是什么？举一个有意思的例子。在悬崖的拐弯处都会有一个路标，用来正确指示方向。但如果有人故意搞破坏，把路标指示方向弄反，那开车的人被误导后，顺着错误的方向行驶，就会发生不幸的悲剧。

这个例子的意思是，计算机在执行指令的时候也是按照预先定义好的逻辑（开发者写的）去执行，然而如果破解者对开发者校验的地方近进行了修改，那么计算机也会按照新的逻辑执行，这种保护措施风险很大，所以也就逐渐没落了。

封建社会时期——dex文件变形

经历了两个时代，开发者也逐渐提高了保护技能。于是很多做java出身的开发者，在经过无数日夜的努力下摇身一变成为了c、c++专家。越来越多的逻辑被写入到c层，并且所有的校验也被移到c层，混淆也同样存在。同时，开发者开始对dex文件AndroidManifest文件做变形处理，这样做的好处是既能保证应用能正常运行，也能使一些反编译工具如apktool在反编译时奔溃。但对dex文件和manifest文件的变形同样有它的弱点。基本世面上的dex变形都可以通过baksmali来得到smali，这样破解者就可继续分析。而manifset文件格式官方有明确的规范，破解者按照规范去解析，遇到不正确字节可以推敲，最终还是可以将其还原。

资本主义社会时期

这是一个移动互联网高速发展的时期，但盗版和二次打包等问题也日益凸显，在这个开放的时期，为了满足开发者保护应用的迫切需要，相继出现了一些基于Android APP加固的第三方产品，通常他们的基本做法有：

1.Dex保护

（1）隐藏dex文件

既然dex文件中包含了核心逻辑，那么把dex隐藏，再通过另外的方式加载起来，是不是就能达到保护dex的目的了呢？于是这成为一些第三方加固产品保护应用的方式。他们通过加密甚至压缩（早期是不存在压缩的，只是单纯的加密）方式把dex转换为另外一个文件。而被加固后的apk里面的dex则是那些第三方加固产品用来启动和加载隐藏dex的入口，也就是壳。

（2）对dex文件进行变形

这里所说的变形，不同于封建社会时期提到的变形。这种办法不隐藏dex，而是让dex保留在外面，但是当破解者去分析这个dex的时候，会发现dex里面的内容是不完整的。

（3）对dex结构进行变形

一些第三方加固产品开始尝试这种方式，他们的保护方案中可能抽取了DexCode中的部分，然后对字节码指令添加nop，或者连ClassDataItem和DexCode一同抽取，或者对上面提到的三个部分都做处理。抽取完之后，还要做修正、修复等工作，总之很烦锁。因为dex运行时有很多关于dex的校验，即使校验通过还有一些偏移问题。
Dex都被抽取修改后为什么还能运行呢？那是因为在运行之前或者运行之中对这个内存中的dex做修正。修正工作也很复杂，一般选择在运行之前做修正，这样可以减少很大的工作量，甚至可能还需要借助hook来帮忙。

2.So保护

（1）修改Elf头、节表

我们知道so其实是一个ELF文件，ELF文件有着自己的格式。有些第三方加固保护是对so文件进行保护，他们的做法是稍微修改一下ELF头或者节表信息，因为这并不会影响程序的正常运行。图3和图4是对ELF文件头中的节头表信息做了修改后，再用010 Editor打开，显示的异常界面：

图3

图4

接着我们用ida打开该ELF文件，发现该文件根本无法打开（一直卡在那里），如图5和图6所示：

图5

图6

其次，还有修改程序头表这种保护方式，如图7 所示，对PT_NOTE段做了一些修改。在该段的属性值中填充了一些无效的数字，导致逆向工具无法正常解析。由于系统并不会对PT_NOTE段进行分析，防御逆向工具的同时保证了该文件能被系统正常加载。

图7

（2）选择开源加壳工具

最常用的当属UPX壳，因为它支持arm架构的ELF加固。在加壳之后再对原文件做一些处理，这样对破解者的分析工作又增加了一些难度。

（3）进程防调试、或增加调试难度

有时候静态分析是非常局限的，这个时候动态分析的好处就体现出来了，然而动态分析的核心就是调试，而调试一个进程首先要ptrace这个进程，如果能有效的防止进程被ptrace，就能有效的防止动态调试。当然还有其他反调试技术，或者增加调试难度等等。

社会主义时期

这个时期，技术的发展与普及让人人都是开发者成为可能。而破解者的破解技术和手段也在随之变化。单一的应用保护措施已经无法有效的应对破解者的攻击，所以还需要从多重维度和深度对应用进行加固保护。
在上面的资本主义时期提到的几种保护措施中，遗留了很多问题，比如：

1.隐藏dex遗留的问题

首先dex是被完整隐藏起来的，一旦破解者得到了dex，就等于破解完成了一半。如果破解了加壳原理，就可以轻易做出脱壳机。另外就是实现自定义rom，这种方式可谓最为简单，只需要在相关的点加一些代码，然后编译一个自己的rom，这样在虚拟机中就可以顺利的脱壳了。还有就是利用Inject原理将目标进程注入,代码进行hook系统函数来达到脱壳的目的。

2.Dex结构变形带来的弊端

  随着安卓5.0的发布，Art步入我们的视野。Art可以直接将dex编译为本地指令运行。
  可是它编译时需要完整的dex，这怎么办？或许有些第三方加固产品选择了根本不编译，当然开发者和用户不知道，因为它表现出来的是程序可以正确运行，但是系统在Art模式下运行的更快这种优势就永远得不到体现了。
  所以Dex结构变形遗留的问题很明显，即兼容性和Art模式下的编译问题。

3.ELF简单修改遗留问题

对应修改ELF头和节头表信息的技巧很容易被识破和修复，所以只能防住初级破解者。

4.UPX方面的劣势

虽然upx是最为so加壳的首选，但是upx代码逻辑复杂，很难达到定制，特别是让它同时支持多种架构。