从2022年开始打，到今年应该算最后一次打了。这么多年下来感觉今年算是初赛最ex的一年了，感觉是为了反AI把junk code拉满了）

之前也从来没发过帖，不过今年这么ex还是发一下，正好也算最后一次打了纪念一下（

驱动是没有签名的，因此首先打开测试模式并关闭Windows驱动程序强制签名。

接下来利用App中提供的指令机型sc create创建内核服务即可，创建完毕后需要使用sc start启动服务

用代码来进行加载和启动如下：

在成功加载驱动之后再运行App即可看到如下交互界面：

本题目没有设置反调试的相关陷阱，因此虽然有大量的加固代码但可以容易的使用调试器来进行关键行为验证。

大部分的加固代码都可以通过临时patch掉加固的call函数和修补push/ret对为jmp来使得ida输出较为正常的结果。

其中patch掉加固的函数不影响主要逻辑，被patch掉的部分之后再进行专门的分析。

从R3侧App的入口点函数出发：

观察可以发现其主要逻辑是循环使用getch来读取用户的输入，并且使用push/retn以及查找表来实现jmp到对应的handler的目的，实际上就是一个switch。

还原成jmp后再反编译即可得到清晰的逻辑：

可以发现在正常流程中与驱动的交互都是通过DeviceIoControl函数实现的。

将三处交互可以代码化如下：

接下来可以在R0驱动侧验证上面的分析是否正确，还是先从驱动入口点出发，可以看到其主要逻辑如下：

注册相关的部分可以用来还原结构体的部分信息，主要还是看IRP_MJ_DEVICE_CONTROL对应的处理：

同样只看其主要逻辑：

与我们在用户侧的分析是一致的。

即题目的主要交互是通过R0-R3的正常IRP_MJ_DEVICE_CONTROL通信完成实现的。

除了正常的IRP_MJ_DEVICE_CONTROL通信之外，题目还存在许多隐蔽的通信手段，可以发现在应用测140001670初始化了许多Windows相关的Event和Semaphore，下面分析创建了哪些以及驱动侧是如何对应通信的。

使用SystemInformer查看R3侧App的句柄可以发现其创建了许多额外的Handle，在正常逻辑中不应出现：

这两者在用户侧的创建非常容易找到，位于140001340：

对应的驱动侧代码则可以通过ZwSetEvent的交叉引用找到：

除了上面提到的相关信息之外，驱动侧还存在一些可疑的导入函数，通过查看KeStackAttachProcess的交叉引用可以发现如下的一个处理：

可以发现其根据传入的参数不同设置了不同的LastError值，用户侧可以通过GetLastError获取这一隐藏信息。

调试可以追踪到每一轮都会从1403179B3开始，经过对应的发送得到一个对应的隐匿消息。而140005004处对应值0134的都已经找到了，为此我们通过调试来寻找2对应的操作。通过调试发现R后连续第5个D会走到这个路径，再通过在1403179D7下断点确认操作就是在这个中间完成的。因此我们在第五次D之前在1403179B3下断点，并通过ta抓取中间的指令。过滤后可以发现这中间调用了如下的内核函数：

很明显ZwProtectVirtualMemory很有可能是隐匿通信的渠道，我们给该函数下断点，抓取其参数可以发现其修改了当前进程的.data段的可执行权限为RWX（默认为RW）

刚启动时：

第五次D后：

为了方便起见我们下面用A和B来分别代指这两个信号量，对应关系如下：

R3侧创建信号量的代码在14021B91F中，这个函数关键的XOR字符串解密部分并没有被混淆，只是整体被插入了垃圾代码，可以容易的通过XOR 0x4B解出上面的两个信号量名称。

R0驱动侧的对应调用可以通过KeReleaseSemaphore的交叉引用找到，位于140319A37函数之中，主要逻辑如下：

除了上面发现的两个可以直接在代码中交叉引用发现的处理之外，我们前面的图上已经观察到了还存在一个Event：

用户态通过给CreateEventW下断点可以容易发现其是在其余的Event和信号量创建后被混淆的代码段中创建的，该函数返回到14021B901

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！