之前的分析都是针对整个 CS 的框架来进行的，但是功能也是整个 C2 中相当重要的部分，接下来几篇文章会对基本的功能类型的流程进行分析

0x01 任务构建

CS 自带的 RDI 类型的功能也有好多，但所有的构建等也都是大同小异了，这里以 HashDump 来进行分析，HashDump 有两种触发方式，一种是在界面上直接点击，一种是通过命令

这两种方式在执行前都会去判断当前用户的权限是否是管理员，如果是才会去执行，而这两种不同的触发方式所使用的检测权限也是在不同位置的

如果是在界面上点击的话，它会在 cna 脚本中直接进行判断

如果通过命令的话，它会在 BeaconConsole 处理的时候直接来判断

而判断方法就是直接判断用户名是否带星号，因为在初始化 BeaconEntry 的时候就已经进行了设置，如果是管理员的话，会直接在名字尾部追加星号

但是无论他们走哪个流程来处理，最终都会通过 TaskBeacon 来进行任务的构建

判断架构也是 BeaconEntry 就已经处理好的

然后先来看一下 HashdumpJob 的内容，可以看到它继承自 Job，而且里面也没有上面所要调用的 spawn，所以这也一定是继承过来的

在 Job 中明显能够看出来有六个函数需要自己来实现

其中最关键的就是 getDLLName、getPipeName、getCallbackType，至于其他设置描述等对于实际的执行也没有那么大的影响

getDLLName 是用来获取所需要调用的 DLL 的，getPipeName 是用来通过制定管道将信息回传给 Beacon 的，这里是特殊字符的占位符，用来后面做 Patch 时候来寻找对应位置的，getCallbackType 是用来决定信息回传到 TeamServer 以后用什么样的格式来回传给 Controller 的

理解了上面的内容以后就可以继续跟入了

首先会通过刚才获取到的名字，将对应的 DLL 读取出来

接着根据架构来 Patch 对应的引导头，并开始构建任务，设置对应的任务号

接着就需要对管道进行处理

它会根据 C2Profile 中设计的命名格式来生成对应的管道名，并在最后将值 Patch 到 DLL 当中

因为 HashDump 功能并不需要进行修复、线程修复、混淆等操作，所以这几步内容都是不需要的

我们也没有设置 SmartInject，这里也忽略掉，然后就构建好了一个任务

当前这个任务的内容就是任务号（4个字节）+ DLLSize（4个字节）+ DLL

紧接着又构建了一个任务，包括了 JobType、CallbackType、WaitTime、PipeName 以及描述等信息，这里的 JobType 之前的任务对应一下，这里很明显就是任务号

最后将两个任务都进行了发送

这里它实际上是调用了两次任务发布，而且这里也很明显能看到之前设置的 Description 是用来在控制台展示的

0x02 结果处理

在结果解密之后，他会先读取 CallbackType

这里也很明显就与之前的设置对应上了

然后会对结果进行处理，对格式进行处理，将凭证添加到 credentials 中，并在最后直接更新上去

这样也就完成了整个流程

0x03 功能 DLL 分析

在 DLL 中可以很容易的看到 Java 在处理时候所设置的这一串值

然后会直接用这片内存的值来连接管道

所以情况也就很明了了，在程序中提前写好固定的值，在 Java 处理的时候，将处理后的值直接替换到这片位置上，用于后续结果通过管道来进行回传