这是我CS二开系列的最后一篇公开文章了，再次感谢WBGIII、鸡哥、单纯、z3ratu1等若干师傅提供的思路和项目，让我受益匪浅。

CS 二开系列到此就告一段落了，相信下面这四篇一定可以帮助各位师傅完成cs从aggressor、teamserver到beacon逆向到实现的完整学习：

CS 4.4 二开笔记：基础篇
CS 4.4 二开笔记：增强篇
CS 4.4 二开笔记：beacon 指令分析篇
CS 4.4 二开笔记：SharpBeacon 实战修复

关于beacon的实现，目前已开放源码的项目包含rebeacon，geacon和sharpbeacon，rebeacon和geacon我之前都已经学习和分析过了，其中geacon的作者也写了相关文章对代码细节的实现进行了阐述。鸡哥的sharpbeacon用C#进行实现，更符合我对C2的设计思路，让我好奇的是关于sharpbeacon网上居然这么久都没有相关文章。代码的细节仍需要打磨，因此花了些时间对鸡哥的sharpbeacon的代码进行问题修复和增强，为了让各位师傅少走弯路，将技术细节总结出来形成本文，如文中存在问题也欢迎各位师傅进行交流学习。

鸡哥源码：SharpBeacon
这里我简单进行注释，具体的代码还是需要亲自去看才能印象深刻。

问题原因
上线后无法区分是x86还是x64，这个判断结果是通过metadata进行传递的，因此定位到metadata代码中。
代码位置
Metadata.cs!GetFlag | Metadata.cs!IsWow64 | Metadata.cs!GetArchitecture
问题分析
通过GetFlag函数获取的1字节放在metadata符号位中，用来表示当前进程的架构。

其中：
GetArchitecture()获取当前系统架构，x64时返回2，x86时返回0，其他架构返回1。
UserProcessToken()函数用来判断当前进程的权限
IsWow64()函数用来判断当前进程的架构，此处也是我们需要修改的函数。
在metadata中，对应符号位的字节有两个值进行判断：

需要注意的是，虽然设置为0也会导致默认代表x86架构，但是会导致部分指令返回Command Error，因此我们需要代码符合CobaltStrike的设计逻辑。因此此处对IsWow64()进行修改：

经过我们修改后，如果 isWow64 为 true，函数返回 1，表示进程运行在 WOW64 模式下；
如果 isWow64 为 false，函数返回 0，表示进程不运行在 WOW64 模式下。当捕获到异常时，函数仍然返回 0。
对应的，我们GetFlag()函数中也无需使用GetArchitecture()的值进行累加，直接通过isWow64()的返回值进行判断即可：

问题原因
sharpbeacon实现了控制台的ls指令，但是实现的指令无法用于文件浏览器。熟悉beacon源码的师傅应该知道，控制台的ls与文件浏览器公用一个函数。
引出下面两个问题：

代码位置
Program.cs | Prase.cs!AnalysisReponseData
问题分析
针对第一个问题，区别在于从beacon接收到teamserver任务数据的前9-12字节（4字节）作为符号位。
我们可以看下面的举例，下面前16字节为控制台ls指令：

下面前16字节为文件浏览器指令：

其中FF FF FF FE为控制台与界面化的区别符号位，文件浏览器中的00 00 00 01表示的是打开了一个文件浏览器。因此我们便可以利用这个符号位在beacon端进行区分，除此之外，前四个字节中的第四个字节代表任务号0x35(53)，对应config.cs中的

第二个问题，在beacon回传数据时，如何让teamserver知道回传的是哪一类的数据呢？
这里参考上面提到的Prase.cs!MakeCallbackData()函数，该函数第一个参数为返回的数据类型，32代表控制台，22代表界面数据。因此，我们修改Program.cs的代码：

其中_strModelFlag是在Prase.cs中实现的，我们新增两个函数根据字节数组解析控制台与界面的模式，然后返回值给_strModelFlag让其用来进行判断，新增函数如下：

其中byte[] lsFlagBytes = new byte[] { 0xFF, 0xFF, 0xFF, 0xFE };就是我们用来判断ls指令的控制台模式和界面模式的字节数组符号，下面的字节数组则用来区别PS指令的两个模式，下文会对此进行说明。

问题原因
在通信上，与上个问题一致，因此不过多赘述。
但是PS指令的返回数据需要进行校验，并且返回数据的列顺序也需要符合cs的设计规范。
代码位置
Prase.cs!AnalysisReponseData | Program.cs | Proc.cs!GetProcessList
问题分析
首先是通信问题，不同指令的四字节符号有所不同，与ls相区别的是PS的四字节符号为：

因此修改后的Program.cs代码：

Prase.cs!AnalysisReponseData函数下面新增的函数与ls一致，在里面新增一个byte[] psFlagBytes = new byte[] { 0x00, 0x00, 0x00, 0x00 };进行判断并返回相应的字符串即可。
另一个就是返回的数据包，正确的数据顺序为：

除此之外，PS数据的回传还存在一个校验，以原生beacon回传的ps数据为例：

在前16字节中，使用了接收到的CommandBuff放在了最后四字节中作为符号：

因此更改后的GetProcessList()函数内容为：

这里直接把cmdBuf的数据贴到返回数据包前面，就符合设计规范了。

这个问题经过debug后发现是在上面的修改中没有正确使用 try catch：

因为在使用pwd和exit等功能时，commandBuff的索引不符合CommandModel的字节数组长度要求，因此需要在使用CommandModel的地方使用try catch围起来：

问题原因
正常beacon上线后SYSTEM是具备额外符号（$*）的，sharpbeacon没有，不过这是一个小问题。
代码位置
metadata.cs!GetUsername()

我们在上面增加一个对SYSTEM字符串的判断就可以了：

问题原因
C# API能获取进程名，但是不包含后缀
有两处不完整：

代码位置
上线进程：Metadata.cs!GetProcessInfo
PS显示：Proc.cs!GetProcessList
解决方法
在C#中，进程名称通常不包括可执行文件的扩展名（如.exe）。如果想获取包含扩展名的完整进程名称，可以使用 Process 类的 MainModule 属性，这将返回一个 ProcessModule 对象，其中包含了主模块（通常是可执行文件）的完整路径。可以使用这个路径来提取文件名，包括其扩展名。原本的代码：

修复后：

PS显示相关代码处理起来会影响上线时间，因此不做处理。

问题原因
需要在初次上传metadata时设置两字节的编码。
代码位置
Prase.cs!MakeMetaData
解决方案

问题原因
sharpbeacon中的globalkey是写死在里面的，这个需要进行随机化。这部分在源代码中已经实现了，但是注释了，我们取消注释即可。
代码位置
Prase.cs!GenRandomAESKey
解决方案
GlobalKey是beacon后续与server沟通使用的密钥。用于加密的AESKey和验证hash的HmacKey分别为其sha256后的前后16位。我们要把globalkey进行随机化：

此处使用AssemblyLoader，这里提供了4种内存加载的方式，以下是每种方法的详细解释和它们之间的区别：

优点：

缺点：

优点：

缺点：

优点：

缺点：

优点：

缺点：

在geacon中使用了Doge-CLRLoad进行了内存加载，原理是ExecuteAssemblyLoadFileAppDomain，并且存在管理员权限无法正确接收回显的问题。我这里使用的是ExecuteAssemblyLoad1。
Cobaltstrike在从aggressor执行execute-assembly，将.net程序对beacon进行下发，当beacon收到字节流时，需要进行额外的处理。
beacon接收到的指令为Cmd type 88，在接收到字节流时，前0x21字节为cs文件头，用来区别cs下发的文件类型，去掉这部分数据才是C#数据

接下来我们需要去找到指令所在部分，在内存中定位的方式（我是使用的这种方式，有更好的方式可以告诉我）是定位</assembly>作为指令区域头，0x4D, 0x5A作为指令区域尾，当查到区域尾时进行回溯检查，在4D 5A之前查找四个连续的0x00，这里相应的实现函数如下：

这里需要注意：ExtractString中的length需要减2。

Cobalt Strike流量传输涉及五种编码：

SharpBeacon的profile为：

编码实现的步骤：

关于这几个编码函数的实现也是比较简单的，我建议单独放在一个文件夹中，并且在处理时不要直接使用原代码中的toBase64String，需要对这几个编码函数进行输出输出统一处理，不然没有办法按顺序进行多个编码，把base64作为基础编码。

源码中密钥的解析使用了NuGet的库，这会导致引用额外的dll，因此如何实现单文件显得尤为重要。主要设计的代码在RSACrypt.cs中，具体实现如下：

其中引用的GetRSAParameters函数在RsaKey.cs中，Exponent和Modulus与原代码中相比我们需要手动实现，并且修改相应的解析代码：

计算PEM的脚本为：

这个是CS用于扩展和自身自带的一些常用功能的关键功能，实际上就是反射dll注入，以不落地的方式实现扩展的功能，常见功能如port scan，hashdump，screenshot等均是job类型命令。使用该类命令会下发两个指令，1. 注入dll(cmd type 1/9/43/44/89/90)，2. 从命名管道读取数据（cmd type 40）。
sharpbeacon并没有对job的相关操作进行实现，job自身的操作一共有2个：

该功能的实现与dll注入紧密相连。

此处实现Inject：直接将指定的dll注入到指定pid的进程中，这里没有实现原生的指令，而是使用的项目为DLL-Injection。其实很多相关的功能后续都可以用C#来实现替代原有写死的功能，这样能够更加灵活多变。

这篇文章主要是用来抛砖引玉的，针对鸡哥提供的sharpbeacon中存在的问题进行了修复，并给出了如何增加新功能的思路。如果文中存在问题，也欢迎师傅们留言评论。

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