代码混淆能起到很好的反逆向分析，类似于 java 的 proguard 混淆和 dex 文件的 dexguard 混淆工具，c/c++ 也有对应的 ollvm 混淆组件。

Android 开发中针对 NDK 的书籍很少，《Pro Android C++ with the NDK》也是出版的比较早的一本书，有些内容可能对现在的开发并不适用。但是书中介绍的内容比较全面，难度也不是很大，对于 NDK 开发有很大帮助，特别是在 NDK 开发的配置和代码规范上。

系统 API 不管 DexClassLoader 还是 PathClassLoader 都只支持文件路径参数，所以在加载 dex 文件的时候必须生成一个缓存文件，而且是正常格式的 dex 文件。自定义的目的就是去掉这个缓存的过程，简单来讲就是让 DexClassLoader 支持 byte 数组参数，以内存形式加载。目前只实现了 Android4.0 系统到 Android4.4 系统真正意义上的自定义 Load。

现在部分 app 出于安全性(比如加密算法)或者用户体验(热补丁修复bug)会考虑将部分模块采用热加载的形式 Load。所以针对这部分的 dex 进行加密是有必要的，如果 dex 是修复的加密算法，你总不想被人一下就反编译出来吧。当然也可以直接用一个加密算法对 dex 进行加密，Load 前进行解密就可以了，但是最好的加密就是让人分不清你是否加密了。一般逆向过程中拿到一个可以直接反编译成 java 源码的 dex 我们很可能就认为这个 dex 文件是没有加密可以分析的。

前段时间忙于破解移动和电信的 apk ,挺久没有更新博客了，最近在写个工具，主要功能是通过配置对 dex 文件中的类型、函数、属性进行隐藏，达到防止被静态分析的效果。所以在写工具前必须对 dex 的文件格式有个清晰的认识，相对于 elf 文件格式 dex 文件格式会简单一些。

Android.mk 的可配置参数会比较多，但是常用的可能很少。在进行多项目 ndk 共享的时候，如果对各个参数比较了解，对项目的结构优化有不小的好处。

最近超级想打球，然后打了五分钟就把脚踝给扭伤了。原以为10月已经够悲伤了，没想到11月还倒霉。还好还有一群小伙伴。在寝室休息了两天，动不了，想起了之前kindle下的好几本书都没看，看了一半的《白夜行》（还不错，手贱先百度了剧情。。。。。雪穗），然后有个比我更无聊的人，发了一个网址给我。。。

近些年来移动 APP 数量呈现爆炸式的增长，黑产也从原来的PC端移到了移动端，伴随而来的逆向攻击手段也越来越高明。本篇章主要介绍应用加固的最基础的四种方式：1.proguard 混淆 2.签名比对验证 3.ndk 编译 .so 动态库 4.代码动态加载

在开发和逆向过程中很多时候都需要动态调试，开发时候可以用开发 android 的 IDE进行调试，native层也可用调试，Android Studio早就可以进行 native 的debug调试了。但是在 release 后的 apk 如果还检测到了 debug 调试，那么说明该 apk 正被破解。

NDK开发最后生成的so文件是基于ELF文件格式。而so是共享目标文件，所以要想对so文件进行加密就必须了解ELF文件格式。