技术合作
Windows Kernel · Driver Development · Reverse Engineering · Compatibility
围绕 Windows 内核与驱动的开发、分析、检测与兼容性适配，承接具体的技术问题。下面写的是我确实做过的方向、能交付什么，以及哪些事我不做。
可以承接的方向
1. Windows 内核与驱动开发
- 驱动骨架与功能实现：WDM / KMDF 驱动，IRP 与派遣函数、设备与符号链接、IOCTL 接口设计与用户态对接
- 内核回调与过滤：进程/线程/镜像回调、注册表回调、Minifilter、WFP Callout 的注册与收敛
- 内核数据采集：对象管理器遍历、内核模块与驱动对象枚举、内核表（SSDT / IDT / GDT）读取
- 工程约束相关的实现：IRQL 纪律、对象引用计数、
ProbeForRead/MmCopyMemory/__try组合的安全读取，以及蓝屏与挂起的排查
2. 逆向分析
- 用户态 / 内核态样本的静态与动态分析：行为梳理、关键逻辑还原、加壳与解包思路
- 恶意样本分析：持久化方式、注入与反射加载、通信行为、检测点定位
- 现有工具的检测逻辑还原与误报/漏报分析（给结论时同时给证据与边界）
3. Windows 内核安全检测与评估
- 隐藏进程、隐藏驱动、Inline Hook、回调异常等场景的检测方案设计与实现
- 多视角交叉验证：把不同来源的枚举结果做集合关联，输出差异与置信等级，而不是直接判定「恶意」
- 检测结果的复核方法：对照组设计、干净基线与重复测试的组织方式
4. 兼容性开发与适配
- 老代码迁移到新的 Windows 版本 / 新的编译工具链（MSVC、WDK 版本差异、调用约定与结构体对齐）
- 跨版本行为差异定位：内核私有结构（
OBJECT_DIRECTORY、LDR_DATA_TABLE_ENTRY等）随版本变化的适配 - 驱动与用户态程序的签名、加载、兼容性问题的排查与回归验证
可以交付什么
| 交付物 | 形态 |
|---|---|
| 代码 | 可编译的驱动 / 工具源码，附构建说明与依赖版本 |
| 分析结论 | 可复现的步骤、关键证据（日志、截图、内存数据）、以及对结论适用边界的说明 |
| 方案评估 | 针对具体场景的可行性判断：能做 / 不能做 / 需要什么条件才能做 |
| 问题定位 | 蓝屏、挂起、枚举结果不符一类问题的根因分析，附复现条件与验证方法 |
典型项目
三个案例都来自实际做过的工作，数字取自各自项目的实测记录。仍在进行中的部分按「已验证 / 未完成」分开写，不把半成品说成已交付；客户名称与商务信息不公开。
案例一：Windows 内核完整性检测（SnowSword 项目）
问题：判断「有没有驱动把自己从内核里藏起来」，不能只看某一个列表 —— 单一枚举源漏掉的，恰恰是隐藏者要藏的那部分。
做法：三个互相独立的采集视角（已加载模块链表 / 对象管理器 DRIVER_OBJECT 目录，含 \FileSystem\Filters 子目录 / 内核映像区的 PE 特征扫描），按映像基址做集合差集，输出「来源视角 + 来源数 + 置信状态」，而不是直接判定「恶意」。
已验证：测试驱动摘链后，SnowSword 在内核模块列表中把它标了出来；同一次实验中，OpenArk 的当前驱动列表没有显示该项。过程与截图见实测记录。
边界：这是单次功能验证，不是检测率基线。模块 / 对象目录 / 内存候选的逐项对照，以及扫描耗时、CPU 占用、IOCTL 次数等性能数据都还没有采集。完整能力清单与验证边界见项目主页。
案例二：旧版系统的输入设备替换定位（零售 / 自助服务终端的 Windows XP 客户机）
问题：某零售与自助服务终端厂商的 Windows XP 收银机，原装 USB 触摸控制器停产，换同接口的替代型号后，操作界面起不来。这类问题最容易被「改代码试错」带偏，改到最后也说不清到底哪一层坏了。
做法：把链路拆成三层 —— 界面控件层、程序注入层、设备枚举与上层闸门，用免注册 OCX 宿主 + 事件计数 + 依赖链跟踪逐层排除，而不是先动驱动。
已验证：三类界面控件在免注册宿主中全部创建成功，真实鼠标各触发 3 个事件（dispid −605 / −607 / −600），按下与抬起有像素级反馈；而同一条按下消息经程序注入下发时，只进消息、无按下视觉也无 Click。据此排除控件层与注入层，把问题范围收敛到「触摸数据进入回调之前」。
边界：双适配器多屏的验证在实验环境没能建立（该平台缺对应的旧版显示驱动与客户机交互通道），这部分结论仍待客户机侧材料补齐；本项目不改客户二进制、不写驱动、不做可部署补丁。
案例三：Windows 侧 USB 设备导出端（USB/IP 方向）
问题：把本机 USB 设备导出给虚拟机使用，需要一条「能反复自动跑」的验收链 —— 手工点一遍、看着像成功了就收工，等于没验证。
做法：分三段推进 —— T0 自动化测试台（构建 / 部署 / 安装 / 自检 / 追踪解码 / 卸载 / 回滚，一条命令闭环）；T1 过滤驱动（Extension INF，原功能用逐字节判据比对）；T2 自研函数驱动接管 PDO（自建 URB 提交通路）。
已验证（数字取自项目测试记录）：
| 阶段 | 结果 |
|---|---|
| T0 测试台 | 连续 3 轮 3/3 通过，单轮闭环中位 63.5 s，人工介入 0 次 |
| T1 过滤驱动 | 连续 3 轮 3/3，接管前后 HID 功能签名 SUMMARY_SHA256 完全一致 |
| T2 函数驱动接管 | 5 轮 × 每轮 20 次重新枚举 = 100/100 无一失手，闭环中位 123.6 s，卸载后设备完整回落到原驱动 |
边界：不宣称完整 USB/IP 设备导出。协议与网络传输层未做；描述符与控制传输已打通，但 Bulk 通路因实验环境里没有带 Bulk 端点的设备而阻断 —— 没有用「伪造成 Mass Storage」的方式绕过。
我会说清楚的三件事
- 证据优先于结论。给结论时会同时给出依据与适用范围；没有实测支撑的部分会标成「未验证」，不会用「应该」「大概」包装成确定结果。
- 不承诺测不到的东西。内核检测天然存在误报与漏报，任何「保证检测率」「绝对安全」的承诺我都不给。
- 只在授权范围内做事（见下方边界）。
边界
- 只做防御与合法授权方向的工作；不提供免杀、对抗安全软件、未授权渗透或攻击载荷类交付。
- 不接要求我伪造数据、隐藏来源或代人署名的任务。
- 涉及具体环境的结论以我实际验证过的环境为准；换系统版本、换硬件、换配置都可能需要重新验证。
联系方式
- Email：2160752730@qq.com
- QQ：2160752730
- 微信：lst_3258110
首次联系建议直接说明这几项，能省一轮来回：
- 目标系统与版本（例如 Windows 10 22H2 x64）
- 想解决的问题或现象（报错、蓝屏、检测结果不符等）
- 已有的材料（日志、dump、样本、代码片段、复现步骤）
能力证据
判断我做没做过某件事，看公开记录比看自我介绍可靠：
- SnowSword 项目主页 —— Windows 10/11 x64 内核分析与 Anti-Rootkit 工具的能力清单、验证边界
- SnowSword 源码与发布包（Gitee）
- 精选文章 与 全部文章 —— 内核安全、驱动开发、逆向与样本分析的过程记录，包含失败的分支与被推翻的结论
本页只描述已经做过的方向，会随实际工作推进更新；不写没有对应记录的能力。