在上一篇文章中已经讲明了 RDI 类型的任务在发布时候的流程，接下来就是执行了，文中不提任务接收与结果回传，这部分内容在之前也已经分析过了，继续使用 HashDump 来进行分析

0x01 任务号

按照上一次流程的分析，RDI 在构建的时候实际发布了两个任务，一个是 HashDump 的任务号，还有一个是通过 getJobType 获取到的

根据上一篇文章的流程 HashDump 所调用的任务号是 44，这里的 getJobType 值也是直接在 Job 类当中写死了 40

同时还有一点比较重要的就是，在第二个任务中所保存的，正是前面 Patch 到 HashDump 中的管道名

其实根据这些，也就大致能够推测出后面这个功能就是用来接收 RDI 功能执行结果的

0x02 功能执行

直接看功能执行函数，接收了两个参数，一个是功能数据，一个是数据大小

再回到 Controller 这边对比一下，刚开始任务号，然后就是处理过的功能 DLL，前四个字节是大小

所以，当前总大小应该是 0x14208，但是从参数传进来的大小并不是这样

所以跟到功能 DLL 的结尾处看一下，可以发现正是另外的一个任务，

这里总共有 0x65 个字节，合起来刚好是 0x1426D

再根据这边的情况可以看出来，会 while 循环来执行

然后通过两次 ntohl 的转换，也就得到了任务号和功能长度，然后就直接进执行函数了，这里就是 switch 找任务号然后执行了

所对应的函数如下

其实里面所实现的内容是非常多的，包含了他所支持的多种内存分配、注入执行等，这些内容全都是通过 C2Profile 的设置来决定到底走哪一个流程

比如说，内存申请使用 VirtualAllocEx 还是 NtMapViewOfSection

它所对应的是 0x34，也就是 52

根据相对应的函数走具体的实现 NtMapViewOfSection

VirtualAllocEx

对于实际的注入也是一样 CreateRemoteThread

RtlCreateUserThread

再或者 NtQueueApcThread 等等

在当前注入等完成以后，会有一个 rundll32 一直在运行，因为它一直在连接管道

0x03 结果接收

然后继续就回到了功能执行，来执行结果接收，解析等等都是一样的，直接跟进执行函数，可以很明显的看到与管道相关的内容

直接取到管道名

接着后续就是创建管道等等操作了

在后续再通过 PeekNamedPipe 获取管道信息，确保内容已经写入了