UCPD从注册表中加载的PE是什么？

ANY.LNK

接上篇https://bbs.kafan.cn/thread-2285219-1-1.html，原来的帖子时间太长被锁了。那个注册表里的base64解码出来后终于是一个有效的PE了。

具有微软的有效签名



简单查一下，说是驱动（本机实际为64位操作系统）



VT上说是DLL



此文件实际只有三部分，PE头，.rdata段，CERTIFICATE证书段。证书段占此PE的实际大部分。判断大概率不具备单独可执行的能力



.rdata段，很短，包括IDA，Binary Ninja等工具在内均没有给出有效可观的解析







目前怀疑这是（可能经过加密后的）配置文件

对应版本的UCPD.sys，UCPDMgr.exe，和解码后的PE：

wwwab

这个PE文件没有指定架构信息，PE文件结构IMAGE_FILE_HEADER结构体中的FileHeader_Machine是无效值，对于PE解析器来说是未知架构。
在PE签名(0x50450000)后的2个字节数据就是FileHeader_Machine
可以看到，DR0000.dll的FileHeader_Machine是0x0000，IDA Pro并不能识别该PE文件的架构类型：



作为对比，可以看一下正常的x86和AMD64 PE的FileHeader_Machine
x86 PE的FileHeader_Machine应当为0x014C

AMD64 PE的FileHeader_Machine应当为0x8664


显然易见，DR0000.dll的FileHeader_Machine为0x0000，并不包含有效的架构信息。





PE文件结构确实是SYS File

wwwab

从OptionalHeader.Subsystem标志的偏移量位置来看其实应该是AMD64的PE(System Driver)


一、核心定位结果
Subsystem 标志位（核心值）
位置：文件偏移0x114-0x115（2 字节）
原始 Hex 值：01 00（小端序，实际值为0x0001）
对应子系统：IMAGE_SUBSYSTEM_NATIVE（原生系统程序，如内核驱动、系统组件）
二、关键验证步骤（帮你核对）
先从 DOS 头 0x3C 处找到e_lfanew=0xB8，定位到 NT 头（PE 签名50 45 00 00在 0xB8-0xBB）；
跳过标准 PE 头后，可选头起始于 0xD0，Magic 字段0B 02（0xD0-0xD1）确认是64 位 PE (PE32+)；
64 位 PE 的 Subsystem 固定偏移为可选头内 0x44，计算得文件偏移0xD0+0x44=0x114；
0x114 处字节为01，0x115 为00，小端转换后值为0x0001（原生子系统）。
三、总结
Subsystem 标志位 Hex 值：01 00（文件偏移 0x114-0x115），实际子系统值为 0x0001；
该 PE 文件属于 Windows 原生系统程序（无 UI、无控制台，如驱动）。

asdfnbbj

360扫描不报

ANY.LNK

wwwab 发表于 2026-1-27 00:10
从OptionalHeader.Subsystem标志的偏移量位置来看其实应该是AMD64的PE(System Driver)

嗯，不过rdata的内容仍处于很难读的状态