LIEF 1.0.0：可执行文件库的 1.0 与行为变更

当天发生了什么

2026-07-12（UTC 13:55），LIEF 在 GitHub 发布了 1.0.0，更新日志标题为“1.0.0 - July 12th, 2026”。LIEF 是解析和修改 ELF、PE、Mach-O 等可执行格式的库。本次变更较多，包括：新增运行时功能；为 ELF、Mach-O、PE 增加 parse_from_dump()，可从内存转储解析；Mach-O 可写出大端二进制、可从 FAT 中选取单一架构并用 FatBinary.create() 组合 FAT，支持 LC_FUNCTION_VARIANT_FIXUPS，并修复 LC_UNIXTHREAD/LC_THREAD 后多写一个字节的问题（#1344）；PE 的 offset_to_virtual_address() 改为返回绝对虚拟地址而非 RVA（#1318）；支持 Objective-C category；Rust 最低版本升至 1.85.0；移除 Python 3.8 支持。

对保护应用逻辑意味着什么

LIEF 两边都在用：分析者用它读取二进制结构，开发团队也可能在构建后处理、打包检查或签名前修改中用到它。对后者来说，1.0 中明确标出的行为变更最需要关注，例如 PE 地址换算接口的返回值语义变了，旧脚本可能不报错却算出错误地址；Mach-O 写出修复也意味着旧版本写出的文件可能存在偏移问题。对威胁模型而言，从内存转储解析可执行格式这一能力提醒我们：只在磁盘上加密或加壳的内容，一旦加载进内存就可能以完整格式被重新解析，“静态加密”不能代替把敏感逻辑放在服务端。Objective-C category 等元数据的解析也说明，ObjC 运行时信息本身就是公开结构。

可以在自己的构建上做的检查

第一，搜索自己的构建脚本和 CI 是否依赖 LIEF；如果有，固定版本，在升级到 1.0 前对照更新日志检查 offset_to_virtual_address() 等接口的用法，并确认 Python 与 Rust 版本满足新的最低要求。第二，对任何构建后修改过的产物重新签名，并验证签名：macOS 用 codesign 与公证检查，Windows 用 Authenticode 验证。第三，比较修改前后的二进制结构，确认没有意外的段或加载命令变化。第四，盘点 Objective-C 类名、category 名和选择器中是否透露业务含义。第五，不要把“磁盘上加密”当作保护承诺写进产品说明。

行动清单

• 检查构建流水线是否依赖 LIEF 并固定版本
• 核对 PE offset_to_virtual_address() 行为变更
• 修改后重新签名并验证 codesign/Authenticode
• 不把磁盘加密当作逻辑保护承诺