[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-3162":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":15,"stars7d":16,"stars30d":17,"stars90d":15,"forks30d":15,"starsTrendScore":15,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":19,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":20,"hasPages":22,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":24,"readmeContent":25,"aiSummary":26,"trendingCount":15,"starSnapshotCount":15,"syncStatus":27,"lastSyncTime":28,"discoverSource":29},3162,"pyre","ant4g0nist\u002Fpyre","ant4g0nist","Ghidra decompiler in your browser","https:\u002F\u002Fpyre.fuzzing.science\u002F",null,"TypeScript",114,4,56,0,1,22,2.1,"MIT License",false,"main",true,[],"2026-06-12 02:00:46","# Pyre\n\nGhidra's C++ decompiler running in your browser.\n\nDrag in an ELF, Mach-O, PE, or `.wasm`. Pyre parses the binary, lazy-loads\nthe SLEIGH spec for its architecture, and decompiles functions on demand.\nNavigate via a function list, Cmd-click on call sites in Monaco to follow\ncalls into new tabs, and read cross-references in the side panel.\n\nEverything runs client-side. Binaries never leave the browser; there is no\nserver, no upload, no telemetry.\n\n## Status\n\nAlpha. The core pipeline (binary parse → wasm decompile → Monaco render\n→ navigation) works on x86 (32\u002F64), AArch64, and WebAssembly modules.\nOther architectures Ghidra supports compile fine but are not bundled\nin the default spec set yet — see [Roadmap](#roadmap).\n\n## Quick start\n\nYou need:\n\n- Node 20+\n- [emsdk](https:\u002F\u002Femscripten.org\u002Fdocs\u002Fgetting_started\u002Fdownloads.html)\n  on your `PATH` (or sourced via `emsdk_env.sh`)\n- A staged set of SLEIGH specs — pre-built `.sla` files for one or\n  more architectures (see step 2)\n\n```bash\n# 1. Build the wasm module (~30 s clean, ~5 s incremental)\n.\u002Fdecompiler-wasm\u002Fbuild.sh\n# → decompiler-wasm\u002Fdist\u002Fpyre_decompiler.{js,wasm}\n\n# 2. Stage SLEIGH specs from a directory laid out as\n#    Ghidra\u002FProcessors\u002F\u003Carch>\u002Fdata\u002Flanguages\u002F...\n.\u002Fspecs\u002Fstage-specs.sh \u002Fpath\u002Fto\u002Fyour\u002FGhidra\u002Fsource\u002Ftree\n# → specs\u002Fdist\u002F\u003Carch>\u002Fdata\u002Flanguages\u002F*.{sla,ldefs,cspec,pspec}\n# → specs\u002Fdist\u002Fmanifest.json\n\n# 3. Run the web frontend\ncd web\nnpm install\nnpm run dev    # http:\u002F\u002Flocalhost:5173\n```\n\nThe `web\u002Fpublic\u002Fdecompiler` and `web\u002Fpublic\u002Fspecs` symlinks point at\nthe build outputs from steps 1 and 2.\n\n## Docker\n\nIf you'd rather not install emsdk + Node locally:\n\n```bash\ndocker build -t pyre-dev -f docker\u002FDockerfile .\ndocker run --rm -it -v \"$PWD\":\u002Fwork -w \u002Fwork -p 5173:5173 pyre-dev\n# inside the container:\n.\u002Fdecompiler-wasm\u002Fbuild.sh\n.\u002Fspecs\u002Fstage-specs.sh \u002Fpath\u002Fto\u002FGhidra\ncd web && npm install && npm run dev -- --host 0.0.0.0\n```\n\n## Layout\n\n```\ndecompiler-wasm\u002F   C++ → wasm. Vendored Ghidra decompiler tree, multi-region\n                   LoadImage, SleighArchitecture subclass, extern \"C\" bridge,\n                   emscripten unity build.\nspecs\u002F             SLEIGH .sla \u002F .ldefs \u002F .cspec staging + manifest pipeline.\nweb\u002F               React + Vite + TypeScript + Tailwind frontend, Monaco editor.\ndocker\u002F            Dev image: emsdk + Node + JDK + gradle.\n```\n\n## How it works\n\n```\n┌──────────────────── browser ────────────────────┐\n│                                                  │\n│  React UI ──► Zustand store ──► DecompilerClient │\n│                                       │          │\n│                         postMessage   ▼          │\n│                                ┌─────────────┐   │\n│                                │ Web Worker  │   │\n│                                │  ┌────────┐ │   │\n│                                │  │ wasm   │ │   │\n│                                │  │ Ghidra │ │   │\n│                                │  │ decomp │ │   │\n│                                │  └────────┘ │   │\n│                                │  FS lazy-   │   │\n│                                │  mount      │   │\n│                                │  \u002Fspec\u002F...  │   │\n│                                └─────────────┘   │\n└──────────────────────────────────────────────────┘\n```\n\nThree design choices worth flagging:\n\n- **Why a Web Worker (hard requirement)**. Emscripten's `FS.createLazyFile`\n  uses *synchronous* XHR on first byte access. That API is illegal on\n  the main thread but fine inside a worker. Spec files (~30 MB across\n  all architectures Ghidra supports) are mounted as lazy entries; only\n  the arch the user actually opens is paid for.\n- **Multi-region `LoadImage`**. Mach-O segments live at non-contiguous\n  virtual memory addresses, and even ELF binaries can have entry\n  points far from the first PT_LOAD page. A flat single-buffer\n  projection silently aliases the wrong bytes. Pyre's `WebLoadImage`\n  holds an arbitrary set of regions keyed by VMA and zero-fills any\n  gaps the decompiler asks about.\n- **Lazy libc prototype catalogue**. Ghidra's `parse_C` binds\n  prototypes to symbols *by name*, so `printf` \u002F `puts` \u002F `malloc` only\n  render as their named forms in decompiled output if the catalogue is\n  imported *after* the JS caller has registered the binary's symbols.\n  The bridge defers this import to the first `decompile()` call.\n\n## Roadmap\n\n- [ ] `sleighc` build step in `specs\u002F` — compile every `.slaspec`\n      under `Ghidra\u002FProcessors\u002F` so we ship every architecture Ghidra\n      supports out of the box (RISC-V, MIPS, PowerPC, SPARC, ...)\n- [ ] In-browser variable rename — round-trip a name edit through the\n      worker and re-decompile\n- [ ] Persistent workspace (IndexedDB) so refreshing the page doesn't\n      drop open tabs\n- [ ] Disassembly side panel (Capstone-wasm next to Monaco)\n- [ ] WASM module decompilation polish — string \u002F data section parsing,\n      better entry-point detection\n\n## License\n\nMIT — see [LICENSE](LICENSE). Vendored Ghidra decompiler sources under\n`decompiler-wasm\u002Fthird_party\u002F` retain their original Apache 2.0 license;\nsee [THIRD_PARTY_NOTICES.md](THIRD_PARTY_NOTICES.md) for full attribution.\n","Pyre 是一个基于浏览器的Ghidra反编译工具。它支持将ELF、Mach-O、PE或`.wasm`格式的二进制文件拖放到浏览器中进行解析，并按需反编译函数。用户可以通过函数列表导航，使用Cmd点击调用点来跟踪调用到新标签页，并在侧边栏查看交叉引用。整个过程完全运行于客户端，确保了数据的安全性与隐私保护，因为所有操作都在用户的浏览器内完成，无需上传任何文件至服务器。此项目采用TypeScript编写，前端框架为React+Vite，后端逻辑通过WebAssembly实现。适用于需要快速且安全地分析二进制代码的研究人员和开发者。",2,"2026-06-11 02:52:42","CREATED_QUERY"]