REA 检测被篡改的 Electron 应用包：1 条命令完成 ASAR 完整性校验教程
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
你下载的安装包，真的还是官方发布时的那一份吗？REA 内置的 ASAR 完整性校验能力，可以把 Electron 应用包app.asar里每个文件的 SHA-256 声明值和实际字节逐条核对，帮你快速发现被篡改、注入或替换过的安装包。整个过程是静态哈希比对，不执行任何应用代码，一条命令即可开始。
一、先认识 ASAR 包：它靠 integrity 声明自己没被动过
在谈"怎么查篡改"之前，先看 ASAR 归档内部长什么样。一个app.asar本质上由两部分组成：
- 文件清单（头部 JSON）：记录包内每个文件的逻辑路径、字节大小、起始偏移，可选地还带一个
integrity字段； - 拼接的字节流：所有文件内容按清单顺序首尾相接，读文件就是按"偏移 + 长度"切区间。
integrity字段就是 Electron 在打包时写入的自证材料，形如算法SHA256加上一串 64 位十六进制哈希。清单一旦写好，每个文件"应该长什么样"就有了书面凭据。
篡改者要改动包体，绕不开三种手法：
- 清单不动、内容换：头部的声明哈希原封不动，只有对应区间的实际字节被替换，肉眼看不出任何差别；
- 伴生文件调包：标记为
unpacked的原生模块存放在归档旁的.asar.unpacked目录里，攻击者直接换掉这个.node文件； - 整包重打包：文件增删或顺序变化后重新打包，归档大小、头部结构随之改变。
而检测思路只有一条：拿"声明的哈希"对"实际算出来的哈希"，逐条核对。这正是 REA 的 ASAR 完整性校验在做的事。
二、一条命令完成检测
先按官方文档完成安装与初始化（Hopper、Ghidra 等引擎对本任务不是必需的）：
- 安装说明：installation.md
- CLI 总览：cli.md
拿到目标应用目录后，把其中的app.asar直接交给 REA：
rea analyze /absolute/path/to/apps/app.asar --json通用rea analyze遇到目录或.asar路径且未显式指定--provider/--snapshot时，会自动选择 JavaScript 应用静态分析工作流。也可以用专用命令直接点名：
rea analyze-javascript-application /absolute/path/to/apps/app.asar --integrity-policy record-and-continue --json整个流程只读取本地字节并做静态解析：不启动 Electron 进程、不拉起浏览器、不加载目标代码。--integrity-policy只有两个取值，fail与record-and-continue，默认是fail。命令与结果字段的完整说明见 javascript-artifact-reconstruction.md。
三、读懂校验输出
每条结果对应包内一个文件条目，三种状态各有一层含义：
| 结果状态 | 含义 | 建议动作 |
|---|---|---|
| 全部一致 | 声明哈希与实际字节相符，无篡改证据 | 保存本次 SHA-256 作为基线，日后复查时对照 |
integrity失败 | 声明哈希与实际字节矛盾，包体被改动过 | 按逻辑路径定位文件，回官方渠道重新获取安装包 |
hash_status: unavailable | 声明了 unpacked 伴生文件，但伴生字节缺失 | 缺失内容记为 unknown 而非"已验证"，补齐文件后重新校验 |
失败条目会同时给出逻辑路径、声明 SHA-256 与计算 SHA-256，并标明该条目是否属于 unpacked。
补充一点策略上的区别：默认策略是"遇到不一致立即失败"。加上--integrity-policy record-and-continue后，每条矛盾都会以integrity_contradictions记录留存，已验证的兄弟文件继续分析，应用图覆盖范围会被标记为 partial——适合"先把能查的查完，篡改记录一条不丢"的场景。更多规则见 mcp-contracts.md 的完整性处理章节。
四、它凭什么防得住篡改
把实现拆开看，防线一共四层：
- 逐条提取声明哈希。清单阶段读取每个文件条目的
integrity元数据，只有算法为SHA256且哈希形如 64 位十六进制串时，才被采纳为可比对的声明值。 - 按声明范围精确读取，边读边算。读取任何条目前，先校验"偏移 + 长度"是否越出容器边界，再按字节区间流式读取并累计实际 SHA-256；实际字节数与声明大小不符直接判失败。见 AsarEntryStream.ts。
- unpacked 伴生文件同样受检，且防符号链接逃逸。
unpacked只是存放方式，不是免检通行证：伴生字节要与归档声明的完整性值比对，路径先做realpath规范化，逃出伴生目录或指向符号链接的条目一律拒绝。 - 防"边读边换"的二次替换。打开归档时先落一份临时快照并记下容器 SHA-256，后续所有读取都绑定这份快照；读取期间若容器大小或文件 inode 发生变化，判定为完整性失败而不是静默通过。核心实现见 AsarArtifactReader.ts。
五、确认被篡改之后怎么办
- 看逻辑路径：
integrity_contradictions记录里的逻辑路径告诉你包里哪个文件出了问题，声明值与计算值并列展示，是否 unpacked 一目了然。 - 回官方渠道重取：从官方发布页重新下载安装包，再跑一遍同样的命令，确认干净版本全部一致，并留存这组哈希作为基线。
- 两份结果并排对比：把官方包与可疑包的结果各存一份，用 REA 的证据导入/导出和比对命令核对差异：
rea evidence-import /absolute/path/to/evidence/bundle.json rea compare /absolute/path/to/evidence/official.json /absolute/path/to/evidence/suspect.json更多证据工作流见 cli.md 的 Import, export and compare Evidence 一节。
六、快速答疑
- Q：校验前必须先把应用装好、甚至运行一次吗？不必。这是纯静态流程：读字节、算哈希、比对照明，不安装、不执行目标应用，对来路不明的样本反而更安全。
- Q：完全没用过哈希工具，会卡在哪一步吗？不会。哈希计算与比对都由 REA 完成，你只需要把
app.asar的绝对路径传给命令，输出里直接给差。 - Q：今天的结果明天还能用吗？可以。
--json输出是结构化 Evidence，可以落盘存档，之后随时用rea compare与另一份结果并排比对。
七、写在最后
回到最朴素的判断标准：声明哈希 vs 实际哈希，逐条核对。这条标准对安全研究员和只想确认安装包没被动手脚的普通用户同样成立，一条命令即可开始。
【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
