[原创]Visual 层反截屏原理与 DWM 侧检测-编程技术-看雪安全社区

**窗口隐藏与反截屏系列 · 第 2 期**

工具：IDA · CE · Hawkeye · Cursor MCP
---

## 目录

1. [背景与系列规划](#1-背景与系列规划)
2. [Visual 是什么](#2-visual-是什么)
3. [跨进程 Visual 与 window_hijack](#3-不靠谱的模型跨进程-visual-与-window_hijack)
4. [CVisual 隐藏与 HasProtectedContent](#4-cvisual-隐藏与-hasprotectedcontent)
5. [开源说明](#5-开源说明)

---

## 1. 背景与系列规划

本系列共三篇，本篇为第二期：

- [第 1 期](../01-display-affinity/)：`SetWindowDisplayAffinity` 原理与检测
- **第 2 期（本文）**：Visual 层隐藏原理与检测
- [第 3 期](../03-readback-mode/)：基于 BitBlt 的「超级截屏」方案

与 DisplayAffinity 不同：Affinity的技术细节主要基于 `CWindowContext` 对象；Visual 相关技术细节在 `dwmcore` 的合成节点上（`CVisual`对象）。

---

## 2. Visual 是什么

在进入正题之前，我觉得有必要先稍微介绍下 Visual：

DWM 在 `dwm.exe` / `dwmcore.dll` 里维护一棵全局 Visual 树。树上每个 Visual(`CVisual`类) 是一个合成节点；许多 top-level 窗口在这个全局 Visual 树中对应一棵子树，子树根节点往往可关联到 `HWND`，其下子 Visual 共同描述该窗口在桌面上的画面。DWM 根据窗口 Z 序、节点层级、遮挡与各类标志，在合成阶段将这些 Visual 融合成最终桌面帧。我们所看到显示器上的画面，本质上是这棵全局 Visual 树融合取舍后的结果。

由此可见，Visual 才是 DWM 所管理的最小单位。并非窗口。

---

## 3. 不靠谱的模型：跨进程 Visual 与 window_hijack

正如上面介绍的那样，DWM 眼睛里，他管理的更多的是 Visual，即，某一个 Visual 属于哪个窗口，属于哪个进程其实并不关心。事实也是如此。基于 window_hijack 源码可以发现，某进程把自己创建的 Visual 融合到其他进程窗口这个异常行为也就是简简单单的几个判断进行阻止。判断逻辑在：

```
win32kfull!NtUserCreateDCompositionHwndTarget
  └─ TestWindowForCompositionTarget
```

一旦突破之后，系统会像没事人一般的，愉快的工作着，再也不会校验某个 Visual 是否异常。

> 其实，到这里也没啥，一个 Visual 在哪显示其实都一样。只不过，如果这个 Visual 带有反截屏技术加持，那就比较棘手了。假设你是个游戏反作弊工程师，你会很诧异，明明作弊透视方框绘制在游戏窗口上，竟始终找不到绘制源。

---

## 4. CVisual 隐藏与 HasProtectedContent

基于对 `dwmcore` 的深入研究，得出几个结论：每个 Visual 对应一个 `CVisual` 对象；`CVisual` 类派生自 `CResource` 类；`CWindowNode` 是 `CVisual` 的子类，用来表示绑定了窗口句柄的子树根节点 Visual.

基于第一期的启发，我们尝试：
 ![pic1](upload/attach/202609/1092084_AM49B2RQ4EBF2AA.webp) `!probe -find:has,protect -mod:dwmcore,dwmredir`，同名函数在 `dwmredir` 与 `dwmcore` 各有一路。

如上图，在使用 Hawkeye 联合查询的时候，不仅发现 `dwmredir` 中存在，竟然 `dwmcore` 中也存在如此抓眼球的同名函数：

- `CWindowContext::HasProtectedContent`（`dwmredir`）
- `CVisual::HasProtectedContent`（`dwmcore`）

看来微软是打算把君子坦荡荡贯彻到底了。

反汇编 `dwmcore!CVisual::HasProtectedContent` 非常直接：
 ![pic2](upload/attach/202609/1092084_APAJNBBDW3VWGE5.webp)读取 `[rcx+0x6A]`，`SHR 7` 后返回，即检测该字节的 bit 7。
根据上一期的经验，很容易会联想到 `CVisual` 对象的 `+0x6A` 偏移处，bit 7 就是关键标志位。
定位 `CVisual` 实例时，前 8 个字节理论上也应该是 `CVisual` 虚表指针（本机示例如下）：
 ![pic3](upload/attach/202609/1092084_DUVFAHDT43PE3D4.webp)`!probe -find:cvisual,vftable -mod:dwmcore`，定位 `CVisual` vftable。
此刻的虚表指针地址：`0x7FF91D4F7F78`
 ![pic4](upload/attach/202609/1092084_BC2UDFD5R5B7YEU.webp) vftable 地址在 `dwmcore.dll` 内，可用于在 DWM 堆上扫描对象。

对此地址数值 CE 中进行搜索和排查。发现 `CVisual` 对象前 8 个字节确实是其虚表指针。且偏移 `+0x6A` 处的 bit 7 为是否反截屏保护的关键标志位。

这似乎还不够，第一期中，我们得到了 PID、窗口句柄，甚至还可以得到窗口的大小（可自行挖掘）。而 Visual 这边能拿到的就比较少了（或者说如果想拿，得做好兼容工作）。

### 先说，基于 Visual 能拿到窗口句柄么？
能，正如上文介绍的那样，如果这个 Visual 就是个子树根节点，就可以直接拿。具体参考 `CVisual::GetHwnd`。如果这个 Visual 就是一个子节点，那只能手动找到父节点，直到某个父节点是子树根节点，就能直接通过 `CVisual::GetHwnd` 拿到窗口句柄。其中涉及到的兼容性问题是客观存在的。

### 基于 Visual 能拿到其所属的进程 PID 么？
可以。由于上文已经提及，`CVisual` 派生自 `CResource`，因此：
![pic5](upload/attach/202609/1092084_VJ2NFJRMG2GKKVJ.webp) `!probe -find:processid,own -mod:dwmcore`，定位 `CResource::GetOwningProcessId`。
反汇编 `dwmcore!CResource::GetOwningProcessId`：
 ![pic6](upload/attach/202609/1092084_NQHXNNWQKD6TVDG.webp)handle 在 `visual+0x38`；有效时 PID 在 `handle+0x1C`。
实现逻辑很直观。兼容性上，偏移宜从指令动态解析，不宜硬编码。

可疑 Visual 与 PID 一旦对应上，整条排查链路也就通了。

---
## 5. 开源说明
第 1 期 DisplayAffinity 检测已在 Hawkeye Community 完整开源（`!hidden_windows`）。Visual 层检测目前仍偏研究向、适用面相对较窄，对应检测思路本次暂未在 Community 开源。文中复现所需的 `!probe`、符号加载与内存分析工具仍可在 Community 获取，读者可按上文思路在本地自行验证。

系列下一篇：BitBlt 的「超级截屏」方案，已在 Hawkeye Community 开源。
- 源码仓库：github.com/hawkeye-Leo/hawkeye-community
- 预编译包：GitHub Releases（latest）

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最新回复 (1)
achenyuan 雪币： 237 活跃值： (1895) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 25 粉丝 0 关注私信	achenyuan 2 楼自己研究了下 CVisual 遍历出来的PID 大半就是dwm.exe 自己写了一个程序创建了IDCompositionVisual 合成输出但是还是遍历不出来自己的进程pid 遍历 CWindowNode 对象遍历出来了,用CWindowNode的获取pid 和 HWND 是正常的最后于 2026-9-12 23:06 被achenyuan编辑，原因： 2026-9-12 14:35 1
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复