背景
codex/wangwei-cm-all-commits-20260830 分支的 17 个提交经审查后，13 个合并进 main、3 个舍弃、1 个部分摘取，之后又追加了若干修复。这批改动全部只做了编译验证（主程序与驱动均 exit 0、零错误零告警、i18n audit 通过），下面两项需要在真机上确认。
被舍弃的 3 个提交内容仍完整保留在 codex/wangwei-cm-all-commits-20260830 及其远端副本上，可随时回看。
一、DynData 运行时偏移解析（重点）
提交： d8b680ee feat(dyndata): EpObjectTable / EpSectionObject 增加运行时解析来源
问题背景
Kernel.EpObjectTable / Kernel.EpSectionObject 此前只有 System Informer 偏移表一个填充点（dyndata_loader.c），而该表按 ntoskrnl 的 TimeDateStamp + SizeOfImage 精确匹配。实测本机内核（Win11 26H2 / 10.0.26300.9022，TimeDateStamp=0x3ABC2041、SizeOfImage=0x01450000）：
| 偏移源 |
条目数 |
覆盖本机内核 |
third_party/systeminformer_dyn SI blob |
3809（x64 ntoskrnl 1738） |
❌ |
profiles/ark_dyndata_pack_v4.json |
2070（ntoskrnl 1538，最新止于 10.0.26100.8764） |
❌ |
后果：进程列表「HandleTable」「SectionObject」两列恒为 Unavailable，句柄页也走退化路径。
ArkRuntimeDynData.cpp 顶部的产品策略明确禁止目标机运行时联符号服务器，因此补的是 feature-local 解析器，不依赖 PDB、不依赖打包 profile。
实现方式
沿用既有 EpProtection / EpSignatureLevel 的手法——反汇编导出访问器取偏移再回读校验，不做无锚点内存扫描。
- EpSectionObject：扫
PsReferenceProcessFilePointer 前 64 字节的第一条 REX.W disp32 内存加载，再要求读出的指针经 ObGetObjectType 判定为 MmSectionObjectType 对象。
- EpObjectTable：无任何导出例程返回该字段，改为以
PsGetProcessId 解出的 UniqueProcessId 偏移为锚点向后 0x600 字节受限搜索；判据是槽位指针指向的 _HANDLE_TABLE 内含等于本进程 PID 的 ULONG，且同一表内偏移在多个采样进程上同时成立。窗口内出现第二个自洽解即放弃。
需要验证
加载 R0 驱动后：
置信度说明
两者置信度不同，请分别看待：
EpSectionObject 置信度高。偏移已从本机内核字节实证解出（mov rcx,[rbx+0x2A8]），且与 PsGetProcessSectionBaseAddress 给出的 SectionBaseAddress=0x2B0 相邻 8 字节、与已知 EPROCESS 布局吻合；ObGetObjectType 判据够硬。EpObjectTable 置信度低。是启发式搜索，无法静态确认该字段落在搜索窗口内——本机 EPROCESS 布局明显被重排过（UniqueProcessId 在 0x1D0，经典 Win10 为 0x440）。
失败也是安全的：解析不出时返回 -1，字段保持不可用，与现状一致；且 StoreRuntimeOffset 只在偏移仍缺失时写入，不会覆盖打包 profile 的结果。所有跨指针读取均先经规范内核地址 + 对齐 + MmIsAddressValid 预检，再置于 __try 保护下。
相关：#175
二、合并进来的功能提交仅过编译
以下提交从分支 cherry-pick 而来，有实际副作用（写防火墙规则、删注册表键值），但交互路径未经手动验证：
三、已确认，无需重复验证
1a93cd9b + 4a997e78 — CID 扫描不再把已退出进程的残骸报成隐藏进程（幽灵行）。已实机确认修复。ad5ab287 — 内核对比默认开启（开关保留）。
背景
codex/wangwei-cm-all-commits-20260830分支的 17 个提交经审查后，13 个合并进 main、3 个舍弃、1 个部分摘取，之后又追加了若干修复。这批改动全部只做了编译验证（主程序与驱动均 exit 0、零错误零告警、i18n audit 通过），下面两项需要在真机上确认。被舍弃的 3 个提交内容仍完整保留在
codex/wangwei-cm-all-commits-20260830及其远端副本上，可随时回看。一、DynData 运行时偏移解析（重点）
提交：
d8b680eefeat(dyndata): EpObjectTable / EpSectionObject 增加运行时解析来源问题背景
Kernel.EpObjectTable/Kernel.EpSectionObject此前只有 System Informer 偏移表一个填充点（dyndata_loader.c），而该表按 ntoskrnl 的 TimeDateStamp + SizeOfImage 精确匹配。实测本机内核（Win11 26H2 / 10.0.26300.9022，TimeDateStamp=0x3ABC2041、SizeOfImage=0x01450000）：third_party/systeminformer_dynSI blobprofiles/ark_dyndata_pack_v4.json后果：进程列表「HandleTable」「SectionObject」两列恒为
Unavailable，句柄页也走退化路径。ArkRuntimeDynData.cpp顶部的产品策略明确禁止目标机运行时联符号服务器，因此补的是 feature-local 解析器，不依赖 PDB、不依赖打包 profile。实现方式
沿用既有
EpProtection/EpSignatureLevel的手法——反汇编导出访问器取偏移再回读校验，不做无锚点内存扫描。PsReferenceProcessFilePointer前 64 字节的第一条 REX.W disp32 内存加载，再要求读出的指针经ObGetObjectType判定为MmSectionObjectType对象。PsGetProcessId解出的UniqueProcessId偏移为锚点向后 0x600 字节受限搜索；判据是槽位指针指向的_HANDLE_TABLE内含等于本进程 PID 的 ULONG，且同一表内偏移在多个采样进程上同时成立。窗口内出现第二个自洽解即放弃。需要验证
加载 R0 驱动后：
EpSectionObject的来源标为 Runtime patternEpObjectTable的来源标为 Runtime patternUnavailable，显示实际地址Unavailable，显示实际地址EpObjectTable）置信度说明
两者置信度不同，请分别看待：
EpSectionObject置信度高。偏移已从本机内核字节实证解出（mov rcx,[rbx+0x2A8]），且与PsGetProcessSectionBaseAddress给出的SectionBaseAddress=0x2B0相邻 8 字节、与已知 EPROCESS 布局吻合；ObGetObjectType判据够硬。EpObjectTable置信度低。是启发式搜索，无法静态确认该字段落在搜索窗口内——本机 EPROCESS 布局明显被重排过（UniqueProcessId在 0x1D0，经典 Win10 为 0x440）。失败也是安全的：解析不出时返回 -1，字段保持不可用，与现状一致；且
StoreRuntimeOffset只在偏移仍缺失时写入，不会覆盖打包 profile 的结果。所有跨指针读取均先经规范内核地址 + 对齐 +MmIsAddressValid预检，再置于__try保护下。相关：#175
二、合并进来的功能提交仅过编译
以下提交从分支 cherry-pick 而来，有实际副作用（写防火墙规则、删注册表键值），但交互路径未经手动验证：
d74e84d6d0ae43611b8781737ee4560c0018a7af— 防火墙阻断规则预填五连（NIDS 告警 / 已核验进程身份 / 流量报文 / WFP 事件 / NSI UDP 端点）f5fe528c6882b080— 注册表搜索结果删除值 / 删除键（含子项）8a17899a+c398066d— 驱动概览拆分为「驱动服务」+「内核模块」两页（必须成对，后者撤回了前者把四个一级诊断页塞进子标签的改动）3af74c89— 虚拟位置：默认位置键不存在时不再回退 R0、不再打 Warnffbc51c4— KernelDock 表格透明样式 +openSilently2122ead5— 最大化时窗口边框裁剪56438aeb— 日志窗口刷新丢选中b657a7eb— 顶部搜索弹层只在表格搜索入口请求时展开三、已确认，无需重复验证
1a93cd9b+4a997e78— CID 扫描不再把已退出进程的残骸报成隐藏进程（幽灵行）。已实机确认修复。ad5ab287— 内核对比默认开启（开关保留）。