PE文件导入表通过OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]获取RVA和大小，需校验非零后经节表映射为FOA；Name和INT中的字符串须按\0截断，OriginalFirstThunk比FirstThunk更可靠，所有RVA须边界检查。
怎么定位PE文件的导入表（IMAGE_IMPORT_DESCRIPTOR数组）
PE文件的导入表不是固定位置，得先解析DOS头、NT头、可选头，再从OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]拿到导入表RVA和大小。这个目录项可能为空（比如纯静态链接的exe），所以读之前必须校验VirtualAddress是否非零、Size是否大于0。
拿到RVA后要转成文件偏移：用IMAGE_NT_HEADERS里的OptionalHeader.ImageBase不能直接减——它只是建议加载基址；正确做法是靠节表（IMAGE_SECTION_HEADER）做RVA→FOA映射。常见错误是硬算RVA - Section.VirtualAddress + Section.PointerToRawData却没检查RVA落在哪个节里，导致读到乱码甚至越界。
- 用
ImageNtHeader()和ImageRvaToVa()（Windows SDK）可省去手动节表遍历，但需确保传入的是映射后的内存地址，不是文件映射视图起始地址 - 若自己解析，注意节名可能被截断（8字节+null）、
VirtualSize和SizeOfRawData可能不等，取小值做边界判断更安全 - 导入表末尾以全0的
IMAGE_IMPORT_DESCRIPTOR结构结束，不能只按DataDirectory.Size循环，否则可能越界读到其他数据区
怎么从IAT/INT中提取DLL名称字符串
IMAGE_IMPORT_DESCRIPTOR里的Name字段是RVA，指向DLL名字的ASCII/UTF-8字符串（如"kernel32.dll"）。这个RVA同样要转FOA，且字符串以\0结尾——但PE规范没保证后面没垃圾字节，所以必须逐字节读直到\0，不能直接按长度memcpy。
真正容易出错的是路径处理：Name指向的只是文件名，不含路径，但有些打包工具或loader会写入相对路径（如"./lib/vcruntime140.dll"），此时字符串里含斜杠。Windows加载器本身只认文件名部分，但检测依赖时应原样保留整个字符串，否则会漏报。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要假设字符串一定是小写——实际有大写（如
"USER32.DLL"），比较DLL白名单时建议用_stricmp或std::equal配std::toupper - 某些加壳程序会把
NameRVA 指向重定位区或加密区，读出来是乱码，此时需结合FirstThunk和OriginalFirstThunk的非空性交叉验证 - 64位PE的
NameRVA 是8字节对齐，32位是4字节，用sizeof(ULONG_PTR)动态判断更稳妥
为什么OriginalFirstThunk比FirstThunk更可靠
导入表里有两个并行的函数指针数组：运行时用的FirstThunk（IAT），和编译时存的OriginalFirstThunk（INT）。前者在ASLR启用或DLL重定位后会被系统覆写为真实函数地址，后者始终不变，存的是IMAGE_THUNK_DATA结构，低32位（或64位）是函数名称的RVA或序号。
直接读FirstThunk内容来反推函数名是危险的：如果进程已加载，IAT里全是有效地址，无法还原原始名称；如果文件未加载，IAT可能全0（取决于链接器设置）。而OriginalFirstThunk只要存在，就一定能拿到原始导入信息。
- 当
OriginalFirstThunk == 0时，退化为用FirstThunk，但此时只能认为该DLL是“延迟导入”或“绑定导入”，需单独标记 -
IMAGE_THUNK_DATA的最高位（bit 31或63）为1表示这是序号导入（如#123），此时剩余位是序号值，不是RVA，别当成指针去解引用 - 有些编译器（如MSVC /DELAYLOAD）会在导入表末尾额外加一个
IMAGE_DELAYLOAD_DESCRIPTOR，它有自己的DllNameRVA，必须单独扫描，否则漏掉延迟加载DLL
如何处理导入名称表（INT）中的函数名结构
每个函数名在INT中由IMAGE_IMPORT_BY_NAME结构表示：前2字节是Hint（提示序号，可忽略），后续是变长ASCII字符串。这个结构没有长度字段，必须靠Hint之后第一个\0确定结尾。但实际文件中，\0之后可能紧跟下一个IMAGE_IMPORT_BY_NAME，也可能有填充字节——所以不能简单按sizeof(IMAGE_IMPORT_BY_NAME)步进。
更麻烦的是Unicode支持：极少数PE（主要是驱动或旧版工具链生成）会用IMAGE_IMPORT_BY_NAME的宽字符变体，但PE规范未定义，Windows loader也不支持，检测时遇到非ASCII字节且后续无\0，大概率是损坏或混淆，应跳过该条目而非崩溃。
- 读
IMAGE_IMPORT_BY_NAME前先检查RVA是否在节范围内，避免访问未映射内存 -
Hint字段不可信——它只是链接器的优化提示，实际调用仍靠函数名字符串匹配，有些UPX加壳会故意填错Hint来干扰分析 - 函数名字符串可能含非法字符（如控制符、路径分隔符），输出时建议过滤不可见ASCII（
126），防止日志污染
实际跑通的关键在于：别信任任何单一字段，所有RVA都要做节边界检查，所有字符串都要找\0终止，所有指针都要判空。导入表结构看着线性，但PE文件里它散落在不同节、可能被对齐填充、还受加壳干扰——最稳的方式是把每个字段都当作需要独立验证的输入，而不是流程化的步骤。
