REA混淆.NET程序集比较路线图官方计划中的下一步能力【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/reaREAReverse Engineer Anything是一个让 AI Agent 驱动本地逆向工程的开源工具其中.NET 程序集比较是它的核心能力之一不加载、不执行目标程序直接读取 PE/CLI 字节做跨版本成员对比。本文将带你了解 REA 混淆场景下 .NET 程序集比较的现状以及官方路线图里计划中的下一步能力。为什么 .NET 程序集比较这么难很多人以为比较两个 .NET 程序集只要“反编译再 diff”就够了。但实际使用中代码混淆会破坏这个假设方法名、类型名被改成a、b或乱码 Unicode名字完全不可信每次构建的 MVID、token 顺序、元数据布局都会变化0x06001234这类 token 在两个版本间根本不指向同一个方法声明了 P/Invoke 却可能通过反射动态解析NativeAOT 则干脆没有 CIL 方法体。因此 REA 的做法是分类先行、字节为准。先用 src/dotnet/ManagedArtifactInspector.ts 判断工件到底是普通 CIL、ReadyToRun、单文件托管还是 NativeAOT再决定分析路线而不是“看到 .NET 就选反编译器”。这套边界设计记录在 ADR-0003 中。已经上线的 7 个托管分析工具目前 REA 的 .NET 程序集比较已经具备一条完整工具链MCP 工具与 CLI 命令一一对应任务MCP 工具识别工件与托管部署形态inspect_managed_artifact检查类型、签名、方法体与 CIL 指令inspect_managed_members列出声明的本地调用边界inspect_managed_native_boundaries跨构建比较成员并映射 tokencompare_managed_members用导出的导出/函数证据核验 P/Invoke 声明verify_managed_native_boundaries导入反编译代码作为分析师推断import_managed_reconstruction将托管发现投影进应用图谱project_managed_application_graphCLI 侧只需把下划线换成连字符并加rea前缀例如rea compare-managed-members。四级匹配算法名字只是兜底compare_managed_members 的实现采用exact-signature-fallback策略匹配优先级为精确 CIL 签名身份指令与签名完全一致直接判定“未变”精确声明签名完整的方法名类型原始签名元组匹配名字只作为元组的一部分参与单独的名字永远不能配对结构化方法形状归一化签名、解码后的指令元组指纹、常量与控制流形状字段签名层字段按同样的精确层处理。无法区分的候选会明确报告为ambiguous未匹配的成员记为unknown——而不是被悄悄增删。比较结果还会区分metadata维度即使 CIL 指令完全相同MethodDef 的可见性或同步标志变化也会单独上报。完整的服务实现在 ManagedMemberComparisonService.ts。官方路线图下一步计划哪些能力在 docs/roadmap.md 的“Planned work”中“改进混淆 .NET 比较并打通托管发现与已验证原生分析之间的链接”是当前明确的开发优先级之一。结合 docs/managed-code-analysis.md计划中的能力可以分为三层1. 更强的抗混淆行为切片官方定义了一个“行为切片behavior slice”概念为验证一个命题记录最小的、有界的观测集合包括归一化签名与继承形状、框架 API 引用、精确字符串/数值常量/序列化键、分支与异常形状、调用与字段流、构造与泛型实例化点以及调用者/被调用者与竞争候选。这样即使所有名字都被混淆两个构建之间仍能靠“结构形状 常量锚点”完成比较。2. 完整归一化 CIL 承诺目前normalized_il_sha256是“解码元组指纹”还不是完整的语义 CIL 身份它不跨 MVID 解析 token也不承诺完整控制流与异常语义。路线图计划引入规范化的 token/字面量身份、完整分支与 switch 目标、显式的 locals/异常语义让跨版本比较可以建立在真正的语义等价上而不只是结构近似。3. 托管 ↔ 原生桥接映射这是与原生分析联动最期待的部分native-body 桥接把托管方法 token 映射到原生实现地址目前只允许“精确声明链接”token 永远不能当地址用ReadyToRun / C/CLI / IL2CPP在版本化映射约束下关联托管声明与 Hopper/Ghidra 的原生函数证据部署分类向量单个文件可能同时含原生宿主、普通 CIL 程序集与 ReadyToRun 组件计划为每个组件输出独立的摘要、分类与覆盖度而不是一个猜测的标签。注上图为原生分析侧截图用于说明路线图第 3 层“托管发现链接到已验证原生分析”的目标场景。4. 验证与可信度提升引入钉住版本pinned的System.Reflection.Metadata差异预言机用独立解析器交叉验证语义事实dnlib、Mono.Cecil 作为未来的差异预言机候选源码构建的抗混淆一致性语料Unicode/无意义/重复外观命名、保持结构的重命名、至少两个 MVID 与布局不同的构建、恶意截断输入等。新手上手三步完成一次构建比较 准备两个构建同一程序的两个版本比如更新前后保持原始文件不变运行比较rea compare-managed-members分别提供两侧工件路径或先rea inspect-managed-artifact确认身份解读结果关注summary的 unchanged/changed/added/removed/unknown 计数与matching中落入structural_method_shape或ambiguous的成员——在混淆场景下这些才是需要人工重点确认的部分。安装 REAgit clone https://gitcode.com/GitHub_Trending/rea2/rea cd rea npm install npm run setup值得收藏的相关资料总路线图与开发优先级docs/roadmap.md托管代码分析完整指南含部署形态对照表、证据记录结构docs/managed-code-analysis.md设计决策与实现状态ADR-0003 托管代码证据与 Provider 边界比较核心实现src/domain/managed/managedMemberComparison.tsMCP 工具注册src/server/registerManagedWorkflowTools/解析器与 CIL 解码src/dotnet/小结REA 的 .NET 程序集比较走了一条“先证据、后推断”的路线名字不可信就用签名和结构结构不完整就如实报告unknown。官方路线图接下来的方向正是让这套机制在深度混淆和混合部署ReadyToRun、单文件、NativeAOT场景下依然可靠并把托管发现真正链接到已验证的原生分析——如果你经常在版本更新后核对 .NET 程序的行为变化这正是值得跟踪的下一步能力。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 REA混淆.NET程序集比较路线图：官方计划中的下一步能力
REA混淆.NET程序集比较路线图官方计划中的下一步能力【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/reaREAReverse Engineer Anything是一个让 AI Agent 驱动本地逆向工程的开源工具其中.NET 程序集比较是它的核心能力之一不加载、不执行目标程序直接读取 PE/CLI 字节做跨版本成员对比。本文将带你了解 REA 混淆场景下 .NET 程序集比较的现状以及官方路线图里计划中的下一步能力。为什么 .NET 程序集比较这么难很多人以为比较两个 .NET 程序集只要“反编译再 diff”就够了。但实际使用中代码混淆会破坏这个假设方法名、类型名被改成a、b或乱码 Unicode名字完全不可信每次构建的 MVID、token 顺序、元数据布局都会变化0x06001234这类 token 在两个版本间根本不指向同一个方法声明了 P/Invoke 却可能通过反射动态解析NativeAOT 则干脆没有 CIL 方法体。因此 REA 的做法是分类先行、字节为准。先用 src/dotnet/ManagedArtifactInspector.ts 判断工件到底是普通 CIL、ReadyToRun、单文件托管还是 NativeAOT再决定分析路线而不是“看到 .NET 就选反编译器”。这套边界设计记录在 ADR-0003 中。已经上线的 7 个托管分析工具目前 REA 的 .NET 程序集比较已经具备一条完整工具链MCP 工具与 CLI 命令一一对应任务MCP 工具识别工件与托管部署形态inspect_managed_artifact检查类型、签名、方法体与 CIL 指令inspect_managed_members列出声明的本地调用边界inspect_managed_native_boundaries跨构建比较成员并映射 tokencompare_managed_members用导出的导出/函数证据核验 P/Invoke 声明verify_managed_native_boundaries导入反编译代码作为分析师推断import_managed_reconstruction将托管发现投影进应用图谱project_managed_application_graphCLI 侧只需把下划线换成连字符并加rea前缀例如rea compare-managed-members。四级匹配算法名字只是兜底compare_managed_members 的实现采用exact-signature-fallback策略匹配优先级为精确 CIL 签名身份指令与签名完全一致直接判定“未变”精确声明签名完整的方法名类型原始签名元组匹配名字只作为元组的一部分参与单独的名字永远不能配对结构化方法形状归一化签名、解码后的指令元组指纹、常量与控制流形状字段签名层字段按同样的精确层处理。无法区分的候选会明确报告为ambiguous未匹配的成员记为unknown——而不是被悄悄增删。比较结果还会区分metadata维度即使 CIL 指令完全相同MethodDef 的可见性或同步标志变化也会单独上报。完整的服务实现在 ManagedMemberComparisonService.ts。官方路线图下一步计划哪些能力在 docs/roadmap.md 的“Planned work”中“改进混淆 .NET 比较并打通托管发现与已验证原生分析之间的链接”是当前明确的开发优先级之一。结合 docs/managed-code-analysis.md计划中的能力可以分为三层1. 更强的抗混淆行为切片官方定义了一个“行为切片behavior slice”概念为验证一个命题记录最小的、有界的观测集合包括归一化签名与继承形状、框架 API 引用、精确字符串/数值常量/序列化键、分支与异常形状、调用与字段流、构造与泛型实例化点以及调用者/被调用者与竞争候选。这样即使所有名字都被混淆两个构建之间仍能靠“结构形状 常量锚点”完成比较。2. 完整归一化 CIL 承诺目前normalized_il_sha256是“解码元组指纹”还不是完整的语义 CIL 身份它不跨 MVID 解析 token也不承诺完整控制流与异常语义。路线图计划引入规范化的 token/字面量身份、完整分支与 switch 目标、显式的 locals/异常语义让跨版本比较可以建立在真正的语义等价上而不只是结构近似。3. 托管 ↔ 原生桥接映射这是与原生分析联动最期待的部分native-body 桥接把托管方法 token 映射到原生实现地址目前只允许“精确声明链接”token 永远不能当地址用ReadyToRun / C/CLI / IL2CPP在版本化映射约束下关联托管声明与 Hopper/Ghidra 的原生函数证据部署分类向量单个文件可能同时含原生宿主、普通 CIL 程序集与 ReadyToRun 组件计划为每个组件输出独立的摘要、分类与覆盖度而不是一个猜测的标签。注上图为原生分析侧截图用于说明路线图第 3 层“托管发现链接到已验证原生分析”的目标场景。4. 验证与可信度提升引入钉住版本pinned的System.Reflection.Metadata差异预言机用独立解析器交叉验证语义事实dnlib、Mono.Cecil 作为未来的差异预言机候选源码构建的抗混淆一致性语料Unicode/无意义/重复外观命名、保持结构的重命名、至少两个 MVID 与布局不同的构建、恶意截断输入等。新手上手三步完成一次构建比较 准备两个构建同一程序的两个版本比如更新前后保持原始文件不变运行比较rea compare-managed-members分别提供两侧工件路径或先rea inspect-managed-artifact确认身份解读结果关注summary的 unchanged/changed/added/removed/unknown 计数与matching中落入structural_method_shape或ambiguous的成员——在混淆场景下这些才是需要人工重点确认的部分。安装 REAgit clone https://gitcode.com/GitHub_Trending/rea2/rea cd rea npm install npm run setup值得收藏的相关资料总路线图与开发优先级docs/roadmap.md托管代码分析完整指南含部署形态对照表、证据记录结构docs/managed-code-analysis.md设计决策与实现状态ADR-0003 托管代码证据与 Provider 边界比较核心实现src/domain/managed/managedMemberComparison.tsMCP 工具注册src/server/registerManagedWorkflowTools/解析器与 CIL 解码src/dotnet/小结REA 的 .NET 程序集比较走了一条“先证据、后推断”的路线名字不可信就用签名和结构结构不完整就如实报告unknown。官方路线图接下来的方向正是让这套机制在深度混淆和混合部署ReadyToRun、单文件、NativeAOT场景下依然可靠并把托管发现真正链接到已验证的原生分析——如果你经常在版本更新后核对 .NET 程序的行为变化这正是值得跟踪的下一步能力。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考