爱加密Android APk 原理解析

转载请标明出处:http://blog.csdn.net/u011546655/article/details/45921025


爱加密Android APK加壳原理解析

一、什么是加壳?
加壳是在二进制的程序中植入一段代码,在执行的时候优先取得程序的控制权。做一些额外的工作。大多数病毒就是基于此原理。

二、加壳作用
加壳的程序能够有效阻止对程序的反汇编分析,以达到它不可告人的目的。这样的技术也经常使用来保护软件版权。防止被软件破解。



三、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文件结构例如以下:


解壳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层。这样的保护方法保护的意义并不大,由于反编译出源代码后通过keyword搜索非常快就行找到验证的代码块。略微一改动这验证保护就全然无效了。


2) server验证
       在android 的java层获取签名信息。上传server在服务端进行签名然后返回验证结果。

这样的保护还不如在纯java层验证实用,一旦没有网络验证保护就无效了。

用android方法获取的签名信息用java方法也能够获取。验证存放在server上也是为了把保护正确的签名信息值,可是保护的意义事实上没有不论什么作用,相同破解后全局搜索keyword然后伪造一个正确的签名信息就可完美破解了。


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我们反编译依稀看看是否有效果!

原文地址:https://www.cnblogs.com/bhlsheji/p/5338751.html