前段时间看到有朋友在问在怎么使用frida去hook动态加载的dex之类的问题，确实关于如何hook动态加载的dex，网上的资料很少，更不用说怎么使用frida去hook动态加载的dex了。（frida的官方文档已经无力吐槽...）后来偶然的情况下发现了一道CTF题目可以作为很好的案例，所以花了很多心思将文章写下来分享给大家，涉及的内容比较多，我打算用上下篇将frida hook动态加载的dex的方法将清楚，上篇主要是引导及一些前置的知识。

博客同步：访问 （一些web安全的研究会直接发布到这上面）

文章使用的是DDCTF2018的android逆向第二题Hello Baby Dex

示例地址：下载

程序功能很简单，就是输入密码并验证，错误会Toast出一些信息，按这个惯性，可能得输入某些正确的值才能获取flag吧，废话不多说，直接反编译看看。

一般情况下，我是直接扔到jadx中去看反编译后的代码，可是这次jadx反编译出来的结果有很多错误，这里我就不贴图了，大家可以尝试一下，看看是什么错误。后面放到jeb工具中，便没有报错，所以查看反编译的效果时，大家可以多尝试几个反编译器对比效果，查看AndroidManifest.xml，找到了程序的入口MainActivity。

在此同时，在cmd中通过apktool d [apk]，再将apk文件反编译出来。

接下来直接定位到MainActivity的onCreate()方法，可以看到代码是混淆过的，阅读上稍微有点小困难，但是在onCreate()方法中，我们还是可以发现一些可疑的方法及变量，比如PatchProxy，changeQuickRedirect等。

继续搜索有用的信息，我们可以发现在onCreate()方法的else逻辑中调用了this.runRobust()，并且我们发现在类中每一个方法里面都会存在一些changeQuickRedirect变量，以及isSupport()，accessDispatch()方法。

上面的先放一边，我们来看看runRobust()方法中写了什么，在else条件语句中可以看到它实例化了一些对象。

跟进PatchManipulateImp类，可以发现在fetchPatchList方法中，它调用了getAssets().open("GeekTan.BMP");从资源文件夹中，加载了一个BMP的图片文件，并将这个BMP文件内容写入GeekTan.jar中。

具体代码如下：

显然这个BMP文件很可疑，我们放到010 editor中看看二进制的内容，发现它真正的文件格式是一个压缩包,并且可以直观的看到在压缩包中存在一个dex文件。

同时我们还可以发现，fetchPatchList()方法中实例化了一个Patch对象。

并在fetchPatchList()方法的最后，调用

回到runRobust()，接下来实例化了PatchExecutor类，可以看到第二个参数即为PatchManipulateImp类的实例。

这个PatchExecutor类是在com.meituan.robust包下的，这是一个第三方的包，目前官方已经将其开源，因为直接看混淆的代码还是比较费时的，在此暂停上面的分析，简单学习一下Robust。

我们先简单了解一下Robust是什么，Robust是美团出的一款热修复框架，可以在github上面下载它的最新的源码。

Robust的基本原理，我们主要了解这4个步骤就能清晰明白了。
1. 将apk代码中每个函数都在编译打包阶段自动的插入一段代码。
例如，原函数：

它会被处理成这样：

可以看到Robust为每个class增加了个类型为ChangeQuickRedirect的静态成员，而在每个方法前都插入了使用changeQuickRedirect相关的逻辑，当changeQuickRedirect不为null时，会执行到accessDispatch方法从而替换掉之前老的逻辑，达到修复的目的。

2.生成需要修复的类及方法的类文件并打包成dex。
接下来你可能已经将需要修复的类及方法写好了，这个时候调用Robust的autopatch文件夹中的类及方法会生成如下主要文件：PatchesInfoImpl.java，xxxPatchControl.java（其中xxx为原类的名字）。

PatchesInfoImpl.java的内是由PatchesInfoFactory类的createPatchesInfoClass生成的，这是它生成PatchesInfoImpl逻辑，可以看到，这个类其实是用拼接得到的。

生成的PatchesInfoImpl类型及类内容如下。

另外还会生成一个xxxPatchControl类，通过PatchesControlFactory的createControlClass()方法生成，具体的逻辑和生成PatchesInfoImpl类类似，大家可以自行去查看源代码,其中每个Control类中都存在以下静态成员变量和方法。

将含有PatchesInfoImpl.java和xxxPatchControl.java,以及xxxPatch.java（具体修复的类）打包成dex文件。

3.动态加载dex文件，以反射的方式修改替换旧类。

在此，我们回到刚刚暂停的地方，我们跟进PatchExecutor类看看。

在run方法中，主要做了2件事。

1.获取补丁列表。

2.应用补丁。

跟进patch()方法，我们具体分析一下。

4.isSupport和accessDispatch
接下来我们再来看看onCreate()中的代码，虽然混淆后代码看起来很冗长，但是通过刚刚我们对Robust原理的简单分析，现在已经可以清晰的知道，这其实就是isSupport()和accessDispatch()。

我们看看源码中的isSupport()具体做了什么。

通过上面的分析，可以知道只有当存在补丁的类changeQuickRedirect.isSupport()才会返回值。这个时候我们把刚刚第二步打包的dex反编译看看，我们可以看到在xxxPatchControl类中存在isSupport，它返回的值其实就是methodNumber。

accessDispatch()方法，替换原方法。

具体看看PatchControl类中的accessDispatch。

花了比较多的篇幅把Robust的基本原理给大家介绍了，接下来完全回到这个apk。

经过我们对Robust的分析，我们现在已经比较清晰的知道了我们需要攻克的难点，它是通过Robust热修复框架将一些方法热修复了，所以我们这里必须知道，它修复了哪些类及方法，当然在上面我们已经零星看到了一些细节，现在我们来具体看看。

我们先将assets文件夹下的GeekTan.BMP改成GeekTan.rar，并解压，得到dex文件直接扔到jadx中分析。在PatchesInfoImpl类中可以看到2个要被修复的类信息。

先看MainActivityPatchControl类，我们看到在accessDispatch()，onCreate()和Joseph()方法将会通过判断ethodNumber来选取。

继续查看MainActivity$1PatchControl类，同样发现onClick被修复了。

所以这个时候，我们必须知道onClick真正执行的逻辑是什么。查看MainActivity$1Patch类中的真正的onClick方法。很明显的两句提示语，可以明确我们要的答案就在这里。

仔细分析onClick方法，可以发现很多invokeReflectStaticMethod，getFieldValue，invokeReflectMethod方法，同样我们还能发现flag就在这里面。

通过上面的分析，可以发现hook有2个思路：
1.hook EnhancedRobustUtils类下的方法获取方法执行的返回值。
2.hook 动态加载的类MainActivityPatch的Joseph方法，直接调用它获取返回值。（下篇）

先来看看EnhancedRobustUtils类下的方法invokeReflectMethod。

我们再看看invokeReflectConstruct。

很简单，通过反射得到类的实例及方法，最终通过invoke代入参数执行方法。这里很幸运，我们发现这个EnhancedRobustUtils 是Robust自带的类，并不是动态加载的。
那hook就非常简单了，我们只需要简单的hook invokeReflectMethod获取Joseph的返回值，以及equals的参数即可。
完整python脚本：下载

最终获得结果如下：

上篇我们主要讲了robust的原理，并采用第一种方法Robust自带的EnhancedRobustUtils工具类来hook，得到我们想要的答案，从做题的角度来说是一种很好很快的办法，但是从学习的角度，可能这道题用hook DexClassLoader的方式更有趣味和意义，下篇我会详细介绍怎么hook DexClassLoader动态加载的类及方法，来获得最终答案：D

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！