简介：本资源是一份面向计算机爱好者与初级系统维护人员的硬件信息伪装技术实操指南，聚焦于通过修改系统底层资源实现右键属性、dxdiag及设备管理器中CPU、内存、显卡等关键硬件参数的可视化伪造，常用于教学演示、安全意识警示或趣味实验场景。PDF文档共1个文件，大小为1010KB，内容完整覆盖reshacker修改系统属性对话框、eXeScope汉化版篡改dxdiag资源字符串、注册表编辑器调整设备管理器显示信息三大核心操作路径，并附详细坐标定位、控件插入与权限配置说明。文中特别强调此类修改仅改变界面显示值，不提升真实性能，且明确提醒读者：检测硬件应以BIOS或专业检测工具为准，避免被虚假信息误导。目前已有150人学习下载，适合对Windows资源结构、PE文件编辑及系统信息呈现机制感兴趣的实践者深入研读。

1. 修改系统属性里“我的电脑”右键显示的 CPU 和内存信息：这不是硬件升级，而是资源层的视觉欺骗

你有没有在二手交易群看到过这样一台“神机”：右键“我的电脑”→“属性”，赫然写着“Intel(R) Xeon(R) Platinum 8380 @ 2.30GHz，128GB DDR4 ECC 内存”——但实际拆机发现是赛扬 N4020 + 4GB 焊死内存？这不是玄学，是 Windows 资源节（Resource Section）被手工篡改后的典型效果。这篇笔记讲的，就是如何用不到 1MB 的 ResHacker、eXeScope 汉化版这类 PE 资源编辑器，精准定位并覆盖shell32.dll、dxdiag.exe、devmgmt.msc后台调用的字符串资源与对话框控件，让系统属性页、DirectX 诊断工具、设备管理器中显示的 CPU 型号、内存容量、显卡芯片等字段全部“按需定制”。它不改变真实硬件，不提升性能，但能骗过 95% 仅靠右键查配置的用户。适用场景非常明确：教学演示（比如信息安全课讲“信息可信度陷阱”）、内部测试环境伪装高配终端、OEM 定制预装界面——绝不可用于商业欺诈或绕过软件授权检测。本文所有操作均基于 Windows XP SP3 / Windows 7 x64 环境实测，不兼容 Windows 10/11 的现代签名强制机制，也不涉及任何驱动级 Hook 或内核 Patch。

2. 修改“我的电脑”右键属性页：从定位 dialog 资源到重写 label 控件 caption

Windows 系统属性页（即右键“我的电脑”→“属性”弹出的窗口）并非动态生成，而是由shell32.dll中编号为101的对话框模板（Dialog Resource）静态加载。ResHacker 是最轻量、最直接的编辑工具，它能绕过资源编译链，直接读写 PE 文件的.rsrc节。下面步骤全部基于 ResHacker v2.6a 汉化版（无数字签名，需关闭 UAC 或以管理员身份运行）。

2.1 定位 shell32.dll 中的 101 对话框及 CPU/内存字段坐标

提示：shell32.dll位于C:\Windows\System32\（64 位系统下 32 位程序需访问SysWOW64\）。操作前务必备份原文件（如shell32.dll.bak），否则系统可能无法启动。

# 步骤 1：用 ResHacker 打开 shell32.dll # 步骤 2：左侧树形菜单展开 → Dialog → 101 → 右侧双击 2052（中文语言 ID） # 步骤 3：此时右侧显示系统属性对话框可视化布局，注意状态栏显示 "Dialog: 101, Control: 2052"

此时你会看到一个灰色底色的对话框预览图。关键不是看整体，而是找文字控件（Static Text / Label）的位置。根据原文描述和实测，CPU 和内存信息通常位于对话框底部区域，坐标（X, Y）集中在(141, 181)到(141, 203)区间。ResHacker 不直接显示像素坐标，但可通过以下方式精确定位：

• 在对话框预览区右键 → Insert Control → Static Text，新建一个临时 label；
• 拖动该 label 至预估位置（如(141, 181)），观察其属性面板中的X,Y,Width,Height数值；
• 若与原文描述一致（如X=141, Y=181, Width=200），说明此处正是原始 CPU 字符串所在控件。

2.2 删除原始控件并注入伪造 label

原文说“点击右下角灰色条纹，按 Del 全部删除”，这实际是指删除对话框中所有已存在的 Static Text 控件——它们是系统硬编码的只读文本块，不删掉就无法覆盖。操作逻辑如下：

# 步骤 1：在 ResHacker 对话框预览区，用鼠标框选所有灰色文字区域（通常是底部三行） # 步骤 2：右键 → Delete Control（不是 Delete 键，是菜单项！） # 步骤 3：确认删除后，对话框底部变为空白 # 步骤 4：右键 → Insert Control → Static Text（第一个选项） # 步骤 5：在属性面板中设置： # - X = 141 # - Y = 181 # - Width = 200 # - Height = 12 # - Caption = "Intel(R) Core(TM) i9-14900KS @ 6.00GHz" # 步骤 6：再插入第二个 Static Text： # - X = 141 # - Y = 192 # - Width = 200 # - Height = 12 # - Caption = "128 GB DDR5 6000 MT/s" # 步骤 7：保存修改：File → Compile Script → Save File

参数说明：Caption是唯一需要人工填写的字段，它将直接显示在属性页上；X/Y决定文字起始位置，必须与原始控件对齐，否则会错位或被遮挡；Width影响文字换行，过小会导致截断（如"Intel(R) Core(TM) i9-14900KS @ 6.00GHz"至少需Width=280）；Height=12是标准单行文本高度，勿随意增大，否则会压住下方“正版验证”按钮。

2.3 验证修改是否生效：重启资源管理器而非重启系统

修改shell32.dll后，不能直接双击“我的电脑”查看效果——因为explorer.exe已将该 DLL 加载进内存。必须强制刷新资源句柄：

# 以管理员身份运行 PowerShell taskkill /f /im explorer.exe start explorer.exe

此时右键“我的电脑”→“属性”，底部 CPU 和内存行应立即显示你填入的伪造字符串。若仍显示旧信息，说明：

• shell32.dll未正确保存（检查 ResHacker 是否提示“Compile successful”）；
• 操作的是SysWOW64\shell32.dll（32 位程序）但当前是 64 位系统，应同步修改System32\shell32.dll；
• Windows 文件保护（WFP）已自动还原原文件（见第 4 章避坑）。

3. 修改 dxdiag.exe 中的 CPU、内存、显卡信息：定位字符串表与对话框控件联动

dxdiag.exe是 DirectX 诊断工具，其硬件信息页同样依赖资源节，但结构比shell32.dll更复杂：CPU、内存、显卡信息分属不同对话框（Dialog），且部分字段由字符串表（String Table）动态填充。eXeScope 汉化版比 ResHacker 更擅长处理这种多层级资源映射。

3.1 用 eXeScope 定位 dxdiag.exe 的中文资源节点

eXeScope 的优势在于能同时展开“对话框”和“字符串表”，并支持跨资源引用追踪。操作流程如下：

# 步骤 1：用 eXeScope 打开 C:\Windows\System32\dxdiag.exe # 步骤 2：左侧树形菜单展开 → Resources → Dialog → 101（主诊断页） # 步骤 3：双击 101 → 查看右侧预览，找到 "Processor" 标题栏（原文称“处理器”） # 步骤 4：右键该标题 → Properties → 记录其 ID（如 1001），这是控件 ID，非字符串 ID # 步骤 5：左侧切换至 Resources → String Table → 查找包含 "Processor" 的字符串（ID 通常为 101~200 区间） # 步骤 6：双击该字符串，修改内容为 "AMD Ryzen Threadripper PRO 7995WX"

关键逻辑：dxdiag.exe中“处理器”标题下的具体型号，并非直接写在 Dialog 控件里，而是通过控件的Control ID关联到String Table中对应 ID 的字符串。例如，控件 ID1001可能指向字符串表 ID150，而150的值就是"Intel(R) Core(TM) i7-10875H"。因此，必须先改字符串表，再确保 Dialog 控件正确引用它。

3.2 修改内存与页面文件信息：同步调整两个资源节点

内存信息在dxdiag.exe中分为两部分：“Installed Memory”（物理内存）和“Page File”（页面文件），它们位于同一对话框（101）但不同控件 ID：

修改步骤：

1. 在String Table中找到 ID151和152，双击修改其值；
2. 返回Dialog → 101，确认控件 ID1002和1003的Text属性为空（表示它将从字符串表取值）；
3. 若控件Text非空（如"16.0 GB"），则需清空该字段，否则会覆盖字符串表内容；
4. 保存：File → Save File。

3.3 修改显卡（VGA）信息：四字段联动与芯片类型陷阱

显卡信息是dxdiag.exe中最易翻车的部分，因为“名称”、“制造商”、“芯片类型”、“估计内存总数”四个字段分别由不同控件 ID 引用不同字符串 ID，且存在硬编码逻辑：

• “名称”（Name）控件 ID1004→ 字符串 ID153
• “制造商”（Manufacturer）控件 ID1005→ 字符串 ID154
• “芯片类型”（Chip Type）控件 ID1006→ 字符串 ID155
• “估计内存总数”（Approx. Total Memory）控件 ID1007→ 字符串 ID156

血泪经验：dxdiag.exe会校验“芯片类型”与“制造商”的语义一致性。若字符串 ID154改为"NVIDIA"，但155仍为"AMD Radeon RX 6900 XT"，dxdiag 启动时会报错崩溃。必须同步修改：

• 154→"NVIDIA"
• 155→"GeForce RTX 4090"
• 156→"24576 MB"

修改后，运行dxdiag.exe，切换到“显示”页，所有字段应完整显示伪造信息。若某字段空白，说明该控件 ID 未正确关联字符串 ID，需返回 eXeScope 检查Dialog → 101中对应控件的Text属性是否为空。

4. 修改设备管理器中的硬件信息：注册表 + OEM INI 双轨方案

设备管理器（devmgmt.msc）显示的硬件信息，一部分来自 PnP 枚举（真实硬件），一部分来自注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\下的DeviceDesc、Mfg等键值，还有一部分由 OEM 信息文件（oeminfo.ini+oemlogo.bmp）驱动。这里提供两种互备方案。

4.1 注册表直改法：定位 PCI 设备的 DeviceDesc 键值

设备管理器中 CPU 和显卡的显示名，本质是注册表中对应设备实例的DeviceDesc字符串值。以 Intel CPU 为例：

# 打开 regedit，导航至： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\ACPI0007\00000000 # 右侧找到 DeviceDesc 字符串值，双击修改为： "Intel(R) Core(TM) i9-14900K (24 Cores, 32 Threads)"

但此法有严重局限：ACPI0007是通用 CPU 枚举名，不同主板厂商可能用ACPI\INT3400或ACPI\PNP0A03，需逐个排查。更可靠的是定位显卡：

# 导航至： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\VEN_10DE&DEV_2206&SUBSYS_145B1043&REV_A1\4&299ccbfa&0&0008 # 此路径中 VEN_10DE= NVIDIA, DEV_2206= RTX 4090, SUBSYS=子系统 ID # 修改右侧 DeviceDesc 为："NVIDIA GeForce RTX 4090 24GB GDDR6X" # 修改 Mfg 为："NVIDIA Corporation"

注意：路径中的4&299ccbfa&0&0008是设备实例 ID，每次硬件变更（如插拔显卡）都会变化。因此，必须先在设备管理器中右键目标设备 → 属性 → 详细信息 → 属性下拉选“硬件 Id”，复制PCI\VEN_...全路径，再粘贴到 regedit 地址栏。

4.2 OEM INI 文件法：覆盖系统属性页的“技术支持”区域

这才是原文重点——通过oeminfo.ini和oemlogo.bmp伪造整个 OEM 信息区，影响“我的电脑”属性页底部的“技术支持”模块。此法无需修改系统 DLL，兼容性更好：

; 创建 oeminfo.ini 文件，内容如下（UTF-8 编码，无 BOM） [General] Manufacturer=QuantumCore Labs Model=QCL-PRO-9000 [Support Information] Line1="24-Core QuantumCore CPU @ 8.0 GHz" Line2="512 GB HBM3 Memory, 128-bit Bus" Line3="QuantumCore OS v1.0 (Build 9000)"

# 保存为 C:\Windows\System32\oeminfo.ini # 同时准备一张 180x110 像素 BMP 图片，命名为 oemlogo.bmp # 保存为 C:\Windows\System32\oemlogo.bmp

参数说明：Line1~Line3最多支持 5 行，每行长度建议 ≤ 50 字符，超长会被截断；Manufacturer和Model会显示在属性页顶部“系统”区域；oemlogo.bmp必须为 24 位 BMP，无压缩，否则显示为黑块。

修改后，重启资源管理器，打开“我的电脑”属性页，底部将出现你定义的三行技术支持信息，与顶部伪造的 CPU/内存形成完整欺骗链。

5. 避坑：Windows 文件保护、UAC 权限、DLL 签名失效的五大翻车现场

这类资源修改操作看似简单，实则踩坑率极高。以下是我在 12 台不同品牌、不同 Windows 版本机器上实测总结的 5 个高频问题，每个都附带可复现的现象、根因分析和一招解决法。

5.1 现象：ResHacker 保存后，重启系统，“我的电脑”属性页恢复原样

原因：Windows 文件保护（WFP）或 Windows 资源保护（WRP）机制检测到shell32.dll被篡改，自动从C:\Windows\System32\dllcache\或 Windows Update 缓存中还原原始文件。
解决：

• 临时禁用 WFP：以管理员身份运行cmd，执行net stop wuauserv && net stop cryptsvc && ren C:\Windows\System32\dllcache dllcache.bak；
• 修改完shell32.dll后，不要重启，立即执行sfc /scannow并忽略警告（它会报“受保护资源损坏”，但此时你已掌控）；
• 最终方案：将修改后的shell32.dll复制到C:\Windows\WinSxS\下对应版本文件夹（如amd64_microsoft-windows-shell32_31bf3856ad364e35_6.1.7601.17514_none_0c64b5d6e555e31d\），覆盖同名文件。

5.2 现象：eXeScope 修改 dxdiag.exe 后，双击运行直接闪退

原因：dxdiag.exe启动时会校验自身数字签名，篡改资源节后签名失效，触发 Windows SmartScreen 或 Authenticode 拒绝加载。
解决：

• 下载并安装 signtool.exe （Windows SDK 组件）；
• 用无效证书重新签名：signtool sign /v /a /s MY /n "DummyCert" /t http://timestamp.digicert.com dxdiag.exe；
• 或更简单：在dxdiag.exe属性 → 兼容性 → 勾选“以兼容模式运行这个程序（Windows XP SP3）”，可绕过部分签名检查。

5.3 现象：设备管理器中显卡名称改了，但“详细信息”页里 Hardware ID 还是真实 VID/PID

原因：DeviceDesc是显示名，HardwareID是底层枚举值，由 ACPI 表或 PCI 配置空间决定，无法通过注册表伪造。
解决：

• 明确告知用户：设备管理器“名称”可伪，“硬件 ID”不可伪；
• 若需彻底隐藏真实硬件，唯一办法是卸载原驱动，安装一个完全无关的假驱动（如用devcon.exe安装null.sys），但这会导致设备功能丧失，仅适用于纯演示。

5.4 现象：oeminfo.ini 生效了，但 oemlogo.bmp 显示为黑块或拉伸变形

原因：oemlogo.bmp必须是 24 位、无压缩、精确 180×110 像素，且 Windows 会强制将其转换为 16 色图标格式。常见错误是用 Photoshop 保存时勾选了“ICC 配置文件”或“Alpha 通道”。
解决：

• 用 Windows 自带的Paint打开图片 → “文件”→“另存为”→ 选择“24 位位图 (*.bmp)”→ 确保“颜色”下拉为“24 位”→ 取消勾选“保存缩略图”；
• 用IrfanView批量转换：Options → Properties → Change Color Depth → 24 bpp。

5.5 现象：所有修改完成，但普通用户登录后看不到伪造信息，管理员登录才显示

原因：shell32.dll和dxdiag.exe是系统级 DLL，普通用户无权写入System32目录，修改操作必须在管理员权限下进行，且文件所有权需归属TrustedInstaller。
解决：

• 修改前，在C:\Windows\System32\右键shell32.dll→ 属性 → 安全 → 高级 → 更改所有者为当前管理员；
• 勾选“替换子容器和对象的所有者”；
• 回到安全页，给当前用户添加“完全控制”权限；
• 修改完成后，务必恢复所有者为NT SERVICE\TrustedInstaller，否则系统更新会失败。

6. 验证与反制：用命令行工具交叉比对，揪出所有伪造痕迹

修改完成只是第一步，真正体现工程师素养的是：如何快速验证哪些字段被改了，哪些还是真实的？我习惯用一套“三线比对法”，5 分钟内完成全链路审计。

6.1 第一线：wmic 命令直取硬件真实值（绕过所有 UI 层）

wmic是 Windows Management Instrumentation 的命令行接口，它读取的是 WMI 库中的硬件数据，不受 DLL 资源篡改影响：

# 获取真实 CPU 型号（非属性页显示值） wmic cpu get name # 输出示例：Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz # 获取真实物理内存总量（单位：字节） wmic memorychip get capacity # 输出示例：8589934592 → 8 GB # 获取真实显卡芯片（非 dxdiag 显示值） wmic path win32_videocontroller get name # 输出示例：Intel(R) UHD Graphics 620

技巧：将以上三条命令保存为verify.bat，双击运行，结果会清晰列出真实硬件，与右键属性页并排对比，一眼识破。

6.2 第二线：PowerShell WMI 查询 + 注册表快照比对

Get-WmiObject比wmic更灵活，可导出为 CSV 便于分析：

# 导出真实 CPU 信息到 csv Get-WmiObject Win32_Processor | Select-Object Name,NumberOfCores,MaxClockSpeed | Export-Csv -Path C:\cpu_real.csv -NoTypeInformation # 导出真实内存信息 Get-WmiObject Win32_PhysicalMemory | Select-Object Capacity,Speed,Manufacturer | Export-Csv -Path C:\ram_real.csv -NoTypeInformation # 检查 oeminfo.ini 是否被加载（注册表键存在即生效） if (Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation") { Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation" | fl Manufacturer,Model,SupportHours }

6.3 第三线：二进制 diff 工具定位篡改点（进阶取证）

当需要向甲方或导师证明“我确实只改了资源节，没动代码段”，用fc或Beyond Compare做二进制比对：

# 用 fc 命令行比对（Windows 自带） fc /b C:\Windows\System32\shell32.dll.bak C:\Windows\System32\shell32.dll > diff.txt # 查看 diff.txt，重点关注： # - Offset 00012340h: 00 01 → 表示在偏移 0x12340 处，原字节 0x00 被改为 0x01 # - 所有改动应集中在 .rsrc 节（资源节），而非 .text 或 .data 节

真实案例：某次帮学生做课程设计，他声称只改了dxdiag.exe的字符串，但fc显示.text节有 3 处字节变化。追查发现他误用了十六进制编辑器直接搜索替换，把0x496E74656C（"Intel" ASCII）在代码段也替换了，导致 dxdiag 解析崩溃。从此我每次交付修改包，必附一份fc /b差异报告。

从那以后我每次做这类资源修改，都强制走一遍“三线比对”：先wmic看真实值，再Get-WmiObject导出快照，最后fc /b确认改动范围。不是为了炫技，而是让每一次“视觉欺骗”都建立在可验证、可追溯、可复盘的技术诚实之上。希望帮到你。

本文还有配套的精品资源，点击获取