驱动开发一周之程

因为公司内部有一个被我挖掘出的漏洞需求需要填,而第三方大厂显然对此并没有什么意向,想到不就是保护注册表嘛,貌似我在哪里见过相关例子.类似进程回调的一种.

所以我自告奋勇的联系IT部门小伙,告知说’我设计过类似的东西’,开启了一周的"驱动级"保护注册表的方案学习旅程.

Win10驱动并不易

新方向的喜悦并没有持续多久,因为挑战接踵而至,连续冲击着时间规划.

第一步肯定是要开始搭建环境.

VS2019+WDK 结果各种报不能抵挡CPU漏洞…来回折腾安装.

无奈关之.还有无限的各种Warning当Error.几番折腾下来也关之,还调低了报警级别,结果很多类型都被忽略了.

然后就是配内核调试.尝试了新的方案.VS2019直接调试虚拟机通过管道.

好的地方就是源码直接下断点?

不足的地方就是VS2019太容易卡死了.Windbg其实本身也能下断点.

叹息:自虐

习惯了字符串的我，开始被迫频繁使用 UNICODE_STRING 令人难受.

用户需要个性化配置，我在实现该功能之前，先尝试封装了内存申请到 UNICODE_STRING 的函数.这里就涉及到使用带锁的双向链表来管理这些. AllocDynamicUNS(PUNICODE_STRING*)

我们缺乏大量的底层函数.连个截取字符串都无法做到.

从网上找了现成的代码结果,问题不断.只能自己去实现了一个.效果还不错.

另一个点就是 配置文件的实现.

ini简单吧,内核没有读取的东西.要从读文件开始封装,再从解析行语法开始写.状态机已经记忆不清楚了,当时就很难.

不过最后还是想通了:

状态机外部其实是专注于状态切换.其内部再实习字符解析

配置搞定后一切都顺理成章了.

权威是正确还是错误?官方注册表里open key从来没发生过

在看《Windows内核安全与驱动开发》的时候发现了一些小错误，另外发现注册表回调里的打开回调怎么也接收不到…

总有意料之外的事情

逐渐适应的UNICODE_STRING

随着基础函数搭建好,反倒是有点喜欢 UNICODE_STRING 函数了.
它帮我们解决了各种字符串没有终止的可能性.

慢慢度过适应期.

签名-从苦恼到解决

肖工要离开团队了.显然他应该拥有更好的未来.
老肖出马帮解决了若干问题.

无论是签名,还是一起找时间转换函数.简直就是答案作弊器.

他教授了一些方法, 比如 windows kernel 替代 wrk wdk

他的经验简直太丰富了.这对于一个年轻小伙子来说非常令人惊奇.

防一手

最终实现了除文件防护之外的所有想法.几乎不太可能有人能够不触发一次锁机的情况下破解该系统.

为了应对部门里小伙子们的可能安全测试.埋了一些隐蔽陷阱.

感觉自己就像在做兵推游戏.

另外 内核蓝屏，简直不要太容易。

后记

其实这个项目给我带来一种自由.即自由设计和实现功能.

另外也是非常熬人.显然投入力度很大.

也让想到自己的局限性,即自己对内核的了解还很少.如果有朝一日能实现网络驱动之类的开发,那我技术也很提高了.也算是未来的一条(出)路.

此外我还回想到了 ARK工具.如果我也能实现一次的话.
可以考虑未来向这方面分配一些时间做一些规划.