在上两篇文章中，讲述了 CS 中的一种功能执行方式 RDI，这一次来分析一下另外一个非常重要的功能执行方式——DotNet
0x01 DotNet功能分析
CobaltStrike 提供了一种可以执行任意 DotNet 程序的方案，使用了名叫 invokeassembly 的 DLL，来加载和执行所传递的 DotNet 功能，提供这个方法的 Job 是 ExecuteAssemblyJob，它跟 RDI 不一样，它继承自 JobSimple 类
与 RDI 一样，它也有一些必须要处理的方法
在实际执行的时候，它会直接来运行 ExecuteAssemblyJob 的 spawn 方法
首先它会获取到 invokeassembly.dll，然后获取到它的 ReflectiveLoader 函数，接着就开始了任务的构建
随后会对其再进行一些设置的操作
在 fix 中，会有对 amsi 的一些处理
接下来有一个比较重要的操作，获取参数
在这里会将 this.file 和 this.args 都组合到一起
而这两个东西，正是我们要执行的 DotNet 和参数，所以说 CS 实际上是把我们要执行的内容当作参数来进行传输了，最后再交给 invokeassembly 来执行
而后就是任务的构建和发送了
0x02 DotNet功能执行
在执行到 DotNet 功能的时候，前面的处理操作先不管了，只看执行这里的
根据之前 RDI 的分析，也很容易能够区分出进程创建的位置，其中的操作基本都是一致的
直接就跳进函数的执行，这里面就包含了各种执行方式以及加载运行
之后执行权限就交给了 invokeassembly
这里再追下去的意义就不是很大了，主要就是调用接口来加载 DotNet 程序集，其中所用到的技术也是已经开源了的 Hosting CLR，可以参考下面的这篇文章来阅读
https://b4rtik.github.io/posts/execute-assembly-via-meterpreter-session/
https://github.com/b4rtik/metasploit-execute-assembly
0x03 写在最后
与 RDI 不同的是，我们并不需要在 DotNet 当中处理管道相关的内容，这些东西都由 beacon 和 invokeassembly 处理了，因为 DotNet 是由我们来传进去的，而 RDI 的功能它是不支持像 DotNet 这样直接调用的，而我们通过二开的方式来进行了使用，就需要直接按照所规定好的方式来进行处理才可以。