爱加密Android APK加壳原理解析

一、什么是加壳？

加壳是在二进制的程序中植入一段代码，在运行的时候优先取得程序的控制权，做一些额外的工作。大多数病毒就是基于此原理。PC EXE文件加壳的过程如下：

二、加壳作用

加壳的程序可以有效阻止对程序的反汇编分析，以达到它不可告人的目的。这种技术也常用来保护软件版权，防止被软件破解。

三、Android Dex文件加壳原理

PC平台现在已存在大量的标准的加壳和解壳工具，但是Android作为新兴平台还未出现APK加壳工具。Android Dex文件大量使用引用给加壳带来了一定的难度，但是从理论上讲，Android APK加壳也是可行的。

在这个过程中，牵扯到三个角色：

1、加壳程序：加密源程序为解壳数据、组装解壳程序和解壳数据

2、解壳程序：解密解壳数据，并运行时通过DexClassLoader动态加载

3、源程序：需要加壳处理的被保护代码

根据解壳数据在解壳程序DEX文件中的不同分布，本文将提出两种Android Dex加壳的实现方

案。

（一）解壳数据位于解壳程序文件尾部

该种方式简单实用，合并后的DEX文件结构如下。

加壳程序工作流程：

1、加密源程序APK文件为解壳数据

2、把解壳数据写入解壳程序Dex文件末尾，并在文件尾部添加解壳数据的大小。

3、修改解壳程序DEX头中checksum、signature 和file_size头信息。

4、修改源程序AndroidMainfest.xml文件并覆盖解壳程序AndroidMainfest.xml文件。

解壳DEX程序工作流程：

1、读取DEX文件末尾数据获取借壳数据长度。

2、从DEX文件读取解壳数据，解密解壳数据。以文件形式保存解密数据到a.APK文件

3、通过DexClassLoader动态加载a.apk。

（二）解壳数据位于解壳程序文件头

该种方式相对比较复杂， 合并后DEX文件结构如下：

加壳程序工作流程：

1、加密源程序APK文件为解壳数据

2、计算解壳数据长度，并添加该长度到解壳DEX文件头末尾，并继续解壳数据到文件头末尾。

（插入数据的位置为0x70处）

3、修改解壳程序DEX头中checksum、signature、file_size、header_size、string_ids_off、type_ids_off、proto_ids_off、field_ids_off、

method_ids_off、class_defs_off和data_off相关项。 分析map_off 数据，修改相关的数据偏移量。

4、修改源程序AndroidMainfest.xml文件并覆盖解壳程序AndroidMainfest.xml文件。

解壳DEX程序工作流程：

1、从0x70处读取解壳数据长度。

2、从DEX文件读取解壳数据，解密解壳数据。以文件形式保存解密数据到a.APK

3、通过DexClassLoader动态加载a.APK。

爱加密实现步骤：

1.把原来的classex.dex 用未知的加密算法实现加密成assets/ijiami.dat

2.把事先写好的jni代码和相应的classex.dex替换到原有的位置

3.程序安装完运行起来以后，先运行爱加密的加壳程序，在jni里面动态加载原 来的classex.dex代码，从而达到加壳保护的目的.

4.源classex.dex 隐藏起来了，在静态的时候就没有办法对其破解。

5.至于动态运行，最好还是在自己代码里面下工夫了。比如内存加密啦。

APK高级保护的方法（一）

运行时验证运行时验证，主要是指在代码启动的时候本地获取签名信息，然后对签名信息进行检验来判断自己的应用是否是正版，如果签名信息不是正版则提示盗版或者直接崩溃。

它的原理：APK的唯一识别是根据包名+签名，包名信息是写死在Android Manifest.xml里面的，但是签名则是与APK绑定的，一旦APK被反编译后签名会自动消失。APK的签名需要签名文件，签名文件的md5值基本上是无法伪造成一样的。

签名验证的方法也可以细分为3种：

1) Java 层验证

获取签名信息和验证的方法都写在android 的java层。这种保护方法保护的意义并不大，因为反编译出源码后通过关键字搜索很快就能够找到验证的代码块，稍微一修改这验证保护就完全无效了。

2) 服务器验证

在android 的java层获取签名信息，上传服务器在服务端进行签名然后返回验证结果。这种保护还不如在纯java层验证有用，一旦没有网络验证保护就无效了。用android方法获取的签名信息用java方法也可以获取，验证存放在服务器上也是为了把保护正确的签名信息值，但是保护的意义其实没有任何作用，同样破解后全局搜索关键字然后伪造一个正确的签名信息就可完美破解了。

3) NDK技术底层获取签名和验证

通过把Context，Activity，PackageManager，PackageInfo四个对象中的一个作为参数参入底层，在底层获取签名信息并验证。因为获取和验证的方法都封闭在更安全的so库里面，能够起到一定意义上的保护作用。不过通过java层的hook技术一样可以把这种保护完美破解。但是相比于前两种，此保护的意义和价值就更大了。

4）爱加密APP安全保护

它采用指纹校验保护APK中的文件，加密后APK中所有的文件都对应一个唯一的指纹。每次运行时，APK内部会再次进行指纹生成，如果生成的指纹和原本指纹不相同，则判断为被二次打包过的APK，程序就会自动退出或直接崩溃。该方法可以防止资源文件、主配置文件被修改或删除等操作，完全保证APK的安全。

APK高级保护的第二种方法——文件夹混淆（二）

文件夹混淆主要指的是利用Windows，Linux，Android 三个系统环境下的文件夹名的特殊性来对源码文件夹进行混淆，让混淆后的文件夹在Window看起来失去原有的逻辑性，但是完全不影响其在Android系统上的运行。

它的原理是：在Windows和Linux下文件夹的名字是不区分大小写的，但是在Android环境下它却要区分大小写。.2在Linux算一个特殊符号，所以文件夹名字里面添加的.2会被忽略，但是windows下.2却是一个很普通的字符串。

具体方法：反编译开发完成的APK，找到包目录下的最后一层文件夹(例如：包名是com.example.test2222，找到test2222所在的文件夹)，修改test2222文件夹名字为test2222.2并创建文件夹Test2222，然后随意存放一个有效的smali文件在Test2222里面，然后重新重写打包成APK签名。 如下图：

这种方法可以达到不错的保护效果，但是开发者一般都没有额外的时间和精力做加固保护。基本时间、技术等原因，爱加密为APK开发者提供免费的技术支持，对APK加壳隐藏源代码，从而防止反编译。它可以对XML 主配文件进行二次签名保护，保护SO文件不被破解和应用，同时可以保护APK不被二次打包！

第三种方式——花指令

花指令是程序中有一些指令，由设计者特别构思，希望使反汇编的时候出错，让破解者无法清楚正确地反汇编程序的内容，迷失方向。“花指令”这个词来源于汇编语言，它的思想是非常不错的，它的另一个目的就是利用反编译工具漏洞，来使工具无法使用。

接下来，我们就在JAVA代码处制“花指令”，让反编译工具(jd-gui)无法反编译查询你的JAVA代码。jd-gui的bug其实挺多了，很多特殊代码块或者字段集都能够让其崩溃无法反编译出源码。

比如：

private static final char[] wJ = "0123456789abcdef".toCharArray();

public static String imsi = "204046330839890";

public static String p = "0";

public static String keyword = "电话";public static String tranlateKeyword = "%E7%94%B5%E8%AF%9D";

在每个类里面加入如上字段，你会发现反编译的类通过jd-gui查看后的结果如下：

我们再来看一下爱加密的三层保护技术，即DEX加壳保护、DEX指令动态加载保护、高级混淆保护，可以保证APP的动态安全和静态安全，黑客将没有机会进行任何破解。

经过加密的APK我们反编译依稀看看是否有效果！