先来说一下一些常用的加密方法：
- 伪加密
伪加密是Android4.2.x系统发布前的加密方式之一，通过java代码对APK(压缩文件)进行伪加密，其修改原理是修改连续4位字节标记为”P K 01 02”的后第5位字节，奇数表示不加密偶数表示加密。
虽然伪加密可以起到一定防破解作用，但也会出现问题，首先使用伪加密对其APK加密后市场无法对其进行安全检测，导致部分市场会拒绝这类APK上传；其次，伪加密的加密方式和解密方式也早已公布导致它的安全程度也大大降低；再次，Android4.2.x系统无法安装伪加密的APK；最后伪加密只是对APK做简单保护，在java层源码加壳保护、核心so库、资源文件、主配文件、第三方架包方面却没有任何保护处理。注意：高版本不支持这样的方法，所以还是不要尝试使用这样的加密方式了。
- 混淆保护
把原来有具体含义的类名，变量名，方法名，修改成让人看不懂的名字，例如方法名getUserName编程了方法名
破解：耐心
- 运行时验证
运行时验证，主要是指在代码启动的时候本地获取签名信息然后对签名信息进行检验来判断自己的应用是否是正版，如果签名信息不是正版则提示盗版或者直接崩溃。当然你可以把必要的数据放在服务器端。
破解：找到smali文件中，判断是否相等的部分。改为常量true,即失效。
总之，反编译一些apk之后，只要是java代码写的总会有smil文件。对于smil文件，如果耐心读的话，还是可以查看到一些关键代码的。
相较于应用来说，游戏apk因为采用cocos2d-x
或者 unity3D，采用的是c++ 和c# 编写的跨平台程序，在apk采用JNI的方式。所以没有smali，可以防止静态被破解apk包。
当然游戏包apk
在运行的时候，会把.*so加载到内存中。动态也是可以在内存中抓取相应的数据。只不NDK 相对于smali破解来说，根部不是一个层级的关系。
难道真的就没有好的加密方式吗。想做一个应用非要把核心部分使用ndk这么复杂的东西嘛。
其实，我们完全可以借助第三方工具。比如爱加密(http://www.ijiami.cn/)以我上次使用gameChange.apk为例。
这是我在爱加密官网申请的加密程序。
该classes.dex是我原来的代码。没有混淆，没有任何的加密保护。反编译的话，真的是一丝不挂的漏了出来。
该classes.dex是经过爱加密处理之后的，反编译之后发现莫名其妙的代码。其实这两个类是，运行使用jni加载so库的代码。
NativeApplication
类，加载exec.so和execmain.so ，里面应该是固定的代码，是对源码
- package com.shell;
- import android.app.Application;
- public class NativeApplication
- {
- static
- {
- System.loadLibrary("exec");
- System.loadLibrary("execmain");
- }
- public static native boolean load(Application paramApplication, String paramString);
- public static native boolean run(Application paramApplication, String paramString);
- public static native boolean runAll(Application paramApplication, String paramString);
- }
复制代码
SuperApplication继承自Application，程序主入口：
- package com.shell;
- import android.app.Application;
- import android.content.Context;
- public class SuperApplication extends Application
- {
- protected void attachBaseContext(Context paramContext)
- {
- super.attachBaseContext(paramContext);
- NativeApplication.load(this, "com.example.gamechange");
- }
- public void onCreate()
- {
- NativeApplication.run(this, "android.app.Application");
- super.onCreate();
- }
- }
复制代码
在加密之后的apk包中，多了一个assets目录，该目录下，有一些ijiami.dat，其实这个就是我们原来的classex.dex
基本原理是在jni层， 使用DexClassLoader动态加载技术完成对加密classex.dex的动态加载，内存中解密classex.dex，完成动态加载。
PS：使用DexClassLoader动态加载技术
可以使用Android DexClassLoader完成DEX的动态加载，DEX文件可以附属在assert或raw目录也可以运行时从网络下载。
我们知道DexClassLoader加载的类是没有组件生命周期的，也就是说即使DexClassLoader通过对APK的动态加载完成了对组件类的加载，当系统启动该组件时，还会出现加载类失败的异常。为什么组件类被动态加载入虚拟机，但系统却出现加载类失败呢？
通过查看Android源代码我们知道组件类的加载是由另一个ClassLoader来完成的，DexClassLoader和系统组件ClassLoader并不存在关系，系统组件ClassLoader当然找不到由DexClassLoader加载的类，如果把系统组件ClassLoader的parent修改成DexClassLoader，我们就可以实现对apk代码的动态加载。
总结一下，爱家密的加密步骤：
- 把原来的classex.dex 用未知的加密算法实现加密成assets/ijiami.dat
- 把事先写好的jni代码和相应的classex.dex替换到原有的位置
- 程序安装完运行起来以后，先运行爱加密的加壳程序，在jni里面动态加载原来的classex.dex代码，从而达到加壳保护的目的.
- 源classex.dex 隐藏起来了，在静态的时候就没有办法对其破解。
- 至于动态运行，最好还是在自己代码里面下工夫了。比如内存加密啦。
由于申请加密之后，爱加密需要增加自己资源（两个so,一个classex.dex文件和三个bin文件）只增加了198.1KB的容量，对于我们动辄上百MB的游戏app而言，这点都不算事儿。
原文地址：http://blog.csdn.net/chengyingzhilian/article/details/38372601
App加密那点事&浅探爱加密原理