移动app安全测试客户端篇（一）反编译

　　1、前言
　　APP客户端作为直接和用户接触的媒介，是公司是非常重要的信息资产。但由于系统本身的一些风险和破解工具的泛滥，使得破解移动应用变得易如反掌。移动应用安全性成为了大家都在关注的焦点。并在此基础上探讨如何做相关的安全测试。
　　本篇将要介绍是反编译的技术手段以及反反编译的一些基本策略。
　　2、反编译
　　未经保护的移动应用有许多弱点可被轻易攻击。比如注入恶意软件，窃取知识产权，破解内购、二次打包，盗取敏感数据等等。而这些操作的前提都是要进行 反编译。
　　这里我用Android系统的apk安装包作为例子，展开来介绍下。
　　2.1 常用的反编译工具
　　Android系统因其比较开放，且主要代码由java编写，所以相应的反编译工具比较多。例如apktool、jeb、jdJUI、jadx、MT管理器等等。iOS端则有IDA、Hopper之类的软件。
　　2.2 反编译效果
　　未经安全处理应用的java层反编译效果，代码及逻辑清晰可见，毫无秘密。
　　未经安全处理的native二进制文件反编译效果，代码逻辑及执行流程清晰明了。
　　通过上面的图可以看到，无论是java层代码还是c层代码，如果不加以适当的防护，都可以被反编译工具轻易的读取信息。
　　2.3 修改代码插桩
　　经过反编译后，我们实际上拿到的对应java层的代码其实是smali代码。它是用于Dalvik（Android虚拟机）的反汇编程序实现的。
　　通过修改smali代码，我们可以实现所有java层代码的功能。包括打印日志、跟踪堆栈、植入弹窗、注入恶意代码等等。然后重新打包就可以生成伪造的恶意apk安装包，然后利用破解等方式引诱不知情的用户下载，从而进行攻击或其他目的。
　　3、反反编译的基本策略
　　从上面的分析可以看到，不做防护的代码就如裸泳，一旦遇到各种反编译工具，立刻就会显出原形。
　　不过还是有一些手段可以用来给应用做安全防护的，例如代码混淆、应用加固等。
　　3.1 代码混淆
　　混淆机制，在应用中做混淆不仅可以减小安装包的大小，也可以增加逆向分析的难度。现在的混淆机制一般有两种，代码混淆和资源混淆。这里暂时只对代码混淆进行展开分析。
　　3.1.1 Java层代码混淆
　　混淆过的代码，在反编译后看到的代码类名、方法名以及代码格式都与正常的代码不太像。因为名称不规范，给逆向和逻辑的分析增大困难。
　　在普通的混淆的基础上，还可以定制高级版的混淆。这些都可以让逆向分析难度上升。
　　3.1.2 native代码混淆
　　关于c/c++代码的混淆，就非常有必要了解一下OLLVM混淆。在2.2章节中，可以看到即便是c/c++代码打包成的二进制动态库文件，如果不进行防护，在强大的反编译软件下依然跪的彻底。
　　OLLVM(Obfuscator-LLVM)是旨在提供一套开源的针对LLVM的代码混淆工具，以增加对逆向工程的难度。它是基于LLVM实现的，LLVM是一个编译器框架，并且得益于LLVM的设计，OLLVM适用LLVM支持的所有语言（C, C++, Objective-C, Ada 和 Fortran）和目标平台（x86, x86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, 和 XCore）。
　　通过上图可以看到，经过ollvm的so库，其流程和代码都被一定程度的混淆了，让静态分析的难度大大增加。
　　但是，代码混淆本身只是对源代码进行一定的变形，并且一些特定的类是不能被混淆的。所以通过这些入口，破解者仍然可以通过工具进行分析，只是难度增加了。而且，根据混淆的特点，可以写出特定的反混淆脚本来修正。
　　3.2 应用加固
　　经过上面的分析可以了解到，现阶段反编译工作相对较容易，虽然有各种混淆功能，但是总体上属于治标不治本。随着攻防的对抗升级，各个大厂纷纷推出了自己的应用加固方案，例如梆梆、加固保、乐固等等。
　　下图展示了一个加固后的应用反编译情况，原始代码均被隐藏了，只展示壳应用的部分代码。壳的解密代码则全部被放进了native层中，这样可以提高应用被破解逆向的难度。
　　不过值得注意的是，给应用套一层壳后，会存在部分兼容性问题，这都要＂归功＂于Android系统及机型的多样性。
　　3.3 其他方案
　　核心代码由c/c++层面实现。经过编译的c/c++代码会生成一个ELF格式文件。想要分析这种格式的文件，要比分析java难度大得多，而且会牵扯到大量汇编语言知识点。而且ELF文件本身也可以被＂修改＂、＂加固＂，例如抹去section信息等，同时又不影响其加载过程。通过这些手段，可以让静态分析的难度大大的提升。
　　还有一些其他的方案，如dex加固、动态加载等等。它们背后的原理其实都是一样的，对关键代码、文件进行修改、隐藏，只有在应用运行的时候才开始解密并执行。
　　4、安全性测试
　　基于这些反编译工具特点及反反编译的策略，我们就可以组织与其对应的反编译安全测试。
　　1、应用是否能够被常用的反编译工具识别，并且得到核心代码。
　　2、应用是否对代码进行了混淆，是否可以轻易还原逻辑。
　　3、应用是否采用了加固措施。