RHI图形API检测实现原理PE二进制扫描如何精确识别dxgi.dll与d3d9.dll【免费下载链接】RHIReShade HDR Installer项目地址: https://gitcode.com/gh_mirrors/rhi/RHIRHIReShade HDR Installer是一款一站式游戏 HDR 与 ReShade 管理工具其核心能力之一是图形API检测通过 PE 二进制扫描读取游戏可执行文件的导入表自动识别游戏使用的是 d3d9.dll、d3d11.dll 还是 dxgi.dllDX12等图形接口从而为 ReShade 自动命名并注入正确的 DLL。本文深入解析 RHI 图形API检测的实现原理带你了解它是如何只读取不到 70KB 的文件内容就精准判断出每款游戏的图形API。如上图所示RHI 在游戏卡片上直接标注了检测到的图形API徽章如 DX11/12 · 64-bit——这正是 PE 扫描与架构识别结果的综合呈现。 为什么必须先搞清楚游戏的图形APIReShade 的工作方式是同名替换它把自己的核心库命名为游戏正在加载的图形接口 DLL让游戏在不知情的情况下加载增强库。不同 API 对应完全不同的注入目标检测到的APIReShade 注入的 DLLDX9d3d9.dlld3d9.dllDX10/11/12dxgi.dll / d3d11.dlldxgi.dllOpenGLopengl32.dllVulkan隐式层implicit layer判断错一个字母注入就会失败。因此 RHI 的 README.md 中将其描述为Detects each games graphics API via PE binary scanning and names the DLL correctly —dxgi.dll,d3d9.dll,opengl32.dll— automatically。核心实现位于 GraphicsApiDetector.cs它不依赖任何 PE 解析库而是手工解析二进制头——这保证了零依赖、极速且对超大 UE5 可执行文件同样有效。 PE 文件速览图形API信息藏在哪里Windows 可执行文件是 PEPortable Executable格式RHI 只关心其中几个关键位置DOS 头文件前 2 字节必须是MZ魔数e_lfanew偏移0x3C处的 4 字节整数指向真正 PE 头的偏移PE 签名PE\0\0其后是 COFF 头与可选头数据目录可选头内第 1 项是导入表目录第 13 项是延迟导入表目录各存一个 RVA相对虚拟地址节表紧随可选头每节 40 字节提供虚拟地址 ↔ 文件偏移的换算依据。游戏依赖哪些系统库记录在导入表中——d3d9.dll、dxgi.dll 这些名字就躺在里面。 两阶段 PE 扫描RHI 的核心算法完整流程见 GraphicsApiDetector.cs#L124-L321分为两个阶段第一阶段读 4KB 头部定位导入表RHI 一次性读取文件前 4096 字节L14足以容纳 DOS 头 PE 头 节表依次校验MZ签名L137-L155、根据PE32 (0x10B)或PE32 (0x20B)魔术数计算导入表目录的偏移并解析节表建立 RVA→文件偏移映射RvaToFileOffset。第二阶段遍历导入描述符匹配图形APISeek到导入表文件位置最多再读 64KB覆盖超大 UE5 可执行文件的导入区逐个遍历 20 字节的IMAGE_IMPORT_DESCRIPTOR项L220-L253取出每个项的 DLL 名称 RVA按节表换算成文件偏移后读出字符串再查映射表导入的 DLL识别为APId3d9.dllDirectX 9d3d11.dllDirectX 11d3d12.dllDirectX 12vulkan-1.dllVulkanopengl32.dllOpenGL映射与优先级定义见 DllMap 与 PriorityDX12 Vulkan DX11 DX10 OpenGL DX9 DX8多命中时取最高优先级。⭐ 关键设计为什么 dxgi.dll 要被单独伺候这是整个检测器最精妙的部分。dxgi.dll是 DXGI 图形工厂接口DX10/11/12 都依赖它创建设备——但问题在于许多 DX12 游戏只导入 dxgi.dll根本不导入 d3d12.dll设备创建走 DXGI 工厂完成。RHI 的解法L236-L259遍历中遇到dxgi.dll只置位importsDxgi标记不直接定 API若普通导入表里没有d3d11 或更高版本且发现了 dxgi.dll →推断为 DX12若已找到明确的 d3d11/d3d12则 dxgi 标记不参与决策。另外还处理了延迟导入表L261-L294UE4/UE5 游戏常用__delayLoadHelper延迟加载 d3d12.dllRHI 会扫描 32 字节的延迟导入描述符补全信息。但这条路径有个防误判护栏——只有当普通导入中没有明确 d3d11 时才启用否则会把默认 DX11 但可选 DX12的 UE4 游戏错误地提升为 DX12。至于 d3d9.dll 这类老 API命中即定 DX9RHI 随后会基于此自动推荐 DXVK Lilium 路线为老游戏开启 HDR。 从单一API到API集合双接口游戏怎么办《博德之门 3》这类游戏会同时提供 DirectX 与 Vulkan 两个可执行文件。为此 RHI 提供了 DetectAllApis对安装目录及常见子目录Binaries/Win64等内的所有exe 做 PE 扫描取结果并集MainViewModel.GameMatching.cs#L531-L602再由 GetMultiLabel 生成展示标签——原生双接口显示为DX11/12 / VLKDXVK 转译的 DX9 游戏显示为DX9 / VLK。检测结果最终以 GraphicsApiLabel 属性呈现到游戏卡片上。 多级回退与缓存又快又稳的检测流水线单靠 PE 扫描不够MainViewModel.GameMatching.cs 中编排了一条完整决策链优先级从高到低用户手动覆盖→manifest 覆盖manifest.json 的GraphicsApiOverrides支持DX12, VLK形式WindowsApps 特判Xbox 商店目录无读取权限改按引擎类型推断UE5 → DX12、RE Engine → DX12、Unity/UE4 → DX11Unity 特判优先读_Data/boot.config中的gfx-device-typeDetectUnityFromBootConfig17→DX11、18→DX12、21→Vulkan缺省 DX11游戏级缓存命中则直接返回D3D12Core.dll 预扫描Agility SDK 的存在是 DX12 的铁证尤其针对运行时用LoadLibrary动态加载 D3D12 的 RE Engine 游戏L399-L410PE 扫描主 exeFindGameExe 取目录中最大的.exe排除启动器等小文件DLL 兜底扫描自定义引擎常把图形调用放在引擎 DLL 里跳过系统库与游戏自带 dxgi.dll 后逐个扫描OpenGL 修正Unity/Unreal/RE 会把 opengl32.dll 作为回退静态链接此时修正为 DX11L482-L487。性能上检测结果以路径 最后写入时间为键缓存到内存与%LOCALAPPDATA%\RHI\api_cache.jsonL18-L28——游戏一更新缓存自动失效无需手工维护。✅ 小结RHI 的图形API检测是一套最小读取 多信号融合的工程4KB 头部校验 → 导入表精确匹配 → dxgi.dll 智能推断 → 延迟导入补漏 → 文件级回退 → 时间戳缓存。整套流程不加载整个 exe、不依赖第三方库却能把 DX9 老游戏、DX12 新游戏与 Vulkan 双接口游戏区分得明明白白——这正是 ReShade 注入一次成功的底层保障。 相关源码导航核心扫描器RenoDXCommander/Services/GraphicsApiDetector.csexe 定位与架构识别RenoDXCommander/Services/PeHeaderService.cs检测编排与回退策略RenoDXCommander/ViewModels/MainViewModel.GameMatching.csAPI 枚举定义RenoDXCommander/Models/GraphicsApiType.cs覆盖规则数据manifest.json更多功能说明docs/WHAT_IS_RHI.md【免费下载链接】RHIReShade HDR Installer项目地址: https://gitcode.com/gh_mirrors/rhi/RHI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
RHI图形API检测实现原理PE二进制扫描如何精确识别dxgi.dll与d3d9.dll【免费下载链接】RHIReShade HDR Installer项目地址: https://gitcode.com/gh_mirrors/rhi/RHIRHIReShade HDR Installer是一款一站式游戏 HDR 与 ReShade 管理工具其核心能力之一是图形API检测通过 PE 二进制扫描读取游戏可执行文件的导入表自动识别游戏使用的是 d3d9.dll、d3d11.dll 还是 dxgi.dllDX12等图形接口从而为 ReShade 自动命名并注入正确的 DLL。本文深入解析 RHI 图形API检测的实现原理带你了解它是如何只读取不到 70KB 的文件内容就精准判断出每款游戏的图形API。如上图所示RHI 在游戏卡片上直接标注了检测到的图形API徽章如 DX11/12 · 64-bit——这正是 PE 扫描与架构识别结果的综合呈现。 为什么必须先搞清楚游戏的图形APIReShade 的工作方式是同名替换它把自己的核心库命名为游戏正在加载的图形接口 DLL让游戏在不知情的情况下加载增强库。不同 API 对应完全不同的注入目标检测到的APIReShade 注入的 DLLDX9d3d9.dlld3d9.dllDX10/11/12dxgi.dll / d3d11.dlldxgi.dllOpenGLopengl32.dllVulkan隐式层implicit layer判断错一个字母注入就会失败。因此 RHI 的 README.md 中将其描述为Detects each games graphics API via PE binary scanning and names the DLL correctly —dxgi.dll,d3d9.dll,opengl32.dll— automatically。核心实现位于 GraphicsApiDetector.cs它不依赖任何 PE 解析库而是手工解析二进制头——这保证了零依赖、极速且对超大 UE5 可执行文件同样有效。 PE 文件速览图形API信息藏在哪里Windows 可执行文件是 PEPortable Executable格式RHI 只关心其中几个关键位置DOS 头文件前 2 字节必须是MZ魔数e_lfanew偏移0x3C处的 4 字节整数指向真正 PE 头的偏移PE 签名PE\0\0其后是 COFF 头与可选头数据目录可选头内第 1 项是导入表目录第 13 项是延迟导入表目录各存一个 RVA相对虚拟地址节表紧随可选头每节 40 字节提供虚拟地址 ↔ 文件偏移的换算依据。游戏依赖哪些系统库记录在导入表中——d3d9.dll、dxgi.dll 这些名字就躺在里面。 两阶段 PE 扫描RHI 的核心算法完整流程见 GraphicsApiDetector.cs#L124-L321分为两个阶段第一阶段读 4KB 头部定位导入表RHI 一次性读取文件前 4096 字节L14足以容纳 DOS 头 PE 头 节表依次校验MZ签名L137-L155、根据PE32 (0x10B)或PE32 (0x20B)魔术数计算导入表目录的偏移并解析节表建立 RVA→文件偏移映射RvaToFileOffset。第二阶段遍历导入描述符匹配图形APISeek到导入表文件位置最多再读 64KB覆盖超大 UE5 可执行文件的导入区逐个遍历 20 字节的IMAGE_IMPORT_DESCRIPTOR项L220-L253取出每个项的 DLL 名称 RVA按节表换算成文件偏移后读出字符串再查映射表导入的 DLL识别为APId3d9.dllDirectX 9d3d11.dllDirectX 11d3d12.dllDirectX 12vulkan-1.dllVulkanopengl32.dllOpenGL映射与优先级定义见 DllMap 与 PriorityDX12 Vulkan DX11 DX10 OpenGL DX9 DX8多命中时取最高优先级。⭐ 关键设计为什么 dxgi.dll 要被单独伺候这是整个检测器最精妙的部分。dxgi.dll是 DXGI 图形工厂接口DX10/11/12 都依赖它创建设备——但问题在于许多 DX12 游戏只导入 dxgi.dll根本不导入 d3d12.dll设备创建走 DXGI 工厂完成。RHI 的解法L236-L259遍历中遇到dxgi.dll只置位importsDxgi标记不直接定 API若普通导入表里没有d3d11 或更高版本且发现了 dxgi.dll →推断为 DX12若已找到明确的 d3d11/d3d12则 dxgi 标记不参与决策。另外还处理了延迟导入表L261-L294UE4/UE5 游戏常用__delayLoadHelper延迟加载 d3d12.dllRHI 会扫描 32 字节的延迟导入描述符补全信息。但这条路径有个防误判护栏——只有当普通导入中没有明确 d3d11 时才启用否则会把默认 DX11 但可选 DX12的 UE4 游戏错误地提升为 DX12。至于 d3d9.dll 这类老 API命中即定 DX9RHI 随后会基于此自动推荐 DXVK Lilium 路线为老游戏开启 HDR。 从单一API到API集合双接口游戏怎么办《博德之门 3》这类游戏会同时提供 DirectX 与 Vulkan 两个可执行文件。为此 RHI 提供了 DetectAllApis对安装目录及常见子目录Binaries/Win64等内的所有exe 做 PE 扫描取结果并集MainViewModel.GameMatching.cs#L531-L602再由 GetMultiLabel 生成展示标签——原生双接口显示为DX11/12 / VLKDXVK 转译的 DX9 游戏显示为DX9 / VLK。检测结果最终以 GraphicsApiLabel 属性呈现到游戏卡片上。 多级回退与缓存又快又稳的检测流水线单靠 PE 扫描不够MainViewModel.GameMatching.cs 中编排了一条完整决策链优先级从高到低用户手动覆盖→manifest 覆盖manifest.json 的GraphicsApiOverrides支持DX12, VLK形式WindowsApps 特判Xbox 商店目录无读取权限改按引擎类型推断UE5 → DX12、RE Engine → DX12、Unity/UE4 → DX11Unity 特判优先读_Data/boot.config中的gfx-device-typeDetectUnityFromBootConfig17→DX11、18→DX12、21→Vulkan缺省 DX11游戏级缓存命中则直接返回D3D12Core.dll 预扫描Agility SDK 的存在是 DX12 的铁证尤其针对运行时用LoadLibrary动态加载 D3D12 的 RE Engine 游戏L399-L410PE 扫描主 exeFindGameExe 取目录中最大的.exe排除启动器等小文件DLL 兜底扫描自定义引擎常把图形调用放在引擎 DLL 里跳过系统库与游戏自带 dxgi.dll 后逐个扫描OpenGL 修正Unity/Unreal/RE 会把 opengl32.dll 作为回退静态链接此时修正为 DX11L482-L487。性能上检测结果以路径 最后写入时间为键缓存到内存与%LOCALAPPDATA%\RHI\api_cache.jsonL18-L28——游戏一更新缓存自动失效无需手工维护。✅ 小结RHI 的图形API检测是一套最小读取 多信号融合的工程4KB 头部校验 → 导入表精确匹配 → dxgi.dll 智能推断 → 延迟导入补漏 → 文件级回退 → 时间戳缓存。整套流程不加载整个 exe、不依赖第三方库却能把 DX9 老游戏、DX12 新游戏与 Vulkan 双接口游戏区分得明明白白——这正是 ReShade 注入一次成功的底层保障。 相关源码导航核心扫描器RenoDXCommander/Services/GraphicsApiDetector.csexe 定位与架构识别RenoDXCommander/Services/PeHeaderService.cs检测编排与回退策略RenoDXCommander/ViewModels/MainViewModel.GameMatching.csAPI 枚举定义RenoDXCommander/Models/GraphicsApiType.cs覆盖规则数据manifest.json更多功能说明docs/WHAT_IS_RHI.md【免费下载链接】RHIReShade HDR Installer项目地址: https://gitcode.com/gh_mirrors/rhi/RHI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
