ant4g0nist/pyre
GitHub: ant4g0nist/pyre
将 Ghidra C++ 反编译器编译为 WebAssembly 在浏览器中运行，支持 ELF、Mach-O、PE 和 WebAssembly 二进制文件的纯客户端反编译与导航分析。
Stars: 90 | Forks: 4
# Pyre
在浏览器中运行的 Ghidra C++ 反编译器。
拖入 ELF、Mach-O、PE 或 `.wasm` 文件。Pyre 会解析二进制文件，延迟加载适用于其架构的 SLEIGH 规范，并按需反编译函数。
通过函数列表进行导航，在 Monaco 中 Cmd 点击调用点以在新标签页中跟踪调用，并在侧边面板中阅读交叉引用。
所有操作均在客户端运行。二进制文件永远不会离开浏览器；没有服务器，没有上传，没有遥测。
## 状态
Alpha 阶段。核心流水线（二进制解析 → wasm 反编译 → Monaco 渲染 → 导航）支持在 x86 (32/64)、AArch64 和 WebAssembly 模块上运行。
Ghidra 支持的其他架构可以正常编译，但尚未包含在默认的规范集中 — 请参阅 [路线图](#roadmap)。
## 快速开始
你需要：
- Node 20+
- 位于你的 `PATH` 中的 [emsdk](https://emscripten.org/docs/getting_started/downloads.html)（或通过 `emsdk_env.sh` 激活）
- 一组预置的 SLEIGH 规范 — 针对一个或多个架构的预构建 `.sla` 文件（参见第 2 步）
```
# 1. 构建 wasm 模块 (~30 s 完整构建, ~5 s 增量构建)
./decompiler-wasm/build.sh
# → decompiler-wasm/dist/pyre_decompiler.{js,wasm}
# 2. 从按以下结构排列的目录中暂存 SLEIGH specs
# Ghidra/Processors//data/languages/...
./specs/stage-specs.sh /path/to/your/Ghidra/source/tree
# → specs/dist//data/languages/*.{sla,ldefs,cspec,pspec}
# → specs/dist/manifest.json
# 3. 运行 web 前端
cd web
npm install
npm run dev # http://localhost:5173
```
`web/public/decompiler` 和 `web/public/specs` 符号链接指向第 1 步和第 2 步的构建输出。
## Docker
如果你不想在本地安装 emsdk + Node：
```
docker build -t pyre-dev -f docker/Dockerfile .
docker run --rm -it -v "$PWD":/work -w /work -p 5173:5173 pyre-dev
# 在容器内：
./decompiler-wasm/build.sh
./specs/stage-specs.sh /path/to/Ghidra
cd web && npm install && npm run dev -- --host 0.0.0.0
```
## 目录结构
```
decompiler-wasm/ C++ → wasm. Vendored Ghidra decompiler tree, multi-region
LoadImage, SleighArchitecture subclass, extern "C" bridge,
emscripten unity build.
specs/ SLEIGH .sla / .ldefs / .cspec staging + manifest pipeline.
web/ React + Vite + TypeScript + Tailwind frontend, Monaco editor.
docker/ Dev image: emsdk + Node + JDK + gradle.
```
## 工作原理
```
┌──────────────────── browser ────────────────────┐
│ │
│ React UI ──► Zustand store ──► DecompilerClient │
│ │ │
│ postMessage ▼ │
│ ┌─────────────┐ │
│ │ Web Worker │ │
│ │ ┌────────┐ │ │
│ │ │ wasm │ │ │
│ │ │ Ghidra │ │ │
│ │ │ decomp │ │ │
│ │ └────────┘ │ │
│ │ FS lazy- │ │
│ │ mount │ │
│ │ /spec/... │ │
│ └─────────────┘ │
└──────────────────────────────────────────────────┘
```
有三个值得指出的设计选择：
- **为什么使用 Web Worker（硬性要求）**。Emscripten 的 `FS.createLazyFile` 在首次访问字节时使用*同步* XHR。该 API 在主线程上是非法的，但在 worker 中运行正常。规范文件（涵盖 Ghidra 支持的所有架构约 30 MB）作为延迟加载项被挂载；只有用户实际打开的架构才会产生开销。
- **多区域 `LoadImage`**。Mach-O 段位于不连续的虚拟内存地址，甚至 ELF 二进制文件的入口点也可能离第一个 PT_LOAD 页很远。单一缓冲区的平坦映射会悄无声息地导致错误的字节混叠。Pyre 的 `WebLoadImage` 包含一组以 VMA 为键的任意区域，并对反编译器询问的任何间隙进行零填充。
- **延迟加载的 libc 原型目录**。Ghidra 的 `parse_C` *按名称*将原型绑定到符号，因此只有在 JS 调用者注册了二进制文件的符号*之后*导入目录，`printf` / `puts` / `malloc` 才能在反编译输出中呈现为它们的命名形式。Bridge 将此导入推迟到第一次 `decompile()` 调用时进行。
## 路线图
- [ ] 在 `specs/` 中的 `sleighc` 构建步骤 — 编译 `Ghidra/Processors/` 下的每一个 `.slaspec`，以便我们开箱即用 Ghidra 支持的所有架构（RISC-V、MIPS、PowerPC、SPARC 等）
- [ ] 浏览器内变量重命名 — 通过 worker 往返传递名称编辑并重新反编译
- [ ] 持久化工作区 (IndexedDB)，这样刷新页面就不会丢失打开的标签页
- [ ] 反汇编侧边面板（Monaco 旁边的 Capstone-wasm）
- [ ] WASM 模块反编译优化 — 字符串/数据段解析，更好的入口点检测
## 许可证
MIT — 请参阅 [LICENSE](LICENSE)。`decompiler-wasm/third_party/` 下引入的 Ghidra 反编译器源代码保留其原始的 Apache 2.0 许可证；完整归属说明请参阅 [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md)。
标签：AI工具, C++, ELF, Emscripten, Ghidra, Mach-O, Monaco Editor, PE, TLS抓取, WebAssembly, 二进制分析, 云安全运维, 云资产清单, 代码导航, 前端, 反编译器, 客户端处理, 数据擦除, 本地分析, 浏览器端, 自动化攻击, 请求拦截, 软件安全, 逆向工程, 零上传