加密技术历史

下面整理安卓的加密技术的历史发展。

用人类历史发展的阶段去类比解释如下：

原始社会时期

主要方式：代码混淆

奴隶社会时期

主要方式： 自我校验

封建社会时期

主要方式： dex文件变形

资本主义社会时期

1. Dex保护
   1. 隐藏dex文件
      • 既然dex文件中包含了核心逻辑，那么把dex隐藏，再通过另外的方式加载起来，是不是就能达到保护dex的目的了呢?于是这成为一些第三方加固产品保护应用的方式。
      • 他们通过加密甚至压缩(早期是不存在压缩的，只是单纯的加密)方式把dex转换为另外一个文件。而被加固后的apk里面的dex则是那些第三方加固产品用来启动和加载隐藏dex的入口，也就是壳。
      • 感觉小花生v3.6.9 和 康美通 v.4.4.0就是这类？
      • 总之是看不到dex文件
   2. 对dex文件进行变形
      • 这里所说的变形，不同于封建社会时期提到的变形。这种办法不隐藏dex，而是让dex保留在外面，但是当破解者去分析这个dex的时候，会发现dex里面的内容是不完整的。
   3. 对dex结构进行变形
      • 此类方法是比较复杂的，了解dex结构的人应该很清楚，dex结构中包含DexClassDef、ClassDataItem、DexCode，这些是dalvik虚拟机运行一个dex必不可少的部分，特别是DexCode，DexCode包含了虚拟机运行的字节码指令。
      • 部分第三方加固产品开始尝试这种方式，他们的保护方案中可能抽取了DexCode中的部分，然后对字节码指令添加nop，或者连ClassDataItem和DexCode一同抽取，或者对上面提到的三个部分都做处理。抽取完之后，还要做修正、修复等工作，总之很烦锁。因为dex运行时有很多关于dex的校验，即使校验通过还有一些偏移问题。
      • Dex都被抽取修改后为什么还能运行呢?那是因为在运行之前或者运行之中对这个内存中的dex做修正。修正工作也很复杂，一般选择在运行之前做修正，这样可以减少很大的工作量，甚至可能还需要借助hook来帮忙。
2. So保护
   1. 修改Elf头、节表
      • 相关工具：
        • 010 Editor
        • IDA
   2. 选择开源加壳工具
      • 最常用的：
        • UPX壳
          • 支持arm架构的ELF加固
   3. 进程防调试、或增加调试难度
      • 调试一个进程首先要ptrace这个进程
        • 防止进程被ptrace

社会主义时期

• 之前遗留问题
  1. 隐藏dex遗留的问题
     • 破解办法：
       • 实现自定义rom
       • 利用Inject原理将目标进程注入,代码进行hook系统函数来达到脱壳的目的
         • FDex2，DumpDex感觉就是用的这个机制？
  2. Dex结构变形带来的弊端
     • 安卓5.0新增了ART
       • ART可以直接将dex编译为本地指令运行
     • Dex结构变形遗留的问题很明显
       • 兼容性
       • ART模式下的编译问题
  3. ELF简单修改遗留问题
  4. UPX方面的劣势
     • 虽然upx是最为so加壳的首选，但是upx代码逻辑复杂，很难达到定制，特别是让它同时支持多种架构
       • -》基于上述原因一些第三方加固产品只是简单的利用upx加壳，并修改一些数据。不过很容易被有upx经验的人识破并脱壳
• 新防护技术
  • llvm混淆
    • 据说是新的llvm混淆，效果非常好，可以实现，即使被破解后，也很难看懂代码
  • VMP