前言&简介

在分析完 payloads/JRMPListener 、 exploit/JRMPListener 、 payloads/JRMPClient 后，再去看 exploit/JRMPClient 就变得很轻松了

先看看作者留言

大致意思就是，这个 exploit/JRMPClient 是为了生成一个 JRMP client 而存在的，并且其功能和 RMIRegistryExpoit 类似，但是 RMIRegistryExpoit 主要目标是 rmi 的 Registry 模块，而 JRMPClient 是瞄准的 rmi 中的 DGC 模块（Distributed Garbage Collection），说的是只要有监听了，都会存在 DGC 的

第二个就是，不会反序列化任何东西，因为它全都是向 server 发送数据，没有接受过任何来自 server 端的数据。在 exploit/JRMPListener 和 payloads/JRMPClient 的利用过程中，这个 server 端和 client 端，攻击者和受害者的角色是可以互换的，在你去打别人的过程中，很有可能被反手一下，所以最好的情况就是，只是发送数据，不去接受另一端传过来的信息，所以说用这个 exploit/JRMPClient 是不会自己打自己的 ; )

java -cp ysoserial.jar ysoserial.exploit.JRMPClient vps port CommonsCollecitons1 'calc.exe'

处理流程

现在直接看它的 main 函数

和 exploit/JRMPListener 的有点类似，多了一个代表 host 的参数，剩下的分别是 端口、需要加载的payload类型、需要执行的命令

流程也是先生成一个 payloadObject ，然后带入了 makeDGCCall 函数里，跟进去

这些流程也已经很熟悉了，就是和 server 端做一个协议通信，还记得在 Registry 里分析过

server 端主要的就是 ***Impl_Skel ，那我们可以看看 DGCImpl_Skel

一进去就看见了 dispatch 函数，这个和 Registry 的利用过程一样的，并且看见了 JRMPClient 写过来的 -66919625358661813

这个时候，我们发现 var4 是传参过来的，那么就需要找找这个 var4 是什么时候获取的，需要知道相应的读取顺序，先 int ，再 long ，最后肯定是一个 readObject

那么就去找找谁调用了 DGCImpl_Skel 中的 dispatch
翻 Registry 的笔记过程中发现，首先处理这些来自 client 的协议通信过程的是 UnicastServerRef.dispatch 跟进去看看

又是熟悉的一幕，按照正常流程的话，这里会调用 UnicastServerRef 的 oldDispatch 函数，跟进去

这里可以看见，var4 就是在调用 DGCImpl_Skel 的 dispatch 之前读取的，那么 var3 呢，发现在 oldDispatch 里没有读取 var3，var3是从参数传递过来的，那么我们回到之前的 dispatch 函数里看看

所以顺序已经找到了，先读取 var3，然后 var4，最后应该读取我们的 payload 了

那么应该就是 DGCImpl_Skel 里的 dispatch 里读取的，我们再次回到其流程中

这里提醒一下，var3 的值应该是 1，var4 是那个很长一串的 long

在 DGCImpl_Skel 的 dispatch 里，对 var3 进行了 switch 匹配

我们看看值为1的时候

跟进读取顺序的话，那么这里就是反序列化payload 的触发点了

一点小测试

其实，这个应该是和 payloads/JRMPListener 配套使用的
流程应该是，先使用 payloads/JRMPListener 的payload发送到目标服务器，因为限制条件小，也没有什么依赖，所以可以在目标服务器上顺利开启 JRMPListnener （我知道虽然真实情况下一般比这情况复杂多了），然后再用 exploit/JRMPClient 的payload打过去，这个过程测试过，能够成功的，但是似乎 payloads/JRMPListener 的 payload 不太稳定啊.......一会儿能够监听端口成功，一会儿不成功的......

不过呢，作者也说了 RMI 只要启动了监听那么是一定存在 DGC 的（不知道我理解的对不对），那么这个模块就可以直接像 RMIRegistryExploit 那样用去打 rmi 的服务，我也测试成功了的