ZjDroid[16]是基于Xposed的脱壳工具。它hook了BaseDexClassLoader对 象来获取包含dex文件的目标内存，它只支持DVM并且需要root权限。对于阿里等将原始dex文件拆分的做法，它也无法克服。Park在[17]提出 了一种方法：对apk进行重新打包，并插入一个调用了waitfor-debug功能的方法，使得APP在启动后会暂停并等待用户利用JWDP调试协议进 行连接。这样可以调试目标APP并读取其内存。但此方法很容易被检测绕过且无法克服反调试的限制。

Jung在[18]提出了一个叫做DABiD的调试器。它可以获取到内存中有效的dex文件。它通过将自己的 模块注入到目标APP的进程中，监视内存中的动态修改包括代码自修改和动态类加载，并将相关信息反映到调试器中。同样地，它不支持ART环境。并且由于它 只监视了dex文件的内存区域，所以针对于修改Android运行时所维护的对象的行为无法进行监视和捕获。

破解思路及实现

之前对于各种APP保护的破解方法，主要还是处于和APP自身同样的运行级别，所以很容易被检测到并且绕过， 所以我们的思路是直接提高脱壳模块的等级，将其整合到Android的运行时中，并使得内存中的dex文件得到最大程度的恢复，这样被运行时解释和执行的 APP便很难绕过了，而且也轻易解决了反调试技术的限制。

根据此思路设计了DexHunter[19，20]，它整合进了DVM和ART两个运行时。通过由用户指定一 个特征字符串来定位到包含dex主体部分的内存区域。这个特征字符串主要用来匹配运行时当前使用的dex文件是否是我们需要的dex文件。一旦获取了 dex的主体部分，接下来便主动加载并初始化dex文件中的所有class，尽力使其恢复到正常运行的状态。接下来我们将整个区域分为三部分，重点处理包 含class数据的第二部分。我们对于每一个class进行解析，并观察其中是否有数据位于主体dex范围之外，及相关的信息是否与Android运行时 所维护的数据一致，如果有所出入，则修改dex文件中的相关数据，并将外部的数据收集在一起重新存储在尾部，并修正相关的指针，这样我们便能够得到一个完 整的dex文件。整体的思路如图1所示。

对于一些无效的字段，我们可以在得到dex文件后将其全部抹除为0，这样便不会影响apktool等工具进行 反编译。对于百度所使用的抹除方法指令的手段，可以监控DoInvoke（ART）和dvmMterp_invokeMethod（DVM）方法实时地提 取有效指令；也可以修改还原的dex文件，去掉调用百度中抹除指令的JNI方法的指令，这样的话同样可以从内存中获取有效的指令。

技术展望

破除APP的保护，主要的手段就是从内存中拿到有效的执行数据，这样关键点就在于时机的选择或主动触发，从而 保证内存中存在有效的数据。所以APP保护技术一个重要的关注点也就在于如何打乱时机，使破解者无法找到一个关键点来获取到有效的dex文件。下一步的发 展趋势是可能使用虚拟机壳的技术。虽然实现上并没有太多障碍，但是由于效率原因，距离实用还是有一些距离的。