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