原帖为PE分析小工具开发流水账（二），原帖内容已合并至PE分析小工具开发流水账一帖。

    从2025年十月份开始我决定写一个PE解析工具来练手，现在项目已开源至 Calparrot/PE-ParsingTool: 个人开发的可执行PE文件解析工具，正在推进中。，写此篇文章来总结一下这一年来开发学习中踩过的坑，以及介绍一下我的设计。

    我的设计核心是，联合性字段检测加激进防御性检测，对于联合性字段检测，简单来讲，提取字段后筛选字段关联，将其关联一条一条列举、匹配，以节区头部分字段为例：

    激进防御性检测主要在于，不因某位置错误就停止检测，不管错误的位置是否导致文件不可执行都继续检测并尽可能给出结果，例如入口点地址超了或者签名错了。不相信字段声明值，按照结构规范扫描并检验原值是否正确，例如节区实际数量与NumberOfSections的关系。

    这个有什么好处呢？和现有工具偏好不同的地方在于，每条规则可追溯，且细节清晰，结构层面难以不留痕迹绕过，相对于现在比较新的机器学习做特征检测上我觉得最好的就是白盒。现有主流开源或闭源项目里面类似项目其实偏向稳健，但激进分析挖掘信息我觉得也是有必要的。

    用户体验方面，在（我）现有（编程）水平上追求轻量、快速和无依赖，尽量不引入依赖和库。然后在我这个工具上面，可能就是说会更偏向展示过程而非结果，比如这个文件哪里出现了异常，而不是直接显示加了壳，不告诉具体为什么说文件为什么被混淆了。我认为非特征匹配式可能对未知特征会更通用，但是也牺牲了对已知特征检测上的效率问题。

    这个工具局限性很多，其实也算是静态分析局限性，一混淆或者无文件什么的就没办法处理了，尤其导入表那块。

    在这个小工具的数据结构设计上，没有涉及什么复杂算法，和处理并发或者查找那种高逻辑密度不同，处理PE文件主要是数据密度高。个人经验觉得对于这种强上下文关联的东西没必要硬拆，耦合就耦合吧，硬拆可能增加记忆复杂度，还可能使内存占用增加，因为要处理耦合的关联信息。对于上下文处理这块，个人比较喜欢约定调用，比如偏移多少就是多少，上一步做完下一步接着做，每步硬编码加检验就不会出错，而且效率也高。

    然后这一年开发来讲吧，我这个初学者踩的坑，希望和各位同学专家大佬交流交流。

    一个是调用约定问题，是类（不限类、结构体、函数等）自己管自己还是调用方管，不仅是new、delete这种，还包括比如，处理输入的文件路径，是由API管还是调用方管这种问题，写到后面非常烦，一开始规定好可以避免踩好多坑。

    变量类型问题属于容易错、但是难找的问题，比如：

for (size_t i = 1; i < n; i++) {
    int64_t j = i - 1;
    while (j >= 0) { ... }
}

这种，j 必须转无符号才行，单独贴出来感觉很傻，但是写的时候容易错。

    还有就是变量作用域问题，容易出现全局变量未刷新的问题，个人经验是每次用的时候都重新创建，全局变量就刷新。

    非常欢迎来提issue和各种批评建议！！！

[招生]科锐逆向工程师培训(2026年7月3日实地，远程教学同时开班, 第56期)！