radare2 6.2.2：JNI、Swift 元数据与 CIL 分析能力补强

当天发生了什么

2026-09-06T17:32Z（UTC），radare2 发布了 6.2.2（代号 infandmore），发布说明称包含 22 位贡献者的 388 个提交。与应用分析相关的条目包括：伪代码输出支持循环、switch 和 try/catch 等结构；函数参数恢复重做，覆盖浮点参数、调用约定和变参识别；分析阶段可解析带类型的 JNI 表调用和 native 方法，并新增 JNI 分析插件；解析 DEX 异常处理器；加入 CIL（.NET）令牌解析；Mach-O 按架构切片和 UUID 匹配 dSYM，并加快了含大量 Objective-C 类文件的加载；新增通用 Swift 元数据类加载器，可从类型元数据恢复 Swift 结构体字段偏移；修复 PE64 SEH 并解析 MSVC C++ 异常区域。说明中还列出大量解析器内存安全修复。

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

这次更新集中在跨平台应用常见的“接缝”：Java/Kotlin 与 native 库之间的 JNI 边界、Swift 运行时所需的类型元数据，以及 .NET 的 CIL。一些团队会把核心逻辑挪进 .so，默认 JNI 边界能让分析变难；当免费工具能自动解析带类型的 JNI 调用，这个假设就更弱了。Swift 类型元数据在运行时本来就需要，无法完全去除，它能透露的结构信息值得单独评估。边界要说清楚：发布说明没有给出准确率数据，我们也无法判断这些改进在经过变换的二进制上效果如何。

可以做的检查

第一，盘点你自己 native 库的 JNI 入口：是按命名约定导出，还是动态注册，导出名和签名透露了多少业务含义。第二，审视发布构建中的 Swift 类型名与字段信息，确认没有把敏感含义写进类型命名。第三，确认 dSYM 和 PDB 等调试符号只保存在内部，不随发布物分发。第四，内部评估时使用当前版本的分析工具，并在隔离环境中运行，因为解析器本身也在持续修复内存安全问题。

行动清单

• 盘点自家 native 库的 JNI 导出名与签名
• 检查 Swift 类型命名是否泄露业务含义
• 确认 dSYM/PDB 不随发布物分发