# Awesome Reverse Engineering Anything: the full curated catalog > Every source-reviewed resource and research paper of AwesomeREA.org, with requirements, limits and sources. The navigation index is https://awesomerea.org/llms.txt; each entry also has its own Markdown page and record.json. The description was reviewed against primary sources. Reviewed against the paper and its primary sources. Cite the original authors using the linked paper or BibTeX. Original editorial content: MIT. Linked projects, papers and assets retain their own rights and licenses. ## Curated resources (1,253) ### Websites (61) #### Dinosaur runner: recovering one acceleration rule > REA’s documented teaching case inspects the HTTP t-rex-runner edition and reconstructs its speed-update rule. A separate controlled original-game check and a new demonstration compare update counts, including the floating-point step that crosses the nominal speed threshold. - Type: Case study - Targets: Game · Website - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The recorded target is wayou’s HTTP browser edition at the cited revision, not chrome://dino/. Source and observation hashes identify that edition. - **Attribution:** After read-only inspection, a separate Playwright controller disabled future scheduling and obstacles to call the original update function under controlled conditions. - **Limits:** The reconstructed claim is limited to acceleration. Drawing, jumping, collisions and controls in the teaching game are newly authored, not independently recovered original gameplay. - **Testing evidence:** Public result tables and code document the author’s checks. The cited original-source excerpts retain Chromium attribution and BSD-3-Clause terms. ##### Primary sources 1. 2. #### rauchg.com: rebuilding an RSC blog from captured Flight output > Documents a website-rebuild-skill case that decodes browser-delivered React Server Component Flight streams, reconstructs a buildable Next project and compares its output with a captured site. The reported rauchg.com campaign uses route-tree comparison and module-reference mapping; the new server source is inferred from observable output. - Type: Case study - Targets: Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented rauchg.com snapshot used Next 16.1.1, Turbopack and React 19 canary. The tooling requires Node.js 22+ and a local Chrome/Chromium for comparison; some stages invoke version-pinned external tools. Repeating the method needs an authorized target snapshot and a separately built reconstruction, not just the skill repository. - **Scope:** Flight decoding exposes delivered element trees, route state and client-module references. The reconstructed server-component source is explicitly an inference from that output; flight-to-mdx also needs site-specific shape/link adaptations. - **Testing evidence:** The author reports 18/18 routes passing a Flight semantic gate and a runtime sweep for this case. The gate compares normalized trees and enforces a global module-ID bijection. It normalizes build-hash namespaces and selected encoding differences; configured prop/class exclusions can omit registered fields or subtrees. - **Testing evidence:** The gate does not check CSS, so layout, fonts and rendered pixels need separate comparisons. Public synthetic self-tests include changed-text rejection and rejection of a one-to-many module mapping. - **Limits:** The method explicitly leaves unobserved error responses, database/write paths, server caches, dynamic-image generator source and unlinked routes unresolved. The author also notes possible model-training familiarity with a nominally blind target. - **License:** MIT applies to the skill and tooling, not to reconstructed websites, their scripts, fonts or other assets. The source documents separate authorization/publication decisions and private, noindex output defaults. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### BaoCut Slides: adapting an interactive web editor > Documents BaoCut’s interactive slide editor, whose author says the implementation draws on Claude Slides. It adds a local deck store, HTML/CSS compiler and annotation-to-agent bridge for browser and desktop hosts; the design reports a Web-flow check, without establishing original backend recovery or full behavioral parity. - Type: Case study - Targets: App · Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs Node.js >=22.12.0, npm workspace dependencies, the apps/slides-editor build and a BaoCut Runtime/host; the runtime declares React ^19.3.0 and patched PptxGenJS 3.12.0. Full BaoCut builds add Rust/Cargo, CMake and C++ tools, with full Xcode/Metal for Apple Silicon inference. Agent-made decks need Codex CLI, Claude Code or another configured engine under its own terms. - **Scope:** The pinned Slides component is an editor runtime, a restricted HTML/CSS slide compiler and a new BaoCut host; decks are a v4 deck.json index with per-slide HTML and local assets. - **Limits:** Single-user and file-backed, with per-file conflict checks but no whole-batch rollback. Shared rooms/presence, share links, persistent comment threads and sending to Google Drive/Slides are out of scope; PPTX/PDF downloads remain P1. - **Testing evidence:** End-to-end validation covers only the Web annotation flow, not Electron; the published tests use fakes and no comparison with the original. - **License:** BaoCut Community License 1.0 is source-available: personal/internal use and content creation are allowed; commercializing the code or commercial hosting needs a separate license. PptxGenJS (MIT) and mediabunny (MPL-2.0) keep their terms; no reuse rights are shown for Claude material or the bundled icon font, slated for replacement. - **Attribution:** Use independently authorized slide content. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### REA in Claude Code: an isolated static-analysis A/B trial > A Japanese field report connects REA 6.4.0 to Claude Code in a separate project directory, denies 43 of its 170 tools and common shell launch forms, and compares REA-enabled and REA-disabled runs on two real tasks: an Electron terminal’s packaged files and a saved HAR capture. Both arms answered correctly, while the REA arm took up to 2.00× the time and 1.67× the API-equivalent cost. It is an analysis-evaluation and safety-configuration case, not a reconstruction. - Type: Case study - Targets: App · Website - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Catalog page: ##### Requirements & limits - **Scope:** The article by keigoly was published on Zenn on 2026-10-14 (JST). It pins REA 6.4.0 from the rea-agents package and runs it with a checksum-verified official Node.js 24.21.0 placed inside the project, because the host’s Homebrew Node 25.8.1 is outside REA’s supported range. All trials used non-interactive claude -p with Claude Opus 5.5 and permission prompts bypassed; the Claude Code version is not stated. - **Limits:** Isolation is configuration, not a sandbox: REA is enabled only through a project-local .mcp.json, a generated deny list blocks 43 tools selected from effect metadata, and Bash prefix rules block common package-runner launches. The author states that deny rules are a fence rather than isolation, that other invocation forms bypass the prefix rules, and that prompt injection through analysis output was not tested. - **Scope:** The tasks were MIT-licensed Orca terminal v1.4.224 (128 MB of distributed Electron files) and a 2.5 MB HAR from an unnamed venue website; answers were checked against Orca’s public source and the HAR data. The author excluded DRM or license circumvention, online multiplayer games, business or customer data and malware from scope. - **Limits:** Each condition ran once (n=1), the REA arm was told to prefer REA tools, parallel processes make timings approximate, and only static JavaScript/web work with one model was tested; an interrupted run was excluded and repeated. One REA analysis result exceeded the 10 MB MCP response limit. Scripts and JSONL logs are excerpted rather than published. - **Attribution:** The author reports that REA helped with extraction, such as asar unpacking and HAR element extraction, while grep and small scripts carried code reading in both arms. Nothing was reconstructed: the HAR task identified an existing request path. Native binaries and APKs are deferred to a planned second step; Orca, the venue site, REA and the model service keep their own terms. ##### Primary sources 1. #### Dinosaur runner: an REA-inspected speed rule rebuilt with Codex > The author uses REA’s MCP browser tools to passively capture the JavaScript loaded by wayou’s open-source T-Rex Runner page, then has Codex rebuild its acceleration rule in one self-contained HTML5 Canvas game. The report identifies the captured script by SHA-256 and separates verified source facts from reconstruction choices; only the speed rule is claimed, not full gameplay equivalence. - Type: Case study - Targets: Game · Website - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Playing needs only a browser: dino-demo.html is self-contained, with no external assets, packages or build step, and a GitHub Pages copy is linked. The embedded tests run from the page’s Run speed tests button, the browser console or the documented Node.js harness with mocked DOM, Canvas and animation-frame interfaces. - **Scope:** The target is wayou’s open-source, Chromium-derived T-Rex Runner page, not chrome://dino/ or hidden proprietary code; the investigation read JavaScript the browser had already loaded. Only the acceleration rule is reconstructed: start at 6 and add 0.001 per eligible update while below 13, with no elapsed-time factor. Artwork, physics, obstacles and scoring are new or simplified, and the intro, ducking, audio and narrow-screen speed reduction are omitted. - **Attribution:** README and the report record REA MCP list_browser_targets and inspect_web_page calls over a local Chrome DevTools Protocol endpoint, with no navigation, clicks or page evaluation; Codex handled analysis, implementation and tests. Evidence IDs and excerpts come from the author’s REA results, but the full evidence bundle is not published and the live upstream script may change. - **Testing evidence:** The author reports 67 of 67 embedded tests passing (15 unit, 52 integration), ten rejected in-memory mutations and seven owner-reported manual browser checks on 2026-10-13 without browser or OS details. Floating-point results such as the extra step past 13 at update 7,001 were measured in the reconstruction, not sampled from the original. There is no CI or cross-browser coverage. - **License:** The project is MIT-licensed; short original-source excerpts keep the Chromium BSD-style header, and THIRD_PARTY_NOTICES.md reproduces the upstream BSD-3-Clause terms. This third-party repository is separate from REA’s own dinosaur-speed teaching case. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Terminal: a Rust terminal informed by TradingView chart research > An independent Rust market interface uses REA browser-scenario research on public logged-out TradingView chart interactions. The notes retain observed/documented/inferred/unknown labels; the result supplies its own chart engine and data providers rather than recovering TradingView or Bloomberg server software. - Type: Case study - Targets: App · Website - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Source builds need Rust and the documented platform graphics setup. Data can use an offline sample or external providers; brokerage connectivity is optional and requires the user's own provider/account setup. - **Attribution:** REA captured browser scenarios from a public logged-out chart. Login-only behavior, some pointer gestures and unavailable interactions remain unknown. - **Limits:** Scanned disclosure PDFs are not OCR-processed; unofficial data endpoints are rate-limited and upstream filing-use terms still apply. - **License:** No project-wide license was identified in the reviewed root/README; repository access does not grant rights to external market data. ##### Primary sources 1. 2. #### webcrack > Improves JavaScript readability by reversing supported obfuscation patterns and unpacking webpack/Browserify bundles. - Type: Tool - Targets: App · Website - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README specifies Node.js 22 or 24; results depend on the obfuscator/bundler patterns present in the input. ##### Primary sources 1. #### humanify > Rename identifiers in minified JavaScript with LLM-suggested names, applied through scope-aware AST rewriting so the program structure stays unchanged. The new names are model suggestions, not recovered original identifiers. - Type: Tool - Targets: Website - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed release: v3.1.1, published 2026-07-29. Version 3 is a single Rust binary with release builds for macOS arm64/x64, Linux x64/arm64 and Windows x64; source builds use cargo install. MIT-licensed. - Select a provider preset: OpenAI, Gemini, Anthropic, OpenRouter and Requesty need an API key, while Ollama runs a local model. humanify makes one model call per identifier with surrounding code context (500 characters by default); hosted modes send that context to the selected provider, and cost and rate limits scale with the identifier count. - Each run processes one JavaScript file and renames identifiers only: it does not unbundle webpack output or remove control-flow obfuscation, and upstream suggests running webcrack first. Name quality depends on the model; upstream describes local models as slower and less accurate than hosted providers. ##### Primary sources 1. 2. 3. 4. #### WABT > WebAssembly tools for binary-to-text conversion, section inspection, validation, interpretation and C translation. - Type: Tool - Targets: Binary · Website - Category: WebAssembly tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Select a release supporting the module's WebAssembly features; optional proposals may require explicit flags. ##### Primary sources 1. #### wasm-tools > Bytecode Alliance CLI and Rust libraries for inspecting WebAssembly modules, metadata, components and WIT interfaces. - Type: Tool - Targets: Binary · Website - Category: WebAssembly tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use prebuilt release artifacts or a Rust toolchain; proposal/component support depends on the selected release. ##### Primary sources 1. #### Chrome DevTools MCP > Connect an agent to Chrome for live page inspection, network debugging, and performance traces. - Type: Integration - Targets: Website - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supported Node.js LTS, Chrome, and an MCP client; selected browser profile and target must be available locally. ##### Primary sources 1. #### mitmproxy > Inspect and record HTTP traffic with an interactive proxy, web interface, or scriptable command-line tools. - Type: Tool - Targets: App · Protocol · Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Configure the client proxy; HTTPS inspection requires the appropriate local trust configuration. Saved captures and live interception are distinct workflows. ##### Primary sources 1. #### Playwright MCP > Drive browser interactions through structured accessibility snapshots to investigate reproducible web behavior. - Type: Integration - Targets: Website - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Node.js 18+ and an MCP client; the upstream also offers a separate CLI-and-skills approach for coding agents. ##### Primary sources 1. #### Burp Suite MCP Server > PortSwigger's Burp Suite extension serves an MCP endpoint, plus a packaged stdio proxy, so agents can query proxy HTTP and WebSocket history, send HTTP/1.1 or HTTP/2 requests, and open Repeater or Intruder tabs. - Type: Integration - Targets: App · Website - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Burp Suite, proprietary PortSwigger software under its own EULA: Professional is a paid subscription, while Community Edition is free under separate Community terms. The extension's GPL-3.0 license does not cover Burp. The extension manifest lists both editions as supported. - Reviewed release: v1.3.0, published 2026-05-26 with a prebuilt burp-mcp-all.jar and also listed in the BApp Store. Source builds use Gradle and need Java and the jar command on PATH; the reviewed build targets a Java 21 toolchain. - The SSE server listens on 127.0.0.1:9876 by default; stdio-only clients use the packaged proxy JAR. Approval prompts for sending HTTP requests and for reading HTTP history, WebSocket history and Organizer items are on by default. Config-editing tools are opt-in, and exported options filter credentials by default. - Scanner-issue and Collaborator tools are registered only in Burp Suite Professional. Data returned to the MCP client is handled by that client's model provider. The default branch was seven commits ahead of v1.3.0 at review, with the same registered tool set. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Wakaru > Recover readable modules from shipped JavaScript bundles by reversing recognized minifier and transpiler patterns. Supports bundle splitting and modern-syntax recovery for inspecting production frontend code. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The npm CLI declares Node.js >=16; standalone v1.14.0 binaries are published for macOS arm64, Linux arm64/x64, and Windows arm64/x64. - Provide supported JavaScript bundles or source maps. Original identifiers may be unrecoverable without maps; heavy control-flow or VM obfuscation requires other tooling. Package/version inventory is explicitly still in development. ##### Primary sources 1. 2. 3. #### Spectral > Analyze captured application HTTP traffic with an LLM to generate MCP tools, OpenAPI 3.1 specifications, or GraphQL schemas. Generated tools call the observed API directly after capture and authentication setup. - Type: Integration - Targets: App · Protocol · Website - Category: Website analysis tools - Relationship: Independent agent integration - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python >=3.11; capture through the Chrome extension or MITM proxy, and configure a supported LLM provider or local Ollama endpoint. - The reviewed v0.11.0 workflow depends on captured traffic and valid application authentication. Analysis and automatic repair use the configured LLM. ##### Primary sources 1. 2. 3. #### jsdeob-workbench > Inspect JavaScript ASTs and variable scopes while building visual chains of Babel transforms. Save analysis projects and reusable plugins to iteratively simplify obfuscated scripts. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Run from source with Node.js and npm; the documented default standalone build targets Windows. No GitHub release was available at review time. - Built-in transforms may need sample-specific scripts, and deeply nested input can overflow the stack. Its optional evaluation helper executes code and should be used in a local sandbox, as upstream explicitly advises. - No license was found at the pinned commit: the repository root has no LICENSE file, and neither the README nor package.json declares one. Public source availability is not a reuse grant. ##### Primary sources 1. 2. 3. #### Browser Reverse Engineering Toolkit > Capture browser-session evidence, crawl websites in a persistent Chromium session, and generate offline architecture/API reports plus OpenAPI, SDK and mock-server drafts from saved captures. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Manual capture needs access to the target browser session. Crawling requires Node.js/npm, Playwright and its Chromium browser; the reviewed package declares Playwright ^1.44.0 but no Node engines minimum. - The Node.js reconstructor processes saved captures offline. The toolkit is experimental; generated architecture, OpenAPI, SDK and mock-server outputs need review. - Browser-side capture cannot read HttpOnly cookies or bypass authorization. Request hooks see traffic only after installation; source-map references are hints, and true screenshots require browser automation. - Authenticated captures may contain sensitive data. MIT-licensed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### screenshot-to-code > Generate HTML/CSS, Tailwind, React, Vue, Bootstrap or Ionic front-end code from screenshots, mockups, Figma designs or screen recordings with multimodal models; an optional headless-browser preview lets the model check its rendered output. The result is a visual reconstruction of the interface, not recovered original source or backend behavior. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Self-host the MIT-licensed repository: a FastAPI backend managed with Poetry (Python ^3.10) and a React/Vite frontend run with pnpm, or both through Docker Compose. No GitHub release or tag existed at review. - At least one OpenAI, Anthropic or Gemini API key is required, and inputs are processed by the selected providers. Gemini is required for video mode and handles asset extraction; a Replicate key is optional but recommended upstream for image generation, editing and background removal. The self-check preview needs Playwright's Chromium. - The README reports no fidelity or accuracy figures. Generated code needs review and cannot recover backend logic, APIs or data that the input does not show. ##### Primary sources 1. 2. 3. 4. #### BaoCut Design: porting reconstructed canvas and design-system editors > Documents BaoCut’s design-canvas and design-system editors, which the project says it ported 1:1 from TypeScript reconstructions of Claude Design’s editors and hosts in agent sessions with annotation and export. Its runtime notes record identifier fixes checked against the original scripts and a structural comparison matching 19,111 of 20,463 canvas main-page functions. Unreviewed differences, the unpublished reconstruction record and reuse rights remain open; no hosted-backend recovery is claimed. - Type: Case study - Targets: App · Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs Node.js >=22.12.0, npm workspace dependencies and the apps/design-editor and apps/design-system-editor builds; the canvas keeps React 18.3.1 beside React 19, with Babel standalone 7.29.0. Full builds add Rust, CMake and platform tools; agent-made designs use a configured local agent CLI such as Codex. - **Scope:** The source reconstructions (src/design-type, src/design-system-type) and their evidence are unpublished, and no original release is named. - **Scope:** BaoCut shims replace the globalThis.claude host interface, the parent-origin allowlist is empty, analytics are off, and rooms, sampling and hosted design-system installs are dropped. System fonts replace Anthropic Sans, but the Anthropicons icon font is still inlined with an unconfirmed license and slated for replacement; use independently authorized content. - **License:** BaoCut Community License 1.0 is source-available: personal, internal and content-creation use only; commercializing BaoCut or its code needs a separate license. Third-party notices give no reuse rights in the reconstructed Claude Design code or the icon font. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. #### Dembrandt > Node.js CLI that renders a website in Playwright-driven Chromium or Firefox and reads computed styles from the DOM to extract its design system: logo, color roles with the evidence behind each pick, typography, spacing, borders, shadows, motion, breakpoints and component styles such as buttons and inputs. Results export as W3C design tokens (DTCG), Tailwind v4 or shadcn/ui themes, DESIGN.md, an HTML report or a brand-guide PDF, alongside WCAG contrast checks on real DOM pairs and a CI drift gate against a committed baseline. It also runs as an MCP server for agent clients. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v0.39.2, published 2026-10-11 on GitHub and npm; the reviewed main commit is ten README, MCP-registry and Action-metadata commits ahead. SECURITY.md describes the project as pre-1.0, with fixes only for the latest 0.x release. - Requires Node.js 18+ and a one-time dembrandt install-browser step, because playwright-core ships no browser; Linux and CI hosts also need Playwright's system libraries, and Docker or CI containers may need --no-sandbox. The experimental --ai brand-color model needs the optional onnxruntime-node package. The MCP server starts with npx dembrandt mcp, and a separate GitHub Action wraps the drift gate. - Input is a live URL, rendered at 1920x1080 by default or 390x844 with --mobile; crawls merge several pages found from navigation links or from sitemap.xml after a robots.txt check. The README's limitations: dark mode needs --dark-mode, canvas/WebGL sites cannot be analyzed, some dynamically loaded content and hover or focus states can be missed, and JavaScript-heavy sites need hydration time. Pages behind a sign-in can be reached with the user's own cookies or an interactive login. - MIT. The README limits intended use to design systems you own or may analyze, on sites whose terms permit automated access, and asks users not to reproduce third-party brand identities, logos or trademarks. The optional --key flag uploads each run's snapshot to the vendor's hosted Dembrandt App, which is in beta. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### shuji > Command-line tool that writes the original JavaScript and CSS sources embedded in source maps back out as files. It reads .map files, or JavaScript and CSS files whose sourceMappingURL holds an inline Base64 or URL-encoded map or points to a map in the same folder, and can walk directories with a regular-expression filter. Output is flattened to file names by default, or keeps the map's folder structure with --preserve. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - npm release at review: shuji 0.8.0, published 2023-12-04, which requires Node.js 14.15.0+; the repository publishes tags but no GitHub releases. The reviewed main commit is 139 commits ahead and unreleased: it raises the minimum to Node.js 24.12.0, which the README already states, moves linting to Oxlint and, since 2026-10-11, rejects output paths that would escape the output directory. - Install the CLI globally with npm and run it on a file or directory with -o for the output directory; the default filter only picks .map files, so -M is needed to scan .js or .css files for inline maps. Maps are read from local files only: a referenced map must sit relative to the code file, and remote maps are not fetched. - Only sources whose content is embedded in the map's sourcesContent are written; entries that list a path without content are skipped, so maps built without included sources yield nothing for them. Existing files are never overwritten, so flattened sources with the same file name are skipped unless --preserve is used. - MIT. Recovered files remain the original authors' code under their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Obfuscator.io Deobfuscator > Deobfuscator dedicated to JavaScript produced by Obfuscator.io (javascript-obfuscator), which its README says also handles most forks. Working statically on a Babel AST, it reveals strings hidden in rotated, Base64- or RC4-encoded string arrays, inlines proxy functions, simplifies objects, arithmetic and string concatenation, removes dead code and the obfuscator's anti-tamper wrappers, and reverses control-flow flattening. Its configuration is detected automatically, and the author also hosts an online version. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - npm release at review: obfuscator-io-deobfuscator 1.0.6, published 2025-03-27. The reviewed main commit, merged 2026-08-09, adds unreleased improvements to string-array wrapper identification and README notes on running the CLI from source; package.json still reports 1.0.6. No GitHub releases are published. - Install the global obfuscator-io-deobfuscator CLI, which takes an input file and an optional output path, or build it from source with npm and TypeScript. It applies its Babel-based transformations repeatedly, for at most 50 passes; package.json declares no Node.js version range. An online version runs at obf-io.deobfuscate.io. - Input must be JavaScript produced by Obfuscator.io or a compatible fork; other obfuscators are out of scope, and the author's general-purpose javascript-deobfuscator covers generic patterns. The README states that it does not run untrusted code or use a sandbox; recovered strings and control flow still need checking against the original script. - The LICENSE file is Apache-2.0, while package.json and the npm metadata declare ISC. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### javascript-deobfuscator > General-purpose JavaScript deobfuscator for common obfuscation patterns, published on npm as js-deobfuscator and usable as a library or CLI. It unpacks arrays of literals and replaces references to them, removes simple, array and arithmetic proxy functions, simplifies arithmetic and string concatenation, removes dead branches, turns computed member access into static properties, renames hexadecimal identifiers such as _0xca830a and beautifies the result. The author also hosts an online version and maintains a separate deobfuscator for Obfuscator.io output. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - npm release at review: js-deobfuscator 1.1.7, published 2025-07-15; the reviewed main commit is that version bump. No GitHub releases are published. The TypeScript package parses and regenerates code with the Shift parser and the author's shift-codegen fork; package.json declares no Node.js version range. - Install it locally to import as a module, or globally for the js-deobfuscator CLI, which reads an input file and writes an output file, with -m for ES modules. The library config toggles each transformation. An online version runs at deobfuscate.io. - Supply the JavaScript to analyze yourself. It handles the generic patterns listed in the README; for Obfuscator.io output the README points to the author's dedicated deobfuscator. Hexadecimal identifiers are replaced with names drawn from a bundled word list, not recovered originals, so output still needs analyst review. - The LICENSE file is Apache-2.0, while package.json and the npm metadata declare ISC. ##### Primary sources 1. 2. 3. 4. 5. 6. #### whatsapp-web-reveng: documenting the legacy WhatsApp Web protocol > Documents and reimplements the WebSocket protocol WhatsApp Web used while browser sessions mirrored a paired phone: QR pairing, Curve25519/HKDF key setup, AES/HMAC-protected binary messages, the token-based node encoding and end-to-end media encryption. A Python backend, Node.js relay and browser front end decode a logged-in session’s messages into inspectable JSON, and the README lists independent reimplementations such as Baileys and go-whatsapp. This is an older protocol generation from before WhatsApp’s 2021 multi-device architecture, not a description of current WhatsApp Web. - Type: Case study - Targets: Protocol · Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Use needs the user’s own WhatsApp account and phone to scan the pairing code, and the backend connects to WhatsApp’s servers. The protobuf definitions come from a helper script that parses the public WhatsApp Web JavaScript bundle. The README’s task list still names growing binary-decoding errors, writing binary messages and a less technical interface as open work. - **Prerequisites:** Bare-metal setup needs Node.js 8+ and Python 2.7 with websocket-client, simple-websocket-server, curve25519-donna, pycrypto (pycryptodome in requirements.txt), pyqrcode and protobuf; Windows also needs Visual C++ for Python 9.0 and a supplied header. A shell.nix (Python 2.7, Node.js 13) and a Dockerfile are provided, and npm start runs the backend, Node API and front end together. The README says the Docker version is not stable enough for production. - **Scope:** Reviewed at the 2024-04-22 master head, a README-only change; the backend and Node relay last changed in August 2021, the protobuf schema in March 2020, and there are no releases or tags. The README’s pairing flow has the phone supply session details such as its battery level, the phone-mirroring companion model that WhatsApp’s July 2021 engineering post says multi-device replaces. A 2022 issue reports the server answering a QR scan with an upgrade_md_prod command. As checked on 2026-10-20, the 2024-04-22 head is still GitHub’s last recorded push, the repository is not archived and the README does not mark it as maintained, superseded or archived. - **Testing evidence:** There is no test suite: the package.json test script only starts the components. The documented correctness checks are HMAC validation of the server’s key data and of each binary message, and an in-browser JavaScript demo prints decrypted messages after a QR scan. - **License:** MIT (LICENSE, package.json). The README states the project is unaffiliated with and not endorsed by WhatsApp, that use is at the user’s own risk, and adds a cryptography export notice; WhatsApp’s services and terms apply separately. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### mitmproxy2swagger > Command-line tool that reverse-engineers undocumented REST APIs from captured traffic. It reads a mitmproxy flow file, or a HAR export from the browser DevTools, and generates an OpenAPI 3.0 specification describing the observed endpoints. Running it again over further captures safely merges the new data into an existing schema. - Type: Tool - Targets: Protocol · Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed from PyPI (also packaged for Arch Linux) or run via the provided Dockerfile; pyproject.toml marks version 0.15.0 and requires Python 3.12+. - Takes a mitmproxy flow file or a browser HAR export as input; the analyst captures that traffic separately, for example with mitmproxy, and supplies the API base-URL prefix. The two-pass workflow lets several captures be merged into an existing schema. - Intended for APIs and traffic the analyst is authorized to capture and analyze. The project metadata in pyproject.toml declares the MIT license; no standalone LICENSE file is present for GitHub to detect. ##### Primary sources 1. 2. #### JPEXS Free Flash Decompiler (FFDec) > Java desktop decompiler and editor for Adobe Flash SWF files. It decompiles ActionScript 1/2 and AS3 side by side with the P-code they came from, edits scripts as source (experimental) or through the assembler view, and exports or replaces images, shapes, sounds, video, fonts and texts, with SWF-to-FLA conversion, SWF-to-XML round trips and SVG or HTML5 Canvas output. It also opens SWC and ABC files, Scaleform GFx and 64-bit Iggy files, has an ActionScript debugger and deobfuscation passes for obfuscated AS3, and offers its parser and decompiler as the ffdec_lib Java library and a command line. - Type: Tool - Targets: Game · Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest stable release at review: 26.3.0, published 2026-09-14, with a Windows MSI, a Debian package, a macOS app and pkg, a cross-platform ZIP and separate ffdec_lib and Javadoc archives; nightly prereleases are built from the dev branch. The reviewed master commit is two commits after the version26.3.0 tag, a Chinese README update and a dependency bump. - The application needs Java 8 or later on Windows, Linux or macOS; the installation guide asks for Oracle JDK 8+ on macOS. build.properties targets Java 8, and source builds use Apache Ant or the bundled NetBeans project, with Git recommended so the build can embed the revision. The Dockerfile runs the command-line interface on an Eclipse Temurin 21 JRE, and CI runs the Ant checkstyle, build and test targets on Windows. - SWF, SWC, GFx and Iggy inputs come from the user. Video display and export rely on the vlcj and JNA libraries, debugging needs a debug Flash Player, either the standalone player launched from FFDec or a remote player in listening mode, and AS3 editing through the Flex SDK is marked unstable. - The application is GPL-3.0-or-later and the ffdec_lib library LGPL-3.0, with bundled third-party libraries under their own licenses. Decompiled scripts and extracted assets keep the rights of the SWF’s owners. The README directs bug reports to the tracker on free-decompiler.com rather than GitHub issues. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Ruffle: a Rust reimplementation of Adobe Flash Player > Reimplements Adobe Flash Player in Rust so that SWF content, from ActionScript 1/2 (AVM1) to ActionScript 3 (AVM2), runs in a native desktop player or in browsers through WebAssembly, as a self-hosted script or a browser extension. Its contributor guide says behavior comes from observing Flash Player's output or from license-compatible sources such as Adobe's open avmplus code, and forbids decompiling Flash Player, Flash Professional or Animate. Regression tests run contributor-made SWFs and compare their trace output, and optionally rendered images, with captures from the official debug Flash Player. - Type: Case study - Targets: Game · Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Users supply the SWF files or the pages that embed them. Release assets cover Linux (x86_64, i686 and aarch64), macOS universal and Windows (x86 and x86_64) desktop builds, self-hosted web and browser-extension packages and a reproducible source archive; the README also points to Firefox and Chrome extensions, Flathub, npm and a separate Android project. - **Prerequisites:** Building needs the latest stable Rust (the workspace uses the 2024 edition) and Java on PATH to compile the ActionScript 3 built-in classes; Linux builds need ALSA, udev, fontconfig, FreeType and OpenSSL development packages. Web builds also need the wasm32-unknown-unknown target, Node.js with npm 7+, wasm-bindgen-cli 0.2.127 and Binaryen. Bundled scanner and exporter tools bulk-parse SWFs and render PNG screenshots. - **Scope:** The README says Ruffle supports ActionScript 1, 2 and 3 pretty well but is not finished. At review, the website's compatibility page reported 99% of the AVM1 language and 82% of its API, and 90% of the AVM2 language and 82% of its API, and acknowledged graphical inaccuracies in AVM1 content. Release at review: v0.7.1, published 2026-10-07 and described as equivalent to v0.7.0 apart from extension-publishing fixes; nightly builds continue, and the reviewed master commit is 73 commits ahead. - **Testing evidence:** Contributors are asked to commit each test SWF with its source, and expected trace output and screenshots come from running the debug Flash Player; known failures can be marked in a test's test.toml. These tests check Ruffle's behavior on authored test files. - **License:** Dual-licensed MIT or Apache-2.0 (GitHub reports NOASSERTION); LICENSE.md lists third-party dependency licenses, and the repository includes asc.jar from the Flex SDK to compile its ActionScript classes. SWF content keeps its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Littlebird.ai static home-page rebuild > Rebuilds the Littlebird.ai home page in plain HTML/CSS/JavaScript from captured markup and assets, with source-wired mobile navigation, FAQ toggles, scroll reveals and OS-dependent call-to-action presentation. It illustrates a bounded website reconstruction, with uncaptured routes and product functionality left outside the scope. - Type: Case study - Targets: Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The captured scope is the home page and five embedded demos. Pricing, blog and other uncaptured routes are absent; several download controls are placeholder links. This is not a recreation of the Littlebird desktop/mobile application or its backend. - The shipped site is plain HTML/CSS/JavaScript without a build step. The documented local preview and asset-integrity suite use Node.js 20+ and its standard library. - The original npm test checks local asset references, basic file and embedded-page completeness, and independence from the ignored capture directory. - The MIT file covers repository code. The README explicitly excludes captured third-party fonts, imagery, markup and copy from that grant and identifies this as an unofficial study rebuild. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### WasmLens: exploratory WebAssembly inspection > Python CLI with static paths for inspecting WebAssembly sections and function signatures, producing WAT-style instruction listings, and reconstructing limited C-like pseudocode. These are exploratory analysis aids for supported modules, not recovered original source or a complete WebAssembly runtime. - Type: Tool - Targets: Binary - Category: WebAssembly tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed package declares version 0.1.0 and Python >=3.10, with Typer, Rich, FastAPI, Uvicorn, Pydantic, NetworkX and python-multipart dependencies; pytest/httpx are development extras. The source includes an MIT LICENSE. Dependency lower bounds are declared. - The info, disasm and decompile commands read a supplied .wasm file through the same parser. That parser has no 0xFD SIMD decoding branch and may label unsupported opcodes as unknown. - The WAT-style module listing is not a lossless reassembly format: data segments are reduced to previews of up to 32 bytes and active offsets use a placeholder. The C-like reconstructor has no general fallback for unhandled instructions, uses only the first result type, and expresses branch labels in comments. - Its dispatch lacks handlers for operations including floating-point arithmetic and indirect calls, and an unhandled instruction can advance the program counter without implementing its effect. - Supply only modules you are permitted to analyze. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### synchrony > JavaScript cleaner and deobfuscator aimed mainly at output from javascript-obfuscator (obfuscator.io). It parses a script with acorn and runs a fixed pipeline of AST transformers that fold expressions, clean member accesses, remove dead branches, split sequence expressions, undo switch-based control-flow flattening and decode string arrays, re-implementing their base64 and RC4 decoders in TypeScript rather than executing the input. It ships on npm as deobfuscator with a synchrony CLI and a library API, and optional renaming replaces identifiers with generated word names rather than recovering the originals. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2.4.6, published to GitHub and to npm as deobfuscator on 2026-07-07, the same day as the reviewed master commit; the previous release, 2.4.5, dates from 2023-11-09. The README also points to a hosted web version at deobfuscate.relative.im. - Install with npm, yarn or pnpm, or from the Git repository; package.json declares no Node.js version. The CLI reads one file, writes .cleaned. unless --output is given, and offers --rename, --loose parsing, --ecma-version and --sourceType. A --config file is loaded with Node's require, so it runs as code, and a custom transformer list replaces the default pipeline; two jsconfuser transformers are available only that way and are not documented in the README. - The README warns that output from old javascript-obfuscator versions will likely not deobfuscate correctly and that there is no user configuration for the automatic string decoder. The repository has no test suite, and its latest commit removed the GitHub CI configuration. - GPL-3.0-only according to package.json and LICENSE.md. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### sourcemapper > Go command-line tool that recreates a web front end's original JavaScript source tree from a source map generated by webpack or a similar bundler, writing each embedded source file under the path the map records. It takes a .map file by URL or local path, walks a directory of .map files, or fetches a JavaScript file and follows its sourceMappingURL comment or SourceMap response header, including inline data: maps. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The project publishes no releases or tags. The README installs it with go install, a clone-and-build, or the BlackArch package; go.mod declares Go 1.16 and lists no third-party modules. The reviewed master commit, dated 2026-07-24, also adds the -dir batch mode and refuses to read a local path named by a remote sourceMappingURL. - Only one of -url, -jsurl or -dir is accepted per run, and -output is required. Remote fetches can carry extra request headers, go through a proxy or skip TLS verification. The README warns that a JavaScript file parsed with -jsurl can make sourcemapper send a GET request to any URL it names as its source map. - The input is a source map the user may inspect. The tool reads only the map's version, sources and sourcesContent fields, so maps without embedded sourcesContent are rejected and minified bundles without a map are out of scope; the mappings are not used, and output is the bundler's captured source text, not code verified against the deployed bundle. - BSD-3-Clause. Recovered front-end code remains subject to the site owner's rights. The README links a 2018 Pulse Security article describing its use for front-end source review in a penetration test. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### ngrev > Electron desktop application that statically analyzes an Angular project's TypeScript sources and draws interactive graphs of its NgModules, components, directives, pipes and providers and how they depend on each other, without running the application. A project is loaded through its tsconfig file; views move from the module tree to individual modules, templates and providers, with fuzzy symbol search and PNG export of the current graph. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Dormant: the latest release is v0.0.35 of 2021-01-18, with an unsigned macOS .dmg, a Linux AppImage and a Windows .exe. The reviewed master commit dates from 2021-07-26 and package.json already names an unreleased 0.0.36. The README calls it a community side project that the Angular team does not maintain. - Input is an Angular project's own source tree with its dependencies installed; for Angular CLI apps the README selects src/tsconfig.app.json. Applications must be compatible with the Ivy compiler, and versions older than Angular 11 are untested. The analyzer pins @angular/compiler-cli 11.0.3, ngast 0.6.2 and TypeScript 4.0.5, and support for later Angular releases is not documented. Deployed or minified bundles are not analyzed. - Source builds use Node.js and yarn (CI uses Node 12), Angular CLI 11 and Electron 11.1.0 packaged by electron-builder. The CI workflow runs a Spectron end-to-end test on macOS, Ubuntu and Windows that opens the app and parses a small Angular 11 fixture project; it does not check graph accuracy on real applications. - The README states MIT; LICENSE.md is the MIT text carried over from the angular-electron template, with its author's 2020 copyright line. Graphs show what ngast resolves from the sources, not runtime behaviour. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### jsluice > Bishop Fox's Go library and command-line tool that parses JavaScript with tree-sitter to recover the endpoints a script calls, judging values by how the code uses them rather than by regular expressions alone. URL extraction follows location assignments, window.open, fetch, XMLHttpRequest and jQuery request calls, keeps the HTTP method, headers and query or body parameters, and stands in a placeholder for values only known at run time. Other modes flag credential-shaped values, print syntax trees, run tree-sitter queries and reformat minified code. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The project publishes no releases or tags: the README installs the CLI with go install and the package with go get. go.mod declares Go 1.18 and pins go-tree-sitter, goquery, jsbeautifier-go and a WARC reader. The reviewed main commit dates from 2024-01-10; the repository has Go unit tests and JavaScript fixtures but no CI workflow. - Inputs are JavaScript files, HTML pages whose inline scripts it extracts, WARC archives, raw source on stdin, or http(s) URLs fetched with optional cookies and headers; output is JSONL. The analysis is static: concatenated runtime values appear as EXPR or a chosen placeholder, and the README calls the approach not foolproof, so extracted endpoints are leads to check against the application. - secrets mode ships active matchers only for AWS, GCP and GitHub key formats and Firebase configuration objects, plus user-supplied JSON pattern files; the README shows that unanchored custom patterns match unintended values. Matches are pattern hits, not confirmed credentials. - MIT, copyright 2023 Bishop Fox. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### REstringer > HUMAN Security's Node.js JavaScript deobfuscator. It identifies the obfuscation type, runs matching processors for obfuscator.io, Caesar Plus and array-based patterns, then iterates 40+ AST modules that rebuild strings, resolve expressions and calls and simplify control flow; unsafe modules evaluate code in a sandbox. It works as a CLI or library. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed HumanSecurity main commit (2025-12-07) is v2.1.0 plus one README edit removing the retired REstringer.tech web tool. The author now continues the project in his fork ctrl-escp/restringer, which the npm package lists as its repository: npm 2.2.0 (2026-05-09) and 2.3.0 (2026-08-30) come from it, and at 2.3.0 its README requires Node.js 22+, makes isolated-vm optional and adds Node, Deno and Bun subprocess sandboxes, so npm installs code newer than the reviewed source. - The reviewed source needs Node.js 20+ (22+ recommended) and installs as a global CLI or a module. It depends on flast, obfuscation-detector, commander and isolated-vm 5.0.4, a native module that CI builds with Python and g++. Output goes to stdout or -deob.js; -m caps iterations, and -c removes dead nodes, which README marks unsafe. - Input is an obfuscated JavaScript file or string. Safe modules transform the AST without evaluating code; unsafe modules evaluate parts of the input with eval() inside an isolated-vm sandbox to resolve expressions and calls. - GitHub Actions runs npm test on Node.js 20 and 22. Besides module and processor unit tests, the full suite deobfuscates 11 bundled obfuscated samples, among them obfuscator.io, JSFuck and Caesar Plus scripts, and compares each result with a stored expected output. - MIT, copyright 2025 HUMAN Security; the fork adds a 2026 copyright line for Ben Baryo. The repository was formerly PerimeterX/restringer, which now redirects to HumanSecurity/restringer. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Chrome extension source viewer (CRX Viewer) > Browser extension and web page by Rob Wu for inspecting packaged browser extensions without installing them. On Chrome Web Store, Opera, Firefox, Thunderbird and Microsoft Edge add-on pages it adds a button that downloads the package as a zip or opens it in a viewer, and links to extension packages hosted elsewhere can be opened as well. The viewer reads CRX, NEX, XPI and ZIP files: it lists and filters files, searches content by string or regular expression, beautifies and syntax-highlights code, previews images, opens nested zips, shows per-file hashes and derives the extension ID from the package key, signature or manifest. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Version 1.7.1, committed on 2026-09-01 as the reviewed master head, is the version in all three manifests: Manifest V3 builds for Chrome 88+ and Opera 74+, and a Manifest V2 build for Firefox 115+. The repository has no tags or releases; the README links the Chrome Web Store, Opera and addons.mozilla.org listings and an online demo page that opens local files or URLs. - Store listings are the documented install route; the README gives no build instructions. make.js builds the Chrome, Opera, Firefox and web packages with shelljs and the less compiler from npm and zips them with 7z. - The extension requests tabs, storage, context-menu, downloads and declarativeContent permissions and access to Google's CRX download endpoints, and asks for optional access to all sites before fetching packages hosted elsewhere. Its Firefox build routes addons.mozilla.org requests through services.addons.mozilla.org, a workaround the source documents for Firefox's restrictions on add-ons reading some Mozilla domains and still uses for non-public XPI files such as developer submissions. - The viewer shows package contents as published: beautification only reformats code and does not reverse obfuscation. Downloaded extensions keep their authors' rights and store terms. - MPL-2.0; bundled libraries such as zip.js, Prism, js-beautify and SparkMD5 keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### har-to-openapi > TypeScript library and CLI that infers OpenAPI 3.0 or 3.1 documents from HAR captures of HTTP traffic, loosely based on har2openapi. Requests are grouped into one document per domain, with options to turn IDs in paths into parameters, infer query, form and JSON body schemas from observed values, and merge several captures into the same operations. Optional settings extract reusable component schemas, keep multiple redacted examples, mark fields required only when every sample contains them, attach per-field observation counts as evidence and apply an OpenAPI Overlay so hand-written names and corrections survive regeneration. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main commit 432e096 from 2026-09-07, tagged v3.0.1 and published to npm the same day; v3.0.0, released a day earlier, added capture merging, reusable schemas, overlays, redaction, reports and requiredness evidence. Node.js 22.19.0+ is required; it installs from npm as a library or runs as the har-to-openapi command. CI tests Node 24 and the latest Node on Linux, macOS and Windows. - Input is one or more HAR files the user records, plus optional JSON or YAML configuration and overlay files. Without --multi-spec the CLI returns only the first domain's document. --validate and --strict check the result locally, and a conversion report lists counts and diagnostics for filtered entries, parse failures and schema fallbacks. - The README states that observations describe finite captures and that a field present in every capture does not establish an API contract, so requirements should be confirmed with the API owner and recorded in an overlay. Endpoints, parameters and responses absent from the captures do not appear, and the default requiredness setting keeps the earlier legacy behavior. - Generated documents copy captured values as examples unless examples are turned off or a redact list masks them; the README presents redaction as a step before sharing, and the reviewed commit closed further redaction gaps. Convert only traffic you are authorized to capture and analyze. - MIT. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### decode-js > Babel-based AST processor that turns obfuscated JavaScript back into readable source, with one target selected per run: javascript-obfuscator (obfuscator.io), JS-Confuser 2.x up to its high preset, sojson and its v7 variant for jsjiami.com.v7, sojson's jjencode variant, and a generic pass for unreachable code, nested blocks and constant expressions. A second, version-aware obfuscator.io target reports the encoder era it detects and returns nothing, with a reason, rather than a half-decoded program when a string-array layer cannot be read. The JS-Confuser notes list each transform it reverses and those, such as variable renaming, that destroy information and cannot be recovered. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags are published; the reviewed main commit of 2026-10-17 runs from source. package.json requires Node.js 26.x to match its native isolated-vm 7 dependency, whose build requirements the README asks users to check first. After npm i, the CLI runs as npm run decode -- -t with optional input and output paths, or through shortcuts such as deob, deobx, dejsc, deso and desov7. - Input is a single obfuscated script, input.js by default, and the README says the file must not contain other, non-obfuscated code. Coverage depends on the obfuscator and its version: the version-aware target covers the javascript-obfuscator 2.x eras and 5.5.0, leaves 3.0.0–4.2.2 unverified and reports samples in that range as unknown, and the JS-Confuser target cannot restore RenameVariables, RenameLabels or ObjectExtraction. - Decoding evaluates parts of the input: string-array decoders and JS-Confuser runtime helpers run inside isolated-vm sandboxes, but the obfuscator, sojson and sojsonv7 targets unpack an outer eval wrapper with Node.js eval in the decoder's own process. Treat inputs as untrusted code, and check recovered strings and control flow against the original script. - CI runs the Vitest suite on Node.js 26; its fixtures pair obfuscated samples, mostly generated from included source files, with expected decodes for the JS-Confuser, obfuscator.io and sojson v7 targets. GPL-3.0-or-later per the README, LICENSE and package.json. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### javascript-deobfuscator (LostMyCode) > Browser-based Vue app that restores the strings Obfuscator.io hides behind string-array lookups in JavaScript. The user pastes the obfuscated script and names its string array or decoder function, such as _0x439c; the tool classifies the calls as plain array indexing, a one-argument decoder or a two-argument RC4-style decoder, runs the script's own decoder to replace each call with its string literal, rewrites bracketed property access as dot notation and beautifies the result. The author hosts a demo at deo.sigr.io. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply the obfuscated script and identify the target function name yourself; a built-in tip shows call shapes such as _0x439c[103], _0x439c('0x4') and _0x439c('0x2','f]Xg'). The README covers only the Vue CLI 4 project commands (npm install, serve, build and lint), and a GitHub Actions workflow builds the site with Node.js 16 and deploys it to GitHub Pages. - **Scope:** Unversioned: package.json reports 0.1.0 and marks the package private, there are no GitHub releases or npm package, and the reviewed master commit of 2024-05-31 is the latest push. - **Limits:** Only these string-array patterns are handled, with a fourth pattern marked experimental, and unrecognized input returns an error. The code has no passes for control-flow flattening, proxy functions, dead code or Obfuscator.io's other transformations, so those remain in the output. Decoding evaluates the pasted script with eval inside a browser web worker, so the input's own code runs; it is not a static AST transformation. The page template also loads js-beautify from cdnjs and a Google Analytics tag. - **Testing evidence:** The repository has no tests, and the README's only result is an example screenshot. - **License:** The repository has no license file and GitHub detects no license, so it grants no stated reuse terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### minusone > Airbus CERT's Rust deobfuscation engine for scripts: it parses PowerShell or JavaScript with tree-sitter, applies rules that infer the values of syntax-tree nodes and prints a simplified script. The PowerShell rules fold arithmetic, string operations, casts, -join, -replace and format operators, Base64 and UTF decoding, predictable variables and loops, and also resolve Gzip or Deflate streams and AES decryption when the data and key are in the script; the newer JavaScript rules cover literals, operators, string and array built-ins, atob and btoa, Buffer calls, predictable function calls and JSFuck constructs. The CLI can list, select or skip rules and export every rewrite step as HTML or JSON, and Python and WebAssembly bindings embed the engine, including in an online version linked from the README. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No prebuilt CLI binaries: the latest GitHub release, v0.4.2 from 2025-10-01, has no attached files, and the published packages are minusone 0.4.1 on crates.io, pyminusone 0.4.1 on PyPI with Linux x86_64 and Windows wheels, and minusonejs 0.5.0 on npm. The reviewed main commit is 538 commits past v0.4.2 and declares the core library 0.5.0 and minusone-cli 0.6.1. - Build with Cargo; the crates use Rust edition 2024, Cargo.lock is not committed, and the PowerShell grammar comes from an unpinned Git dependency on a tree-sitter-powershell fork. The CLI needs --lang powershell or --lang javascript. The project's devenv/Nix environment uses nightly Rust, the Python bindings build with maturin, and the WebAssembly module targets wasm32-wasip2 and is transpiled to JavaScript with jco. - The README still lists only PowerShell as supported, names basic JavaScript support as a roadmap item and links rule files at older src/ paths; the JavaScript backend dates from March 2026, after the crates.io and PyPI packages and the v0.4.2 release. Rules rewrite the script statically from values they can infer, and the analyst supplies the scripts; the samples folder holds only small JSFuck test files next to their plain sources. - CI runs devenv test, which runs cargo test and the Python binding test script; the core has unit tests for both languages. MIT license; Cargo metadata names Airbus CERT as author, and the LICENSE copyright line names Sylvain Peyrefitte. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. #### JS-Deobfuscator (0x1Avram) > Node.js deobfuscator for JavaScript produced by Timofey Kachalov's javascript-obfuscator, also offered as obfuscator.io. It parses the sample with esprima and runs eleven stages named after the obfuscator's own, which remove injected self-defending and debug-protection code, unwind control-flow flattening and dead-code injection, restore converted literals and object keys, replace string-array calls with the decoded strings, simplify the result and recursively process code passed to eval. String-array code is detected automatically or supplied as separate files, and an Examples folder pairs original, obfuscated and deobfuscated samples. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Inactive since the reviewed main commit, a README update on 2023-04-17. The last release, 1.0.7 (2022-12-29), attaches binaries.zip with standalone Windows and Linux builds made with pkg, while package.json still reports 1.0.2. The README says it was developed with Node.js 16.15 and worked with obfuscator versions current at the time; output from older obfuscator versions may produce a different AST. - Run from source after npm install (esprima, escodegen, esquery, estraverse, winston and yargs) with node index.js -i input -o output. When automatic detection fails, the string array, its wrappers, the wrapper names and the rotate code are passed as separate files with -s, -w, -n and -r. esprima does not parse all newer JavaScript syntax, so the README suggests transpiling such input with Babel first. - The README warns that the code is not secure and should run only in an isolated environment such as a virtual machine: string-array decoding evaluates code taken from the sample with eval inside the deobfuscator's own Node.js process. The identifier- and property-renaming stages are empty placeholders, so obfuscated names are not recovered. - Supply the obfuscated script yourself. The Examples text files are derived from small snippets, javascript-obfuscator's example script (BSD-2-Clause) and javascript-algorithms (MIT), with both licenses included. - MIT (LICENSE). A different project from ben-sb javascript-deobfuscator, whose npm package is also named js-deobfuscator; this one is used from its repository or release binaries. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### HTTP Toolkit > Open-source HTTP(S) debugging proxy for Windows, Linux and macOS that sets up interception for browsers, terminals, backend runtimes, Electron apps and Android devices, then shows the full headers and body of every request and response with body decoding, inline header documentation and filtering. Its transparent proxy handles plain HTTP, HTTPS, HTTP/2 and WebSockets on one port; breakpoints rewrite live requests or responses, and a built-in client sends custom requests. This repository is the project's umbrella README and issue tracker, while the UI, server, Mockttp proxy library, Android app and desktop shell live in sibling repositories. - Type: Tool - Targets: App · Protocol · Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - At the reviewed commit this umbrella repository holds only the README, a security policy and a demo animation, and serves as the project's issue tracker. The product is built from sibling repositories: httptoolkit-ui (TypeScript and React), httptoolkit-server (Node.js, whose interceptor list covers Chromium-based browsers, Firefox, terminals, Electron, Android over ADB, Frida on Android and iOS, JVM processes and Docker containers), the Mockttp proxy library, the Android app and the Electron desktop shell. - Latest desktop release at review: v1.27.3, published 2026-10-20, with a Windows installer and zip, macOS x64 and arm64 DMGs and Linux x64 and arm64 AppImage, deb, rpm and zip builds. The desktop shell bundles the server and opens the UI in Electron; the server can also run standalone as a CLI with the hosted web UI opened in a browser, and both update themselves separately from the desktop executable. - HTTPS inspection needs the client to trust HTTP Toolkit's CA certificate: interceptors launch preconfigured browsers, terminals and apps, and the server's certificate check downloads or installs the certificate where it is not yet trusted. The Android app trusts the certificate and forwards device traffic through a local VPN; its README says a rooted device is not required but widens the real app traffic that can be tested. Inspect only traffic from your own clients and devices or ones you are authorized to test. - The pricing page lists interception of all supported clients, raw inspection, filtering, manual rewriting and manual requests in the free Hobbyist tier, while mock rules and automatic transforms, edit-and-resend, rule and traffic import/export (including HAR), API validation and advanced proxy settings such as TLS passthrough and upstream proxies need a paid Pro account. The README describes the HTTP Toolkit-specific components as AGPL-3.0 and the reusable libraries as Apache-2.0 or MIT; this repository has no license file, and the desktop README offers its binaries under AGPL-3.0 or CC BY-ND 4.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Javascript Deobfuscator > Browser-based workbench for deobfuscating JavaScript by hand, also hosted on GitHub Pages, that pairs a Monaco editor with step-by-step rewriting and evaluation commands instead of a one-click pipeline. Formatting commands beautify the code and, on a selection or the whole file, decode escaped strings, convert hex numbers, turn bracketed property access into dot notation and rename _0x-style identifiers to short names; evaluation commands push declarations onto a code stack, evaluate a selected expression against it and substitute JSON results, replace captured variables automatically and collapse chains of aliases. The README says the process is not automatic and expects the analyst to know JavaScript. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags; the reviewed master commit of 2023-06-29 is the latest code change, and a CI workflow builds the Vite site on each push to master and deploys it to the gh-pages branch that serves the hosted copy. Running it locally needs Node.js and npm for vite serve or vite build; package.json requires Monaco Editor ^0.39.0, js-beautify ^1.14.8 and Vite ^4.3.9 and declares no Node.js version. - The evaluation commands pass the selected code and the code stack to JavaScript's eval in the page itself, so those parts of the obfuscated script run unsandboxed in the user's browser; the README suggests keeping the browser console open. The string, number and renaming helpers, and the console-only experimental ones, work by regular expressions, and the README warns that they can corrupt complex strings and that hex renaming does not detect name collisions. - Users paste in the script they analyze, and the editor contents are kept only in the tab's sessionStorage. package.json declares MIT, but the repository has no license file and GitHub detects none. ##### Primary sources 1. 2. 3. 4. 5. 6. #### go-fAST > Go library for parsing, traversing, transforming and regenerating JavaScript abstract syntax trees, which its README presents for code analysis, obfuscation and deobfuscation. Its parser builds on goja's parsing code, a generated SWC-style visitor API supports depth-first rewriting and cloning of nodes, a resolver tracks scopes and bindings, the ext package adds node-removal, side-effect and value-inference helpers, and a generator prints JavaScript from the tree. The documentation calls it a lightweight, faster alternative to Babel that deliberately omits parent, sibling and reference maps and automated mutation helpers. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest tag at review: v0.1.0, created 2026-07-02 and served by the Go module proxy under the lowercase module path github.com/t14raptor/go-fast; there are no GitHub releases. The reviewed master commit of 2026-10-04 is 11 commits ahead of that tag, with parser, resolver and generator fixes and a new PreserveParens parse option. - go.mod requires Go 1.24 and depends only on nukilabs/ftoa and nukilabs/unicodeid. Unit tests cover the parser, generator, resolver and statement helpers, but the only CI workflow checks that the generated union, visitor and clone files are up to date and does not run them. Guides and example visitors, such as unrolling sequence expressions and expanding variable declarations, are on the project's GitBook documentation site. - It is a library rather than a ready-made deobfuscator: users write their own visitors for the transformations they need and supply the JavaScript they analyze. The README does not state which ECMAScript versions it parses. - MIT (copyright 2024 T14Raptor); the README credits goja for parsing code and SWC for the visitor API design. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Hetty > Open-source HTTP toolkit for security research, which its author aims to make an alternative to Burp Suite Pro. A single Go binary runs a machine-in-the-middle HTTP proxy backed by its own generated root CA, logs proxied requests and responses in per-project databases with search filters and scope rules, and serves a web admin interface. From that interface an analyst can hold requests and responses for manual review, then edit, forward or cancel them, or copy logged requests into a Sender module to edit and resend them. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.7.0, published 2022-03-29, with Linux, macOS and Windows builds for x86_64 and arm64; the README also lists Homebrew, snap and Scoop packages and Docker images. The reviewed main commit (2026-06-27) is 14 commits ahead of that release, among them the January 2025 switch from BadgerDB to a single bbolt database file (by default hetty.db in the .hetty folder of the user's home directory). The hetty.xyz getting-started guide still describes the older BadgerDB directory. The README says Hetty is under active development. - Run hetty, open the admin interface on port 8080 and create a project; only then are proxied requests logged. By default the server listens on all interfaces (:8080). On first start Hetty creates a root CA certificate and private key in that .hetty folder. To inspect HTTPS from their own browser, analysts trust that CA (hetty cert install adds it to the system trust store, and optionally to Firefox and Java) or use --chrome, which launches Chrome with the proxy settings applied and certificate errors ignored. Hetty logs only traffic from clients the analyst points at the proxy; the docs recommend the --chrome profile or a browser proxy extension over system-wide proxy settings. - Source builds need Go 1.23 and Yarn: the Makefile builds the Next.js admin interface and embeds it into the Go binary with CGO disabled. The README's link to source-build instructions is still marked as coming soon. - MIT license (© 2019–2025 Hetty Software). The README's feature list covers proxy logs with search, the request sender, interception, scope and project storage. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### debundle > Node.js command-line tool that unpacks JavaScript bundles produced by Browserify or Webpack back into a tree of module files, so a bundle can be read file by file instead of as one script. A JSON configuration gives the bundle type, the entry-point module and optional knownPaths that map numeric module IDs to output files or node_modules packages, and it can rewrite a minifier's renamed require identifier inline or through a variable so the output can be rebundled or run in Node. The README says it was built to learn how bundles are structured for a reverse-engineering project and that debundling is lossy: package.json settings and Webpack module names are not recovered, and minified code stays minified. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README calls this a research project that is no longer maintained and says it works in a laboratory environment most of the time but often fails on real-world bundles. The reviewed master commit dates from 2018-06-16; npm's latest debundle release is 0.5.4 of 2017-09-12, newer than the repository's v0.5.3 tag and package.json, and unfinished v2 branches were last updated in 2020. - Installs with npm i -g debundle and runs as debundle -i -o -c . package.json requires Node 6 or newer, .nvmrc and the Travis CI configuration use Node 6, and the dependencies date from that period, such as acorn 4 and recast 0.5. - Only Browserify bundles and Webpack bundles whose modules are passed as an array are decoded: the Webpack decoder aborts when the module list is not an array, and other bundlers are not officially supported, although the moduleAst option can point to a module list with the same layout. Webpack output files are named after module IDs unless knownPaths names them. - test_bundles/ holds four small sample bundles with their configurations and original sources, which CI debundles with test_bundles/run_test.sh; the comparison with the original sources is commented out, so CI only checks that debundling finishes. Users supply the bundles to unpack, and the README's legal note warns that some terms of service forbid reverse engineering. - package.json and the npm package declare ISC, but the repository has no license file and GitHub detects none; src/extern/replace-method is a vendored MIT-licensed module by Hugh Kennedy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### JStillery > Minded Security's JavaScript deobfuscator, which Stefano Di Paola forked from esdeobfuscate in 2015, simplifies scripts by partial evaluation on an esprima AST. It folds constant and string expressions, propagates known values through variables and pure function calls, evaluates calls to built-in String, Array and Number methods and atob/btoa, and parses string arguments passed to eval back into code. It runs as a command-line tool on a file or stdin, as an Express server with a web UI and a REST endpoint, or as a browserified library. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The newest commit on master dates from 2019-04-22, and there are no releases or tags. The 2015 Minded Security blog post that the README links describes JStillery as an internal tool used, among other things, to analyze JavaScript malware samples and normalize scripts for classification. The README also links a hosted REPL at mindedsecurity.github.io/jstillery. - Needs Node.js and npm install; package.json declares no Node.js version and leaves esprima, escodegen and esmangle unpinned, and no lockfile is committed, so each install takes their latest releases. The CLI prints the original and the deobfuscated code. npm run build_server copies the web UI and browserifies the library, and npm run start_server then serves the UI and a /deobfuscate endpoint on port 3001, with server_config.json allowing any origin by default. - Partial evaluation is on by default (the USE_PARTIAL environment variable turns it off only when set to an empty string) and passes selected expressions from the input to Node's vm.runInNewContext. Node's documentation says the vm module is not a security mechanism, so analyze untrusted samples in an isolated environment. - JStillery predates the newer deobfuscators, such as webcrack, javascript-deobfuscator and the Obfuscator.io Deobfuscator, and its documentation does not mention bundle unpacking, string-array decoding or control-flow unflattening. The mocha suite in tests/ compares output for samples including JSFuck, aaencode, jjencode and Dean Edwards' packer with stored expected results, some of which remain only partly simplified. - LICENSE and the README state GPL-3.0, while both package.json files declare ISC; src/jstiller.js keeps the BSD-style notice of esdeobfuscate. The web UI vendors jQuery, Bootstrap, CodeMirror, Font Awesome and js-beautify. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### box.js > Node.js utility for studying malicious JavaScript that runs a sample inside an emulated Windows JScript environment, with WScript, ActiveX, filesystem, registry, WMI and HTTP objects emulated and source rewriting that exposes eval calls and conditional-compilation code. Each analysis writes a results folder with the URLs requested and those that led to an executable payload, every code snippet executed (JavaScript, cmd.exe and PowerShell), files written with their types and hashes, and a list of IOCs; by default downloads are answered with simulated 404 errors so that fallback sites are revealed. Batch runs, an optional prepended file of browser-object stubs, a Docker image, a REST API and export to VirusTotal or Cuckoo support triage at scale. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest npm release at review: 1.9.29, published 2026-07-02 alongside the reviewed master commit, which adapts the sandbox to the latest vm2 package; RELEASE_NOTES.txt numbers the same releases 1.19.x. Recent development is by Kirk Sayre through pull requests. Installs with npm install box-js --global; package.json declares Node.js 6 or later and depends on vm2 >=3.9.19, jsdom 16, acorn and escodegen, and the READMEs list REMnux and BlackArch packages and Cuckoo, CAPE and IntelOwl integrations. - Input is the analyst's own sample file or folder of samples; the repository ships no malware samples, only emulator code, a generated Windows process list (emulator/processes.json), source-rewriting patches and a mocha test file. Encoded .jse files must first be decoded with the bundled decoder.c, MrBrownstone's 2000–2005 Script Encoder decoder, compiled with a C compiler; VBScript is not parsed as input. - Samples run inside vm2, with a 10-second default timeout; --dangerous-vm switches to Node's vm module, which the README says can be broken. --download makes real requests to the URLs a sample contacts, so leave it off unless the network is isolated. The README recommends a temporary Docker container for further isolation; integrations/docker/Dockerfile is based on node:8-alpine, and the REST API server needs a user who can start Docker containers. - Emulation is incomplete by design: unsupported ActiveX objects or methods stop the analysis until someone implements them, and samples with environment or date checks may show no behaviour. MIT; decoder.c keeps its author's notice. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### breakinggood > breakinggood captures a website's screenshots, cleaned DOM, computed design values, images, and XHR/fetch responses, then generates a Vite, React, and Tailwind rebuild with a mock API replaying observed JSON. Its CLI and MCP server expose site capture alongside a separate Git repository setup workflow. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Node 20 or newer and Git; website mode needs an installed Chrome or Edge browser and a configured model provider. - **Limits:** Pages behind logins, strong bot protection, or mostly rendered with canvas/WebGL may capture poorly. - **License:** MIT license. ##### Primary sources 1. #### Sheypoor MCP: mapping marketplace APIs from browser traffic > Sheypoor MCP implements a client and MCP server for the Sheypoor classifieds site using API behavior documented from browser traffic. Its reference records observed endpoints, request headers, cookies and phone-based login. The server exposes listing search and details, account functions, chat room lists and unread message counts to MCP clients. - Type: Case study - Targets: Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Node.js 20.11+ is indicated for the MCP server. - **Prerequisites:** Account features require Sheypoor phone and SMS authentication. - **License:** MIT License. ##### Primary sources 1. 2. 3. #### ZCode-Android: reconstructing the ZCode remote-control client > ZCode-Android recreates ZCode remote control on Android from captured traffic and analysis of its official web page. Its Kotlin client implements WebSocket relay, HMAC pairing, IPC encoding, fragmented RPC frames and Conversation V4 session messages. - Type: Case study - Targets: App · Protocol · Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Android 12+ on arm64-v8a and a desktop ZCode pairing link are required. - **Prerequisites:** Building requires JDK 17 and Android SDK 35. - **Limits:** Changes to the official web protocol may break the client. - **License:** The README declares an MIT licence. ##### Primary sources 1. #### Power BI API Scraper: decoding a published report query format > Power BI API Scraper reconstructs the web client's undocumented query and response format for published reports. It sends SemanticQueryDataShapeCommand requests, follows restart tokens and expands bitsets and ValueDicts into CSV rows. The included example is hardcoded for an Ohio liquor permit report. - Type: Case study - Targets: Protocol · Website - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.7+ and requests; access to a public Power BI report. - **Scope:** The included query, resource key and model ID are hardcoded for one report; retargeting requires code changes. - **Limits:** Non-200 responses stop the run, and overlapping pages are not deduplicated. - **License:** MIT License. ##### Primary sources 1. #### Facebook BitMap Codec > Facebook BitMap Codec encodes and decodes Facebook web API parameter values using the project's reverse-engineered bitmap, run-length and custom Base64 scheme. Its Python module exposes a FacebookCodec class for converting ID lists to encoded strings and back across parameters including __dyn and __csr. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.8+ and the FCodec.py module are required. - **Limits:** The author claims lossless conversion and compatibility with the listed bitmap parameters. - **License:** No licence file in the repository. ##### Primary sources 1. #### DevLens Ultra > DevLens Ultra is a Chrome extension for inspecting and extracting website component structure. It analyzes selected DOM elements, computed styles and framework state such as React Fiber props, then generates React JSX and Tailwind classes. An optional AI step refines selected snippets through a configured provider. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Chrome with extension Developer Mode to load the unpacked extension. - **Prerequisites:** AI refinement requires a configured provider API key and base URL. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### AppThreat wasm-tools > wasm-tools is a pure-Python parser and disassembler for WebAssembly core modules and Component Model binaries. It reports sections, decoded instructions, strings with memory provenance, imports, exports and static call graphs, then adds heuristic capability and risk findings in JSON. - Type: Tool - Targets: Binary - Category: WebAssembly tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10 or later is specified in pyproject.toml. - **Limits:** Text-format .wat parsing and specification validation are excluded. - **License:** MIT license; the author raises uncertainty about third-party specification text in the AI-assisted code provenance. ##### Primary sources 1. 2. #### web-crawler ReverseAgent > web-crawler includes ReverseAgent for investigating website JavaScript and request signing. It hooks fetch, XHR, cookies, crypto.subtle and webpack activity in a browser, captures traffic, separates webpack modules and uses an LLM to reimplement a discovered signature algorithm in Python. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10 or newer. - **Prerequisites:** ReverseAgent uses CamoufoxFetcher and a compatible LLM service; optional browser dependencies are required for that path. - **License:** MIT license. ##### Primary sources 1. 2. #### Mirrorframe > Mirrorframe captures webpages with Playwright and reconstructs their observed layout and behavior as a self-contained React app. It records computed styles, assets, motion and selected interaction states, then compares rendered nodes and replayed states against the original with image diffs. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Node.js 18 or later and Playwright Chromium are required. - **Limits:** The 0.x CLI, genome schema and report format may change. - **Limits:** Live Canvas, WebGL and WebGPU drawing programs are not reconstructed; Canvas output is a captured still. - **License:** MIT License. ##### Primary sources 1. 2. #### unwebpack-sourcemap > unwebpack-sourcemap is a Python script that recovers TypeScript, JSX, and other source files from Webpack source maps. It accepts local or remote source maps and can search a web page's scripts for them. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python 3, BeautifulSoup4, and requests. - Intended for TypeScript with React or Vue templates. - The repository is archived and is not being maintained. - Licensed under MIT. ##### Primary sources 1. #### Wirebrowser > Wirebrowser is a desktop tool for instrumenting browser JavaScript through the Chrome DevTools Protocol. It can hook functions, trace where values originate, search and modify runtime objects, and intercept or replay HTTP traffic. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use a macOS, Windows, or Linux desktop build, or build from source with npm. - On Linux with the AppImage, keep the installed Chrome extension in its visible directory under the home directory. - The repository declares the MIT License. ##### Primary sources 1. #### Thug > Thug is a Python low-interaction honeyclient that mimics a web browser to detect and emulate malicious content. It supports the study of client-side attacks. - Type: Tool - Targets: Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - GPL-2.0 per the README. ##### Primary sources 1. #### spy-debugger > spy-debugger is a tool for remotely debugging pages in mobile browsers and app WebViews while capturing HTTP and HTTPS traffic. It injects weinre debugging code into HTML responses and can use its built-in proxy or an external one. - Type: Tool - Targets: App · Website - Category: Website analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Install spy-debugger with npm on a computer. - Connect the phone and computer to the same network and configure the phone's HTTP proxy. - Install a certificate on the phone for HTTPS debugging; on iOS 15, the tool cannot identify whether a request came from a browser. - License: MIT. ##### Primary sources 1. ### Games (318) #### DX-Ball: reconstruct sound panning > Recover one sound-pan function from instructions and constants; upstream cites 3,205 cases and a 63-byte match. - Type: Case study - Targets: Binary · Game - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The matching DX-Ball 1.07 executable and the documented native-analysis environment. - **Testing evidence:** The cited reconstruction checks concern one function. ##### Primary sources 1. #### TH04: recover a DOS bullet-ring helper > Inspect a 16-bit PC-98 DOS helper and relate its angle calculation to a pinned reconstruction and historical compiler checks. - Type: Case study - Targets: Binary · Game - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The matching original TH04 MAIN.EXE and the documented Ghidra DOS load profile. - **Scope:** The showcase covers one helper. ##### Primary sources 1. #### Super Mario 64 DS: matching decompilation with relocation checks > Reconstructs Super Mario 64 DS functions as C/C++ and permitted assembly primitives, comparing compiled output with a user-supplied cartridge dump. Independent relocation-destination checks strengthen the matching gate; integration into the PC port is tracked separately. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s cartridge dump, the pinned mwccarm matching compiler, its separate linker/setup and Python tooling such as ndspy, Capstone and pyelftools. - **Testing evidence:** The pinned README reports 11,389/11,389 matched functions, including 108 byte-exact assembly primitives, but only 10,957 linked into the PC port. These counters describe different gates. - **Limits:** The same README retains older near-finished prose, and port/README.md describes a historical smoke-build stage. Treat matching and port-playability statements as source-specific reports, not a verified complete playable port. - **Attribution:** Agent-assisted matching is documented, together with source review and relocation checks. - **License:** The repository has an MIT license; original game data and external compiler rights remain separate. ##### Primary sources 1. 2. 3. 4. 5. #### GoldenEye 007: an agent-assisted native port from a decompilation > Builds a native PC port on the existing GoldenEye 007 decompilation, with a host platform layer and assets extracted from the user’s ROM. The project documents agent collaboration, rendering comparisons, playtest scope and unresolved platform support. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The reviewed v0.5.0 documentation supports Windows 10/11 x64 and x86-64 Linux/Steam Deck with glibc 2.31+; both need OpenGL 3.0 drivers. macOS and ARM builds remain planned, despite the broader repository About description. - **Prerequisites:** Release packages require the user’s US NTSC-U ROM; PAL and Japanese releases are not yet supported. This is a native port from decompiled source, not static binary recompilation. - **Prerequisites:** Source builds need CMake 3.16+, C/C++, SDL2, zlib, OpenGL, Python 3 and the documented asset-extraction tools. - **Testing evidence:** v0.5.0 playtests were campaign spot-checks and multiplayer sessions; the full Agent-difficulty campaign was last reported end-to-end at v0.4.0. - **License:** MIT covers original port/build/tooling/docs work only. NOTICE states inherited n64decomp/007 material has no explicit upstream license, and vendored components have separate terms; the MIT file is not a blanket grant over all contents. ##### Primary sources 1. 2. 3. 4. #### ssbu-recomp: static recompilation with explicit mode limits > Translates Super Smash Bros. Ultimate 13.0.4 AArch64 code ahead of time and supplies a Windows runtime with Vulkan/OpenGL rendering. It also reconstructs selected fighter scripts as editable C++ and compares translated/source behavior through differential and deterministic tests. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Running requires Windows 10/11 x64, a Vulkan 1.3-capable GPU and the user’s own 13.0.4 game dump. Linux and Steam Deck support have not started. - **Prerequisites:** Building requires Python 3.10+ with the documented packages, LLVM/clang 9.0.0 (8.0.0 is also documented as working), MSVC/Windows SDK, SDL3, Vulkan headers, glslang and reference tooling. Music needs libopus; movies need Media Foundation, VP9 Video Extensions and Web Media Extensions 2.x, with Media Feature Pack additionally required on Windows N. - **Limits:** Only some modes have reported play coverage. Adventure maps/fights and several multiplayer modes are untested; online is unavailable. Physical controllers are not yet confirmed. - **Testing evidence:** The author credits Claude agents. Reported frame rates, differential equivalence and selected fighter match traces. - **License:** The README grants GPL version 3 or later. The public repository supplies tools/runtime rather than the game dump, keys or assets; game-derived output is a separate requirement. ##### Primary sources 1. 2. 3. #### KartPad: platform integration for a Mario Kart Wii recompilation > Builds Apple and Android integration around WiiCompiled’s ahead-of-time translation of Mario Kart Wii, with native graphics, input and optional Retro Rewind support. Its status and rights documents distinguish platform acceptance, unresolved device defects and game-content requirements. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires user-supplied supported PAL RMCP01 revision 0 game data. Retro Rewind 6.13.3 needs matching separately obtained content and a compatible compiled profile in the reviewed 0.8.3 build. - **Prerequisites:** Android targets ARM64/Vulkan on Android 9+; iPhone/iPad require iOS/iPadOS 16+. The README documents a PadMint/source route for Apple Silicon macOS 14+, while the pinned status table still labels Mac experimental. tvOS 17+ is also an experimental preview. - **Limits:** Physical-device and emulator checks cover specific builds and devices. Missing graphics, freezes, controller and performance problems remain on some hardware. - **Attribution:** Substantial AI assistance is disclosed without an audited generated-code percentage. - **License:** KartPad-owned work is GPL-3.0-only, with upstream component terms retained. RIGHTS_AND_LICENSES separates software obligations from game-derived logic and assets; GPL does not relicense Mario Kart Wii. ##### Primary sources 1. 2. 3. 4. 5. #### BattleShip: an AI-assisted Super Smash Bros. native port > Ports the existing Super Smash Bros. N64 decompilation using libultraship and Torch. The author’s earlier README describes agent-built graphics/audio comparison tools and differential debugging against emulator behavior, rather than claiming AI recovered the game from a cartridge without prior community work. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own Super Smash Bros. N64 dump matching a documented hash: US NTSC-U v1.0 (NALE) or Japanese v1.0 (NALJ). Each region is a separate build; Torch extracts assets locally during a source build or on a packaged build’s first run. - **Prerequisites:** The README lists native Windows, Linux, Apple Silicon macOS and Android builds; native C mods and the GameCube adapter driver are desktop-only. BUILDING.md covers desktop source builds with Git/submodules, CMake and Python 3, plus Ninja on Linux/macOS or Visual Studio 2022 and the Windows SDK on Windows. - **Attribution:** The author reports developing the port alone with Claude until v0.3-beta and says it is no longer a pure AI project, crediting community testing, fixes and features; these statements are self-reported. - **License:** The LICENSE grants MIT only to port-specific code, build scripts, tools and docs. The decomp submodule and decomp-derived files defer to the upstream decompilation, which publishes no explicit license; libultraship/Torch, bundled fonts and controller mappings keep their own terms; game rights are separate. ##### Primary sources 1. 2. 3. 4. #### Agent decompilation: a byte-matching retrospective > Maurice Heumann describes replacing plausible-looking agent output with compiler-based checks of reconstructed functions, relocations, data and types. The retrospective reports 99% function presence and 83% of all functions byte-exact, while keeping the reconstruction code private. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Catalog page: ##### Requirements & limits - **Scope:** Author retrospective dated 2026-10-09; the reviewed article leaves the game unnamed. - **Scope:** The project uses the original compiler and binary as references; no public implementation or reproducible artifact is supplied. - **Testing evidence:** Coverage figures and runtime success are author-reported. - **Scope:** A documented case study. ##### Primary sources 1. #### Snowboard Kids 2: an LLM-assisted N64 matching decompilation > A public matching decompilation of the N64 game Snowboard Kids 2, begun in 2024 with community decompilation tools. The author’s dated posts document Claude, Codex and GLM workflows, including headless one-shot loops, similarity-based function scheduling and hook-guarded, hash-checked builds, through a reported complete function match. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building needs the user’s own big-endian Snowboard Kids 2 ROM, make, Python 3, MIPS binutils and the toolchain installed by make setup; the README reports testing only on x86 Debian/Ubuntu and macOS. It states the repository has no game assets or assembly, although the reviewed tree tracks menu-sprite PNG and palette files under assets/. - **Testing evidence:** Progress figures are author-reported. The 2026-02-16 post describes matched code rising from about 25% to 58% with one-shot loops, then to about 75%, with 124 functions left; the 2026-05-17 post reports every function matched. The 2025-11-27 post’s 79% figure was a projection. - **Limits:** Byte-matching C is not documented or idiomatic source. The 2026-05-17 post notes remaining __asm__ coercions, many generated names and structures still needing cleanup, and graphics/audio assets mostly handled as binary blobs; the 2026-02-16 post describes brittle agent matches. - **Attribution:** Agent assistance is not quantified beyond the posts. The 2026-05-17 post dates the first commit to September 2024 and credits four named N64 decomp community members with significant contributions, especially across the final ten functions; the 2025-11-04 post describes a human-led loop. The work relies on community tools such as splat, m2c, decomp.me, asm-differ and decomp-permuter. - **License:** No license file is present at the reviewed commit. The June 2026 Snowboard Kids 2: Recompiled release and the August 2026 decompilation of the original Snowboard Kids are separate projects. ##### Primary sources 1. 2. 3. 4. 5. 6. #### IsaacRecomp: translating Flash game bytecode to native C++ > Translates The Binding of Isaac’s Flash AVM1 bytecode into C++ functions and supplies a native rendering/input runtime. The project reads graphics and audio from the user’s original game and documents deterministic input, headless runs and screenshot regression checks. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s original Steam Isaac.exe; Wrath of the Lamb and Eternal Edition depend on the corresponding game version. This is ahead-of-time translation, not recovery of the original authored ActionScript project. - **Prerequisites:** Documented targets include 64-bit Windows/Linux, Android 7.0+ on 64-bit ARM and Switch homebrew. Source builds use CMake/Ninja and SDL2/OpenGL 3.3 or ES 3.0; mobile/console builds have separate SDK/toolchain requirements. - **Testing evidence:** The author credits AI assistance and reports 30 Hz game logic with higher-rate interpolated rendering. - **Testing evidence:** Reported regression tests compare deterministic logic and screenshots across engine revisions. - **License:** MIT covers the authored engine, tools, build files and docs only. LICENSE explicitly excludes gen/, gen720/, patch1080/ and patch720/ translated game-code directories; third-party and original-game rights remain separate. ##### Primary sources 1. 2. 3. 4. #### Nanolathe: a documented Total Annihilation engine reimplementation > Reimplements a Total Annihilation-compatible strategy-game engine in Go, with public file-format research and separate gameplay profiles. It distinguishes intended retail 3.1 behavior from community-patch research and deliberate modern changes, and separates synthetic checks from tests requiring original game data. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Native use requires the user’s installed Total Annihilation HPI archives. The reference installation includes Core Contingency, Battle Tactics and patch 3.1; other combinations remain under testing. - **Prerequisites:** The pinned source requires Go 1.27.1 or newer and Ebitengine 2.10.5. Native targets include Windows, macOS 13+ and Linux with graphical/audio libraries; the browser build remains experimental. - **Scope:** The project is beta. Modern rules intentionally change behavior, while Strict 3.1 expresses a compatibility aim. - **Testing evidence:** Synthetic tests run without retail assets; the separate retail tier requires an installed game. - **License:** Original engine code is MIT; original game assets and dependency licenses are separate. The publication note describes curated integration snapshots, omitted raw research and unresolved attribution questions. ##### Primary sources 1. 2. 3. 4. 5. 6. #### TH08: exact-source reconstruction and separately tested ports > Reconstructs the original Japanese Touhou 8 version 1.00d against its binary and original compiler, then adapts the recovered code for other platforms. Source presence, strict function matching, whole-executable identity and playable-port checks are recorded as different milestones. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Exact checks require the user’s original Japanese TH08 1.00d executable and Visual C++ .NET 2002 toolchain. Ledgers and analysis helpers need Python 3.11+; Linux/macOS toolchain setup also needs Wine and msiextract. Playable products still need original game data. - **Scope:** The pinned main README reports source for 1,107 authored functions and strict acceptance of 1,106, with whole-executable identity still in progress. - **Scope:** The VC7 i386 runtime checkpoint is distinct from a redistributable modern Windows release; macOS remains in progress. Exact normal-build checks and bugfix playtests have different purposes. - **Testing evidence:** A historical oracle accepted instruction bytes while missing wrong floating-literal data. The linked issue/PR records later data-reference checks. - **License:** MIT covers repository code/docs, not the original game. Historical source lineage and agent contributions retain their attribution. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Zelda 64: Recompiled — a native Majora’s Mask port without a full source decompilation > Uses N64Recomp to translate Majora’s Mask into a native application and RT64 for rendering. The project separates static recompilation from source decompilation while reusing decompilation headers and selected functions for patches and enhancements. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The reviewed build accepts the US Nintendo 64 Majora’s Mask ROM supplied by the user; game assets are not included. Ocarina of Time remains planned, and this is not an emulator for arbitrary ROMs. - **Prerequisites:** Runtime graphics require Direct3D 12.0 with Shader Model 6, Vulkan 1.2, or Metal Argument Buffers Tier 2. x86-64 needs SSE4.1; the README lists macOS 13.0+ with Apple Silicon or a 7th-generation Intel CPU. - **Prerequisites:** Source builds additionally require submodules, CMake 3.20+, C++20 tooling, N64Recomp/RSPRecomp and the specified decompressed ROM. The build guide lists SDL2 and platform dependencies; ordinary play uses the standard ROM. - **Testing evidence:** The project documents high-frame-rate, widescreen, camera and save enhancements, plus overlay and cutscene issues. These are project claims. - **License:** GPLv3 project license; original game content and dependencies retain separate terms. The team states that it does not use generative AI and bans contributions using GenAI tooling in any capacity. ##### Primary sources 1. 2. 3. 4. 5. #### OpenGOAL: recovering GOAL code and rebuilding the Jak games > Reconstructs readable GOAL code from the original Jak binaries and compiles it with a new GOAL compiler for modern PCs. Its workflow combines a specialized decompiler, manually supplied type information, asset extraction and an interactive development runtime. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s original PS2 game copy and extracted assets. The README covers retail PAL, NTSC and NTSC-J editions, including Greatest Hits, and excludes later PS3/PS4/PS5 releases. - **Prerequisites:** The supported runtime is x86-64 on Windows, Linux and macOS. The macOS guide requires Rosetta 2 on Apple Silicon and lists macOS Sequoia; native ARM64 builds are experimental and unsupported. No mobile release is planned. - **Prerequisites:** Development uses C++20, CMake, NASM and platform libraries, then the project’s asset-extraction and GOAL compilation steps. The documented task commands need the corresponding task runner; runtime code editing is a development feature. - **Scope:** The pinned README reports Jak 1 as complete, Jak 2 as beta with remaining issues, and substantial work still needed for Jak 3. - **License:** ISC license for project work; original game assets and third-party components retain their own rights. ##### Primary sources 1. 2. 3. 4. 5. #### LEGO Island: source reconstruction with separately reported exact rebuilds > Reconstructs the English LEGO Island 1.1 source for its original 32-bit Windows target. The project distinguishes function-comparison reports, ReproBit’s reported byte-identical retail rebuilds and ordinary developer builds; its modern portable adaptation is a separate repository. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Exact verification requires the user’s matching English 1.1 CONFIG.EXE, ISLE.EXE and LEGO1.DLL, the original Visual C++ 4.2 toolchain, Python 3.11+, Git and ReproBit; Linux/macOS also need Wine. - **Prerequisites:** Running the rebuilt executables still requires the original installed game data and the documented data paths. The README notes that d3drm.dll may also be needed on newer Windows systems. - **Testing evidence:** The pinned README reports a cold rebuild matching all three retail binaries byte for byte. - **Scope:** The ordinary CMake path is for development and is not the release-verification path. This repository targets 32-bit Windows only; cross-platform and Web support belongs to isle-portable. - **License:** The repository carries the LGPLv3 license; original game data and toolchain rights remain separate. ##### Primary sources 1. 2. 3. #### Snowball War: a bounded REA-assisted minigame reconstruction > The author uses REA’s Ghidra workflow to investigate the DOS Ski or Die binary, document Snowball War rules and rebuild that one minigame in Rust with SDL2. The public notes distinguish recovered tables and mechanics from approximations and deliberate presentation changes. - Type: Case study - Targets: Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s matching DOS/EGA game files and Python 3 for asset extraction. The Linux build uses Rust stable (author-tested with 1.93), Cargo and SDL2 development libraries; Cargo.toml specifies the SDL2 binding 0.37. - **Attribution:** The reported analysis used Ghidra 12.1.4 and JDK 21 through the REA CLI after unpacking EXEPACK. Caller-supplied function/code seeds are assertions. - **Scope:** Only Snowball War is reconstructed. Other events and the original engine are excluded; menus are new, and the close-up animation is deliberately restricted to the fort zone rather than reproducing every original placement. - **Limits:** The frame rate is approximated at 35 Hz, the original PRNG was not recovered, pause/exit keys are approximations, and audio playback is missing. - **License:** The pinned LICENSE.md and Cargo.toml offer MIT OR Apache-2.0, while the README’s license sentence mentions MIT only. Original art/audio must be extracted separately. ##### Primary sources 1. 2. 3. 4. 5. #### SpaceCadetPinball: decompiled game logic adapted to SDL2 > Converts the reverse-engineered Space Cadet pinball game into compilable C++ for desktop platforms. The README identifies the Windows XP executable and public PDB, a Full Tilt executable, and the work of recovering structures, naming variables and adapting the decompiled routines. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires original game resources supplied separately. The project supports resource data from Windows and Full Tilt editions; its releases do not supply those assets. - **Prerequisites:** Source builds require C++11, CMake, SDL2 and SDL2_mixer. The README gives Visual Studio, GCC/Clang and Xcode build paths, including x86_64 or arm64 selection on macOS. - **Scope:** The main project targets desktop Windows, Linux and macOS. Its list of console, mobile and browser ports points to separate projects. - **Scope:** The README reports that all subroutines were decompiled and converted to C++. Full Tilt feature work and possible support for its other two tables remain separate plans. - **License:** MIT license for this repository; original game resources and dependencies retain their own terms. - **Scope:** As checked on 2026-10-20, the latest release is Release_2.1.0 (2023-10-16); the reviewed 2024-08-21 commit is still the master head and GitHub’s last recorded push, the repository is not archived and the README does not mark it as maintained, superseded or archived. ##### Primary sources 1. 2. 3. 4. #### Super Mario 64: ROM reconstruction with explicit comparison gates > Reconstructs Super Mario 64 source for Japanese, North American, European, Shindou and iQue releases. Its build files distinguish original-ROM hash comparison from nonmatching or modified configurations, while source naming and documentation remain ongoing. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s matching original ROM for asset extraction. The five target releases are separate. - **Prerequisites:** The documented build uses GNU make, Python 3.6+, MIPS binutils, pkgconf and host development tools. Windows instructions use WSL/Linux; macOS instructions require an appropriate MIPS toolchain and newer GNU make. - **Testing evidence:** The Makefile normally checks the output ROM’s SHA-1 against the selected reference. NON_MATCHING, a non-N64 target or nonstandard configurations disable comparison. - **Testing evidence:** The pinned Jenkins configuration explicitly sets COMPARE=0 for iQue and enhancement builds. - **License:** The repository carries CC0-1.0; original Nintendo content and any separate third-party rights are not supplied by that declaration. - **Scope:** As checked on 2026-10-20, the reviewed 2023-08-17 commit is still the master head and GitHub’s last recorded push was 2024-02-04; the only GitHub releases are 2019 qemu-irix helper binaries, not game builds, the repository is not archived and the README does not mark it as maintained, superseded or archived. ##### Primary sources 1. 2. 3. 4. 5. #### Unleashed Recompiled: translating Xbox 360 game code and shaders > Builds an unofficial Sonic Unleashed PC port by statically recompiling Xbox 360 PowerPC code with XenonRecomp and Xenos shaders with XenosRecomp. The port adds modern display and modding options while documenting original-engine limits and remaining compatibility issues. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s US or EU Xbox 360 game files and the title update; the Japanese release and PS3 files are unsupported by the reviewed installation guide. DLC is optional, and the project does not provide game assets. - **Prerequisites:** The README’s Windows/Linux baseline includes an AVX-capable CPU, 8 GB RAM and Direct3D 12.0 with Shader Model 6 or Vulkan 1.2 graphics. It lists Windows 10 version 1909 and a modern Linux distribution such as Ubuntu 22.04. - **Prerequisites:** Source builds require submodules, CMake 3.20+, C++20 tooling, vcpkg with VCPKG_ROOT configured, and matching executable/update/shader inputs. At the same revision, BUILDING.md documents Xcode 16.3+ and macOS presets while the README says macOS is not on the roadmap. - **Limits:** High-frame-rate gameplay glitches, loading stutters and ultrawide cutscene issues remain documented. Mods replacing the original executable or shaders are unsupported. - **License:** GPLv3 project license, with separate original-game and dependency terms. This is static recompilation. ##### Primary sources 1. 2. 3. 4. #### OpenMW: replacing Morrowind’s engine while reusing original content > Provides an independent engine for playing Morrowind and an alternative editor, OpenMW-CS. It loads original game content through its own runtime and documents script and mod compatibility differences; it is an engine replacement rather than a recovered Bethesda source tree. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Playing Morrowind requires the user’s original game data, including Morrowind.esm and the installation settings. Tribunal and Bloodmoon are optional expansions; the installation guide recommends both for best results. OpenMW-CS can also support separately authored projects. - **Prerequisites:** The source configuration uses CMake 3.16+, C++20, SDL2 2.26+, OpenSceneGraph 3.6.5+, Boost 1.70+ and OpenAL; launcher/editor/wizard builds use Qt6. Additional dependencies depend on enabled components. - **Scope:** The pinned README and build files identify version 0.52.0; this is a source-snapshot identifier. The README lists Windows 10+, macOS 14.8+ and Linux, with no 32-bit support. - **Testing evidence:** The project reports the main quests as completable, but warns about side quests and mods that depend on original-engine quirks. Example Suite integration tests and the separate Morrowind-content test setup cover selected behavior. - **License:** The official GitHub mirror points to the main GitLab project. GPLv3 covers project code, with separate font/dependency terms and original-game data rights. ##### Primary sources 1. 2. 3. 4. 5. 6. #### REDRIVER2: reconstructing Driver 2 through a PlayStation compatibility layer > Translates reverse-engineered Driver 2 MIPS routines into C/C++ and uses Psy-X/Psy-Cross to adapt PlayStation interfaces for desktop systems. The project documents symbol-assisted Ghidra/IDA work alongside intentional bug fixes and gameplay changes. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s copies of both Driver 2 discs. The pinned installation wiki lists English PAL EU and NTSC US revisions 1.0/1.1; other languages remain planned. - **Prerequisites:** Documented play paths cover Windows and Linux; installation converts disc video/audio using Java. Linux runtime instructions list SDL2 and OpenAL; original game content is not supplied by the project. - **Prerequisites:** Source builds use submodules, Premake5 and a C++ toolchain. The Windows guide uses Visual Studio 2022; Linux builds link SDL2, OpenAL, OpenGL and libjpeg. - **Limits:** The README reports a playable reconstruction but explicitly excludes the memory-card menu from its decompilation claim. Original bugs and some gameplay are deliberately changed; [D], [T] and [A] annotations distinguish decompiled, tested and altered code. - **License:** MIT license for project code; original game data and third-party components retain their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### DevilutionX: porting Diablo’s reconstructed engine > Builds a modern Diablo and Hellfire port on the Devilution reconstruction, with platform support, bug fixes and optional quality-of-life features. The project documents the original symbol-assisted reconstruction and includes selected dungeon-generation and saved-game regression checks. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Full Diablo play requires the user’s original DIABDAT.MPQ. Hellfire additionally needs hellfire.mpq, hfmonk.mpq, hfmusic.mpq and hfvoice.mpq. The separately offered spawn.mpq supports only the shareware portion; source availability does not supply rights to original game content. - **Prerequisites:** The pinned source identifies 1.6.0-dev and requires CMake 3.22 and C++23. SDL2 is the default, with separate SDL1/SDL3 options; build documentation lists platform-dependent libraries and packaging steps. - **Scope:** The background describes Devilution’s use of PlayStation debug symbols, assertion strings, compiler information and assembly comparisons. - **Testing evidence:** The reviewed timedemo test replays a warrior’s level-1-to-2 session and compares saved hero state; it skips without MPQ data and explicitly selects shareware mode. Separate dungeon tests compare seeded fixtures. These are bounded regression checks. - **License:** The root LICENSE.md declares Sustainable Use License 1.0: use/modification is limited to internal business purposes, non-commercial use or personal use, while distribution must be free and non-commercial. Components and original game data retain separate terms. - **License:** The same snapshot retains conflicting Public Domain wording in the Windows package README and Unlicense metadata in the Apple bundle configuration. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Touhou reconstructions: an agent-driven method across three games > An essay published on REA’s site, with pinned evidence notes, describes one author’s agent-driven reconstructions of TH08, TH095 and TH04. It dates milestones from public commits and progress ledgers, separates exact-comparison and playable-build oracles, and documents a TH08 check that missed wrong floating-literal data. Project results remain author-reported, and REA is credited with supplying analysis evidence, not the reconstructions themselves. - Type: Case study - Targets: Binary · Game - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The essay and notes supply no game files, compilers or builds; each project’s repository documents its own original-game and toolchain requirements, and game rights stay with their owners. GensokyoClub’s TH08 history keeps its attribution and license. - **Scope:** The evidence notes, checked on 10 October 2026, treat three separate projects: a continuation of GensokyoClub’s TH08 1.00d reconstruction, a TH095 1.02a reconstruction started from zero confirmed functions, and a PC-98 TH04 reconstruction crediting ReC98. Milestone intervals use public commit timestamps and measure recorded spacing. - **Testing evidence:** Pinned ledgers report 1,106 of 1,107 TH08 functions accepted, 696 exact TH095 functions out of 697 confirmed, and 661 exact TH04 functions out of 663 reviewed candidates, each under its own definitions; the notes warn against cross-game rates or whole-executable completion percentages. TH08 Linux and Web ports, a playable TH095 Windows i386 build and four TH04 DOS products are recorded milestones. TH04 play results rest on the maintainer’s manual observations, and its 64-bit port is in development. - **Testing evidence:** In TH08, an instruction-byte comparison accepted source using 0.0 where the original executable used 128.0, because it did not check the referenced literal data. TH08 PRs #11 and #13 added literal-data checks and corrected twelve more stale references among 1,548 audited. - **Attribution:** REA is described as supplying analysis evidence to agents; the projects also used their own analysis bridges and tooling. The author presents the method and its industrial analogy as an account and argument. ##### Primary sources 1. 2. 3. 4. 5. 6. #### TicTacToe-AI: a bounded REA-fork reconstruction of one game method > The author’s REA fork, posted as rea-engine and since renamed RE-Agent, decompiles the shipped .NET executable of the GPL-licensed TicTacToe-AI game, recompiles the recovered C# and resources, and repairs one decompiler error against the original IL. A differential probe runs original and rebuilt code on all 19,683 board assignments for one status method and compares six form renders. The report passes only that method; the whole game remains partial. - Type: Case study - Targets: Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The fork needs Node.js 22.19+ or 24.11+; recovery uses ilspycmd plus a host Roslyn compiler and Mono references, with script defaults pointing at Homebrew paths on macOS. Verification needs a local X11 display and Mono/libgdiplus. The recorded run used macOS 15.3.1 on ARM64 with Xvfb, so both renders come from the same Mono runtime rather than native Windows. - **Testing evidence:** The reviewed develop commit (2026-10-15) reports Feature PASS for CheckGameStatus over its declared 3^9 board domain and PARTIAL for the whole game. AI move selection and RNG, menus, timing and sound are unverified, the executables are not byte-identical, and raw terminal captures differ by one carriage return. The posts’ “byte for byte” wording applies to structured board records and six render PNGs. - **Scope:** The input is the published TicTacToe-AI executable from tatlead’s GPL-3.0 repository, identified by SHA-256 in the report. The repository redistributes it with the GPL text and a source archive kept for license compliance; the statement that this source was not consulted during reconstruction is author-reported. - **Testing evidence:** Scripts recover a fresh replica, then a probe executes the original and rebuilt assemblies, compares return values and indicator bytes for every board, and captures Form.DrawToBitmap images after button sequences. The current result JSON records zero board-record mismatches and terminalBytesEqual false. - **License:** The fork is MIT with morluto’s REA copyright retained and lists optional engines such as Ghidra and Frida under their own licenses; the game and its reconstruction carry GPL-3.0 obligations. Fork-specific code is not part of upstream REA releases, and the repository was renamed after the posts, whose rea-engine link now redirects to RE-Agent. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### UltraSunnyMoon: a partial, REA-led Pokémon Ultra Sun reconstruction > The author uses a pinned REA build with Ghidra to analyze a user-supplied Pokémon Ultra Sun base executable, rebuild it byte for byte from split objects, and swap in two small compiled C runtime routines. Both replacements are behavior-tested but nonmatching and every other byte stays original; one recorded input movie drives the original and hybrid builds to the same bedroom movement in the Azahar emulator. Retail compiler identity, exact matching, module loading and broader gameplay remain open. - Type: Case study - Targets: Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own Ultra Sun base version 0 container (title 00040000001b5000, product code CTR-P-A2AA) kept locally; the v1.2 update stays a separate comparison input. TARGET.md records the author’s base container SHA-256 3bb3b4eb0d17f18875d8b847c871dc97a172beeda03ce99e59e62a78ed5c1a53 and notes that these hashes identify the supplied dumps, not every copy. Retail containers, extracted code, raw REA dossiers, game frames and emulator logs stay in ignored private directories. - **Prerequisites:** SETUP.md uses Ubuntu WSL on Windows with Node.js 22, Python 3, GCC and readelf. Its bootstrap builds REA from source revision 7ae3c50a9d49c480035855de9fcc4484befacd92 (package version 6.4.0) and runs it with Ghidra 12.1.4 and Temurin JDK 21, with Capstone 5.0.7 as an independent decoder. Rebuilds use a pinned 3DS Decomp Pipeline revision, the C replacements were compiled with Ubuntu’s gcc-arm-none-eabi (GCC 10.3.1), and runtime checks use Azahar 2126.2 and its RPC interface. - **Scope:** README reports that the original and combined rebuilt games reproduce controllable bedroom gameplay, that both C replacements are behavior-tested but nonmatching, and that no completion percentage is claimed. STATUS.md (updated 2026-10-12) lists an unchanged main executable and one CRO module rebuilt byte for byte, the integrated __aeabi_vec_ctor_nocookie_nodtor helper and a 36-byte startup BSS clearer. The hybrid builds still contain mostly original code and assets and need a 3DS runtime; a native PC port is a later phase. - **Testing evidence:** The project reports independent byte checks of the unchanged rebuilds, isolated behavior tests and live RPC readbacks for the replaced routines, and 60 passing source-owned tests. Runtime evidence is a bounded startup, setup and bedroom comparison under one input movie; routine execution counts, battles, overworld coverage, full-movie completion and timing determinism remain unverified. The tests use source-owned fixtures, not retail bytes. - **Attribution:** README directs agent-accessible analysis through REA and Ghidra and requires AI-assisted reconstructions to be reviewed against binary evidence; AGENTS.md and HANDOFF.md are written for continuing agent sessions, and RUNTIME.md records frame review by an independent reviewing agent. The repository has no license file and GitHub detects none; it describes itself as an independent fan project unaffiliated with Nintendo, Game Freak or The Pokémon Company. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### DX-Ball: an REA-guided function-level reconstruction with Codex > The author has Codex use REA’s Ghidra tools to inspect the English DX-Ball 1.07 executable and recover it as typed C/C++, then compiles each function with the original-era Visual C++ 4.0 and compares it byte for byte with the original after mapping relocations. The same source also builds a MinGW Windows game and a portable core library. Exact reconstruction is still in progress; REA’s separate sound-pan showcase covers just one function. - Type: Case study - Targets: Binary · Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply the English v1.07 Windows archive identified in config/target.toml; the importer verifies the archive and DXBALL.EXE hashes and puts the executable and assets in the git-ignored original/ directory. README points to a third-party download site for that archive; the repository does not establish its distribution rights. - **Prerequisites:** The documented host is Linux x86-64 with Git, Python 3.11+, Node.js 22.19.0, 32-bit Wine, Xvfb, CMake, Ninja and GCC or Clang, plus i686 MinGW for Windows cross-builds. Bootstrap scripts fetch a hash-pinned JDK, Ghidra and a Visual C++ 4.0 compiler from a third-party archive repository. The REA lock file pins rea-agents 6.5.0 with Ghidra 12.1.4, while docs/REA.md still names 6.4.0; the Codex goal workflow needs Codex 0.128.0 or newer. - **Scope:** README marks exact reconstruction as in progress, to be followed by a playable Visual C++ 4.0 build and later platform ports. Generated PROGRESS.md counts 553 provisional function candidates, 475 with source, 395 byte-exact (85,106 exact code bytes) and 249 with scoped semantic acceptance, and says both Windows builds completed recorded original-board campaigns under Wine. A separate 50-board restored-CRT attempt on October 17 ended at its time limit without a full pass. - **Testing evidence:** An exact unit has zero differences across the whole function after COFF relocations are mapped to original functions, imports and data, with literal data also checked; match-units.toml records the inputs needed to replay each unit. Differential tests run original x86 routines under Unicorn emulation against the compiled maintained C, and public CI builds the portable source, validates recorded evidence and compiles the Windows adapter without game resources. All results are project-reported. - **License:** MIT covers repository code; the original game, credited to Michael P. Welch with 3D graphics by Seumas McNally, is supplied separately and keeps its own rights, as do the downloaded compiler and tools. REA use is documented through saved responses and a worked projectile-list example, but agent effectiveness is not independently measured. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### re2ds: a native Nintendo DS engine for Resident Evil 2 > Reimplements Resident Evil 2’s PS1 game rules in a native Nintendo DS engine, with converters that turn data from the user’s own disc into DS formats. A helper wraps the PS1 executable as an ELF for REA’s Ghidra lane, analysis notes name the PS1 functions and tables each part follows, and the Reddit post linking it credits REA and Claude Code. Leon’s disc 1 is reported playable, while Claire’s disc, most enemy types and some menus remain unfinished. - Type: Case study - Targets: Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own Resident Evil 2 PAL disc 1 as a .bin/.cue dump, of which only Track 1 is used; local conversion produces about 290 MB of DS data. The repository states that it contains no game data and that the generated build/, nitrofiles/ and re2ds.nds outputs contain Capcom data that must never be committed or shared. - **Prerequisites:** Building uses devkitARM and libnds (devkitPro nds-dev), Python 3, FFmpeg with its development libraries, a C compiler and pkg-config. Windows builds run in WSL Ubuntu, and make falls back to devkitPro’s Docker image when no local devkitARM is found. The README plays the ROM in melonDS, needs DLDI SD-card setup for saves and shows a photo captioned as running on a Nintendo DSi XL. - **Scope:** The reviewed commit targets the PAL PS1 release (SLES-00972), disc 1 with Leon. README reports all 125 disc 1 rooms, a script interpreter covering every opcode used on that disc, zombies, the lower-screen status menu, sound, voices, the opening movies and typewriter saves; it lists the map and files, other enemy types, the remaining movies and Claire’s disc as missing. It is a native engine, not an emulator, a matching decompilation or a complete port. - **Testing evidence:** Host tests compile the platform-independent script, enemy and cutscene code for a PC and run it against the user’s converted data; the script test reports unknown opcodes, and scd_disasm.py --check validates jump targets across rooms. Analysis notes cite PS1 addresses and mark observed versus assumed behavior. psxexe_to_elf.py wraps the executable and symbol lists as a MIPS ELF accepted by REA’s Ghidra lane; Claude Code use is stated only in the Reddit post. - **License:** No license file is present at the reviewed commit. The README credits the MIT-licensed OpenBiohazard2 reimplementation’s file-format work and script opcode table as the starting point for several converters. Capcom’s game data, movies and audio stay outside the repository and retain their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Horizon: a Rust rewrite of Minecraft: Java Edition 26.3 with REA bytecode queries > Rewrites Minecraft: Java Edition 26.3 as a native Rust client, dedicated server and launcher that prepare their resources from the user’s own copy of the game. Contributors are told to read the vanilla code first, and tools/rea_vanilla.py runs a pinned REA release with a headless JADX engine over the shipped client and server jars to inspect classes, methods and callers. Differential harnesses run Java oracles against the real game and Rust probes against Horizon; README reports all 281 passing, which covers only what they compare. - Type: Case study - Targets: Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository was created on 2026-10-03, and the reviewed main snapshot (2026-10-19) follows the date-tagged release v2026.10.19.12. README reports a playable client on Linux, macOS (Apple Silicon) and Windows with vanilla world generation, mobs and their AI, villagers, raids, redstone, every command, Anvil saves and joining vanilla servers, and its own audit of 2026-10-13 scores every subsystem complete. Listed known issues include unsupported online-mode servers, skin and pack-icon gaps, unwired creative hotbar keys and missing attribute lines in tooltips. - Needs Minecraft: Java Edition installed with the official launcher and 26.3 played once, plus the 26.3 server jar for the first preparation; research-lock.json pins the client and server jar SHA-1 checksums. horizon-prepare (Python 3.10+ and JDK 25) builds resources from that copy into the gitignored .local/ directory. README says Horizon never downloads game files and never publishes decompiled source or prepared resources, and tools/check_public_tree.py rejects them in commits. - Players install through the Horizon launcher for Linux x86-64, macOS Apple Silicon or Windows x64, which also starts a dedicated server that needs no Java; rendering needs Vulkan on Linux and Windows. Source builds need Rust 1.90+, Python 3.10+, JDK 25 and, on Linux, the ALSA and udev headers; development and the vanilla harnesses run on Linux. tools/rea_vanilla.py needs Node.js 22.19+ and Java 17+, runs rea-agents 6.4.0 through npx unless that version is installed, and downloads jadx-headless-mcp 0.7.1 checked by SHA-256. - Each tools/test_*_parity.py harness drives the same inputs through a Java oracle under mods/horizon running the vanilla code and through a Rust probe, then compares the outputs; README says 100% means 100% of what the harnesses compare, not proof that nothing else differs. CI runs the Python and cargo tests on GitHub-hosted Linux runners and the vanilla harnesses on a self-hosted runner holding the maintainer’s copy of the game. - LICENSE applies MIT to the project’s original work; dependencies, including the wgpu-hal copy under third_party/, keep their own licences, and README says Minecraft code and assets belong to Mojang and Microsoft under the Minecraft EULA and that the project is not affiliated with them. docs/parity-workflow.md describes agents working in parallel worktrees behind a shared gate, and horizon-ctl exposes the game to AI agents as a CLI and MCP server. REA’s documented role is limited to the bytecode queries in CONTRIBUTING.md and tools/rea_vanilla.py. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Untangle: a browser rebuild from REA and Ghidra evidence > An author-documented REA/Ghidra investigation of the shipped Untangle Windows binary produces a single-page playable rebuild and a claim-by-claim grading receipt. The report separates frozen findings, a later source-code answer key and a prior-knowledge audit. - Type: Case study - Targets: Binary · Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The recorded run uses REA 6.3.0, Ghidra 12.1.4 and Windows 11 against puzzles version 20260923.616da16; the rebuild is available as a browser page. - **Testing evidence:** The reported 52/54 correct claims and L3 seed fidelity are the author's grading results; ten names absent from REA output indicate possible prior-knowledge contamination. - **Limits:** The 72 MB evidence export is omitted; its hash is retained. The README documents a pre-publication history rewrite and maps old commit hashes to new ones. - **License:** Original puzzle binary and source retain Simon Tatham and contributors' MIT license. ##### Primary sources 1. 2. 3. #### OpenBattlefield2: an unfinished Refractor 2 engine reimplementation > A C++20 reimplementation of Battlefield 2’s Refractor 2 engine reads original game data and documents menu rendering, level loading and server interoperability. Published crosshair research cites REA/Ghidra evidence IDs and binary addresses; major gameplay systems remain unfinished. - Type: Case study - Targets: Binary · Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an owned Battlefield 2 1.5 installation, CMake 3.24+, Ninja, a C++20 compiler and SDL3; the Flash menu additionally needs Rust and Ruffle. - **Attribution:** Published crosshair research cites REA Evidence IDs; CLAUDE.md describes the mixed REA/Ghidra workflow and its payload and temporary-project limitations. - **Testing evidence:** macOS arm64 is the primary platform; the Windows preset is kept building but is not exercised. Tests needing game files can pass with a note when those files are absent. - **Limits:** Ammunition/reloading, recoil, projectiles, audio, driving and full commander/squad interaction remain unfinished; this is an engine research project, not a complete game port. - **License:** MIT covers the project code; no original Battlefield 2 game content is redistributed. ##### Primary sources 1. 2. 3. #### keen-clone: a Commander Keen 1 C/SDL2 port > A native Linux and browser port of Commander Keen Episode One is documented as a function-by-function REA/Ghidra reconstruction of KEEN1.EXE. Published analysis artifacts accompany the C/SDL2 game; the scope is the first episode, rather than the entire series. - Type: Case study - Targets: Binary · Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Native builds need a C compiler, make and SDL2 development files, plus the user's Keen 1 data files including KEEN1.EXE; the README lists v1.1 and shareware v1.31. - **Limits:** Browser builds require Emscripten and supplied game data; the documented web packaging is restricted to the shareware episode. Browser shortcuts and per-origin IndexedDB storage differ from the native host. - **Testing evidence:** The repository lists decompilation/disassembly, a call graph and raw REA output as analysis artifacts. It does not provide an independent behavioral-parity or full-playthrough evaluation. - **License:** No project license file was present in the reviewed root. Commander Keen and its original data retain their owners' rights; public source access supplies no additional reuse grant. ##### Primary sources 1. #### samp-client-re: a partial SA-MP client reconstruction > A documented REA/Ghidra investigation maps SA-MP 0.3.DL-R1 client subsystems to a new C++ DLL, loader and smoke-test executable. The result is an architectural reconstruction with explicitly unresolved network and graphics behavior, not an established retail-compatible client. - Type: Case study - Targets: Binary · Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Testing evidence:** The README reports a Windows/MinGW x64 build and a GTA-independent smoke executable; actual GTA: San Andreas use requires a separate 32-bit toolchain/build. - **Attribution:** The architecture table attributes addresses and recovered procedures to REA/Ghidra 12.1.4; names inferred from the stripped binary remain analyst interpretations. - **Limits:** Full RCON/RPC handling, the default-port wire format and the exact Present trampoline are marked unknown/TODO. The archive parser is described as behavior-equivalent, not a complete decryptor. - **License:** No project license file was present in the reviewed root. Original GTA and SA-MP components remain separate prerequisites with their own rights. ##### Primary sources 1. #### Desktop Games Nostalgia: a macOS and browser port > A Swift/macOS and JavaScript/browser port recreates the Desktop Games screen-smashing toy from a captured image. The author documents Claude and REA/Ghidra work on the Peter interpreter, a decompiled program tree and extracted assets, with explicit visual differences and no project license. - Type: Case study - Targets: Binary · Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Native use requires macOS 14+; Screen Recording access captures one screen image, while wallpaper mode is available without it. The browser version uses a simulated desktop and needs a mouse/keyboard. - **Attribution:** The README attributes interpreter analysis to REA/Ghidra and the port to Claude Code; extracted images/sounds are included upstream. The effects alter an image, not the real desktop files. - **Limits:** True-color rendering and translucent sprite shadows differ from the original palette renderer. The browser cannot capture the actual desktop; no independent parity measurements are supplied. - **License:** The author explicitly provides no project license and retains Gemtree credit for original design/art/sound. Desktop decoration and other upstream assets retain their separate rights. ##### Primary sources 1. #### GunZRs: a Rust reimplementation of GunZ: The Duel > A Rust/Bevy port reads GunZ: The Duel files from the user's installation and provides native releases, browser build tooling, screenshots and a documented REA/Ghidra investigation framework. Its LAN protocol and inferred movement behavior remain distinct from retail-server compatibility and proven gameplay parity. - Type: Case study - Targets: Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user's GunZ: The Duel installation; no original game files are included. Native downloads target Linux/Windows, with Linux builds requiring the documented system libraries; WebGPU needs localhost or HTTPS and packs built from the user's data. - **Attribution:** The README documents REA/Ghidra use for static questions about retail files. - **Limits:** LAN uses the port's own protocol and does not connect to retail servers; several round/quest/Blitzkrieg modes are not played over LAN. Movement constants and some content choices are inferred. - **License:** The project says gameplay has been exercised on Linux. Code is Apache-2.0, bundled fonts retain OFL terms, and original game files remain separately owned. ##### Primary sources 1. 2. #### Does reverse engineering need a bigger model? General and specialist models in Touhou reconstruction > An essay on REA’s site by N0zoM1z0 (13 October 2026) uses dated Touhou reconstruction commits to ask whether exact function matching needs a larger general model, a compiler-specialist model or better retrieval. It walks through TH09, TH095, TH04 and TH08 cases where later GPT-6-series sessions closed stubborn matches, and the TH08 audit that found accepted functions with wrong floating constants. Specialist and reinforcement-learning comparisons are proposed as future experiments; no trained specialist was evaluated. - Type: Case study - Targets: Binary · Game - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The essay and its notes supply no game files, compilers or builds; each linked Touhou repository documents its own requirements. - **Scope:** The essay is dated 13 October 2026. Its examples are function-level comparisons recorded in linked TH09, TH095, TH04 and TH08 commits. - **Limits:** Later sessions inherited earlier source, diagnostics and failed experiments, so the before-and-after closures are not controlled estimates of model-size effects. The notes treat gpt-web as a changing label that does not identify a run’s model, per-run reasoning effort and budgets are not uniformly recorded, and the GPT-6-Luna-max closure is presented as a discovery across model tiers, not a measured smaller-model advantage. - **Testing evidence:** The TH08 example comes from commit a393f400 (2 September), which target-checks every VC7 floating-literal relocation; the follow-up audits 1,548 relocations and corrects 12 stale rows in five accepted units. The essay’s concern that a reward built on the old check could reinforce wrong source is stated as an inference: the notes record no actual RL exploit or trained model doing so. - **License:** Game rights stay with their owners. ##### Primary sources 1. 2. 3. #### sh23ds: a native 3DS reconstruction of Silent Hill 2 > sh23ds rebuilds Silent Hill 2: Director's Cut as a native C engine for Nintendo 3DS using the player's PC game data. Game logic, camera, lighting and events were reconstructed from the PC executable; the research notes report analysis with Ghidra and REA. The author reports a complete playthrough in Azahar, while real-console testing and some PC behaviors remain unfinished. - Type: Case study - Targets: Game - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A 3DS or 2DS running Luma3DS, a copy of Silent Hill 2: Director's Cut for PC and about 1.8 GB of SD-card space are required. - **Prerequisites:** DSP firmware must be dumped once with DSP1 for sound. - **Limits:** The build is in development; the author reports little testing on real consoles and remaining behavior and rendering gaps. - **License:** GPL-3.0 license; bundled third-party code keeps its own licenses. ##### Primary sources 1. 2. 3. #### RenderDoc > Inspect frame captures, draw calls, shaders, and graphics resources in your own game or graphics application. - Type: Tool - Targets: App · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supported graphics API and replay platform; upstream supports captures of your own, open-source, or free projects. Metal is not supported. ##### Primary sources 1. #### AssetRipper > Analyze Unity game files, inspect asset dependencies, and convert supported assets into Unity project formats. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Unity 3.5.0–6000.4.X coverage varies by version; GPL-3.0 open-source edition, with separate premium features. ##### Primary sources 1. #### Cpp2IL > Recover managed representations from Unity IL2CPP builds using binary and metadata analysis; reconstruction remains a work in progress. - Type: Tool - Targets: App · Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Compatible Unity build and metadata; current development branch is a major rewrite and primarily targets .NET 9.0. ##### Primary sources 1. #### Il2CppDumper > Recover IL2CPP metadata and dummy assemblies, and generate helper scripts for native analysis tools; method code is not restored. - Type: Tool - Targets: App · Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Matching IL2CPP executable and global-metadata.dat; documented Unity support is 5.3–2022.2. - As checked on 2026-10-20, the latest release is v6.7.46 (2024-07-06) and the master head is a same-day commit, four commits after the reviewed one with the README unchanged; GitHub’s last recorded push was 2024-08-18, the repository is not archived and the README does not mark it as maintained, superseded or archived. ##### Primary sources 1. 2. #### RenderDoc MCP > Expose existing RenderDoc captures to an agent for bounded frame, pipeline, resource, and shader inspection. - Type: Integration - Targets: App · Game - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows and replayable .rdc capture; maintainer baseline is RenderDoc 1.43. Optional native Python backend needs a source-built binding. ##### Primary sources 1. #### UndertaleModTool > Browse and modify supported GameMaker data files, extract assets, and decompile or compile GML VM code. Includes room editing, scripted changes, a CLI, and the reusable UndertaleModLib library. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supply a supported game data file such as data.win, game.ios, or game.unx. Stable 0.9.2.0 provides a 64-bit Windows GUI and CLI packages for Windows, Ubuntu, and macOS. - GML VM code editing excludes YYC, and some language features remain unsupported. Building the reviewed source requires the .NET 10 SDK or later and recursive submodules; the GUI build requires Windows. ##### Primary sources 1. 2. #### frida-il2cpp-bridge > Inspect IL2CPP classes, methods, and fields in a live process, and trace or intercept method calls without supplying global-metadata.dat. Complements static IL2CPP dumpers with runtime observation. - Type: Tool - Targets: App · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Frida access to a running IL2CPP application and the npm module. The current bundled CLI needs Python 3.12+ (inferred from its typing.override import) and Frida tooling. - The reviewed README states Unity 5.3.0–6000.3.x support. Android and Linux are the platforms upstream tests; Windows, iOS, and macOS are listed as supported with explicit warnings of possible breakage. Latest release at review: v0.14.0. ##### Primary sources 1. 2. 3. 4. 5. #### objdiff > Compare functions and data in reference and rebuilt object files to guide matching decompilation. Displays instruction-level differences, demangles C++ symbols, and can rebuild when source files change. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Provide reference and rebuilt object files. Project integration and automatic rebuilding use objdiff.json plus a working toolchain and build command; direct CLI comparisons can use file paths. - v3.8.2 provides GUI binaries for Windows/Linux x86_64 and macOS arm64/x86_64, with additional CLI targets. Building from source requires Rust. Supported architectures include ARM, ARM64, MIPS, PowerPC, SuperH, and x86/x86_64. ##### Primary sources 1. 2. 3. #### decomp-permuter > Randomly or systematically permutes one C function, recompiling each variant and scoring it against a target object file to search for matching compiler output. PERM macros specify manual alternatives, and the optional permuter@home mode distributes runs to other workers. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Each input directory needs a single-function .c file, the target .o, a project-specific compile script and a settings .toml; import.py can generate them for configured Make or Ninja projects. The README lists MIPS (IDO, possibly GCC), PowerPC and ARM32 assembly. - Requires Python 3 and toml; pynacl and Levenshtein are optional. permuter@home needs access granted by an existing network member, supports a limited compiler list and does not run on native Windows; workers also need Docker. - A zero score means the scored disassembly matches. The README warns that random passes often find nonsensical changes, so a human must still choose readable, non-overfitted code; the tool does not recover names, types or semantics. - MIT license. No packaged release; last commit at review: 2026-10-06. ##### Primary sources 1. 2. #### asm-differ > Diffs original and rebuilt assembly for one function or ROM address to guide matching decompilation; its watch mode can rerun make when sources change. The README describes it as decomp.me’s default diff viewer and points to objdiff as a modern alternative. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Each project needs a diff_settings.py naming the original and rebuilt images and linker map; object-file mode compares against references in an expected/ directory. Requires Python 3 with colorama, watchdog, levenshtein and cxxfilt, plus an objdump for the target. - The README lists MIPS, PPC, AArch64, ARM32, SH2, SH4, m68k and limited x86. Install it as a submodule, by copying diff.py or with pip from Git; there is no packaged release. Last commit at review: 2026-09-06. - Released under the Unlicense. It shows instruction-level differences only and does not recover names, types or semantics. ##### Primary sources 1. 2. 3. 4. #### UE Explorer > Explore Unreal packages through class, property, and dependency trees; decompile and export UnrealScript classes, inspect bytecode, and examine structured binary data. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows application built on .NET Framework 4.8; provide supported Unreal Engine 1, 2/2.5, or 3 packages. Latest stable release at review: 1.6.2. - UE2X and UE4/5 are not generally supported; only limited experimental parsing of loose UE4 .uasset containers is documented. Game-specific engine modifications can affect compatibility; older 1.6-and-earlier builds require decompressed packages. ##### Primary sources 1. 2. #### GARbro > Browse recognized visual-novel resource archives as folders, preview their contents, and extract images or audio with conversion to common formats. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Windows and .NET Framework 4.6 or newer; archive browsing and conversion depend on the supported game/format list. Encrypted archives may require credentials or a recognized game selection. - Latest GitHub release at review remains v1.5.44 (2019-03-31). As checked on 2026-10-20, the reviewed 2023-10-27 commit is still the master head, GitHub’s last recorded push was 2024-07-08, the repository is not archived and the README does not mark it as maintained, superseded or archived. ##### Primary sources 1. 2. 3. #### LASRecomp: Link’s Awakening static recompilation > A native desktop reconstruction of the 2019 Switch version of Link’s Awakening using static recompilation. The author attributes most code, tooling and reverse-engineering work to Claude Code with human direction and review. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Users must supply their own legally obtained v1.0.0 game files; the repository and release builds omit Nintendo game code, assets and fonts. - **Prerequisites:** Release requirements include macOS 15+ on Apple Silicon or Windows 10+/Linux on x86-64; the x86-64 paths need AVX2 and Vulkan 1.3. Linux ARM remains experimental and untested on hardware. - **Limits:** Beta status includes documented crashes and rendering defects. AI involvement is author-reported. ##### Primary sources 1. #### Godot RE Tools > Recover supported Godot project files, GDScript and imported resources from exported games. Includes PCK inspection and extraction, script decompilation, and resource conversion for examining and rebuilding project structure. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supports Godot 2.x, 3.x and 4.x project decompilation; release builds are available for Windows, macOS and Linux. Edit recovered projects with the original game's Godot version. - Encrypted inputs require the corresponding key. Godot 2.x model conversion and GDNative/GDExtension script recovery are not supported. - The tool is MIT-licensed. Building current source additionally requires the documented Godot fork, rustup and .NET 10 SDK. ##### Primary sources 1. 2. 3. #### UE4SS > Inspect Unreal Engine games at runtime through live UObject property views, reflected C++ header dumps, property mappings and actor dumps. Lua and C++ APIs support experiments while reconstructing game structures. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Targets Win64 Unreal Engine games; compatibility is game-dependent and may require custom signatures or configuration. - The development README targets UE 4.7–5.8, while the latest stable tag is v3.0.1 from 2024. Match documentation to the chosen build rather than assuming the stable release has every development feature. - MIT-licensed. Current source builds require the documented C++23, Rust and CMake toolchains plus Epic-authorized Unreal submodule access; Linux cross-compilation produces Windows binaries. ##### Primary sources 1. 2. 3. #### FModel > Explore Unreal Engine game archives with CUE4Parse-backed package and property inspection, asset previews and export. The 2026 summer release adds USD world export for reconstructing supported scene content. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows x64 and the .NET 10 Desktop Runtime or later; provide supported Unreal Engine game archives. Encrypted archives require the appropriate AES key. - World export in the reviewed aug-2026 release is USD-only; sockets and attachments may be positioned incorrectly. - GPL-3.0-licensed project; bundled dependencies have their own notices. ##### Primary sources 1. 2. 3. 4. 5. 6. #### PSP Web Recomp > Translate PSP MIPS executables into C++ and WebAssembly, backed by a PSP high-level emulation runtime and WebGL2 renderer. Native tracing, frame capture and audio tools support investigating missing behavior during game porting. - Type: Project - Targets: Game · Website - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Provide an image of a game you own and a compatible executable decrypter. Builds need Git, CMake, Ninja, C++20, Python 3, PSPRecomp and Emscripten. Linux is the documented tested build host; macOS is untested. - Author demonstrations cover two Ready at Dawn titles sharing an engine. Other games can require missing HLE calls or graphics features. Movies are skipped, and encrypted saves from a PSP or PPSSPP do not yet load. - Threaded browser hosting requires cross-origin isolation headers and HTTP Range support. The optional native runner also requires EGL/OpenGL ES development headers. - Upstream states that game data is not included and asks users not to redistribute generated game C++ or WebAssembly. Project code uses MIT; the bundled ATRAC decoder retains LGPL-2.1-or-later. ##### Primary sources 1. 2. 3. #### N64: Recompiled > Statically recompiles N64 MIPS binaries into C functions from symbol metadata, emitting function lookups and relocation macros so a runtime can handle statically linked and relocatable overlays. The output needs a runtime such as N64ModernRuntime; the repository also includes RSP microcode and mod tooling. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README documents an ELF as the metadata source, most easily produced from an existing disassembly or decompilation; the reviewed source also accepts a symbols file plus ROM, which the README does not yet describe. A TOML file sets inputs, stubs, skips and instruction patches; full option documentation is not available. - Build N64Recomp from a recursive clone with CMake 3.20+ and a C++20 compiler. The only GitHub release (2025-05-04) packages the separate Recomp Mod Tool, not the recompiler. Last commit at review: 2026-05-27. - Testing has mostly covered old MIPS compilers (GCC 2.7.2, IDO) and modern clang; modern MIPS GCC output may need specific flags, and relocation support for TLB-mapped code is still planned. - MIT-licensed tool; submodules keep their own licenses. It ships no game code or assets. Downstream recompilations such as Zelda 64: Recompiled are separate projects. ##### Primary sources 1. 2. 3. 4. #### XenonRecomp > Converts Xbox 360 PowerPC executables into C++ that can be compiled for other platforms, with the XenonAnalyse companion detecting jump tables and function boundaries. Output is a literal instruction translation rather than decompiled code and needs a runtime that the project does not supply. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A per-game TOML file supplies the XEX (plus an optional title-update XEXP), output directory, jump-table file and addresses of register save/restore and setjmp/longjmp functions; some function boundaries may need manual entries. Jump-table detection targets Sonic Unleashed patterns and may need changes for other games. - The README disclaimer states that no runtime is provided and that making a game work is the user’s responsibility. MMIO is unimplemented, exceptions are unsupported, and some PPC instruction variants are missing. - Building needs a recursive clone, CMake 3.20+ and Clang 18+; other compilers are untested and not recommended, including for generated output. There is no GitHub release; last commit at review: 2025-08-04. - MIT-licensed project code; submodules keep their own licenses. It ships no game code or assets. ##### Primary sources 1. 2. #### ArkWeb: a two-game movement and collision experiment > Runs Spider-Man Remastered and Arkham Knight together, streaming Gotham collision into Spider-Man’s physics world and compositing his rendered frame into Arkham. This experimental runtime bridge is not a recovered standalone game or new engine. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires owned Steam copies of both games, Spider-Man 4.0630 specifically, Windows 10 x64, an Xbox-style controller and hardware able to run both games simultaneously. - **Prerequisites:** Build prerequisites include Visual Studio 2019 C++ tools, Windows 10 SDK and Python 3.12 dependencies. Collision gaps, clipping, lighting and combat-pose limitations remain. - **Attribution:** End-to-end operation is project-reported. AI setup/documentation collaboration is visible. Public source has no repository-wide license found in the reviewed tree; game files are not supplied. ##### Primary sources 1. 2. 3. #### Perfect Dark: matching Nintendo 64 decompilation > Reconstructs Perfect Dark’s Nintendo 64 code with a documented matching-ROM build. The project combines reconstructed source with assets from a user-supplied original ROM, then checks version-specific artifact hashes. It is a reproducible-build research case, distinct from the separate native PC port; matching results remain project-reported here. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply an independently authorized original ROM in non-byteswapped .z64 form, with header 0x80371240, named for the selected ROMID. make extract reads assets and comparison segments from that ROM; final builds also reuse extracted boot code. Existing extracted files are not overwritten, so modified inputs can invalidate matching results. - **Prerequisites:** The documented host setup is Linux: GNU Make, host C/C++ tools, Python 3, MIPS binutils/GCC, armips, Capstone development files and the listed 32-bit libc headers. Initialize the pinned ido-static-recomp submodule. Matching mode reconstructs IDO 5.3 and 7.1 compiler tools from its IRIX inputs; optional GCC builds are nonmatching and limited to ntsc-1.0/ntsc-final. - **Scope:** The reviewed GitHub repository mirrors Ryan Dwyer’s GitLab project. README describes a complete matching decompilation; six build targets cover NTSC beta, NTSC 1.0/final, PAL beta/final and Japanese final, with ntsc-final as default. This reconstructs an N64 ROM, not a Windows/Linux/macOS game executable or the separate Perfect Dark PC port. - **Testing evidence:** After building, make test runs quiet MD5 verification against the selected version’s checksum manifest, including the final ROM and intermediate artifacts. The README also documents comparing base/built ROM hashes. The mutable status page reports all six versions complete/matching. - **License:** The repository declares MIT for source; original ROMs and extracted game assets retain separate rights. Compiler components have their own terms, including the submodule’s SGI notice for IDO 5.3; the project’s MIT declaration does not replace them. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### Super Mario Sunshine: a native PC port from an AI-assisted decompilation > Builds a native PC port of Super Mario Sunshine’s North American release from a pinned matching-decompilation fork, adding a host platform layer for graphics, disc, audio, input and OS services. The fork’s README says AI was used extensively to reconstruct and match its code; the port documents scripted regression hashes and lockstep comparisons with retail captures. Functions that do not yet match can still behave differently from retail, and the game must come from the user’s own disc image. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own GMSE01 Rev 0 disc image as .iso, .gcm or Dolphin .ciso; the port reads models, textures, levels, music and movies from it at run time and ships no game data. Given the image, the build also makes a standalone executable containing the game’s files, which README says must not be shared. Optional language, texture and HD-cutscene packs are separate. - **Prerequisites:** build.sh and run.sh drive CMake, Python 3, patch, SDL2 and a host compiler: Ubuntu/Debian multilib GCC for the default 32-bit Linux build, Homebrew LLVM clang targeting x86_64 on macOS, or MSYS2 MINGW64 GCC on Windows. The decomp submodule is pinned to sms-english 967436b; PC-only changes are patches applied to copies of its sources, and the separate decomp build to a matching mario.dol uses its own GameCube toolchain. - **Scope:** Targets only the North American GMSE01 Rev 0 release. README reports the 32-bit Linux and macOS builds as playable, 64-bit Linux as playable but still being tested stage by stage, and 64-bit Windows as booting under Wine with native runtime checks. macOS builds x86_64, run under Rosetta 2 on Apple Silicon, because native arm64 cannot map game memory below 4 GiB. - **Testing evidence:** At that pin, the fork’s PROGRESS.md reports, as of 2026-09-27, 99.57% fuzzy, 72.94% byte-perfect and 33.18% source-linked code, with 12,002 of 12,904 functions matching and a byte-identical rebuilt DOL that still links extracted objects for unfinished code; its README gives slightly higher 2026-09-29 figures. The port compiles the decomp’s 588 game, JSystem and THPPlayer units, so non-matching functions can still diverge from retail. It reports scripted headless runs hashed against a baseline and compared between 32- and 64-bit builds, lockstep tracing against retail Dolphin captures and qemu-ppc checks of math routines. - **License:** The port is MIT-licensed (SoftwareAura LLC) and the decomp fork is CC0-1.0; the game and the user’s disc contents keep separate rights. AI involvement is stated by the fork’s README and agent guides, which describe Claude and Codex orchestrators. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Majora’s Mask: matching US N64 decompilation > Recreates a C source base for The Legend of Zelda: Majora’s Mask from information in the game and static or dynamic analysis, then rebuilds the US Nintendo 64 ROM. The build takes assets and assembly from a user-supplied ROM and checks the output against stored MD5 checksums. The team states it will not produce a PC port; the separately curated Zelda 64: Recompiled only credits it for headers and some functions. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own US Majora’s Mask ROM as the base ROM; .z64, .n64 and .v64 byte orders are accepted. The repository includes no game assets or assembly: the build decompresses the supplied ROM and derives files, assets and disassembled code and data from it before compiling a ROM and a compressed ROM. - **Prerequisites:** The documented host is Linux, native or under WSL or a VM, with Debian or Ubuntu recommended: Git, build-essential, MIPS binutils, curl, Python 3 with pip and venv, libpng and libxml2. macOS and Docker have separate guides. The default compiler is a static recompilation of IDO 5.3 and 7.1 that the tools Makefile downloads from decompals/ido-static-recomp; GCC and NON_MATCHING builds turn the checksum comparison off. - **Scope:** README calls this a work-in-progress decompilation whose codebase may still change drastically, and warns that some parts of the ROM may not yet be shiftable, so modifications can be difficult. Only N64 US 1.0 is supported; the Makefile also lists a WIP N64 Japan 1.1 target with checksum comparison disabled. Majora’s Mask 3D is out of scope, and the output is an N64 ROM, not a PC executable. - **Testing evidence:** A default build checks both ROMs against stored MD5 values and prints OK or FAILED; FAILED means a bad base ROM or non-matching code. CI builds the US version in matching mode and Japan 1.1 as non-matching, using base ROMs from the project’s build container. The project’s mutable progress badge read 100% at review while the README still says WIP. - **License:** The reviewed tree has no top-level license file and GitHub detects no license, so source reuse terms are unstated; ROM contents and derived assets keep their own rights. The README forbids contributions from anyone who has ever accessed leaked Nintendo 64 SDK, libultra or Zelda 64 source. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### DLSSNR-AMD: reimplementing DLSS 5 neural rendering for RDNA4 > Reimplements the neural-rendering network of NVIDIA’s DLSS 5 library as Vulkan compute shaders for AMD RX 9000 (RDNA4) cards and supplies it to games through an NGX-compatible core and ReShade or Vulkan-layer routes. The weights are not distributed: installers extract them, hash-checked, from the user’s own nvngx_dlssnr.dll 310.9.16 or 310.8.0. The project compares its output with NVIDIA’s DLL on an RTX 5090 and reports close, not bit-identical, pictures. - Type: Case study - Targets: Binary · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The reviewed 0.0.x main targets RX 9000 cards because the network needs RDNA4 FP8 matrix instructions, reached through VK_KHR_cooperative_matrix; README says it was tested only on an RX 9070 XT. Linux under Steam/Proton with Mesa 26.2+ is the main version; Windows is an experimental preview tested with AMD Software 26.9.2, slower by default and closer to Linux with precompiled ACO machine code. OpenGL games are unsupported, and README warns against online games with anti-cheat. - **Prerequisites:** Requires the user’s own nvngx_dlssnr.dll, version 310.9.16 (both models) or 310.8.0 (the old model only); other versions are refused, and a model file is written only when every extracted entry matches a known hash. README says packages containing the model must not be shared. The optional int4-mixed network derives its weights at install from the user’s model and project calibration tables, which THIRD_PARTY.md says hold no weight values. - **Prerequisites:** The documented build runs on Ubuntu 24.04 with git, curl, Python 3, CMake, Ninja, MinGW-w64 and multilib g++; fetch_deps.sh pins third-party components, including glslang 16.5.0 for reproducible SPIR-V, and the Windows DLLs are cross-compiled. Games reach the network through an NGX core loaded by OptiScaler-NR, for DirectX 11/12 titles with an upscaler option, or through ReShade-based routes that estimate motion from the picture. - **Testing evidence:** For the 310.9.16 model, the verification notes report single-frame PSNR of 49.15–50.59 dB and SSIM of about 0.997 against NVIDIA’s unmodified DLL on an RTX 5090, plus short moving sequences, from one Tomb Raider (2013) frame and its downscales; the 310.8.0 comparison reports 45.56–49.06 dB. These are project measurements on one AMD card. - **License:** MIT covers the repository’s code; third-party components keep their own licenses, including GPL-3.0 OptiScaler-NR shipped as released. NVIDIA’s DLL and weights remain NVIDIA’s, and the project states it is not affiliated with NVIDIA or AMD. The repository does not describe how the network structure was recovered; its CLAUDE.md addresses coding assistants. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Breath of the Wild: per-function matching decompilation of the Switch executable > Reimplements part of Breath of the Wild’s Switch v1.5.0 main executable in C++ and checks each function against the original machine code. The project calls itself a hybrid decompilation/reimplementation: it contains no assets, its ELF holds only reimplemented functions and cannot run the game, and porting is an explicit non-goal. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Setup needs the user’s own main NSO executable from the Switch release. The pinned setup script verifies its hash, uses 1.5.0 directly and converts listed 1.6.0 or 1.9.0 executables to 1.5.0 with a project-hosted patch; RomFS and other game content are not used. The About page says the project is useless to anyone who does not own the game. - **Prerequisites:** The installation guide assumes Linux (native or WSL) or macOS and lists Python 3, Ninja, CMake, ccache, xdelta3, Clang and a Rust toolchain; the pinned CMakeLists requires CMake 3.30. Setup fetches Clang 4.0.1 for game code and installs tools/check. Submodules supply sead, agl, EventFlow, NintendoSDK headers and the shared nx-decomp-tools; the decompiling guide works from Hex-Rays or Ghidra output. - **Scope:** README calls this an experimental work-in-progress decompilation of Switch v1.5.0. The About page scopes it to the main executable (game code and most statically linked libraries), excluding RomFS assets, dynamically linked SDK libraries, libcurl, NEX and most of Havok. Functions are matched individually rather than placed at original addresses, so this is not a whole-executable matching build, a playable game or a port. - **Testing evidence:** tools/check diffs each listed function against the original executable, and data/uking_functions.csv records its status. At the pinned commit that list marks 32,079 of 113,490 functions matching, 514 non-matching, 7,601 work in progress, 6,270 library and 67,026 not decompiled; the mutable botw.link badges showed 17.493% by size and 30.398% by function on review. - **License:** The pinned tree has no root license file and GitHub detects none, so no reuse license is stated; submodules and Nintendo content keep their own terms, and the About page calls the work a legal gray zone. AGENTS.md sets disclosure and human-review rules for AI-assisted contributions. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Skyward Sword: Wii decompilation with hash-checked relinking > Reconstructs C++ source for The Legend of Zelda: Skyward Sword’s Wii main.dol and REL modules, starting from the user’s NTSC-U 1.0 (SOUE01) disc files. Objects marked matching are compiled from source and linked with objects split from the original, and the result is checked against SHA-1 hashes; the repository ships no assets or assembly and is not a port. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building needs the user’s own SOUE01 game: README names sys/main.dol and files/rels.arc from its data partition as the only required files. The repository contains no game assets or assembly; decomp-toolkit splits the user’s files into objects locally, using the input hash and split tables in config/SOUE01. - **Prerequisites:** Builds run natively on Windows with Python and ninja, or on Linux/macOS with ninja and the automatically downloaded wibo wrapper. configure.py pins decomp-toolkit v1.7.1, objdiff v3.4.1, binutils 2.42-1 and a 20250812 compiler bundle, selecting Metrowerks Wii/1.5 for most code and Wii/1.3 for most NW4R code; objdiff compares individual objects during development. - **Scope:** README describes a work-in-progress Wii decompilation whose only supported version is SOUE01 (NTSC-U 1.0); configure.py also lists SOUP01, but the pinned tree has configuration only for SOUE01. The output is a rebuilt main.dol and REL set for the Wii, not a PC executable or port. - **Testing evidence:** The default ninja target links source-built objects only for units marked Matching (493 in configure.py; 536 remain NonMatching) and uses the original extracted object for the rest, then checks main.dol and 636 RELs against build.sha1. A passing check shows output identity. decomp.dev’s report for the pinned commit lists 27.89% of code bytes and 33,940 of 76,968 functions matched; CI uses a private container holding game files. - **License:** The repository carries CC0-1.0; that dedication does not cover Nintendo’s game, its files or the downloaded compilers. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### 2 Ship 2 Harkinian: a native Majora’s Mask port built on the decompilation > Builds native Windows, Linux and macOS versions of The Legend of Zelda: Majora’s Mask from an adapted copy of the zeldaret/mm decompilation, with libultraship reimplementing N64 SDK functions. Game data comes from a user-supplied ROM and is packed into an archive that custom asset packs can override. It targets a playable PC port with enhancements, not a byte-identical ROM. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** No copyrighted assets are included: supply a supported copy of Majora’s Mask. The docs list SHA-1 hashes for NTSC-U 1.0 and NTSC-U GC versions. Built-in extraction turns the supplied game into an mm.o2r archive; custom .o2r or .otr packs go in a mods folder, and the README notes that fast64 does not fully support MM. - **Prerequisites:** Source builds need the libultraship, OTRExporter and ZAPDTR submodules plus CMake. Windows uses Visual Studio 2022 with the v143 toolset, Python 3 and at least 8 GB of RAM; the Linux lists include GCC or Clang, Ninja, SDL2, libzip, spdlog, tinyxml2 and Opus/Vorbis libraries; macOS needs Xcode tools with SDL2, libpng, GLEW, Ninja, CMake, nlohmann-json and libzip. - **Scope:** The reviewed develop commit follows release 5.0.1 (2026-08-25), published as Windows, Linux and macOS archives; nightly CI builds are for playtesting and may have bugs and crashes. The repository’s decomp_diff.py describes its game sources as changed decompilation code compared with the official zeldaret/mm repository. Rendering uses DirectX 11, OpenGL or Metal. - **Testing evidence:** The README and build guide report no matching, checksum or fidelity checks for the port; the release notes list tweaks and bug fixes. Enhancement and randomizer code changes behavior relative to the original game. - **License:** The repository is CC0 1.0, and the libultraship submodule is MIT; game content from the user’s copy keeps its own rights, and the README says the project does not condone piracy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Ship of Harkinian: a native Ocarina of Time port built on the decompilation > Builds Ocarina of Time as a native PC application from the OoT decompilation’s source, with libultraship standing in for the N64 libultra SDK and DirectX 11, OpenGL or Metal rendering. No game assets are shipped: they are converted from the user’s supported ROM into an .o2r archive, and the port adds save states, alternate and custom assets and other enhancements. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Play requires a legally acquired, supported Ocarina of Time ROM; docs/supportedHashes.json lists 19 SHA-1 entries covering PAL, NTSC (US/JP), GameCube, Master Quest and debug variants. Copyrighted assets are not included and are converted from that ROM into oot.o2r or oot-mq.o2r; prebuilt releases still need the ROM. - **Prerequisites:** README documents Windows, Linux (AppImage) and macOS releases with DirectX 11, OpenGL or Metal; CMake also has Nintendo Switch and CafeOS (Wii U) branches. Source builds need CMake 3.26+, Python 3, Git and the libultraship and Torch submodules, plus Visual Studio 2022 (v143) on Windows or the listed distribution packages and minimum GCC/Clang versions on Linux. - **Scope:** README presents Ship of Harkinian as built on libultraship and dependent on source from the OoT decompilation project; the soh/src tree carries that decomp-derived game code. The output is a modified native port (CMake project version 9.3.0) with added features, not a matching ROM build or a byte-for-byte reconstruction. - **Testing evidence:** The reviewed CI workflow builds Windows, macOS and Linux packages and generates soh.o2r; it runs no gameplay or fidelity comparison against the original game. - **License:** The pinned tree has no root license file and GitHub detects none; the randomizer’s 3drando component carries its own license, the submodules are separate repositories and Nintendo content keeps its own rights. README says the project does not condone piracy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### The Minish Cap: a GBA decompilation targeting five ROMs > Recreates a C source base for The Legend of Zelda: The Minish Cap from information in the game and static or dynamic analysis, building five Game Boy Advance ROMs: USA, EU, JP and two demos. Each version takes its assets from a user-supplied original ROM, and normal builds check the output’s SHA-1 hash. The project remains a work in progress, and some parts of the ROM may not yet be shiftable. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The repository includes no game assets. Each version to be built needs its own original base ROM matching the SHA-1 listed in INSTALL.md; the build derives its assets from that ROM. - **Prerequisites:** Builds run on Linux, on macOS with the Xcode command line tools (GNU make and sed are recommended), or on Windows through WSL, WSL2 or Cygwin. They need build-essential, Git, Python 3 with pip and pycparser, CMake, libpng, an arm-none-eabi-gcc toolchain (standalone or devkitPro gba-dev) and pret’s separate agbcc compiler installed into the tree. - **Scope:** README calls this a WIP decompilation whose codebase can still change drastically, and warns that some parts of the ROM may not yet be shiftable, so modifications can be difficult. Its targets are tmc.gba (USA, the default), tmc_eu.gba, tmc_jp.gba, tmc_demo_usa.gba and tmc_demo_jp.gba. The output is a GBA ROM, not a native PC port. - **Testing evidence:** COMPARE runs the SHA-1 check for normal builds and is off for CUSTOM builds, which INSTALL.md requires after modifying the game. The Jenkins pipeline builds all five versions with ROMs held on its build agent and publishes progress from the USA map file. For the reviewed commit, the matching log counts all 647,908 USA code bytes as source by the script’s own rules, which also count asm/src, asm/lib and libc objects, but only 238,628 of 13,933,140 data bytes. - **License:** The reviewed tree has no license file and GitHub detects no license, so reuse terms for the source are unstated; original ROMs, derived assets and agbcc keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Ocarina of Time: decompilation with MD5-checked ROM builds for 16 versions > Recreates a C source base for Ocarina of Time that rebuilds 16 Nintendo 64, GameCube and iQue Player ROM versions, using information from the game and static and dynamic analysis. Assets come from the user’s own ROM and each default build is checked against that version’s MD5; README states the project is not producing a PC port and still calls the repository a work in progress. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Each build needs the user’s own base ROM for the chosen version, matching an MD5 listed in README; the repository includes no game assets and extracts them from that ROM during setup. Native ports such as Ship of Harkinian, and recompilation projects, are separate from this repository’s output. - **Prerequisites:** README documents Linux or WSL builds, with separate macOS and Docker guides, needing Git, build-essential, curl, Python 3.10+ with pip and venv, libxml2 and a MIPS binutils toolchain. N64 and GameCube code builds with IDO 7.1 and 5.3 through ido-static-recomp; iQue builds also use EGCS for some files, and an optional GCC build is non-matching. - **Scope:** README describes recreating a source base from scratch using information inside the game and static and/or dynamic analysis, and states that it is not producing a PC port. It builds 16 N64, GameCube and iQue Player ROM versions (default gc-eu-mq-dbg); some ROM parts may not yet be shiftable, so modding can be difficult. - **Testing evidence:** With the default COMPARE=1, make checks the built ROM’s MD5 against the version’s checksum file and prints OK or FAILED; NON_MATCHING=1 or COMPILER=gcc turns the check off. GitHub Actions, using a private container holding the base ROMs, reported all 16 version builds successful for the pinned commit, and the mutable progress badge read 100% on review. - **License:** The pinned tree has no license file and GitHub detects none, so no reuse license is stated; Nintendo content and compiler components keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Project Arwing: Star Fox recompiled from a matching disassembly > Disassembles Star Fox’s 65816 and SuperFX code from runtime coverage and recursive descent, reassembles it into the original ROM, then translates it statically to C on a from-scratch SNES runtime for Windows, macOS and Linux. Code never reached in recorded sessions, and RAM code that no longer matches the ROM, falls back to an interpreter; the README reports identical per-frame hashes for both paths. The generated C is a mechanical translation rather than hand-decompiled source, and results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Star Fox (USA) (Rev 2) ROM matching the SHA-1 in README; other revisions and regions are untested. Graphics, models and music are extracted from it at build time. The source build expects a headerless image, while the installer strips a 512-byte copier header. No game data is included. - **Prerequisites:** Releases target Windows x64, macOS 11+ (not notarized) and Linux x86_64/ARM64 AppImages. Source builds need Python (3.10+ on Windows) with Visual Studio 2022 Build Tools, Xcode command-line tools and SDL2, or gcc, SDL2, FreeType and DejaVu fonts; tools/build.py chains extraction, assembly, recompilation and compilation. - **Testing evidence:** README reports a byte-identical ROM rebuild, 34,472 65816 and 14,577 SuperFX instructions, and 99.4% CPU / 100% SuperFX dispatches running recompiled over 20k gameplay frames. It lists the intro, title, training, Corneria and other levels reached by random play as playable. Labels are auto-generated, unreached code remains data run by the interpreter, and audio was checked only indirectly, not against hardware. - **Testing evidence:** tools/build.py compares the reassembled ROM’s SHA-1 but only warns on a mismatch. The documented contributor check diffs --hashlog output from recompiled and --interp runs. CI assembles and recompiles without a ROM, zero-filling data. - **License:** MIT covers tools/, src/, installer/, res/ and the build scripts; LICENSE excludes asm/, a disassembly of Nintendo's Star Fox code, and anything extracted from a ROM. This is an unofficial fan project unaffiliated with Nintendo. ##### Primary sources 1. 2. 3. 4. 5. #### Project Arwing (2): Star Fox 2 recompiled from a matching disassembly > Rebuilds Star Fox 2 from a coverage-seeded 65816 and SuperFX disassembly that reassembles to the original ROM, then translates it statically to C for native Windows, macOS and Linux builds. Unreached code and RAM code that differs from the ROM run through an interpreter, and the README reports identical per-frame hashes against interpreted runs. It accepts the SNES Classic release image, not the 1995 prototypes; results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Star Fox 2 ROM from the SNES Classic / Mini release, matching the SHA-1 in README; the 1995 prototypes will not work. Graphics, models and music are extracted from it at build time, and battery saves are written beside the rebuilt ROM. No game data is included. - **Prerequisites:** Releases target Windows x64, macOS 11+ (not notarized) and Linux x86_64/ARM64 AppImages. Source builds need Python (3.10+ on Windows) with Visual Studio 2022 Build Tools, Xcode command-line tools and SDL2, or gcc, SDL2, FreeType and DejaVu fonts; tools/build.py chains extraction, assembly, recompilation and compilation. - **Scope:** README reports a byte-identical ROM rebuild, 66,520 65816 and 23,186 SuperFX instructions, and 99.7% CPU / 100% SuperFX dispatches running recompiled over 20k gameplay frames, listing intro, title, menus, map and missions as playable. Labels are auto-generated, unreached code stays as interpreted data, and audio was checked only indirectly. README says Smooth mode removes slowdown but, unlike the Star Fox project, adds no interpolated 60 fps frames yet. - **Testing evidence:** tools/build.py compares the reassembled ROM’s SHA-1 but only warns on a mismatch, and the documented contributor check diffs --hashlog output from recompiled and --interp runs. HD 3D hooks one of several projection routines and recovers sub-pixel positions for about 66–90% of vertices. - **License:** MIT covers tools/, src/, installer/, res/ and the build scripts; LICENSE excludes asm/, a disassembly of Nintendo's Star Fox 2 code, and anything extracted from a ROM. This is an unofficial fan project unaffiliated with Nintendo. ##### Primary sources 1. 2. 3. #### Little Planet: Sonic CD recompiled from a matching disassembly > Disassembles every executable file on the Sonic CD disc from runtime coverage and recursive descent, reassembles them byte-identically, and translates the code statically to C on a from-scratch Mega-CD runtime that replaces the BIOS with a high-level implementation. Recompiled blocks run only where memory still holds the code they came from, and a script compares 96 stage runs frame by frame against the interpreter. The project also patches in widescreen and per-zone saves; results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Sonic CD disc image (cue/bin, iso, ccd/img/sub, chd, or cue with compressed audio). The Japanese G-6021 release, identified by a data-track SHA-1 in README, is the tested one; other releases boot but are untested. No BIOS dump is needed, and no disc data is included. - **Prerequisites:** Releases target Windows x64 (installer or portable zip), macOS 11+ (not notarized) and Linux x86_64/ARM64 AppImages. Source builds need Python (3.10+ on Windows) and SDL3, with Visual Studio 2022 Build Tools, Xcode command-line tools or gcc/g++. The optional remastered opening also needs a separately built FFmpeg and a fetched video. - **Scope:** README reports that all 112 executable files reassemble byte-identically to the Japanese release, that 622k instructions recompile into 22,897 blocks, and that boot, gameplay, audio and bit-exact save states work. The disassembly is code only; graphics, sound and level data stay on the user’s disc. True16:9 widescreen and saves after every zone patch the game’s own programs, so those options depart from the original game. - **Testing evidence:** README documents tools/decomp.sh for extracting the disc, reassembling asm/ and comparing each file; tests/rc_check.sh compares per-frame RAM and CPU-PC hashes of recompiled and --interp runs across 96 scripted stages. README also reports SingleStepTests results: all 1.6M Z80 cases, and all 1M 68000 cases apart from some undocumented DIVS/ASR and address-error cases. CI tests only a homebrew test disc. - **License:** MIT covers the runtime, tools and installer. third_party/ code, the bundled LGPL 2.1 FFmpeg and LuanUP’s remastered opening, included with permission, keep their own terms, and nothing extracted from a disc is covered. The reviewed LICENSE’s exclusion note names Star Fox 2 rather than Sonic CD. The project is unofficial, unaffiliated with Sega. ##### Primary sources 1. 2. 3. 4. 5. #### vf2-decomp: differentially validated Virtua Fighter 2 recovery > Recovers Virtua Fighter 2 Version 2.1’s Sega Model 2A i960 program into portable, non-matching C17, accepting each recovered path only when it matches a reference i960 executor at controlled boundaries. The repository adds ROM validation, i960 and 68000 analysis tools, a bounded Model 2A hardware model and snapshot-based differential runners. README states that it is not yet a playable port; match flow, combat, physics, AI, rasterization and much of the audio remain open. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** ROM-backed analysis and differential tests need a user-supplied, legally obtained copy of the supported arcade ROM set. config/vf2_v22_roms.csv records only filenames, sizes and hashes, and vf2rom verifies the set. The repository contains no Sega game data, and contributors must not commit ROMs or reconstructed region images. - **Prerequisites:** Builds use CMake with a C17 compiler and warnings treated as errors, plus an optional sanitizer configuration. STATUS lists GCC/Clang CI, and README names native Windows MSVC as the canonical agent workflow. Setting VF2_ROM_DIR enables the ROM-backed CTest targets; otherwise only ROM-independent tests run. - **Scope:** README describes a clean-room, non-matching recovery whose native runtime preserves CPU, frame, counter and mutable-memory state through repeated scheduler and gameplay dispatches, including a 1,270,824-instruction post-scheduler corridor with no interpreted instructions. It explicitly does not claim complete decompilation, a playable executable, full Model 2/TGP emulation, SCSP DSP audio or every gameplay branch. Unverified paths fail closed with VF2_ERROR_UNSUPPORTED. - **Testing evidence:** The vf2i960 native-dispatch commands run the recorded differential milestones, and vf2cycles advances recovered C and the reference executor from a shared snapshot, stopping in strict mode at the first unsupported block, reference failure or state mismatch. STATUS reports MATCH for the third through sixth dispatches. CI runs only ROM-independent tests, so the ROM-backed results remain project-reported. - **License:** BSD-3-Clause covers the project’s code; MAME and public Intel i960 documentation serve as cross-references, not included source. docs/LEGAL.md discloses 301 original Sega symbol names, taken from a later Model 2 port DLL, as non-clean-room naming, and an untracked Sonic The Fighters disassembly is used only as a navigation aid. AGENTS.md addresses coding agents. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### z2rs: an incremental Rust reconstruction of Zelda II checked against an emulator > Rebuilds Zelda II: The Adventure of Link (NES) in Rust for desktop, browser and Android by replacing the game’s 6502 routines one at a time. A built-in interpreter still runs the user’s ROM and hands ported routines to Rust, while a verifier compares RAM, sprites, palette and frames with a reference emulator. It is a behavioral, clean-room-style reconstruction guided by a community disassembly, not a decompilation or a finished standalone engine. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Only the No-Intro USA dump is accepted, identified by the hash of the ROM body without its 16-byte iNES header (CRC32 BA322865). Graphics, maps, text and music are read from that ROM at run time, and nothing from the game is in the repository. Co-op, widescreen, HD packs, the randomizer and other enhancements are optional additions; Android lacks online co-op, the randomizer and enhancements. - **Prerequisites:** Source builds need stable Rust; the browser build adds the wasm32-unknown-unknown target and wasm-pack, Android adds the SDK, NDK and cargo-ndk, and the default desktop netplay feature needs a C compiler. Release archives are not code-signed. Online co-op uses a public signalling server by default, and the desktop build shows Discord presence unless it is turned off. - **Scope:** The reviewed commit is release v0.5.2 (2026-10-10), with Linux, macOS (Intel and Apple Silicon) and Windows archives plus an Android 8.0+ APK; z2rs.com hosts the browser build. PROVENANCE.md says it is not yet a standalone reimplementation: ported routines register in trap tables and the rest of the ROM is interpreted. The pinned ports.toml still marks all 2,960 routines unported. - **Testing evidence:** z2-verify runs the ROM in tetanes-core 0.15 beside z2rs with identical input and compares RAM, battery WRAM, sprite OAM, palette and framebuffer after every frame, with two documented edge allowances for that emulator. Long tests replay TASVideos movies downloaded separately, and ROM-dependent tests skip without their inputs. The reviewed workflow only packages releases; no published verification results were found. - **Attribution:** The sole maintainer releases the code under MIT; vendored matchbox_socket is MIT OR Apache-2.0, and the game itself is not covered. Routine layout comes from the CC0 FiendsOfTheElements/z2disassembly submodule and Data Crystal notes; the project describes one maintainer working from that material, not a two-team clean room, and publishes only a snapshot of earlier private history. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### sm64ex: an enhanced Super Mario 64 PC port from the decompilation > Builds native Super Mario 64 executables from decompiled source, extending the sm64-port fork of the n64decomp reconstruction with renderer, input, camera, save-format and external-data options. Game assets are extracted from the user’s own ROM at build time. It is a non-matching enhanced port, not a byte-identical ROM reconstruction. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply an original Super Mario 64 ROM named baserom..z64 for each version built (us by default, jp or eu); extract_assets.py compares its SHA-1 with the bundled reference before extracting assets. The sh (Shindou) option skips extraction and is labelled experimental in the Makefile and broken in the wiki option table; a 2020 known-issues page reports buggy EU text and missing EU audio. - **Prerequisites:** The README defers building to the wiki, whose pages cover Linux (Python 3.6+, SDL2, GLEW, host GCC toolchain), Windows through MSYS2, FreeBSD, Raspberry Pi and an Emscripten/WebGL target; cross-compiling for Windows from Linux or WSL needs MXE, and OSX_BUILD enables macOS fixes. Renderers are OpenGL 2.1, OpenGL 1.3, Direct3D 11 and Direct3D 12, the DirectX ones only on Windows. - **Scope:** The reviewed nightly branch (last pushed 2024-12-17) describes itself as a fork of sm64-port/sm64-port, which GitHub records as a fork of n64decomp/sm64, the separately catalogued ROM reconstruction. The Makefile builds PC targets only: it defines NON_MATCHING and AVOID_UB and forces COMPARE to 0. - **Testing evidence:** The Jenkinsfile builds us, eu and jp and rebuilds us after each enhancement patch, all with comparison disabled. Options such as disabled draw distance, analog camera, texture fixes and cheats intentionally change behavior, and the wiki notes the draw-distance option may affect gameplay. - **License:** GitHub detects no repository license and the reviewed tree has no root license file; bundled tools carry their own licenses, and the src/pc notice reproduces an n64-fast3d-engine license that forbids binary redistribution. Original Nintendo content is not supplied, and the README forbids uploading copyrighted assets. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Ghostship: a libultraship native port of Super Mario 64 > Builds Super Mario 64 as a native PC, Switch and Android program by compiling decompilation-style game source against the libultraship platform library. A bundled extractor converts the user’s US or Japanese ROM into an O2R archive at first launch or build time. The project ships modern renderers, configuration menus and mod-archive loading, not a matching ROM. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Super Mario 64 ROM in .z64 byte order: the README accepts only the US and Japanese releases and lists their SHA-1 values. PC releases convert it to sm64.o2r; the Switch build reuses an O2R generated on PC, and the Android app checks the ROM hash and converts it on the device. No game data is bundled. - **Prerequisites:** Source builds use CMake with the libultraship and Torch submodules: Visual Studio 2022 with the v143 toolset, Python 3 and CMake on Windows, or GCC/Clang, Ninja, SDL2, libzip and the listed libraries on Linux. Renderers are DirectX 11, OpenGL, Metal and Vulkan where drivers allow. The building guide still names sf64.o2r and 2s2h.elf from other Harbour Masters ports. - **Attribution:** The reviewed develop branch declares version 3.0.0, matching the latest “Alfa” release. Its src tree keeps the audio, engine, game, goddard and menu layout of the n64decomp/sm64 reconstruction, with port code under src/port. - **Testing evidence:** GitHub Actions workflows build Windows, macOS, Linux, Switch and web packages. The README calls CI builds playtest-only and warns of bugs and crashes. No matching, regression or original-hardware comparison result is published. - **License:** The root LICENSE.md is MIT (2026, Lywx) for the project’s own code. Submodules keep their own terms, and Nintendo’s code-derived content and ROM assets are not licensed by it; the README says it does not condone piracy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Super Mario Sunshine: an in-progress matching GameCube decompilation > Reconstructs Super Mario Sunshine’s C++ source so that the original Metrowerks compiler reproduces byte-identical object files for four GameCube releases and the Switch 3D All-Stars build. The target binary comes from the user’s own disc image, and objdiff compares rebuilt objects function by function. The work is incomplete, and the repository publishes contribution rules for AI agents alongside its human workflow. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Copy your own disc image for each version into orig/. ISO (GCM), RVZ, WIA, WBFS, CISO, NFS, GCZ and TGC images are accepted, and the repository says it contains no game assets or assembly. The GMSJ01 symbol configuration is generated from the mario.MAP linker map found on that disc; the CI workflow notes that GMSE01 has no MAP file and skips symbol-order checks for it. - **Prerequisites:** Builds need Python and Ninja on Windows, macOS or Linux; the build fetches decomp-toolkit, binutils and retro Metrowerks compilers (GC 1.2.5 for most code), and runs them through the wibo wrapper on macOS and Linux. objdiff compares rebuilt objects with those extracted from the original DOL, and each version’s build.sha1 records the target DOL hash. - **Scope:** The README calls this a work-in-progress decompilation. configure.py defaults to GMSJ01 (JPN Rev 0) and also targets GMSP01, GMSE01, GMSJ01 Rev 1 and the GMSP01_NX build from Super Mario 3D All-Stars. Only objects marked Matching are linked by default; --non-matching links equivalent or modded objects. For GMSJ01 at the reviewed commit, decomp.dev reported 49.51% of code decompiled and 18.42% fully linked. - **Testing evidence:** AGENTS.md requires ninja baseline and changes_all regression reports for all five versions, each still reporting its DOL as OK. CI builds every version in a build container that supplies the original files and checks symbol order for changed units. These are project-reported checks and progress figures. - **Attribution:** AGENTS.md, symlinked as CLAUDE.md and GEMINI.md, sets workflows for AI agents. It bars unsupervised agents from MSL, MetroTRK, THPPlayer, Dolphin SDK and JSystem code and defers hard judgment calls to humans, but it does not quantify agent-written code. The repository declares CC0-1.0; Nintendo’s game, disc contents and the downloaded compilers keep separate rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Dusklight: a native Twilight Princess port built on the decompilation > Reimplements Twilight Princess as a native application for desktop and mobile platforms, building on the zeldaret/tp decompilation and the Aurora GameCube/Wii compatibility layer. It runs from the user’s own disc image with no bundled assets and aims to stay accurate to the original while adding options, enhancements and mods. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** No copyrighted assets are provided: the user supplies a dump of their own disc, and README says every commercial disc except the Korean Wii release is supported. The executable reads ISO (GCM), RVZ, WIA, WBFS, CISO and GCZ images directly. - **Prerequisites:** Runtime needs a GPU with D3D12, Vulkan 1.1+ or Metal; D3D11 and Android OpenGL ES are best-effort without full accuracy or performance. The pinned tree has Windows, Linux, macOS, iOS, tvOS and Android platform folders, and CI builds Linux, macOS, iOS, Android and Windows targets. Source builds need CMake 3.25+, Python 3, the listed per-OS toolchains and recursive submodules, including Aurora. - **Scope:** README calls Dusklight a reverse-engineered reimplementation that aims to be as accurate as possible while adding options, enhancements and tools. It is based on the zeldaret/tp decompilation, which README says is matching only for GameCube, so Wii discs still show the GameCube HUD and other GameCube specifics. This is a modified port, not a matching rebuild of the original executable. - **Testing evidence:** The CI workflow builds packages but runs no comparison against the original game. Accuracy and enhancement claims are project-reported. - **License:** LICENSE.md is CC0-1.0; it does not cover Nintendo’s game or disc content, and submodules such as Aurora and the randomizer mod are separate repositories. README says the project does not accept primarily AI-generated contributions and warns of unaffiliated sites spreading AI-generated misinformation. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Metaforce: a Metroid Prime engine reimplementation rebuilt on the decompilation > Started in 2015 as a reverse-engineered reimplementation of the Metroid Prime engine, Metaforce has been rewritten on top of the PrimeDecomp matching decompilation. Its native app compiles that game code as non-matching C++ for desktop and mobile through the Aurora GameCube compatibility layer and loads a user-selected disc image. The README says builds are unavailable while the rewrite stabilizes. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The repository ships no game files; its orig/ version folders hold only placeholders. At startup the app takes or asks for a Metroid Prime disc image (ISO, GCM, CISO, GCZ, RVZ, WIA or TGC). CMake compiles the native target with TARGET_PC, NONMATCHING and VERSION=1, and configure.py names version 1 as the default GM8E01_00 (NTSC-U v1.088) build; the README lists no supported disc revisions. - **Prerequisites:** Building needs CMake 3.25+, Python 3 and a recursive clone with the aurora, borealis and musyx submodules; Windows uses Visual Studio 2019 with the Clang and clang-cl components, macOS needs Xcode 11.5+, and Linux needs the listed Ubuntu, Arch or Fedora packages. README platforms are Windows 10+ (D3D12, Vulkan or D3D11), macOS 10.15+ (Metal), Linux (Vulkan), Android (Vulkan or OpenGL ES) and iOS (Metal); Android also needs SDK Platform 37, the NDK and JDK 17+. - **Scope:** README dates development to June 2015 by Cirrus and Antidote and says the project was recently rewritten on the PrimeDecomp matching decompilation; builds are unavailable while it stabilizes, although CI builds Windows, Linux, Apple and Android packages. The only GitHub release is a 2015 prerelease, so none corresponds to the rewrite. This is separate from Odrannnn/MetroidPrimePort, another native port built from PrimeDecomp. - **Testing evidence:** configure.py still records per-object matching status across ten disc versions for the separate GameCube build, but CI ignores those files and builds only native packages. The reviewed sources publish no fidelity or gameplay checks for the native app. - **License:** Metaforce contributors’ code is MIT, and a separate LICENSE.decomp carries CC0 1.0; the reviewed files do not say which directories each covers. Disc content keeps its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Super Mario Sunshine (USA): an AI-assisted matching decompilation fork > Extends the doldecomp Super Mario Sunshine decompilation to the North American GMSE01 release. The README says AI was used extensively, and the repository’s agent rules, work order and progress files describe batch-based Claude and Codex orchestration. Its rebuilt DOL is reported byte-identical, but unfinished objects are still linked from code extracted from the user’s disc. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own North American Rev 0 disc image in orig/GMSE01 (ISO, RVZ, WIA, WBFS, CISO, NFS, GCZ or TGC). The GMSE01 build notes record the required extracted-DOL SHA-1. Those notes say the initial symbols came from a community-hosted marioUS.map that is not on the US disc, while AGENTS.md calls the US map a real map shipped on the disc. - **Prerequisites:** Builds use Python 3 and Ninja on Windows, macOS (with Wine Crossover) or Linux (wibo on x86, Wine elsewhere), plus the pinned decomp-toolkit and Metrowerks tools. The output is build/GMSE01/mario.dol, checked against the extracted original. Playing it still needs the original disc image in Dolphin; a separate native PC port uses this fork as its decompilation submodule. - **Scope:** This hobby fork of doldecomp/sms targets GMSE01 (USA Rev 0). The README says it began when upstream’s Japanese decompilation was about 38% matched, and PROGRESS.md names upstream ab00c3c9 as its base. GMSJ01 and GMSP01 configs remain, but the README marks PAL as slightly broken and AGENTS.md says neither can be built or regression-tested in this clone. - **Testing evidence:** The README (2026-09-29) reports 99.60% fuzzy, 73.65% byte-perfect and 34.79% source-linked code, with 12,052 of 12,904 functions exact and 542 of 732 objects linked; PROGRESS.md (2026-09-27) gives slightly lower figures. The fork’s CI matrix builds only GMSJ01, so GMSE01 results are locally reported. - **Attribution:** AGENTS.md, symlinked as CLAUDE.md and GEMINI.md, lifts upstream’s ban on autonomous library work. It requires agents to work only from the binary, the linker map and the repository, and forbids fakematches and leaked SDK sources. The repository keeps CC0-1.0, while Nintendo content and the compilers keep separate rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Donkey Kong 64: Recompiled — an N64Recomp native port > Uses N64Recomp to statically recompile the US Nintendo 64 release of Donkey Kong 64 into a native port, with RT64 as the renderer. The port is not built from decompiled source, but borrows headers and some functions from the in-progress DK64 decompilation for patches and enhancements. Its recompiler configuration reads a checked-in symbol dump and the ROM rather than a decompilation ELF. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Plays only the user’s US Nintendo 64 Donkey Kong 64 ROM; other dump formats of that ROM are converted to .z64. The repository and releases contain no game assets, it is not an emulator for other ROMs, and the README describes modding and other-language support as future work. - **Prerequisites:** Release v1.0.3 (2026-09-30) ships Windows, Linux x64/ARM64, Flatpak x64 and macOS ARM64 archives. The README requires a Direct3D 12.0 (Shader Model 6) or Vulkan 1.2 GPU and an AVX-capable CPU, and lists Intel GPUs on Linux, the prebuilt Linux binary on some distributions, and overlay software as known problems. - **Prerequisites:** Source builds need a recursive clone, CMake and Ninja with Clang (Visual Studio 2022 with Clang and vcpkg curl on Windows), separately built N64Recomp and RSPRecomp, and a decompressed copy of the NTSC-U 1.0 ROM matching the SHA-1 in BUILDING.md; play still uses the standard ROM. - **Testing evidence:** The README reports high-frame-rate, widescreen and input-lag improvements alongside cutscene edge quirks at very wide aspect ratios. It publishes no equivalence or gameplay test; pinned-commit CI only builds the port, with extra inputs from a secret-configured checkout. - **License:** GPLv3 project license; the original game, the decompilation submodule and other dependencies keep separate terms. CONTRIBUTING.md forbids AI-generated code contributions. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Twilight Princess: a decompilation with fully matching GameCube code > Reconstructs Twilight Princess source that compiles back to binaries identical to the originals, building GameCube, Wii and Nvidia Shield releases from one codebase through conditional compilation. README reports the GameCube code as completely matching but not every translation unit linked yet, with Debug and Wii alignment ongoing; the repository ships no assets or assembly and will not produce a port. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building needs the user’s own disc image of the chosen version in a supported format (ISO/GCM, RVZ, WIA, WBFS, CISO, NFS, GCZ or TGC), which can be deleted after the first build. The repository contains no game assets or assembly; decomp-toolkit splits the original locally. - **Prerequisites:** Builds run natively on Windows with Python and ninja, or on Linux/macOS with ninja and the automatically downloaded wibo wrapper. configure.py pins decomp-toolkit v1.8.0, objdiff v3.6.1, binutils 2.42-1 and a 20251118 compiler bundle, selecting Metrowerks compiler versions per target and library; objdiff provides per-object diffing. - **Scope:** README describes a work-in-progress decompilation with ten listed targets: three GameCube releases (GZ2E01, GZ2P01, GZ2J01), five Wii builds including a kiosk demo, and two Nvidia Shield China builds. Output is the original platform’s executable and REL modules; README states the project will not produce a PC or other port, and Dusklight is a separate project built on this code. - **Testing evidence:** The default build links source-built objects for units marked complete and original extracted objects for the rest, then checks the output against each version’s build.sha1 (758 entries for GZ2E01). decomp.dev’s reports for the pinned commit list 100% of code matched for all three GameCube versions, with 2,583 of 2,608 units complete, against 54.47% for ShieldD and 47.06% for Wii RZDE01_00. CI runs in a private container holding game files. - **License:** LICENSE.md is CC0-1.0; it does not cover Nintendo’s game, disc content or the downloaded compilers. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Castlevania: Symphony of the Night: matching decompilation across PlayStation, PSP and Saturn builds > Recreates C source for Castlevania: Symphony of the Night from its PlayStation, PSP and Saturn binaries, aiming for code that compiles byte for byte to the original game files. The work-in-progress build combines decompiled code with assets and assembly extracted from a user-supplied disc image, then checks per-version SHA-1 hashes. Native PC experiments in the same tree are documented as unfinished and are not a released port. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The repository includes no game assets and none of the assembly needed to compile; README requires a prior copy of the game. The Build wiki asks for an unmodified US PlayStation disc as BIN/CUE, while the pinned Makefile reads both PSP-derived builds from a European Dracula X Chronicles ISO and the Saturn build from a Saturn BIN/CUE, each placed under disks/ with a version-specific name. - **Prerequisites:** The Build wiki is tested against Ubuntu 24.04 LTS in CI and also covers Windows through WSL 2 and Arch-based distributions; a Dockerfile provides an Ubuntu Noble environment. Builds need Go, Rust, Python 3.12+, MIPS and SH binutils, a MIPS GCC, ninja and submodule tools such as m2c, maspsx, asm-differ, mipsmatch and decomp-permuter. Project-hosted prebuilt archives, including cc1-psx, mwccpsp, a Cygnus 2.7 toolchain and wibo, are checked against SHA-256 files; the Saturn build also uses dosemu. - **Scope:** README describes a work-in-progress matching decompilation of four builds: us (PlayStation SLUS-00067, the reference), hd (an unreleased Japanese PS1 build found in Castlevania: Dracula X Chronicles data), pspeu (the European Dracula X Chronicles release) and saturn (the externally developed Saturn port). The Build wiki notes that some non-matching functions remain behind a NON_MATCHING macro and are not guaranteed to be functionally equivalent. README links mutable progress pages on sotn.xee.dev and decomp.dev. - **Testing evidence:** Unless SKIP_CHECK is set, the pinned build code hashes its outputs against config/check..sha, which lists main.exe, DRA.BIN, RIC.BIN and stage and overlay files for us and shorter lists for hd, pspeu and saturn. The wiki still names a make check step that the pinned Makefile does not define. These checks compare file identity for the supplied version. - **License:** The Makefile also accepts a pc version and src/pc holds native-port code, but the PC Port wiki page says no working end-to-end port based on the decompilation exists yet. The repository declares AGPL-3.0, while disc images, extracted assets and assembly, and the downloaded compilers keep separate rights. CONTRIBUTING allows coding-agent assistance only for changes contributors can justify and operate manually and requires commits and pull requests without autonomous tooling. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. #### LEGO Island, portable: a multi-platform port of the decompiled source > Adapts the LEGO Island decompilation into a portable build for desktop, mobile, console, DOS and Web targets. Windows-only subsystems are replaced with SDL3, miniaudio, iniparser and a custom Direct3D Retained Mode re-implementation, while core gameplay is meant to stay unchanged. It ports reconstructed source rather than checking byte-identical binaries, so it is distinct from the exact-rebuild decompilation case. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An existing copy of LEGO Island is required. The guided installer asks for the retail CD-ROM or a disc image made from it and says any 1.0 or 1.1 retail version in any language works; its optional HD audio pack is limited to English 1.1. The installer describes the isle.pizza Web build as streaming the game without a local disc. - **Prerequisites:** Builds use CMake 3.25+ with a C++17 compiler; by default CMake fetches SDL3 and iniparser, and libsmacker and miniaudio are submodules. README points to the CI workflow instead of a separate build guide; that workflow uses MSVC, MinGW, macOS/Linux toolchains and platform SDKs such as Emscripten, devkitPro, VitaSDK, DJGPP and Android, and the desktop settings tool needs Qt 6. Release downloads are continuous builds of master, which README warns may regress. - **Scope:** README describes a portable version of English LEGO Island 1.1 built on isledecomp/isle, aiming at platform independence without gameplay changes or rewrites for their own sake, and the contributor guide accepts LEGO1 changes mainly when they serve platform compatibility. Light modding goes through extensions, which in the reviewed tree include multiplayer, a third-person camera and asset loaders. The status table lists Windows, macOS, Linux, FreeBSD, DOS, Web, iOS, Android, Xbox One, PlayStation Vita, Nintendo Switch and Nintendo 3DS. - **Testing evidence:** CI checks formatting and configures, builds and packages each platform target; it does not run the game or compare its behavior with the original. The per-platform status entries are CI badges. Kaitai Struct descriptions document save, animation, world-database and texture formats. - **License:** The repository carries LGPL-3.0; bundled and fetched third-party libraries keep their own terms, and the original game data, LEGO trademarks and the bitmaps the installer takes from the original setup program retain separate rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### c1: a C port of PlayStation Crash Bandicoot > Ports the original PlayStation Crash Bandicoot game code to C function by function; its coding standard labels functions with the addresses of their original implementations. Only the PC build, using OpenGL, SDL2 and FluidSynth, currently works; it loads asset files from the user’s game disc and is only partially playable. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Running needs the NSD/NSF asset files from the user’s own Crash Bandicoot disc; the repository ships no game data and the README does not name a supported disc region or version. The game boots into the title sequence unless a constant is changed and the code recompiled. - **Prerequisites:** Only 32-bit x86 executables are supported, built with GNU Make and a 32-bit GNU toolchain (multilib GCC/G++ on 64-bit hosts) against OpenGL 2.0+, SDL2 and FluidSynth (cimgui is bundled). Compilation has been tested only on Ubuntu/Debian; there are no releases, and the last commit at review is 2024-01-22. - **Limits:** The README reports the code as 100% ported but functionality at 78%. The tracked issue list includes crashes in several levels, incorrect camera and collision behavior, broken demo mode and title states, and behavior that changes under compiler optimization; the PlayStation (Psy-Q) build does not work. - **Testing evidence:** No byte-matching, equivalence or automated gameplay check is published. The repository has no license file, so reuse rights are unspecified, and the original game retains its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Metroid Prime Port: an AI-assisted native port of the PrimeDecomp decompilation > Compiles the PrimeDecomp decompilation of Metroid Prime’s game and engine code as native C++20 for Linux, Windows and Android, with an experimental macOS build. Aurora supplies the GameCube SDK compatibility layer and rendering, and the port reads a user-supplied disc image at run time. The author states that parts were written with AI coding assistants under their oversight. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** No game content is included: supply a GameCube USA 1.00, 1.01 or 1.02 (GM8E01) or PAL (GM8P01) disc image as .iso, .gcm, .rvz, .wbfs, .ciso or .nkit. Japanese, Korean, Wii Trilogy and Remastered releases are not run as the base game; an experimental importer can read models and effects from the user’s own Remastered dump. - **Prerequisites:** Builds need CMake 3.25+, Ninja, a C++20 compiler and a C23-capable C compiler for MusyX; Windows uses clang-cl from LLVM in an MSVC developer environment, and Android builds through Gradle. Configuring downloads about a dozen SHA-256-checked dependencies; Linux links several statically and then needs only OpenSSL 3 and the C/C++ runtime. The macOS app is ad-hoc signed and not notarized. - **Scope:** The reviewed port-branch commit is 16 commits after release v0.29.0 (2026-10-17), which ships Windows, Linux tarball, AppImage, Flatpak, Android and macOS arm64 packages; the macOS build is experimental and has not been played on a real Mac. The repository forks PrimeDecomp/prime and adds widescreen, uncapped frame rate, controls, save conversion, a randomizer and an Archipelago client. It does not link the separate DolRecomp recompilation experiment, and its decomp/ GameCube build is not used by the port. - **Testing evidence:** CI builds and runs the disc-free CTest port suite on Linux with GCC 14 and Clang 18 for pushes and pull requests; Windows and macOS workflows run weekly or by hand, and the Windows job also checks that the package reaches main and reports the missing disc. Opt-in real-disc smoke drivers cover lifecycle, mouse, area-reload and world-jump scenarios, with results reported by the author. The 1.00 sequence-break option restores named script locks, not missing 1.00 geometry. - **License:** MIT covers only the project’s platform layer, scripts, tests, tools and docs. NOTICE says the game code in src/ and include/, the decompiled Dolphin SDK and the config/ symbol data derive from the retail executable, remain with their owners and are outside that grant, and that no game assets may be packaged; vendored and fetched components keep their own licenses. AI coding assistance is author-disclosed. ##### Primary sources 1. 2. 3. 4. 5. 6. #### The Wind Waker: a GameCube decompilation with hash-checked relinking > Reconstructs source for The Wind Waker’s GameCube executable and REL modules across the USA/Korea, PAL and Japanese releases and a Japanese kiosk demo. Matched units are compiled from source and linked with objects split from the user’s disc, then checked against per-version SHA-1 hashes; the repository ships no assets or assembly and covers the GameCube game, not the HD remaster. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building needs the user’s own disc image of the chosen version in a supported format (ISO/GCM, RVZ, WIA, WBFS, CISO, NFS, GCZ or TGC), which can be deleted after the first build. The repository contains no game assets or assembly; decomp-toolkit splits the original locally. - **Prerequisites:** Builds run natively on Windows with Python and ninja, or on Linux/macOS with ninja and the automatically downloaded wibo wrapper. configure.py pins decomp-toolkit v1.8.3, objdiff v3.7.3, binutils 2.42-1 and a 20251118 compiler bundle; README also describes a shared Ghidra project as an aid whose output is not accurate enough to copy directly. - **Scope:** README describes a work-in-progress GameCube decompilation supporting every GameCube version: GZLE01 (USA Rev 0 and Korea Rev 48), GZLP01 (PAL), GZLJ01 (Japan) and the D44J01 Japanese kiosk demo. Output is the original executable and REL modules, not a port. - **Testing evidence:** The default build links source-built objects only for units marked complete, uses original extracted objects for the rest and checks the result against the version’s build.sha1 (415–417 entries per version). decomp.dev’s reports for the pinned commit list 79.58% of GZLE01 code (32,968 of 39,324 functions) matched, 78.38–78.65% for the other retail versions and 74.08% for the demo. CI runs in a private container holding game files. - **License:** The repository carries CC0-1.0, which does not cover Nintendo’s game, disc content or the downloaded compilers. CONTRIBUTING.md rejects primarily AI-generated pull requests. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Sonic Mania: a game-code decompilation for the RSDKv5 engine > Reconstructs Sonic Mania’s game code in C and builds it with the separately decompiled RSDKv5 or RSDKv5U engine for Windows, Linux, Switch and Android. Assets must come from an official Sonic Mania (Plus) release; the project adds a mod loader and can build several retail versions. Its license describes the code as mostly functionally the same as the original, not byte-matching. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** It does not run without assets from an official Sonic Mania (Plus) release for Windows (Steam or Epic Games Store), Switch, PS4 or Xbox One; the Netflix Games version is not supported. By default it builds with the bundled RSDKv5 engine submodule at revision 3 (RSDKv5U) and game version 6, the last Steam release; with WITH_RSDK off it builds only the game code, and RETRO_DISABLE_PLUS is to be enabled for distribution builds. - **Prerequisites:** Clone recursively, because GitHub’s source ZIPs omit the required submodules. CMake builds use Visual Studio with vcpkg (libtheora, libogg, GLEW, GLFW3, SDL2) on Windows, build tools with GLEW, GLFW and libtheora development packages on Linux, devkitPro packages for Switch, and the engine repository’s instructions for Android. GL builds need a user-made shader mod for videos and filters. - **Scope:** The repository describes itself as a complete decompilation of Sonic Mania (2017); its license says it also contains original code and that most code is expected to be functionally the same. It adds a built-in mod loader and API and can build 1.00 (console launch), 1.03 (PC launch) and 1.06 (Plus update) variants. The reviewed commit is 15 commits after release v1.1.1 (2025-11-01). - **Testing evidence:** CI builds Windows x86 and x64 and Linux binaries against both the RSDKv5 and RSDKv5U configurations. The project publishes no comparison with the original binaries, and its FAQ says bugs present in official releases will mostly not be fixed. - **License:** The custom Sonic Mania Decompilation Source Code License v1 allows copying, modification and distribution only for non-commercial use, requires stating that the code is not the distributor’s, forbids distributing game assets other than unique modded ones, and binds forks to the same terms. Sega’s game and assets keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. #### MediEvil Recomp: a PlayStation static recompilation to C# > Statically recompiles the North American PlayStation release of MediEvil into C# with the RecompOne recompiler and runtime. The runtime stands in for BIOS, GPU, CD-ROM and other hardware services, and project patches change rendering, widescreen and terrain behavior. README stresses that this is a recompilation, not a decompilation, and labels it an open beta. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a legally owned North American MediEvil disc in bin/cue or CHD form; README and disc/README.md name the two track .bin files and the .cue expected in disc/. The project does not supply game files. RecompOne states that its runtime needs no BIOS or other Sony files, only the game files. - **Prerequisites:** Building needs Git with the pinned RecompOne and ShaderMod submodules and the .NET 10 SDK. Windows batch scripts or a manual RecompOne run against config/MediEvil.json generate the game code, which is then compiled as a .NET 10 application. Running needs the .NET 10 runtime, OpenAL and an OpenGL 2.1 GPU; v0.2b release packages cover Windows x64/arm64, macOS x64/arm64 and Linux x64. - **Scope:** The reviewed tree targets the North American PlayStation release (SCUS-942.27); config/MediEvil.json lists the main executable and its overlays for RecompOne to translate. README calls this an open beta in which things will break, with stable 1.0 unreleased. The v0.2b changelog replaces the PGXP renderer with a native floating-point rendering patch and adds widescreen fixes and an automatic updater. - **Testing evidence:** The build workflow recompiles and compiles the project using disc inputs from a separate access-restricted repository, then uploads the build; it does not run the game or compare behavior with the original. README credits references from an unnamed decompilation for function names and patches. - **License:** MediEvilRecomp has no license file in the reviewed tree, so its reuse terms are unstated; the RecompOne submodule declares MIT. Original game content, including the executable code the recompiler translates, retains separate rights. Both READMEs state that no AI was used to write the code and that AI-generated contributions are rejected. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Crash Bandicoot 2 Recompiled: a PSXRecomp native build > A Windows launcher that uses the PSXRecomp recompiler and runtime to translate the user’s Crash Bandicoot 2: Cortex Strikes Back disc to C and compile it locally, so the game runs as native code with an emulated PlayStation hardware layer. The repository holds the launcher, a patched vendored runtime and a long bring-up log; it distributes no game code or data. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs a disc image the user owns of the North American release (serial SCUS-94154), as .cue/.bin or .chd; the launcher checks tracks, sectors and boot serial and hashes the image. No PlayStation BIOS is required because MIT-licensed OpenBIOS is included, and locally generated files derived from the disc must not be redistributed. - **Prerequisites:** Release v0.9.6 (2026-10-08) is a 64-bit Windows 10+ bundle; a first build takes about 3 GB of disk space and five to twenty minutes. Source use needs Python 3.11+ with PySide6 and the PSXRecomp MinGW-w64 Clang toolchain; the notes say MSVC is unsupported, and 59 runtime patches are kept in tuning/patches. - **Limits:** The README calls the game completable from start to finish but a work-in-progress preview with minor sound and graphical issues. Streamed level-code overlays are compiled natively when possible and otherwise fall back to a MIPS interpreter; the opt-in 60 FPS mode runs the emulated CPU at 200% and is not verified across the whole game. - **Testing evidence:** Published checks are launcher settings and UI smoke tests, scenario scripts and a harness comparing its own Direct3D 12 and OpenGL renderers. - **License:** There is no top-level license file. The README lists PolyForm Noncommercial 1.0.0 for PSXRecomp, MIT for OpenBIOS, zlib for SDL3 and LGPLv3 for Qt/PySide6; the game and its trademarks belong to their owners. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Petari: a matching Super Mario Galaxy decompilation > Reconstructs Super Mario Galaxy’s Wii code as C++ that rebuilds, object by object, against main.dol files extracted from the user’s own Japanese, North American, PAL or Korean disc. Matched objects are linked from source and checked with objdiff and a target hash. The project describes itself as a work in progress, separate from any PC port, and says it does not accept AI-generated decompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Extract your own copy of the game for the chosen region with Dolphin into orig/RMG01; only sys/main.dol is needed. The repository says it contains no game assets or assembly. Each version’s config records the expected DOL SHA-1 in config.yml and build.sha1. - **Prerequisites:** Builds need Python and Ninja on Windows, macOS or Linux; wibo runs the Windows tools on macOS and Linux. configure.py pins Metrowerks compiler packages from the GC 2.7–3.0a5.2 and Wii 1.0 families. The GitHub Actions workflow builds all four versions in a build container its comments call private. - **Scope:** configure.py targets RMGJ01, RMGE01, RMGP01 and RMGK01, defaulting to the Korean RMGK01 build. Only objects marked Matching are linked unless --non-matching is used. For the reviewed commit, decomp.dev reported 100.00% of RMGK01 code decompiled with 68.75% fully linked, and 99.70% decompiled for the other three versions, with 55.61–58.17% linked. These figures are project-tracker results. - **Testing evidence:** CONTRIBUTING.md requires 1:1 matching for objects marked as decompiled, objdiff checks and a successful link. Every non-matching function in a pull request must link a decomp.me scratch, and decompiler output must not be copied directly. The README credits doldecomp bte, zeldaret tp (JSystem) and ogws as sources of code and headers. - **Attribution:** The README states that AI or LLMs played no role in the decompilation and limits permitted AI use to cleanup, formatting, documentation and naming. That is a project statement. The repository declares CC0-1.0, while Nintendo content, extracted files and toolchains keep separate rights. The separate AstroCore PC port mentioned in the README has no public source here. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Wind Waker HD Recomp: a native port by static recompilation of the Wii U game > Statically recompiles The Wind Waker HD’s Wii U PowerPC code to C ahead of time, reimplements the Cafe OS libraries the game uses and implements GX2 graphics on Metal or Vulkan, producing native macOS, Linux, Windows and Android builds without a Cemu runtime. All game code and data are generated locally from the user’s own dump; an experimental macOS-only build can instead run functions from the separate ZeldaWWHDDecomp/wwhd decompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs the user’s own, legally obtained game: a .wud/.wux disc image with its disc key and the Wii U common key, a Cemu .wua archive, or an extracted game folder. Setup checks code/cking.rpx against the SHA-256 of each supported version. The repository and releases contain no game code, assets or keys, and the locally generated code and caches must not be redistributed. - **Prerequisites:** Releases target Apple Silicon macOS 14+, Windows 10 1903+ or 11 on x86-64 or arm64, and glibc 2.35+ Linux on x86-64 or arm64, with Vulkan 1.3 (or 1.1/1.2 with VK_KHR_dynamic_rendering) where Vulkan is used; Android arm64 builds the game on the phone. First setup translates and compiles the code locally with a downloaded compiler (llvm-mingw on Windows, zig on Linux) or Apple’s command-line tools. Source builds need CMake 3.20+ and Python 3. - **Scope:** README describes a static recompilation of the USA or European Wii U release (version 0, without the update) and reports the game playable from start to finish on macOS, Windows, Linux and Android. Known gaps include unimplemented geometry shaders and rectangle primitives and no controller rumble on macOS; true 60 fps is experimental. Unlike source decompilations such as zeldaret/tww, the default build runs machine-translated game code. - **Testing evidence:** Reported checks are side-by-side rendering comparison with Cemu, players completing the game and, for the decompiled path, tools/verify’s function-by-function comparison of hand-written C++ with the recompiled original on generated and recorded inputs. The experimental decomp build (macOS, USA game only) runs 22,705 verified functions in 862 units at the pinned submodule. All results are project-reported. - **License:** Project code is MPL-2.0; vendored Cemu code is MPL-2.0, while metal-cpp, {fmt}, Dear ImGui, zstd and the AppImage runtime components keep their own licenses, and the game remains Nintendo’s property. README calls it an unofficial fan project. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Castlevania 64: Recompiled — a beta static-recompilation port > Uses N64Recomp to statically recompile the US 1.0 Nintendo 64 release of Castlevania into a native PC port rendered with RT64. Game-specific C patches build against headers from a separate Castlevania 64 decompilation. A beta release tagged at the reviewed commit reports a working build with known issues, while the README there still describes an unfinished project. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The metadata says the original game is required. The launcher accepts a single entry, the US 1.0 release (game ID cv64.us.1.0) identified by a fixed ROM hash, and cv64.toml configures the NTSC 1.0 recompilation from a decompressed ELF plus an overlay list. CI copies that ELF and a decompressed ROM from a private repository through secrets; neither is in the public tree. - **Prerequisites:** The CMake project needs CMake 3.20+, C++20 and the N64Recomp and RSPRecomp tools; the workflow pins an N64Recomp commit and builds Linux x64 and ARM64 AppImages, an x64 Flatpak, Windows and macOS targets. Patches compile as MIPS code with clang and ld.lld against headers from the k64ret/cv64 decompilation submodule, with symbol dumps from CV64Syms and submodules for N64ModernRuntime, RecompFrontend and RT64. Several sources and functions still carry Banjo names. - **Scope:** The AppStream metadata describes Castlevania 64: Recompiled as an N64: Recompiled static recompilation into a native port using RT64 for rendering. The v0.5.0 beta release, tagged at the reviewed commit, calls itself a working build and lists known issues: Banjo Recomp assets still to be replaced, texture scrolls that do not animate above 30 FPS, and glitches in some looping animations. At the same commit the README still says the WIP recomp does not build, and BUILDING.md only says WIP. - **Testing evidence:** GitHub check runs recorded for the reviewed commit report successful builds on those platforms. No matching, test or performance results are documented. - **License:** COPYING is GPLv3 and the metadata declares GPL-3.0+; the original ROM and the dependencies keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### RSDKv5 Decompilation: reconstructing Retro Engine v5 and v5U > Reconstructs the Retro Engine (RSDK) v5 and v5 Ultimate runtime, the engine that runs Sonic Mania’s game code, and builds it for Windows, Linux, Switch and Android. RSDKv5U can also run RSDKv3 and RSDKv4 games such as Sonic CD and Sonic 1 & 2. The project adds a mod loader, a shader compiler and extra Windows backends, and ships no game data. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Neither game data nor game logic ships here. The engine loads data files from an official RSDKv5(U) game such as Sonic Mania (Plus), and game code comes from a separate project linked as Game, such as the Sonic Mania decompilation, which also bundles this engine. The FAQ covers Sonic Origins data files, which lack the games’ music and sound effects, and notes that release builds block the Origins Plus characters. - **Prerequisites:** Clone recursively, because GitHub’s source ZIPs omit the required submodules. CMake builds use Visual Studio with vcpkg on Windows, GLEW, GLFW and libtheora development packages on Linux, devkitPro packages for Switch, and a separate Android guide; community forks for WebAssembly, New 3DS, Wii U, Wii and Vita are listed as possibly WIP or outdated. The default Windows DirectX backends support only XInput controllers, and GL builds need a user-made shader mod for videos and filters. - **Scope:** The repository describes itself as a complete decompilation of Retro Engine v5 and v5Ultimate; its license says it also contains original code and that most code is meant to be functionally the same as the specified RSDK version. RETRO_REVISION defaults to 3 (RSDKv5U). The reviewed commit is 13 commits after release v1.1.1 (2025-11-01). - **Testing evidence:** CI builds Windows x86 and x64, Linux and Android binaries. The project publishes no comparison with the original engine binaries, and the FAQ says bugs present in official releases will mostly not be fixed. - **License:** The custom RSDKv5(U) Decompilation Source Code License v2.1 requires any distributed prebuilt executable to have DLC disabled by default, forbids commercial use and distributing game assets other than unique modded ones, requires crediting Evening Star and the decompilation authors Rubberduckycooly and chuliRMG, and binds forks to the same terms. The README says Evening Star owns the Retro Engine. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### C2C: hybrid recompilation and hand decompilation of Crash Bandicoot 2 > An early reverse-engineering effort on PlayStation Crash Bandicoot 2 that converts the engine’s MIPS machine code directly into a very large C file and runs it against a modified PCSX-R emulator library for hardware I/O. Translated functions are meant to be decompiled by hand and moved into ordinary C, gradually replacing the mechanical translation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Running needs the user’s own PAL Crash Bandicoot 2 disc as a raw BIN image with full sector headers and that disc’s SCES_009.67 executable, plus third-party PlayStation emulator GPU, SPU and two gamepad plugins and a 128 KB memory-card file; the repository ships no game data. - **Prerequisites:** Windows only: the main program builds under Cygwin with GNU Make, GCC and SDL2, the emulator library needs Microsoft Visual C++ 2005 or later, and the optional C# disassembler needs Visual C# 2005 or later. Development ran on the develop branch from January to April 2015, and there are no releases. As checked on 2026-10-20, GitHub’s last recorded push was 2020-09-30, the repository is not archived and the README does not mark it as maintained, superseded or archived. - **Limits:** The README warns that the software is not intended for regular use and reports no playability status. Its translator does little decompiling and does not resolve indirect branches or jump tables, so code regions must be listed by hand; docs/FUNCTIONS.md names 18 of 818 listed function entry points. - **License:** No matching or equivalence check is published. The repository has no license file; the PCSX-R-derived emulator sources carry GPL-2.0-or-later headers, and the original game retains its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. #### MediEvil decompilation: an early checksum-gated PlayStation project > Decompiles the US PlayStation release of MediEvil toward C source that rebuilds its main executable, game executable and 26 overlays. splat splits the user's own disc files, and the default build compares all 28 outputs with SHA-1 checksums. README describes the project as a work in progress and publishes no progress figure. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires files from the user's own US MediEvil disc in disk/; the splat configuration expects SCUS_942.27 with a fixed SHA-1, and make extract splits the executables and overlays from those files. The repository supplies no game files. - **Prerequisites:** The build expects a Linux-style host: GNU make, mipsel-linux-gnu binutils, Python 3 with the listed packages such as spimdisasm and rabbitizer, and the splat, m2c, maspsx and asm-differ submodules. C files go through a bundled PlayStation GCC 2.8.1 cc1 binary and maspsx. README points contributors to wiki pages for setup, the rebase workflow and the decompilation process. - **Scope:** README describes a work-in-progress decompilation of the US PlayStation MediEvil 1, with MediEvil 2 left for later. The Makefile targets SCUS_942.27, MEDIEVIL.EXE and 26 overlay binaries. In the reviewed tree most functions are still included as split assembly through INCLUDE_ASM rather than written in C, README's progress section is a placeholder, and the pinned commit dates from 2026-02-23. - **Testing evidence:** make all builds every binary and runs sha1sum against config/medievil.check.sha; CI runs extraction and that check using disc files from an access-restricted repository. A passing check shows that the assembled outputs match those checksums. - **License:** The repository declares MIT; original game content, the bundled compiler binaries and the PSY-Q headers and data in the tree retain their own terms. The project is separate from the MediEvil Recomp static recompilation. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Conker's Bad Fur Day: Recompiled — an N64Recomp native port > Statically recompiles the US Nintendo 64 release of Conker’s Bad Fur Day with N64Recomp into a native Windows, Linux and macOS port on N64ModernRuntime and RT64. Function names and boundaries come from a vendored, still mostly assembly decompilation, while the recompiled code is taken from the user’s ROM so unmatched decompiled C cannot change behavior. The author reports heavy use of Claude Code across the project. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s US ROM in big-endian .z64 form with the SHA-1 listed in the README; the repository and release packages contain no game data. ROM hacks that change only assets are accepted, while hacks that change code and other regions’ ROMs are refused. - **Prerequisites:** Release V0.1.6 (2026-10-13) packages Windows, Linux and macOS builds plus a mods archive. Rendering uses Direct3D 12 or Vulkan on Windows, Vulkan on Linux and Metal on macOS; Linux builds are tested on Ubuntu 24.04, and the unsigned macOS release targets Apple Silicon with macOS 15 or later. - **Prerequisites:** Source builds need a recursive clone, Git and Python 3 plus Visual Studio 2022+ on Windows, CMake, Ninja, Clang and SDL2 on Linux, or full Xcode and Homebrew on macOS, in a path without an apostrophe. N64Recomp and RSPRecomp run from a committed symbol file; regenerating it with the optional decompilation build also needs IDO and MIPS binutils. - **Testing evidence:** The README reports the game played through to the end, with a widescreen pause-background issue; a macOS play-through is not yet confirmed and Intel Macs are untried. Decompiled C must rebuild the ROM’s code byte for byte, and the port is checked by play and by comparison with the original in an emulator; names are marked as guesses. - **Attribution:** The author reports heavy Claude Code use for the recompilation setup, tool patches, host application, mods and decompiled functions. Own code is MIT, but builds including GPLv3 N64ModernRuntime are distributed under GPLv3, an RT64 patch is GPL-2.0-or-later, and the game is not covered. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### ProjectCane: a native PC port of Sly Cooper and the Thievius Raccoonus > Rebuilds the NTSC PlayStation 2 release of Sly Cooper and the Thievius Raccoonus as a native C++ game for Windows and Linux, running on data extracted from the player's own disc image. The README reports the full game as playable while work continues on accuracy and remaining differences from the original. It does not describe its reverse-engineering method or relate the port to the separate sly1 decompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** No original game data is included. Players supply their own NTSC disc image, which the bundled extractor identifies by the serial SCUS-97198, and the extracted Worlds and Cutscenes directories must sit beside the executable. The Beta 0.4.1 notes say game data must be extracted again after that update. - **Prerequisites:** Windows builds use Visual Studio 2022 with the C++ desktop workload, plus the .NET 9 SDK for the Avalonia-based extractor, or CMake presets. Linux builds need CMake 3.22+, Ninja, a C++20 compiler, pkg-config and FFmpeg development libraries; CMake fetches GLFW 3.4 and SDL2, and graphics use OpenGL through glad with Dear ImGui. Portable AppImages are built in Docker against an Ubuntu 22.04 / glibc 2.35 baseline. - **Scope:** README describes a complete, playable native port of the NTSC release for Windows and Linux, including Steam Deck, that began as a map viewer; the Beta 0.4.1 release is tagged one commit before the reviewed revision. Work is said to continue on accuracy, performance, controller support, platform compatibility and remaining differences from the PS2 release. The repository description says the port was rebuilt through reverse engineering, but the README gives no method, symbol source or comparison with the original. - **Testing evidence:** No automated tests, matching checks or side-by-side comparisons are documented, so playability and fidelity remain project claims. - **License:** No license file is present, so reuse terms for the source are unstated; Sly Cooper names and assets belong to their owners, and the README disclaims affiliation with Sony Interactive Entertainment and Sucker Punch Productions. The README also asks for Sly 2 or Sly 3 debug builds with symbols to support future ports. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Firefighter: a decompiled DOS game ported to Rust > Eric S. Raymond’s terminal port of Firefighter, Eben Sprinsock’s 1985 DOS shareware game. The project history says ChatGPT 5.5 decompiled the DOS binary to Borland Pascal and translated it to Rust, after which Raymond modernized the interface and corrected a scoring mismatch. Unchanged gameplay is the author’s statement; the intermediate Pascal and any comparison runs are not published. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Build with Cargo (crossterm and rand); the Makefile wraps cargo build, installs the binary and renders the manual page with Asciidoctor. Building or playing the port needs no original DOS binary or game data; the history page links an Internet Archive copy of the shareware original. - **Scope:** The reviewed 1.2.0 release (2026-06-08) is a Rust terminal game for Unix-like systems: a 25×25 forest-fire board with easy, medium and hard modes, an optional RNG seed and mouse cursor movement. It needs a UTF-8 ANSI terminal of at least 80×25 with alternate-screen and raw-mode input; mouse movement also needs mouse reporting. - **Attribution:** The history lists the recovery steps: decompiling the DOS binary to Borland Pascal with ChatGPT 5.5, translating that to Rust, then adding interface changes, a seed option and a fix for per-difficulty maximum scores that did not match the score computation. The decompiled Pascal, prompts and original binary are not in the repository. - **Testing evidence:** Verification is limited to make check (cargo check and clippy) and a few unit tests for option parsing, the display test pattern and maximum-score consistency. No comparison with the original program is published; unchanged gameplay logic is the author’s claim. - **License:** COPYING is BSD-2-Clause, and source headers name Raymond and Sprinsock as joint copyright holders; the README says the port is released with the original author’s permission. The shareware original keeps its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Kingdom Hearts 358/2 Days: native PC port built on a matching decompilation > Compiles the C of the khdays-decomp matching decompilation for Windows x64 and supplies a native platform layer for the Nintendo DS hardware, SDK services and sound driver. README reports the whole game running without an ARM interpreter; its rendering, controls, mod support and network multiplayer are the port’s own additions. This is a decompilation-based port, distinct from the byte-matching DS reconstruction it builds on. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own European Kingdom Hearts 358/2 Days ROM (game code YKGP); the tools check it against a single supported-ROM entry before preparing local game data. Optional HD screens, videos and menus are generated from the player’s own KINGDOM HEARTS HD 1.5+2.5 ReMIX and HD 2.8 Final Chapter Prologue copies. The repository includes no ROM, assets, SDK files or game binaries. - **Prerequisites:** Building needs Windows, Visual Studio 2026 with the C++ workload, CMake, Ninja, Python 3.11+ and pycparser; running needs a Direct3D 12 or Vulkan GPU. Build preparation rewrites game pointers as DS-address references and repairs ARM calling-convention gaps from a ROM-derived Ghidra ABI table; cases it cannot repair mechanically stop at named KHDAYS_ABI_GAP points. - **Scope:** Reviewed version 0.1.2 is labelled work in progress. README reports the title, Story Mode, Mission Mode, combat, the shop and save round-trips running natively; builds exist only for Windows x64, with Linux, macOS, Windows on ARM and Switch listed as planned. The pinned khdays-decomp submodule (a2b0478) reports all 306 EU YKGP modules byte-identical; the port compiles that C after build-time rewriting and does not reproduce the DS binary. - **Testing evidence:** Reported checks are ctest suites (MSVC static analysis, short libFuzzer runs, GPU renders compared with the port’s software DS engines, a DeSmuME savestate comparison) and scripted regression walks through Mission Mode, Story Mode, saving and multiplayer. Tests needing player data are skipped without it, and CI builds only the format library on Windows and Linux. Internet play is reported tried through the maintainer’s server, local-network play between two PCs not yet. - **License:** The port declares MIT; its third-party notices record the decompilation as CC0 1.0 and list SDL3 (zlib), Lua, Dear ImGui and other components under their own terms. No repository license applies to the original game or material extracted from it. README states that AI-assisted coding tools were used. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### ico-pc: a native ICO port compiled from the PS2 decompilation > Compiles the decompiled C of the PlayStation 2 game ICO natively for Windows, Linux, Android, iPhone and Apple-silicon Macs, with host code standing in for the PS2 hardware and Sony libraries. No PS2 code is interpreted or recompiled, and the program reads the player's PAL disc image on first start. It is a native port of a separately byte-matched decompilation, with documented divergences and optional enhancements. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the player's own PAL ICO disc image (SCES-50760) as .iso, .chd or .bin/.cue; other regions and editions are unsupported. Building needs no disc image, but the first run copies the game's files, about 1 GB, into the ico.o2r archive and loads the data tables from it. The legal notes exclude disc data, boot ELFs, assets and data tables from the repository and downloads. - **Prerequisites:** Builds use CMake presets with Ninja. The Linux quickstart targets Debian 13 or Ubuntu 24.04 with gcc 14 (gcc 13 also builds), Python 3 and a fetch script that downloads about 1.6 GB of pinned toolchains and dependencies, among them llvm-mingw, mingw-w64 gcc, SDL3, Vulkan components and DXC. Rendering uses Vulkan, Direct3D 12 on Windows, or MoltenVK on Apple platforms. - **Scope:** README describes a port of the PAL PS2 release (SCES-50760). The architecture guide says the game's decompiled C under ico2/ is compiled for the host, while port/ replaces the EE kernel, GS/VU1 rendering, SPU2 audio, disc, pad and memory-card services. Its platform table, current at release v0.7.10, lists 64-bit Windows 10/11, x86-64 and arm64 Linux, Steam Deck, Android 10+, iPhone through LiveContainer and Apple-silicon macOS 12+; the maintainer reports not testing the iPhone and Mac builds. - **Testing evidence:** CI runs hygiene and audit checks, builds and runs ctest on x86-64 and arm64 Linux, cross-builds Windows and packages Android, iPhone and macOS; disc-dependent tests skip without the player's image. The divergence list documents known differences from the PS2 and states that no test compares a run with the PS2. The upstream decompilation separately reports byte-identical PAL and Japanese boot ELFs, with most read-only data still taken from the disc. - **License:** README and LICENSE apply MIT only to the project's own code, scripts and documentation, granting no rights in the game, its data or Sony and Team Ico trademarks; third-party code is listed separately. The LICENSE notice says building requires a disc image, unlike the build guide. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Sly Cooper and the Thievius Raccoonus: matching PlayStation 2 decompilation > Reconstructs source code for SCUS_971.98, the NTSC-U PlayStation 2 executable of Sly Cooper and the Thievius Raccoonus, as a work-in-progress matching decompilation. Functions not yet matched are still assembled from code split out of the user's own executable, and the build checks the linked ELF's SHA-1. The result runs in PCSX2 with the original disc for assets; it is not a native PC port. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The repository contains no game assets or original code. Users supply SCUS_971.98 from their own legally obtained disc, or an NTSC-U ISO for the quickstart script. Running the build requires PCSX2 2.0, the user's game ISO for assets and a BIOS from the user's own PS2. - **Prerequisites:** Builds run on Debian-based Linux or WSL, with a Distrobox guide for other distributions. They need Python 3.9+ with the listed packages, MIPS binutils, Ninja, and Wine or wibo to run the downloaded ee-gcc 2.95.2 SN (ProDG) compiler archive. configure.py splits the ELF with splat, inserts split assembly in place of non-matching functions and links the executable; objdiff, decomp.me and CodeMatcher support matching, the last currently against the May 19, 2002 prototype. - **Scope:** README describes a work-in-progress decompilation of the NTSC-U executable SCUS_971.98 (SHA-1 prefix 57dc305d) that aims to decompile the game engine to matching source. Its FAQ says the project has built a matching ELF since July 2024 and still aims to match 100% of functions. Engine, Splice scripting-engine and data progress are reported on decomp.dev. - **Testing evidence:** By default the build checks out/SCUS_971.98 against config/checksum.sha1; --skip-checksum is documented for intentional code changes, whose output may not boot. CI downloads the original ELF through a repository secret and runs this check on main, and the check run recorded for the reviewed commit succeeded. This verifies byte identity of one executable. - **License:** The repository is dedicated under CC0 1.0; the original game, extracted assembly and data, and the ProDG compiler and SCE runtime library keep separate rights. CONTRIBUTING takes mangled function names from the May 2002 prototype's debug symbols. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Pokémon Emerald: a matching Game Boy Advance decompilation > Reconstructs Pokémon Emerald for the Game Boy Advance as buildable C source, with game scripts and data kept as assembler directives. The default agbcc build produces pokeemerald.gba, and make compare checks it against the SHA-1 of the original English ROM; an optional modern-GCC build is not hash-checked. Graphics and audio sources are committed in the tree, so the documented build reads no base ROM. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented build reads no original ROM: graphics, audio samples and map data are committed as PNG, WAV/AIF and JSON files and converted by bundled tools. rom.sha1 records the target English release as SHA-1 f3ae088181bf583e55daf962a92bb46f4f1d07b7, and README links that ROM’s No-Intro record. - **Prerequisites:** INSTALL.md covers Windows (WSL1 recommended; msys2 or Cygwin), macOS and Linux. On Debian/Ubuntu it lists build-essential, binutils-arm-none-eabi, git and libpng-dev; the matching build also needs pret/agbcc built and installed into the tree. make modern instead uses devkitARM’s arm-none-eabi-gcc and writes pokeemerald_modern.gba. - **Scope:** README describes a decompilation of Pokémon Emerald that builds a single ROM, pokeemerald.gba; the Makefile sets game code BPEE, revision 0, and CI builds the English version. Most game code is C, while startup code, part of the m4a sound library and the GameCube multiboot library remain assembly files, and three multiboot programs (berry fix, Colosseum, e-Reader) are included as prebuilt .gba binaries. The output is a GBA ROM, not a native PC port. - **Testing evidence:** make compare runs a SHA-1 check of the built ROM against rom.sha1 and reports pokeemerald.gba: OK on a match; the Makefile notes that comparison only makes sense for non-modern builds. CI builds with COMPARE=1 and also builds the modern target. These checks establish byte identity for this one release. - **License:** The repository has no top-level license file and GitHub detects none; license files cover only some bundled tools, and agbcc’s GCC sources carry GPL v2. The original game’s code, graphics and audio remain subject to their rights holders. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Paper Mario: matching Nintendo 64 decompilation for four releases > Reconstructs Paper Mario’s Nintendo 64 code as C source that rebuilds the US, Japanese, PAL and iQue ROMs. The build takes assets and comparison inputs from a user-supplied original ROM, then checks each output against a recorded SHA-1. Mutable project reports list no remaining nonmatching functions, while the README still calls the decompilation work in progress; it is distinct from the PaperBoat native port. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** At least one independently obtained original ROM matching a listed SHA-1 is required, supplied as that version’s baserom.z64; the Nix route expects all four. configure splits assets from those ROMs, and neither ROMs nor extracted assets are distributed with the source. - **Prerequisites:** SETUP.md supports Linux, macOS, WSL 2 and Nix. The build uses a Python configure script with ninja, pigment64 from cargo, host MIPS binutils/GCC/cpp, and downloaded compiler builds: project GCC/binutils, GCC 2.7.2, EGCS and statically recompiled IDO 5.3. configure refuses a matching iQue build on macOS because EGCS is unavailable there. - **Scope:** README calls this a work-in-progress decompilation that builds US, JP, PAL and iQue ROMs, each with a listed SHA-1. For the reviewed commit, papermar.io’s mutable progress CSVs list zero nonmatching functions for all four versions (12,679 for US), and its US page announces 100% for US, PAL and iQue. The output is an N64 ROM, not a native PC executable; HarbourMasters’ PaperBoat port is a separate project. - **Testing evidence:** A matching build ends with sha1sum checks against each version’s checksum.sha1, reporting “papermario.z64: OK”. --non-matching, --modern-gcc and --shift builds skip that check, so they are not matching results. Jenkins builds all four versions plus a shiftable US build and publishes the progress reports. - **License:** The reviewed tree has no top-level license file and GitHub detects none, so no reuse grant is established for the source. Original ROMs and extracted assets retain separate rights, and downloaded compilers carry their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. #### Budokai Tenkaichi 3: a native PC port built on a matching decompilation > Compiles the decompiled code of Dragon Ball Z: Budokai Tenkaichi 3 (PS2, USA release SLUS-21678) for PC on a new renderer, sound, input and platform layer rather than an emulator. The game code comes from the separate BT3-Decompiled matching decompilation, and the game's data is read from the user's own disc image. The README reports the full game loop and experimental online play and says AI helped make the project; these results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own disc image of the unmodified USA release (SLUS-21678) as an .iso. The setup and install.py read the game's data from it and check SHA-1 digests of the extracted main program (SLUS_216.78) and menu program (BIN/DBZP.BIN); a patched or damaged image is rejected. The repository carries the built-in data tables as shapes without values (port/data), which the program fills from the disc at start; no game data is distributed. - **Prerequisites:** Releases target 64-bit x86 Linux (glibc 2.35 or newer) and Windows 10/11 with Vulkan, falling back to OpenGL; Apple Silicon macOS is experimental and source-only. On Linux, install.py checks gcc/g++, clang with its Python bindings for the 64-bit pointer rewriting, glslc and SDL3, then reads the disc, builds the program and runs the game's demo fight headless as a self-test. Linux and Windows release archives are built in a Docker container (clang/LLVM, SDL3, mingw-w64) without any disc input. - **Scope:** README describes a native PC port of the PS2 USA release, not an emulator: the game's code from BT3-Decompiled sits in src/ and include/ with PC changes behind #ifdef PORT, on a new platform layer with Vulkan and OpenGL 3.3 renderers, sound and input. It reports the whole game loop working (boot, movies, menus, saves, fights, split screen), plus experimental online play with rollback through a Cloudflare Worker matchmaking service whose source is included; the 32-bit Linux build has no rollback. The port log in docs/port records what is and is not verified. - **Testing evidence:** The BT3-Decompiled README reports 99.92% of the main program's game code and 99.97% of the menu program in matching C, with both rebuilt binaries byte-identical; Sony SDK and CRI libraries are out of scope. The port log reports a replay recorded in PCSX2 matching console health values at sampled ticks and the final clock, while an early entry still noted differing fighter state words; macOS is reported to match the Linux state on every demo frame. These remain project-reported. - **License:** The port's own code is AGPL-3.0-only after commit 06e4671 and MIT up to and including it; bundled libraries keep their own terms. README states that the game code in src/ and include/ belongs to the game's rights holders, and BT3-Decompiled's CC0 1.0 dedication covers only its own reconstruction work. README says the project was made with AI help, and the docs carry working rules for parallel decompilation agents. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### D2R Mobile: rehosting Diablo II: Resurrected’s Switch program on Apple devices > Runs the Nintendo Switch release’s own aarch64 program natively on iPhone, iPad and Apple silicon Macs, rewriting only instructions that depend on the Horizon kernel and supplying its system services and the NVN graphics API on Metal. Shaders are translated offline from the user’s files, and the project adds its own touch interface and endgame features. It is a rehosting compatibility layer, not a decompilation or recompiled source. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Switch program files (ExeFS main, sdk and subsdk0) and RomFS update data for that version; the rewritten program, translated shaders and on-device resource folder are generated locally from them. The repository holds no game code, art, text or shaders, but records shader interface tables, graphics-API names and about 800 main-program addresses, itemized in docs/DERIVED.md. - **Prerequisites:** The main route is a full build on an Apple silicon Mac with Xcode, the Python environment that setup.sh prepares and an Apple signing account; a no-Xcode route packages a prebuilt shell on Windows, with Linux packaging and sideloading-tool signing reported unverified. Shader translation bundles Ryujinx’s translator, and SPIRV-Cross emits Metal source. - **Scope:** Targets only the Switch release with the Reign of the Warlock expansion at 1.0.34.0 (PC 3.3.94012); the rewrite rules stop on other versions. README reports iPhone/iPad builds for A14/M1 or later (iOS 26, or iOS 18–25 via an older-API build) and native Apple silicon Mac builds; A16-and-earlier devices need an extra texture pack, Apple TV is a community developer preview, and Intel Macs, A13-and-earlier chips and online play are unsupported. - **Testing evidence:** dm/verify documents structural checks and Unicorn-based equivalence tests for every rewrite site, which need only the user’s files, plus unit tests. Save, tick-state and screenshot gates compare against ground-truth recordings from a patched Ryujinx; those recordings and driver scripts are not shipped, so these gates cannot be rerun from the repository. README reports a 44-device closed beta and dated iPhone 17 Pro Max measurements. - **License:** The project declares MIT; bundled third-party code keeps its own license (the Ryujinx translator MIT, deko3d-derived code zlib, FLIP BSD 3-Clause). Seven offline-play rewrites come from a community patch whose authorship and license are unknown. Blizzard and Nintendo retain their rights in the game. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Ratchet & Clank: a matching PS2 decompilation with a documented agent workflow > Reconstructs C source for SCES_509.16, the PAL v2.00 PlayStation 2 executable of Ratchet & Clank (2002), with every function linked at its retail address. Functions not yet decompiled are still built from disassembly generated from the user's own executable, and the build audits functions, layout and the whole image against retail. The project documents an LLM-agent matching workflow and written build-fidelity rules for what counts as a match. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** No game assets, retail executables or disassembly are included. Users supply SCES_509.16 from their own disc image, checked against the SHA-1 in README and LEGAL.md, and tools/setup_asm.sh generates the disassembly locally. LEGAL.md says the repository will not build a runnable game for anyone who does not own and dump a copy. Credited sibling projects, such as the Lombyte NTSC decompilation and the ReRAC PC port, are references. - **Prerequisites:** Linux and macOS builds run in a prebuilt Wine container under Docker or Podman; Windows builds use Git Bash and Python 3.10+ natively, with a short repository path. Both clone community mirrors of SN Systems ProDG for PS2 3.01 and the SCE PS2 SDK 2.4. Game code compiles with ProDG GCC 2.95.3 and Sony SDK objects with EE-GCC 2.9-ee-991111; GNU as is used together with listed tools that model the original ps2eeas assembler and linker behaviour. - **Scope:** README describes a work-in-progress matching decompilation of SCES_509.16 (PAL v2.00) within the OpenRAC initiative; matched code is then refactored toward readable C++, with matching builds as regression tests. BUILD_FIDELITY.md records 3,591 matched functions as of 2026-10-07, and live progress is published on openrac.dev and bytematch.dev. The repository description names native PC reimplementation as a later goal; no port is part of this repository. - **Testing evidence:** tools/build_sn.sh rebuilds from scratch, audits each decompiled function's bytes and address against retail, and compares every loaded section, allowing differences only inside known near-miss C functions; level code is checked per function. The image therefore matches retail outside in-progress functions rather than as a whole. CI enforces the build-fidelity list. - **Attribution:** AGENT_WORKFLOW.md describes a lead model directing tiers of worker models whose candidates a strict match tool accepts or rejects; a Claude Code worker definition is committed, and a Ghidra MCP container serves decompilation to agents. Project code is GPLv3; reconstructed libraries and third-party components keep their own licenses, and the game and toolchains keep separate rights. CONTRIBUTING bans Sony SDK source and leaked material, and LEGAL.md reports that movie code derived from an SDK sample was reverted to assembly on 2026-09-30. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Banjo: Recompiled — an N64Recomp Banjo-Kazooie native port > Uses N64Recomp to statically recompile the US 1.0 Nintendo 64 release of Banjo-Kazooie into a native port on N64ModernRuntime, rendered by RT64 and extended with mod support. Like Zelda 64: Recompiled, it is not built from decompiled source; a symbols repository generated from the Banjo-Kazooie decompilation supplies function names for locating code in the ROM and writing patches. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Plays only the user’s US 1.0 Nintendo 64 Banjo-Kazooie ROM, loading assets from it at startup; other dump formats of that ROM are converted to .z64. The repository and releases contain no game assets, and it is not an emulator for other ROMs; the game is changed through mods instead. - **Prerequisites:** Release v1.0.2 (2026-07-31) ships Windows, macOS, Linux x64/ARM64 and Flatpak x64 builds. Runtime graphics need Direct3D 12.0 with Shader Model 6, Vulkan 1.2 or Metal Argument Buffers Tier 2; x86-64 CPUs need SSE4.1, and Macs need macOS 13.0+ with Apple Silicon or a 7th-generation Intel CPU. - **Prerequisites:** Source builds need a recursive clone, CMake and Ninja with Clang (Visual Studio 2022 with Clang plus make on Windows), separately built N64Recomp and RSPRecomp, the BanjoRecompSyms submodule and a decompressed copy of the NTSC-U 1.0 ROM matching the SHA-1 in BUILDING.md; play uses the standard ROM. - **Testing evidence:** The README reports faithful audio, intact N64 effects, widescreen, high frame rates, note saving and fixed duplicate Mumbo token IDs, and lists overlay software as a known problem. It publishes no equivalence or gameplay test; pinned-commit CI only builds the port. - **License:** GPLv3 project license; the original game, the decompilation and other dependencies keep separate terms. The team states that it does not use generative AI and bans GenAI-assisted contributions. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Pokémon FireRed and LeafGreen: a matching Game Boy Advance decompilation > Reconstructs the English Game Boy Advance releases of Pokémon FireRed and LeafGreen as buildable C source, with game scripts and data kept as assembler directives. Default agbcc builds produce six ROM images, covering both games' 1.0 and 1.1 releases and two variants labeled switch, each checked against its own SHA-1 manifest. Graphics and audio sources are committed in the tree, so the documented build reads no base ROM. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented build reads no original ROM: graphics, audio samples and map data are committed as PNG, WAV/AIF and JSON files and converted by bundled tools. Six .sha1 manifests name the target images (for example pokefirered.gba, SHA-1 41cb23d8dccc8ebd7c649cd8fbb58eeace6e2fdc), and README links each image’s No-Intro record. The contributor helper compare.sh hex-diffs the output against a baserom.gba only when one is present. - **Prerequisites:** INSTALL.md covers Windows (WSL1 recommended; msys2 or Cygwin), macOS and Linux. On Debian/Ubuntu it lists build-essential, binutils-arm-none-eabi, git and libpng-dev; the matching builds also need pret/agbcc built and installed into the tree. make modern and the matching *_modern targets use devkitARM’s arm-none-eabi-gcc, and a TOOLCHAIN variable selects another ARM toolchain. - **Scope:** README describes a decompilation of English FireRed and LeafGreen that builds six ROM images: each game’s original and rev1 releases plus variants named _switch, which config.mk builds as revision 10. INSTALL.md documents make, make leafgreen and the rev1 targets; the Makefile adds the _switch targets. Most code is C, while startup code, part of the m4a sound library and the GameCube multiboot library remain assembly, and three multiboot programs are included as prebuilt .gba binaries. The outputs are GBA ROMs, not a native PC port. - **Testing evidence:** make compare and the compare_* targets check each built image against its .sha1 manifest; config.mk notes that comparison only makes sense for non-modern builds. CI compares all six images and also builds the modern target. docs/bugs_and_glitches.md lists original-game bugs that the optional BUGFIX and UBFIX defines change, so those builds intentionally diverge. These checks establish byte identity for the listed images. - **License:** The repository has no top-level license file and GitHub detects none; license files cover only some bundled tools, and agbcc’s GCC sources carry GPL v2. The original games’ code, graphics and audio remain subject to their rights holders. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### PaperBoat: a native Paper Mario port built on the decompilation > Compiles Paper Mario decompilation sources, credited to the pmret and Paper Mario DX projects, into a native US-version application on libultraship. Torch converts the user’s own ROM into a local asset archive, and the port adds rendering backends, enhancements and archive-based mods. Desktop releases are published, while Android, iOS and web builds are documented on the development branch. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s US Paper Mario ROM with the SHA-1 listed in the README; config.yml carries recipes for that hash only, and the README states no copyrighted assets are included. Torch generates the pm64.o2r game archive on the user’s machine or device; that archive never ships with the app. - **Prerequisites:** Source builds need the Torch and libultraship submodules, CMake 3.24+, Ninja and C99/C++20 compilers. Windows uses Visual Studio 2022 with clang-cl, because plain MSVC cl.exe is unsupported for the C99 decompilation sources. Renderers are DirectX 11, OpenGL and Metal. Android arm64-v8a, iOS 16.3+ and Emscripten builds are documented, with scripting and native mods disabled there. - **Scope:** The reviewed develop snapshot follows release 1.0.3 (2026-10-11), whose packages cover Windows, Linux and macOS. CMake compiles the decompilation’s game C sources for VERSION_US with port code replacing the N64 boot and most OS layers. This is a native port that deliberately adds enhancements and fixes, not a matching ROM build or a static recompilation. - **Testing evidence:** The CI workflow builds Linux, Windows, macOS, iOS, Android and web artifacts and checks package contents; the platform guide states CI never touches a ROM, and its named desktop check script is absent from the reviewed tree. Nightly builds are labeled playtest-only with expected bugs and crashes. No gameplay-equivalence or performance results are reported. - **License:** The repository carries CC0-1.0 text, but GitHub detects no license for the credited pmret and Paper Mario DX repositories, and submodules have separate terms; the CC0 file is not treated as a grant over inherited code or game content. The README says AI-assisted pull requests are accepted under a HarbourMasters policy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Halo 2: an agent-assisted matching decompilation of an LTCG Xbox build > A work-in-progress matching decompilation of Halo 2 for the original Xbox: contributors write C and C++ that the period compiler, building the whole program with link-time code generation, must turn back into the retail executable's bytes function by function. The README reports just under half of the game-function bytes matched and leaves a native port for a later stage. It discloses that much of the maintainer's work runs in Claude and Codex coding-agent lanes. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply the retail default.xbe from a copy you are entitled to use, and the XDK 5849 development toolchain, yourself; neither is provided, and the maintainers will not help obtain the SDK. README says byte-for-byte checking currently depends on that original compiler, which no open-source toolchain can yet reproduce; analysis and documentation need neither. The repository holds no game assets, disc images or leaked material. - **Scope:** README targets the retail disc build's default.xbe (internal name halo2ship.exe, linked 2004-09-28, XDK 5849, Visual C++ 7.1 with /LTCG), identified by SHA-256. At the reviewed commit it reports 9,115 of 11,321 game functions matched (46.90% of game-function bytes; 35.59% of all in-scope bytes). Decompilation and readability work are in progress and a native port is a later stage, so the project produces no playable or ported build. - **Testing evidence:** The tools are Python (requirements-dev.txt, with capstone for the checker). tools/build.py builds the whole game as one LTCG image with each source file's flags; tools/check.py compares every marked function with the retail bytes apart from relocated address fields, writes matched/near/todo status to config/functions.csv and exits nonzero while any function differs. Public CI runs the Python tests, whose retail and SDK tests skip without those local inputs, and exports the decomp.dev report from the committed CSV. - **Attribution:** Match counts come from the project's checker; tools/masked.py lists differences the address masking can hide, such as nearby float constants and strings. PROVENANCE.md reports that earlier names drew on sources its policy forbids (third-party names derived from unreleased 2003 linker maps, and an internal 2007 debug build); those were removed or renamed with match status unchanged, while the derivation of names that follow the Halo CE decompilation is still under review. - **License:** Contributors' own work is CC0 1.0; LEGAL.md states this places no Halo 2 code, content or trademarks in the public domain, and the project is unaffiliated with Microsoft, Bungie or 343 Industries. README says much of the maintainer's decompilation runs in automated lanes driven by Claude and Codex, with each batch reviewed and checked before it lands, and it offers contributors a prompt for AI coding agents. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### DiabloWeb: a WebAssembly browser port built on Devilution > Runs Diablo in web browsers by compiling a stripped-down fork of Devilution, the community reconstruction of the game’s original source, to WebAssembly behind a React front end. The fork removes the Storm, DiabloUI, DirectX and Windows dependencies and reworks event handling for the browser. It is a port built on a reconstruction and reports no matching or behavior-equivalence checks of its own. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The full game needs the user’s own DIABDAT.MPQ from an original copy (the page points to the GOG release); the shareware SPAWN.MPQ runs the free demo. Data files are selected or dropped in the browser, saves are kept in IndexedDB and can be downloaded or uploaded as .sv files, and the app can optionally compress the MPQ locally. Neither repository includes retail game data. - **Prerequisites:** The front end is a webpack/React project built with Node.js. Rebuilding the WebAssembly modules requires Emscripten and the fork’s node build.js; the fork can also build a Windows app in Visual Studio 2017. README says the hosted page serves the shareware SPAWN.MPQ; local runs need it placed in the public folder. - **Scope:** Reviewed diabloweb 1.0.39 at its last commit (May 2022). Prebuilt WebAssembly modules for the retail and shareware builds, and an MPQ compressor, are committed; their C/C++ source is the separate d07RiV/devilution fork. That fork’s README says many parts of the code were modified, correct behavior is not guaranteed and network play was broken; diabloweb carries WebSocket and WebRTC client modules. - **Testing evidence:** Neither README reports tests, matching results or comparisons with the original executable, and the reviewed front-end tree has no test files. Reported playability rests on the hosted deployment. - **License:** diabloweb has no license file. The fork ships Unlicense text, yet its README limits the source to non-commercial use; current upstream Devilution uses the Sustainable Use License 1.0, and Blizzard retains its rights in Diablo and its data. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### pokered: a matching Pokémon Red and Blue disassembly > Reconstructs the Game Boy games Pokémon Red and Blue as RGBDS assembly, with graphics and data kept as editable source files. One tree builds the USA/Europe Red and Blue ROMs, a Blue debug build and patches for the Virtual Console releases, each checked against a recorded SHA-1. It is a full disassembly rather than a decompilation into a higher-level language. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The build reads no original ROM: every input is in the repository, so the outputs are rebuilt from source rather than combined with extracted assets. The repository therefore carries the game's text, graphics and data in source form. - **Prerequisites:** INSTALL.md covers Linux distributions, macOS with Homebrew, Windows through WSL (or Cygwin on older Windows) and Termux. The build needs make, gcc or clang, git and rgbds 1.0.4, which the repository pins; helper tools under tools/ handle graphics conversion, compression and patch generation. - **Scope:** README says the disassembly builds Pokemon Red (UE), Pokemon Blue (UE), the BLUEMONS.GB debug build and two Virtual Console patch files, listing a SHA-1 for each. Code, text, maps and audio are RGBDS assembly, and graphics are PNG files converted during the build; Virtual Console patches come from separate VC builds and patch templates. - **Testing evidence:** make compare builds every target and runs sha1sum against roms.sha1. pret's CI does this on Linux and macOS with rgbds 1.0.4 and fails when the build leaves uncommitted changes, while forks only build. Matching hashes show identical output bytes. - **License:** The repository has no license file, so reuse terms for the disassembly are unstated, and the original game's content remains its rights holders'. rgbds is a separate project with its own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Lighthouse: a Banjo-Kazooie PC port built on the decompilation > A native Windows, Linux and macOS port of Banjo-Kazooie that compiles game C sources, many tagged with their Banjo-Kazooie decompilation file paths, against libultraship, a reimplementation of the N64 SDK. Torch extracts the user’s ROM into an asset archive, and the port adds Anchor multiplayer, romhack and language-pack support and a randomizer. Unlike Banjo: Recompiled, it builds from decompiled source rather than statically recompiling the ROM’s code. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a supported retail ROM in .z64 form, identified by SHA-1 in the README: US 1.0, US 1.1, Japanese or PAL. It is extracted into a local bk.o2r archive; other regions can be added as language packs, and romhacks need the US 1.0 base. The repository includes no copyrighted game assets. - **Prerequisites:** Source builds need the libultraship and Torch submodules and CMake, plus Visual Studio 2022 (MSVC v143), Python 3 and at least 8 GB RAM on Windows, GCC or Clang with Ninja and the listed SDL2, libzip, tinyxml2, spdlog, Boost and Vorbis packages on Linux, or Xcode and the listed packages on macOS. Build targets extract bk.o2r from the ROM and package port assets as lighthouse.o2r. - **Scope:** Release 1.1.0 “Hatteras Alfa” (2026-08-17) ships Windows x64, Linux and macOS archives. Rendering backends are DirectX 11 (Windows default), OpenGL on all platforms and Metal (macOS default). - **Testing evidence:** The README publishes no matching or fidelity checks. Most supported romhacks are not fully tested, and CI nightly builds are for playtesting and may crash. - **License:** The repository is dedicated under CC0 1.0; submodules keep their own licenses, and the game is not covered. The README discloses AI assistance for information gathering and accepts AI-assisted pull requests under the HarbourMasters policy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Lost Odyssey Recomp: statically recompiling an Xbox 360 RPG into native ports > Translates Lost Odyssey’s Xbox 360 PowerPC executable with patched XenonRecomp tooling and runs the generated code on a native runtime that renders through Direct3D 12, Vulkan or Metal. Windows, Linux, macOS and Android packages import the user’s own disc data. The maintainer documents development with Claude Code and Codex CLI and records each release separately from validation and acceptance. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Players import data from one supported four-disc set, Asian multilingual or USA/Europe (Title ID 4D5307FA); Disc 1 is required, DLC is optional, and other regions, title updates and modified XEX files are unsupported. Source builds use the Asian multilingual Disc 1 default.xex, LO.fpi and resource archives, and BUILDING.md still calls four-disc integration incomplete. Game data and generated code are kept out of the repository. - **Prerequisites:** Builds need submodules including XenonRecomp, XenosRecomp, plume and SDL 3, with project patches applied, plus Python 3.11+, CMake 3.28+, Ninja and Clang: clang-cl with Visual Studio 2022 Build Tools on Windows 10 1803+, or Clang/LLD with a Vulkan driver on Linux. tools/ppc_codegen.py regenerates the guest sources locally before the runtime build. - **Scope:** The reviewed main snapshot follows v1.0.4 (2026-10-18), packaged for Windows x64 with AVX, Linux x64 AppImage/Flatpak, macOS 15+ on Apple Silicon and 64-bit Android 8.0+ with Vulkan. STATUS.md and ROADMAP.md record each release as published but not accepted by the maintainer. This is static recompilation of the shipped executable, not recovered authored source or a general Xbox 360 emulator. - **Testing evidence:** STATUS.md separates implementation, validation, acceptance and release; for example, v1.0.4’s save fix passed a logic review, a CPU fixture and a Release link but was not run in-game. Upscaler and rendering checks name bounded fixtures and GPUs. The workflow guide states that a release does not mean the game was completed start to finish. - **License:** GPL-3.0 covers project code; Lost Odyssey and its assets belong to their owners, and dependencies such as the Xenia FFmpeg fork, DXC, optional DLSS/FSR/XeSS SDKs and Android GPU drivers keep their own terms. docs/AI_WORKFLOW.md says one maintainer used Claude Code as the main session with Codex CLI and subagents; Ghidra scripts and a third-party reverse-engineering skill are referenced. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Super Smash Bros. Melee: a matching GameCube decompilation with a shiftable build > A matching decompilation of Super Smash Bros. Melee's US 1.02 release (GALE01) that rebuilds main.dol from C with the original Metrowerks compilers and checks it against the retail SHA-1. decomp.dev reports the code fully decompiled and linked at the reviewed commit, and the README says current work is mostly naming and cleanup. Because the build can be shifted, a separate non-matching mode lets modders add code to a DOL run with their own disc dump. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply main.dol from your own GALE01 disc; the repository's orig/GALE01 folders hold only placeholders. The README's modding path needs the whole disc dumped to a folder, enables configure.py --non-matching with new objects marked Equivalent, and runs the rebuilt DOL in Dolphin. Such modified builds are not byte-identical to retail. - **Prerequisites:** Host tools are Python and ninja on Windows (native tooling recommended), macOS (Game Porting Toolkit runs the Windows compilers) or Linux (WiBo on x86, Wine elsewhere). configure.py sets up decomp-toolkit, sjiswrap and the Metrowerks GC/1.2.5 and GC/1.1p1 compilers with the GC/1.3.2 linker; objdiff diffs objects and tools/decomp.py drafts functions with m2c. CI builds link, test and debug modes in a build container that provides the original files, plus a Nix matching build. - **Scope:** README describes a matching decompilation that builds the US 1.02 main.dol (game ID GALE01) with SHA-1 08e0bf20134dfcb260699671004527b2d6bb1a45, the digest config/GALE01/build.sha1 checks. decomp.dev reports 100.00% decompiled and 100.00% fully linked for this commit, and README says most effort now goes to naming and cleanup. The output is a GameCube DOL, not a PC executable; the CMake library and DWARF packages CI also builds are not documented as a playable port. - **Testing evidence:** Matching rests on the linked DOL's SHA-1 and objdiff's per-unit report; CI's check_complete.py warns when a unit matches fully but is not yet marked complete. The 100% figures are decomp.dev's report for this commit. - **License:** No repository-wide licence file is present at the reviewed commit and GitHub detects none; bundled tools under tools/ carry their own licences, and the game, its DOL and assets keep their rights holders' terms. CONTRIBUTING.md says using AI to match functions is acceptable and frequently practiced, while asking contributors not to let AI name struct fields or global identifiers or attempt data-section matches. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### pokecrystal: a matching Pokémon Crystal disassembly > Reconstructs the Game Boy Color game Pokémon Crystal as RGBDS assembly, with graphics, maps and data stored as editable sources. One tree builds the international 1.0 and 1.1 releases, the Australian release, two debug builds and a Virtual Console patch, each checked against a recorded SHA-1. Companion documentation covers script command formats and known bugs in the original game. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The build reads no original ROM: code, text, maps, audio, PNG graphics and other data are in the repository, including the mobile library code linked into the ROM. The repository therefore carries the game's content in source form. Packaging the Virtual Console patch into an installable title is outside the project's scope. - **Prerequisites:** INSTALL.md covers Linux distributions, macOS with Homebrew, Windows through WSL (or Cygwin on older Windows) and Termux. The build needs make, gcc or clang, git and rgbds 1.0.4, which the repository pins; FAQ.md notes that rgbds releases before 1.0.0 fail. - **Scope:** README lists six outputs with SHA-1s: Crystal (UE) 1.0 and 1.1, the Australian release, two debug builds and the CGBBYTE1.784 Virtual Console patch. Version differences are selected with assembler defines such as _CRYSTAL11 and _CRYSTAL_AU, and plain make builds only the 1.0 ROM. The Japanese release is not among the listed targets. - **Testing evidence:** make compare builds every target and runs sha1sum against roms.sha1. pret's CI does this on Linux and macOS with rgbds 1.0.4 and fails when the build leaves uncommitted changes, while forks only build. Bug and design-flaw notes describe fixes as optional diffs, since the matching build keeps the original behavior. - **License:** The repository has no license file, so reuse terms for the disassembly are unstated, and the original game's content remains its rights holders'. rgbds is a separate project with its own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Pokémon HeartGold and SoulSilver: a work-in-progress, checksum-matched DS disassembly > Rebuilds the US Nintendo DS releases of Pokémon HeartGold and SoulSilver from a work-in-progress disassembly in which part of the code has been decompiled to C. Each default build checks the ARM9 and ARM7 binaries, the filesystem and the complete ROM against per-game SHA-1 manifests. README warns that, because decompilation is incomplete, edits that change code or data layout can crash the game. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented build reads no original ROM: the DS filesystem’s graphics, model, text and data files are committed under files/. The target images are identified by SHA-1 (HeartGold 4fcded0e2713dc03929845de631d0932ea2b5a37, SoulSilver f8dc38ea20c17541a43b58c5e6d18c1732c7e582), and README links their No-Intro records. Only the contributor asmdiff tool refers to a user-supplied base ROM. - **Prerequisites:** INSTALL.md covers WSL2 (recommended), WSL1, MSYS2, macOS and Debian, Arch and Fedora Linux; packages include an ARM GCC toolchain, bison, flex, Ninja, Python 3, libpng and 32-bit libc, and macOS also needs Wine. The Makefile clones Meson 1.12.0 and downloads the metroskrew 0.1.3 release, which its repository describes as a relinked Linux port of the proprietary Windows Metrowerks ARM compiler; Meson fetches pinned NitroSDK, NitroSystem, NitroDWC, NitroWiFi and libvct subprojects. make builds HeartGold and make soulsilver builds SoulSilver. - **Scope:** README calls this a work-in-progress disassembly of the US releases; it warns that symbol names and code structure can change, and that edits altering the size or layout of any function or data structure can crash the game because the ROM is not fully decompiled. At the reviewed commit asm/ still holds 283 assembly files beside 406 C files in src/, and CONTRIBUTING.md describes NONMATCHING C kept beside the inline-assembly versions used for matching builds. Outputs are pokeheartgold.us.nds and pokesoulsilver.us.nds, not a PC port. - **Testing evidence:** make runs Meson tests after building that check the ARM9 main binary, ARM7 binary, filesystem and complete ROM against SHA-1 manifests; the Makefile tells modders they may drop that check after their first build. CI builds and checks both games and runs a progress calculation on pushes. Matching hashes establish identity for these two US images. - **License:** The repository has no top-level license file and GitHub detects none; some bundled tools carry their own licenses, and the metroskrew and ntrtwl SDK repositories declare no license on GitHub. SDK libraries and original game content remain subject to their rights holders. CONTRIBUTING.md prohibits LLM-generated contributions apart from narrow, disclosed exceptions. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### FFTARecomp: static recompilation of Final Fantasy Tactics Advance > Recompiles the user’s Final Fantasy Tactics Advance (USA) Game Boy Advance ROM ahead of time into native code for Windows, Linux and Steam Deck, building on JRickey’s gba-recomp toolkit. ARM and Thumb code is translated to C and compiled locally, while a Rust runtime models the console’s graphics, sound, DMA, timers and BIOS calls. The port adds widescreen, zoom, fast-forward and remappable controls. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Final Fantasy Tactics Advance (USA) ROM, serial AFXE; the project manifest records the expected SHA-1. No console BIOS is needed, because BIOS calls are high-level emulated. The installer recompiles the game on the user’s PC, and the project excludes ROMs, saves, memory dumps and generated game C from its uploads. - **Prerequisites:** Building from source needs Rust and Windows PowerShell (build-all.ps1). A C compiler is also a runtime requirement: the recompiler emits C11 and links a per-title library. The Windows installer downloads the w64devkit 2.10.0 GCC toolchain, and Linux release builds use Zig as a build-only cross compiler. - **Scope:** Reviewed source follows the v2.0 release (2026-10-13) and is labelled a work in progress. README targets Windows 10/11, Linux and Steam Deck; its recomp manifest also lists Android and calls the game fully playable from start to finish. Without a C compiler the recompiler falls back to an interpreter, which upstream keeps for self-modifying code and as a differential-testing oracle. Known issues include brief sprite silhouettes in the first level and a gamepad that may go undetected on first launch. - **Testing evidence:** A dated release audit (2026-10-12) reports clean source-upload scans, 26 passing input-configuration and menu tests and successful Windows and Linux release builds, and leaves physical-controller behavior unmeasured. README cites no hardware or emulator comparison results. - **License:** FFTARecomp changes are MIT and retain upstream gba-recomp notices (MIT OR Apache-2.0); gamedb.sqlite function metadata is CC0 1.0, and w64devkit tools keep their GPL-family licenses. Square Enix and Nintendo retain their game rights. Upstream gba-recomp describes itself as AI-assisted. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### SymphonyRecomp: a RecompOne static recompilation of Symphony of the Night > Statically recompiles the North American PlayStation release of Castlevania: Symphony of the Night into C# with BlackLabelHQ’s RecompOne, whose runtime simulates the BIOS, memory-mapped I/O, GPU and CD-ROM so the game runs natively without a console BIOS. Per-overlay function maps and patches add widescreen, quality-of-life, randomizer and cheat features. References from the SOTN decompilation help name functions, but the project stresses that it is a recompilation, not a decompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own North American disc (serial SLUS-00067) as a two-track BIN/CUE set or CHD with fixed file names; other-language discs are described only as future sources for a language switcher. The repository contains no game data, and RecompOne needs no BIOS or other Sony components. - **Prerequisites:** Release v0.5.1b (2026-08-19) ships Windows x64/ARM64, macOS ARM64/x64 and Linux x64 builds; Linux ARM64 was dropped in 0.5b. Source-build prerequisites list an OpenGL 2.1+ GPU, .NET 10, OpenAL and Git, and the changelog calls the OpenGL 2.1 path experimental with bitmasking problems. Game code is generated by running the RecompOne submodule against config/sotn.json. - **Limits:** The README calls this an open beta that may contain game-breaking bugs, and 1.0 has not been released. No equivalence or automated gameplay test is published. - **License:** SymphonyRecomp has no license file, so reuse terms are unspecified; the pinned RecompOne recompiler and runtime are MIT-licensed, and the game retains its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### The Two Towers Recompiled: an original Xbox static-recompilation port > Statically recompiles the x86 code of The Lord of the Rings: The Two Towers (Xbox, USA, 2002) into C with the bundled xboxrecomp toolkit, producing native Windows, Linux and experimental macOS builds. The recompiled sources are generated locally from the player's own default.xbe, and game data comes from their disc image or extracted folder. README reports the game as fully playable, with visual, frame-rate and mod issues listed. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Players need their own USA Xbox disc image or extracted game folder, and no game data is included. generate.py checks the retail default.xbe against a fixed SHA-256, then runs the xboxrecomp pipeline (XBE parsing, disassembly, function identification, ABI analysis, naming and recompilation) to write the C sources locally, so no recompiled code is committed. A separately distributed GameCube high-resolution texture pack is optional and not part of the release. - **Prerequisites:** The repository vendors the xboxrecomp 0.12.0 static-recompilation toolkit, which translates an XBE's x86 code into C, and CHANGES.md lists the fixes made to it for this game. The game project builds with CMake 3.20+ and C11 under MSVC, MinGW or Clang/GCC; Linux uses SDL2 with OpenGL loaded at run time, and the renderer options are Direct3D 11, Vulkan through DXVK or OpenGL. The README at this revision has no build section; generate.py only says to build with CMake afterwards. - **Limits:** README for v1.9.2 calls the port a fully playable work in progress and recommends 60 FPS; unlocked frame rates and widescreen are experimental. Downloads cover 64-bit Windows 7 SP1 to 11, x86-64 Linux with glibc 2.27+, and macOS 10.15+ on Intel or through Rosetta 2, with the macOS build not yet tested on a Mac. Known issues include stretched character shadows, lighting glitches, Vulkan black screens and several problems with the bundled extra-heroes mod. - **Testing evidence:** Testing reported for 1.9.2 covers menus, level loading and fonts in several languages under Wine and on Linux with OpenGL, and states that the Windows, Linux and macOS builds compile. No automated tests or CI runs are recorded for the reviewed commit. - **License:** LICENSE.txt applies MIT to the port's own code (twotowers/ and generate.py); the vendored xboxrecomp keeps MIT plus LGPL-2.1-or-later for parts taken from xemu. The license adds that the release's game program contains code mechanically translated from the original executable, which it does not cover and which remains the rights holders' property. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Melee Unlocked: a Windows source port and static recompilation of Melee > A beta Windows build of Super Smash Bros. Melee (NTSC 1.02) with two engines: a source port that compiles the doldecomp decompilation as a native library, and a static recompilation that translates the retail DOL's PowerPC code and Slippi's Gecko codes into C++. Both run on a native runtime with Direct3D rendering, unlocked display rates and natively implemented Slippi rollback play. The user's own ISO supplies all game data, and the README says the work was AI-assisted. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Melee NTSC 1.02 ISO: the game reads its data from it, and the from-source build takes the retail main.dol from it as the recompiler's input. Nothing from the disc is committed or shipped. Online play needs a Slippi account through the Slippi Launcher; the optional DLSS 5 path needs NVIDIA's separately supplied runtime and model. - **Prerequisites:** Windows 10/11 only. The Static Recomp build uses Python, CMake and the Visual Studio 2022 Build Tools (play.bat can install them with winget). The Source Port additionally needs MinGW-w64 GCC 14 or newer with Ninja for the game DLL, an MSVC-built host, and the same guest-translation step; it pins the doldecomp/melee and encounter/aurora submodules and applies its patch with a checking script. - **Scope:** README describes a beta Windows build with two engines chosen in the launcher. The Source Port compiles doldecomp/melee (a submodule pinned at 039c4bf plus a tracked native patch) into melee_game.dll on a native runtime with Direct3D 12/11 rendering, a mixer and direct controller input. The Static Recomp uses the project's Python recompiler to translate the retail DOL's PowerPC code and Slippi's Gecko codes ahead of time into C++, over HLE of the GameCube SDK. Game logic stays at 60 Hz while the display interpolates from animation data; VERSION and the latest release are 0.8.99, though README still names 0.8.76. - **Testing evidence:** README lists CTest unit tests, a validator requiring 2,400 simulation checkpoints to match across headless, hidden, threaded and authored rendering, and a two-instance Slippi match that must log no DESYNC. docs/replay-validation.md compares replays frame by frame in eight Slippi post-frame fields; PORT_COMPLETION.md makes resolving a differing replay byte a precondition for claiming deterministic online compatibility. These are project-reported. - **License:** GPL-3.0-or-later from 0.8.5 (GPL-2.0-or-later through 0.8.1); NOTICE lists code ported from Dolphin, Slippi Ishiiruka and Slippi, bundled components with their own licences, and a GPL section 7 permission for NVIDIA and Intel SDKs. Melee belongs to Nintendo and HAL Laboratory, and the project is unaffiliated with the Slippi team. README says it was developed with Fable 5.1 and GPT 6 Astra, and PORT_COMPLETION.md names Fable and Codex working branches. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### pokeruby: a matching Pokémon Ruby and Sapphire decompilation > Reconstructs the Game Boy Advance games Pokémon Ruby and Sapphire as C source built with pret's agbcc compiler, alongside assembly data scripts and editable graphics. Matching builds cover the English 1.0, 1.1 and 1.2 revisions, debug builds and the first German editions, each checked against a stored SHA-1. A separate modern-GCC target is not expected to match. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The build reads no original ROM: code, scripts, text, graphics and sound sources are in the repository, so the repository carries the game's content in source form. German builds need a setup script before compiling and a teardown script before any English build. - **Prerequisites:** INSTALL.md lists Linux, macOS with Xcode Command Line Tools, and Windows through WSL or the devkitPro MSYS2 environment, plus build-essential, git, libpng and devkitARM. pret's agbcc must be cloned, built and installed into the tree; make modern uses devkitARM's arm-none-eabi-gcc instead, and other toolchains can be set with TOOLCHAIN. - **Scope:** README still calls the project a disassembly and lists hashes for English pokeruby.gba and pokesapphire.gba; INSTALL.md adds 1.1/1.2 revision targets, 1.0-only debug targets and first-edition German builds, and the tree holds 14 SHA-1 files. No asm/ directory remains in the reviewed tree: game code is C under src/, apart from handwritten startup and library assembly and functions marked NONMATCHING whose matching builds keep inline assembly. The contributor guide still describes the earlier asm-to-C workflow. - **Testing evidence:** With COMPARE=1 the Makefile checks the selected build against its SHA-1 file. The GitHub Actions workflow compares the English 1.0/1.1/1.2 Ruby and Sapphire builds and German first-edition variants, then compiles the NONMATCHING sources and the modern target without comparison; README's build badge still points to Travis CI. Matching hashes show identical ROM bytes. - **License:** No license file is present, so reuse terms are unstated; the original game's content remains its rights holders', and agbcc and devkitPro components keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Vandal Hearts: native PC port built on matching decompilations > Builds on shao113’s matching decompilation of PlayStation Vandal Hearts, adds a Japanese matching tree, and carries both through to a native Windows and Linux port. SDL2, OpenGL or Metal and OpenAL backends replace the console’s GPU, GTE, CD-ROM/XA, SPU, MDEC and pad interfaces, and one executable runs the USA, Asia and Japan discs. The matching builds are still checked on every change; PC-only features such as Tactical Mode and HD packs are opt-in. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own raw .bin disc image of the USA (SLUS-00447), Asia (SCPS-45183) or Japan (SLPM-86007) release; the port verifies and auto-detects each disc. The matching build also needs the original executable as its MD5 reference and locally sourced proprietary PsyQ SDK files (README lists ASPSX 2.21 and LIB34.ZIP by MD5). The kanji font, in-game text and static data segment are generated from the user’s copy, not committed. - **Prerequisites:** The port builds with Make or CMake against SDL2, OpenAL, OpenGL (Metal on macOS), libwebp, libav and Python 3; Windows binaries are cross-compiled from Linux with MinGW-w64, and Linux ships as an AppImage. The matching build uses splat, maspsx, decompals’ GCC 2.5.7/2.6.3 frontends and MIPS binutils, and needs a Linux host because those frontends are 32-bit Linux executables. - **Testing evidence:** Reviewed source follows v2.1.0 (2026-08-31). README reports every non-PsyQ function decompiled, with make check confirming byte-identical rebuilds of the US SLUS_004.47 and, since 2.0.0, the Japanese SLPM_860.07 by MD5, and full playthroughs through the endgame on Windows and Linux. macOS is a community-supported experimental build tested through the first battle; its full-playthrough and notarisation validation are pending. - **Testing evidence:** Project-reported checks include make check for both regions, AddressSanitizer and UBSan sweeps that fixed seven latent out-of-bounds bugs, audio/visual fidelity validated against BizHawk, and a software rasterizer reported 99.84–99.99% pixel-exact against DuckStation VRAM captures. The known-issues list places remaining defects in the port’s rendering and backend layer. - **License:** GPL-2.0 covers only the project’s original port code, tooling and documentation. The decompiled game code, derived from shao113’s unlicensed decompilation, and the reconstructed data tables are Konami’s and are not licensed by the project; pre-built releases embed part of the game-derived data segment and a BIOS-derived font. The repository keeps its setup recipe in Claude Code skill files. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Pokémon Platinum: a checksum-matched Nintendo DS decompilation > Reconstructs the US Nintendo DS release of Pokémon Platinum as C source that rebuilds revision 1 by default and revision 0 on request. The default make target runs Meson checks of the code binaries, filesystem and complete ROM against SHA-1 manifests. README still calls the project work in progress; its contributing guide says the code is entirely C but much of it remains obfuscated, leaving documentation and tooling as the main work. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** INSTALL.md covers WSL2 (recommended), WSL1, MSYS2, macOS and Debian, Arch and Fedora Linux; packages include an ARM GCC toolchain, bison, flex, Ninja, Python 3, libpng and 32-bit libc, and macOS also needs Wine. The Makefile clones Meson 1.12.0 and downloads the metroskrew 0.1.3 release, which its repository describes as a relinked Linux port of the proprietary Windows Metrowerks ARM compiler; Meson fetches pinned NitroSDK, NitroSystem, NitroDWC, NitroWiFi and libvct subprojects. make debug builds a GDB-enabled ROM, for which INSTALL.md points to an overlay-aware binutils-gdb fork. - **Scope:** README calls this a WIP decompilation of US Pokémon Platinum. CONTRIBUTING.md states that the repository is 100% C code, although much of it is obfuscated, so current work is mainly documentation and tooling; at the reviewed commit asm/ holds only macro includes beside 1,013 C files in src/. Outputs are pokeplatinum.us.nds ROM images, not a PC port. - **Scope:** The documented build reads no original ROM: graphics, sound, text and data sources, including some prebuilt data, are committed under res/. Revision 1, the default, has SHA-1 0862ec35b24de5c7e2dcb88c9eea0873110d755c; ROM_REVISION=0 builds revision 0, SHA-1 ce81046eda7d232513069519cb2085349896dec7, which INSTALL.md describes as the original North American retail version with a GTS level-range display error that a later shipment patched. README links both No-Intro records. - **Testing evidence:** make runs Meson tests that check shared, revision-specific and ARM7 binaries, the filesystem and the complete ROM against SHA-1 manifests; make rom skips the checksum when code is modified. CI installs metroskrew and runs make check for the default revision. - **License:** The repository has no top-level license file and GitHub detects none; some bundled tools carry their own licenses, and the metroskrew and ntrtwl SDK repositories declare no license on GitHub. SDK libraries and original game content remain subject to their rights holders. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Saints Reborn: a ReXGlue static recompilation of Saints Row > An unofficial native Windows port of Saints Row (Xbox 360, 2006) that statically recompiles the game's PowerPC executable to C++ for x86-64 with the ReXGlue SDK, which also reimplements the console's kernel, GPU (on Direct3D 12), audio and input. A recompiler manifest, game-specific function overrides and an SDK patch make the result run, and each user builds it locally from their own disc. The README reports the game fully playable with built-in co-op and lists known issues. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own Saints Row (Xbox 360) disc as an .iso, or a game folder containing default.xex and packfiles. Only the disc version the port was made with is supported: setup compares default.xex with one known SHA-1 for the World disc release and warns otherwise, because the hooks use fixed addresses. The repository contains no game code, data, recompiled output or executables, and its legal notice forbids using it to distribute them. - **Prerequisites:** Windows 10/11 (64-bit) with a Direct3D 12 GPU, about 15 GB of disk space and 16 GB of RAM. Setup downloads a portable clang, CMake, Ninja and Microsoft's C++ headers and libraries (about 1.5 GB) and builds the game locally in 10–60 minutes; the older setup.bat path needs Visual Studio 2022 with its Clang and CMake components, plus Git. README lists Linux (through Proton) as coming soon, although BUILDING.md already describes Setup as working on Windows and Linux. - **Scope:** README describes a static recompilation, not a decompilation or an emulator: the ReXGlue SDK, pinned at v0.10.0 (commit c94f5eb) and patched by patches/rexglue-sdk.patch, translates every PowerPC function in default.xex to C++. config/saintsrow_manifest.toml adds ABI helpers, 19 functions reached only through vtables and two mid-function hooks, and project/src overrides rendering (predicated tiling), audio, kernel-object and occlusion-query behaviour. README reports the game fully playable from start to finish, with co-op over LAN, direct IP or a join code, an optional 60 FPS mod and a mod loader; known issues include texture flicker in the character creator. - **Testing evidence:** Playability and the known-issue list are the author's reports. The only CI workflow builds the setup application; the repository's tests cover co-op, modding and map tools, and no automated comparison of recompiled behaviour against the console is documented. - **License:** Project code is Apache-2.0 with a NOTICE that redistributors must keep, crediting Saints Reborn by Whompay. The SDK patch keeps the ReXGlue SDK's BSD-style licence, the SDK derives in part from Xenia, and libraries downloaded at build time keep their own terms. Saints Row remains its owners' property, and the NOTICE covers no file extracted or generated from the game. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Pokémon Platinum PC Port: a native port built on the pret decompilation > Builds native 64-bit Windows and Linux executables of Pokémon Platinum from a fork of pret’s decompilation, replacing NitroSDK with the author’s libntr libraries; the same tree keeps the DS ROM build and an experimental Switch target. README says the game should be playable from start to finish but may crash or show graphical bugs. Prebuilt binaries require the player’s own US ROM, and the fork’s default build no longer runs pret’s checksum tests. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** README requires users of the prebuilt release binaries to supply their own dumped US Platinum ROM (game code CPUE01), selected on first launch; only the US version is supported. The source tree keeps pret’s committed res/ data, and README asks forks not to publish releases that bundle compiled assets with PC binaries. - **Prerequisites:** Linux builds are recommended through the Docker wrapper drun.sh; a non-container build on Arch Linux lists nasm, enet, arm-none-eabi-gcc, Ninja, flex and bison. Windows uses PowerShell scripts that create a portable MSYS2 environment before make win64, and the NX target needs devkitA64. The ARM and Linux CI jobs install the inherited metroskrew Metrowerks compiler, and the libntr subprojects track their main branches rather than pinned revisions. - **Scope:** README describes an experimental PC port of US Pokémon Platinum based on pret’s decompilation, using libntr, libntrsystem, libntrwifi and libntrdwc in place of NitroSDK and related DS libraries. The Meson build_target option selects arm (DS ROM), linux, win64 or nx, and README calls the NX target working but slow. Its goals of full WiFi and multiplayer support and later homebrew console ports are stated aims. - **Testing evidence:** CI builds the ARM ROM, Linux and Windows targets on pc_port pushes and packages Linux and Windows artifacts; the latest release, v0.1.12 (2026-10-10), ships Linux and Windows zip archives from a commit earlier than the reviewed one. The fork’s default make target drops pret’s checksum dependency and CI does not run make check. - **License:** The fork has no top-level license file and GitHub detects none; libntr declares MIT, which README says release publishers must honor, while pret’s decompilation declares no license and original game content remains subject to its rights holders. README states that generative AI/LLM shortcuts were not used and that AI-made pull requests are rejected, and AGENTS.md repeats that refusal. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### MikuPan: a native Fatal Frame PC port built on the Himuro decompilation > Ports the PS2 game Fatal Frame to native PC builds without emulation; its repository description names the Himuro decompilation as its basis. Stubs replace PS2 kernel calls and a new SDL3-based layer handles rendering, audio and UI, while game data comes from the user’s own disc. The README calls the port very early work and publishes no matching or fidelity checks. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires IMG_HD.BIN and IMG_BD.BIN from an independently obtained Fatal Frame disc image of the matching region: NTSC-U for the default presets or PAL/EU for the *-eu presets. NTSC-J images are unsupported. The README states that the game data is not packaged, including in Android APKs. - **Prerequisites:** Builds use CMake 3.28+ and C++20 and fetch SDL3, FFmpeg, SDL_shadercross and other libraries; Windows uses MinGW, Cygwin or MSVC, and Linux uses GCC. macOS is not officially supported, though contributors report Apple Silicon builds on SDL_GPU’s Metal backend. Android packaging needs Android SDK 35+, NDK r28c+ and prebuilt FFmpeg libraries. - **Scope:** README describes an in-progress native PC port of the PS2 game with no emulation and calls it very early work; debug builds are recommended because release builds have issues. Per the repository description its basis is Himuro, a separate decompilation aiming for matching US, EU and JP PS2 executables, and MikuPan’s game-code directories follow Himuro’s source layout. - **Testing evidence:** CI builds Windows, Linux and macOS targets on pushes and pull requests and publishes nightly prerelease archives. The reviewed tree has no test suite, matching check or gameplay-comparison result. - **License:** MikuPan declares AGPL-3.0 and Himuro declares MIT; bundled third-party binaries and libraries keep their own terms, and Fatal Frame data retains separate rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Starfox 64: Recompiled — an N64Recomp static-recompilation port > Uses N64: Recompiled to statically recompile the US 1.1 (Rev A) Nintendo 64 release of Star Fox 64 into a native port for Windows, Linux and macOS, rendered with RT64. Its patches and enhancements draw on headers and some functions from the separate sf64 decompilation, but the port is not compiled from that decompilation's source. The README reports high-frame-rate, widescreen and mod support, with assets loaded from the user's own ROM. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Players provide the US 1.1 (Rev A) N64 ROM in the main menu; the port accepts only that ROM, converting other dump formats of it to .z64, and loads its assets from it. Building also needs a decompressed copy of the same ROM as recompiler input, identified in BUILDING.md by MD5. The repository and releases contain no game assets; CI copies the decompressed ROM from a private repository through secrets. - **Prerequisites:** Runs on Windows, Linux (x64, ARM64, Flatpak, Steam Deck) and macOS 13 or newer, with a GPU supporting Direct3D 12 (Shader Model 6), Vulkan 1.2 or Metal Argument Buffers Tier 2, and SSE4.1 on x86-64. Building needs CMake, Ninja and clang (on Windows Visual Studio 2022 with its Clang and CMake components plus make; on Ubuntu SDL2, GTK 3, LLVM and lld), with N64Recomp and RSPRecomp built separately; CI pins N64Recomp at commit 98bf104. - **Scope:** README describes a static recompilation, not an emulator or a decompilation-based source port: N64Recomp translates the game code in the ROM (us.rev1.toml, with symbols from the Starfox64RecompSyms submodule) and RSPRecomp the audio microcode (aspMain.us.rev1.toml), running on N64ModernRuntime with RT64. Patches use headers and some functions from the sf64 decompilation submodule. README links release 1.0.3, the latest GitHub release (2025-12-30), lists planned features and one overlay-related known issue, and calls Starship a sibling port built with different technology. - **Testing evidence:** Nightly CI builds run for Windows, macOS and Linux. DOCS/fox_lore.md recounts the sf64 decompilation's matching history. - **License:** COPYING is GPLv3; the original ROM and the bundled libraries keep their own terms. This is a static recompilation, not recovered authored source, and README credits the decompilation team's reverse engineering for the port's enhancements. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Syphon Filter: The Omega Strain — matching PS2 executable decompilation > Reconstructs much of the NTSC-U PlayStation 2 executable of Syphon Filter: The Omega Strain as C; with the remaining functions kept as split assembly, the build reproduces the retail SCUS_972.64 byte for byte. Committed objdiff reports track per-function matching against the user’s own executable. This is a matching-decompilation case, not a PC port; progress figures remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply SCUS_972.64 from an independently owned disc or image; configure.py checks its SHA-256 against config/target.sha256 before splitting. No disc data, split assembly, objects or rebuilt executable is committed; derived files are generated in git-ignored folders. Executable data regions are committed as generated C definitions. - **Prerequisites:** Setup needs Python 3.10+ with pinned splat 0.50.0 and spimdisasm 1.42.4, ninja, MIPS binutils and objdiff-cli. Windows runs the tools natively; Linux/macOS run the Windows compiler through wibo or wine. The setup script downloads a CodeWarrior PS2 3.0.3 build archived by decomp.me, but the licensed 3.0 build 38 and 3.04 build 22 installations used by per-unit overrides are not supplied; without them those units fall back to retail assembly. Library units use EE-GCC 2.95.3 and 2.96. - **Scope:** Targets only the NTSC-U executable SCUS_972.64; the output is a rebuilt PS2 ELF, not a native PC program. At the reviewed commit, the committed objdiff report and handoff note list 13,413 of 14,331 functions (93.59%), 76.59% of code bytes and 99.92% of data as matched, with the rest still assembly. The dated status table in PROGRESS.md shows older, lower figures, and function totals shift as boundaries are refined. - **Testing evidence:** Verification is a whole-image SHA-256 comparison: ninja fails unless the rebuilt executable matches the retail hash, and the project claims a function match only with that check and objdiff identity. CI cannot build without the executable and only uploads the locally generated report for decomp.dev. The project treats build 38 compatibility as code-generation evidence. - **License:** No license file is present at the reviewed commit, so reuse terms for the project’s code are unstated; the game, its executable and the proprietary Metrowerks compilers retain separate rights. The handoff note addresses a person or AI agent and the progress log plans parallel agent work. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Animal Crossing: a native PC port of the GameCube decompilation > Runs Animal Crossing’s decompiled GameCube C code natively on 32-bit x86, replacing the GX graphics API with an OpenGL 3.3 translation layer and console services with SDL2-based platform code. Game assets are read at startup from the user’s own disc image instead of being shipped. It is a port built on ACreTeam’s ac-decomp, not a matching rebuild of the original executable. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own Animal Crossing (USA) disc image in ISO, GCM or CISO form; at startup the port loads main.dol, foresta.rel.szs and about 2,500 assets from it in memory. The README states that the repository contains no game assets or assembly. Saves use Dolphin-compatible GCI files, and optional HD texture packs use Dolphin’s naming format. - **Prerequisites:** Windows is the primary target: the documented build uses an MSYS2 MINGW32 shell with 32-bit MinGW GCC, CMake 3.16+ and SDL2, plus vendored GLAD for an OpenGL 3.3 Core context. Builds must be 32-bit, unoptimized (-O0) and define NDEBUG, because the decompiled code casts pointers to 32-bit values and contains optimization-sensitive undefined behavior. Linux i686 is described as compiling and linking but is not officially supported. - **Scope:** The reviewed snapshot is the v0.9.3-playtest pre-release and supports only the USA Rev 0 release (GAFE01_00). The README calls the underlying ac-decomp complete, while the developer documentation calls it 99.52% complete. Online play is not planned, and the Animal Crossing Deluxe mod is incompatible, although this release adapts some of its quality-of-life changes. - **Testing evidence:** About 100 decompilation files carry TARGET_PC changes, and optional PC_ENHANCEMENTS add settings, MSAA and texture-pack loading. The project describes Windows as fully tested and records an unresolved bass-distortion audio issue, but publishes no automated tests or byte-matching checks for the port. - **License:** LICENSE keeps the decompilation code under CC0 1.0 from ac-decomp and licenses the pc/ layer and TARGET_PC additions under MIT, with a separate MIT notice for FixNES; GitHub classifies no single license. Game content rights are separate. The README discloses that AI tools such as Claude were used for port code only. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### GoldenEye 007: matching Nintendo 64 decompilation for three releases > Reconstructs GoldenEye 007’s Nintendo 64 code as C source that rebuilds the US, Japanese and PAL ROMs. Assets come from a user-supplied US ROM, with Japanese and PAL differences taken from their own ROMs, and the default build compares each output with a recorded SHA-1. The README still calls the project work in progress, while a mutable status page reports all 208 files done; it is distinct from the separately curated PC port. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an unmodified, independently obtained US ROM; JP and PAL builds additionally need their own original ROMs, and US asset extraction must come first. The README states that the repository does not include all assets needed to compile the ROMs. - **Prerequisites:** Documented hosts are Linux, WSL or a VM, plus Docker or Docker Compose. The build uses GNU make, MIPS binutils, Python 3 and host build tools. By default it compiles C with a locally generated static recompilation of the IRIX IDO 5.3 compiler from vendored decompals/ido-static-recomp; alternatively it runs the original IDO binaries under qemu-irix. - **Scope:** The reviewed GitHub repository describes itself as a mirror of the kholdfuzion GitLab project. README calls it a work-in-progress decompilation that builds US, JP and EU ROMs, each with a listed SHA-1. The mutable status page reports 208 of 208 files done and 100% for src, src/game, src/inflate and src/libultra without stating its unit. The output is an N64 ROM, not the separately curated native PC port. - **Testing evidence:** With the default COMPARE=1, the build checks the output ROM’s SHA-1 and prints an OK line for the selected version; COMPARE=0 and the DEBUG and USB variants skip that check. NTSC, JP and EU CI workflows build from secretly supplied base ROMs and generate status reports. - **License:** GitHub detects no license and the reviewed tree has no top-level license file, so no reuse grant is established. Original ROMs and extracted assets retain separate rights, and the checked-in IRIX IDO binaries and vendored tools keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Starship: a Star Fox 64 PC port built from the decompilation > A native PC port of Star Fox 64 that compiles the game's decompiled C code against libultraship, an N64 porting library that reimplements libultra and renders through Fast3D. On first run it uses the Torch tool to turn the user's US ROM into an asset archive, and it ships for Windows, Linux, macOS and Switch. The README of the separate Starfox 64: Recompiled static recompilation calls this port its sibling, built with different technology. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply a US 1.0 or US 1.1 Rev A ROM in .z64 form; README lists the SHA-1 of each. The first run, or the ExtractAssets build target, turns it into sf64.o2r through Torch, using the definitions in config.yml and assets/yaml. JP and EU ROMs serve only as voice-language replacements alongside a US ROM, and the Switch build needs the archive generated on PC. The repository holds extraction definitions, not game assets. - **Prerequisites:** Releases target Windows, Linux (AppImage), macOS and Nintendo Switch, with DirectX 11, OpenGL and Metal back ends. Building needs CMake, Python 3 and Git with Visual Studio 2022 (v143 tools; at least 8 GB of RAM) on Windows, or gcc or clang with Ninja and libraries including SDL2, libzip, spdlog, tinyxml2, Boost and Ogg/Vorbis on Linux. Submodules are libultraship, Torch and asm-differ; CI generates only the port's own starship.o2r and packages builds without a ROM. - **Scope:** Starship's README presents a PC port with release and playtest builds. DOCS/fox_lore.md in the sibling Starfox64Recomp repository describes it as a native port of the sf64 decompilation's C code on libultraship (which reimplements most of libultra and uses a Fast3D renderer) and says native porting exposed asset-linking errors and undefined behaviour that matching code alone did not reveal. CMakeLists.txt compiles src/engine, src/overlays, src/sys and src/audio with a port layer in src/port. The latest release is v2.0.0 (2025-05-25), and README warns that CI playtest builds will likely show bugs and possibly crashes. - **Testing evidence:** Neither README nor BUILDING.md documents automated gameplay tests or comparisons with the original game. - **License:** LICENSE.md is CC0 1.0 Universal; the ROM, extracted assets and the game remain their owners' property, and the submodules keep their own terms. README says the project does not condone piracy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### CTR Turbocharged: a PC sourceport built on the Crash Team Racing decompilation > Extends the Crash Team Racing: High Octane sourceport, which derives from the CTR Native port of the CTR-ModSDK PlayStation decompilation, into Windows and Linux builds with a native 3D renderer, selectable aspect ratios and frame rates up to 240 FPS. The decompiled game code still assumes 32-bit pointers and loads assets from the player’s own NTSC-U disc image. Renderer, timing and option tests exist, but device coverage and fidelity remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Game data is not included. The player supplies a raw MODE2/2352 BIN image of the NTSC-U (US) retail Crash Team Racing disc, used as assets/ctr-u.bin; 2048-byte ISO images and CUE files are not accepted. The first-run importer checks sector layout, the NTSC-U executable and boot configuration, required files and the audio manifest, but does not compare the image against a retail checksum. Optional PAL voiceovers and custom characters need a PAL or NTSC-U disc image and the project’s Python tools. - **Prerequisites:** Builds must target 32-bit x86 because the decompiled code assumes 4-byte pointers. The documented CMake 3.20+ presets cover Linux gcc-multilib, Windows MinGW32/MSYS2 and Visual Studio 2022, with SDL3 and other dependencies vendored; Linux builds also need 32-bit X11, OpenGL, audio, udev and D-Bus development packages. Running needs an OpenGL 3.3 GPU and driver, plus 32-bit runtime libraries on Linux. - **Scope:** The reviewed turbocharged branch (VERSION 2026.10.1) forks High Octane v1.4.1, which builds on CTR Native and the CTR-ModSDK decompilation. It is a source port of decompiled C, not a matching decompilation or a static recompilation. Only Windows and Linux PC builds are supported; the inherited PS Vita and web builds are not, and the online leaderboard and Discord Rich Presence are disabled. - **Testing evidence:** README reports 31 CTest tests with renderer tests enabled: 25 display-independent and 6 needing an OpenGL context. CI runs the display-independent subset on Linux and Windows and the GPU subset under Xvfb with software GL, which may skip without a context. The tested-devices table confirms one Linux setup and no Windows machine, and known issues include Wayland problems with 32-bit libraries. These are project reports. - **License:** The repository is GPLv3. Its third-party notices record PsyCross-derived platform code (MIT), PSn00bSDK headers (MPL 2.0), SDL and other vendored components under their own licenses, and the bundled fonts keep Apache 2.0 and OFL terms. Contributing rules keep retail disc data and extracted assets out of commits; the original game remains its owners’ property. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### The Darkness Recomp: an Xbox 360 static recompilation with a native D3D11 renderer > Builds a native Windows x64 port of The Darkness by translating its Xbox 360 executable to C++ ahead of time with a patched XenonRecomp. A D3D11 renderer draws from the engine’s original geometry, shader sources and device state instead of interpreting console GPU packets. Gameplay coverage and Linux results are project-reported, and the author discloses OpenAI Codex assistance. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s extracted Xbox 360 dump: the original encrypted default.xex plus Content, System and the other dump folders. An ISO alone is not accepted, and the repository includes no game code, assets or generated translation output. The runtime decodes default.xex in memory and accepts only the approved original disc revision and Russian localization by SHA-256; title updates and other Xbox games need their own verified translation. - **Prerequisites:** Playing the release needs 64-bit Windows 10/11 with a Direct3D 11 device. Source builds need Git, Visual Studio 2022 with ClangCL, CMake 3.24+, Python 3.11+, MSYS2 MinGW64 tools, standalone LLVM and about 15 GB. The build fetches hedge-dev/XenonRecomp at c5bfd90d and applies the bundled Darkness and correction patches before generating the translation. - **Limits:** The README reports full gameplay with mouse/controller input, XMA audio, saves, local achievements and added video and remapping menus; Xbox Live synchronization is unavailable. Under Proton in WSL2, the opening level rendered with audio, but camera movement and tutorial completion were not confirmed; Steam Deck remains unverified and there is no native Linux build. - **Testing evidence:** The build runs a CTest suite of native and contract tests, and the updater re-tests builds and checks packaged files with SHA-256. These are project checks of the port. - **License:** GPLv3 per COPYING, matching UnleashedRecomp/XenonRecomp; the generator patches are GPLv3, SMAA and the CC0 Xelu prompt icons keep their own terms, and the game retains separate rights. This is static recompilation, not recovered authored source. The README states that development includes OpenAI Codex assistance. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### MarioKart 64: Recompiled — a native port through N64Recomp static recompilation > Statically recompiles the US Nintendo 64 release of Mario Kart 64 into a native Windows, Linux and macOS application with N64Recomp, rendering through RT64. The README distinguishes this from a source port: game code is translated from the user’s ROM, while headers and some functions from a decompilation fork support patches and enhancements. Enhancement, fidelity and input-lag claims are project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Accepts only the user’s US N64 Mario Kart 64 ROM; other dump formats of that ROM are converted automatically, and the README states it is not an emulator for arbitrary ROMs. The repository and its releases contain no game assets. Source builds read the same US ROM as mk64.us.z64 plus a separate symbol-file submodule. - **Prerequisites:** Running requires Direct3D 12.0 with Shader Model 6, Vulkan 1.2 or Metal Argument Buffers Tier 2; x86-64 CPUs need SSE4.1, and the README lists macOS 13.0+ on Apple Silicon or a 7th-generation Intel CPU. Known issues include Intel GPUs on Linux and the prebuilt Linux binary on some distributions. - **Prerequisites:** Source builds need submodules, CMake 3.20+, C++20, and Clang/LLD with SDL2 and GTK 3 on Linux or Visual Studio 2022 with its Clang tools and make on Windows. N64Recomp and RSPRecomp are built separately and run on the provided TOML configurations to generate C code; patches compile against headers from a fork of the mk64 decompilation. - **Testing evidence:** CI recompiles and builds Linux, Windows and macOS targets with a ROM held in a private repository behind CI secrets; it publishes no matching, fidelity or gameplay comparison. Release v0.9.2 (February 2026) offers Windows, Linux, Flatpak and macOS archives. Rendering-accuracy, framerate and input-lag statements are project claims. - **License:** COPYING is GPL-3.0; original game content, decompilation-derived headers and libraries such as RT64 and RmlUi retain their own terms. Static recompilation translates machine code rather than recovering authored source. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Animal Crossing: matching GameCube decompilation > Reconstructs Animal Crossing’s GameCube code as C and C++ source that rebuilds the USA release’s main executable and its foresta.rel module. The dtk-template build reads the original binaries and assets from a user-supplied disc image, then checks both outputs against SHA-1 hashes. A separate native PC port builds on it; completeness figures remain project-reported here. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own Animal Crossing (USA) disc image; README states the repository contains no game assets or assembly. The build configuration expects the disc’s main.dol to match a recorded SHA-1 before splitting it, so other revisions or modified images are not supported inputs. - **Prerequisites:** Windows builds use native Python and ninja; macOS adds wine-crossover, and Linux uses an automatically downloaded wibo wrapper on x86 or Wine elsewhere. configure.py downloads pinned decomp-toolkit, binutils, Metrowerks CodeWarrior GameCube compiler, objdiff and sjiswrap releases; objdiff supports per-object diffing. - **Scope:** README lists one supported version, USA Rev 0 (GAFE01_00). configure.py also defines an Australia Rev 0 (GAFU01_00) target, but CI builds only the USA version and 19 objects are marked matching for USA alone. The outputs are a GameCube DOL and REL module, not a PC executable. - **Testing evidence:** The default ninja target runs decomp-toolkit’s SHA-1 check of static.dol and foresta.rel against build.sha1. configure.py lists 4,005 objects as matching and none as non-matching, and CI builds with a private container that supplies the original files. The mutable decomp.dev page reports 100.00% decompiled and fully linked at this commit. - **License:** The repository is dedicated under CC0 1.0. Original game content and the downloaded toolchain binaries are outside that dedication and keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Kingdom Hearts 358/2 Days: a matching Nintendo DS decompilation > Reconstructs the ARM9 program and overlays of the EU Nintendo DS release of Kingdom Hearts 358/2 Days as C that recompiles byte for byte with CodeWarrior. README reports all 306 modules byte-identical, with about 99.5% of functions in real C and library assembly counted separately; the ARM7 binary is outside its scope. The repository holds no ROM, game assets or extracted disassembly and produces no playable build. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own EU ROM dump, days.nds: 268,435,456 bytes, SHA-1 6fae8f5bbe80114b4e2535260eab5f4d0fc8a844 (CONTRIBUTING.md also lists SHA-256 and MD5). Other dumps will not line up with the committed addresses. The repository tracks no ROM, extracted data (including the extracted asm/ tree), build output or proprietary toolchain, and a pull-request check rejects added ROM, binary or asset files. - **Prerequisites:** CONTRIBUTING.md lists Python 3 with capstone, pyelftools and ndspy, the dsd extraction and delinking tool, the proprietary CodeWarrior mwccarm 3.0 build 139 compiler (not supplied), arm-none-eabi-as and a Ninja-driven mwccarm/mwldarm build; its commands call tools/dsd.exe alongside Bash scripts. A few precompiled-middleware units use an older mwccarm through per-file compiler overrides. - **Scope:** README reports every function of the EU (YKGP) ARM9 program and its overlays matched and all initialized data reconstructed, with 306 of 306 rebuilt modules byte-identical; the remaining work is readability, such as shared structures, naming and file grouping. It counts 23,125 of about 23,233 functions as real C and tracks 108 assembly implementations (library routines and two game functions that need clz) separately. docs/ARM7.md states that the decomp covers the ARM9 only. This is a matching decompilation, not a port, and it produces no playable build or redistributable binary. - **Testing evidence:** dsd check modules compares each built module with the base ROM, verify_idx.py checks single functions including relocations, and the ROM round-trip script is expected to differ from the reference dump only in four non-functional CRC bytes. CONTRIBUTING notes that functions listed as known mismatches are kept out of the link and filled with original bytes. CI does not build the game; it rejects forbidden files and regenerates progress reports. decomp.dev reports YKGP 100.00% decompiled and fully linked at the reviewed commit, counting verified SDK assembly. - **License:** Contributors’ decompilation and tooling are dedicated to the public domain under CC0 1.0; the original game and its assets remain their owners’ property, and the CodeWarrior compiler is not distributed. DS Protect sources are reconstructed after taxicat1/dsprot, and the SDK identification harness compiles NitroSDK sources from pret/pokediamond. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### decomp.me > Collaborative decompilation website for matching work: its compile service builds candidate source with a selected platform compiler, assembles the target assembly and diffs the two objects with asm-differ. m2c drafts initial decompilations for its MIPS, PowerPC, ARM and SuperH platforms. The 18 platform definitions span N64, PlayStation, PS2, PSP, GameCube/Wii, Wii U, DS, GBA, 3DS, Switch, Saturn, Dreamcast and Xbox 360 plus IRIX, Mac OS X, MS-DOS, Win32 and Android x86. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use the hosted site or self-host the Next.js/Django stack with Docker and Docker Compose; the self-hosting guide asks for at least 4 GB RAM, ideally 6 GB+. Its Docker configuration disables Switch support by default because of the Clang compilers' size, and ENABLE__SUPPORT variables enable platforms. - Each platform definition names its assembler, objdump and nm commands; compilers are added as packages in the separate decompme/compilers repository. Compiler, assembler and objdump subprocesses can run in an nsjail sandbox, enabled by default in the cromper container; outside it, nsjail must be built locally with unprivileged user namespaces enabled. - MIT license; the README notes that dependencies keep their own licenses. No tagged releases, so this entry pins the reviewed main-branch commit. Diffs show instruction-level differences for the compiled code and m2c output is a draft; neither recovers names, types or semantics. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### TonyWasAProSkater: a THPS1 native port forked from a matching decompilation > Ports Tony Hawk’s Pro Skater (PlayStation, USA) to native Windows and Linux builds from a fork of an in-progress matching decompilation of the retail executable. The decompilation recompiles reconstructed functions with a Psy-Q toolchain and compares them byte for byte with the user’s retail executable, while the port replaces PlayStation hardware and libraries with SDL2 and OpenGL services. Play needs the user’s own disc image; matching and gameplay results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Play requires a raw MODE2/2352 BIN image of the user’s own Tony Hawk’s Pro Skater (USA) PlayStation disc; the Dreamcast disc image (.gdi and its tracks) can supply the assets instead. The first start copies about 630 MB into a Data folder. Building also needs the retail SLUS_008.60 executable from the user’s disc for the function layout. README states that no game assets or original executable are committed, while decompiled code and initialised data are included. - **Prerequisites:** Builds run on Windows with MSYS2’s 32-bit MinGW toolchain and SDL2 (64-bit builds use ucrt64) or on x86 Linux with multilib GCC and 32-bit SDL2, plus Python 3 and Ghidra’s GNU demangler; a Psy-Q library name table is generated from ghidra_psx_ldr signatures. Running needs 64-bit Windows 10/11 or x86 Linux with 32-bit SDL2 and OpenGL libraries, and an OpenGL 3.3 GPU. Re-verifying matched functions additionally needs Node and the Psy-Q 4.5 compiler, which is not distributed. - **Scope:** The reviewed main branch, a fork of LANCommander/THPS, targets only the retail PS1 USA executable SLUS_008.60, not later games in the series. decomp/PROGRESS.md, generated 2026-10-13, reports 88.0% of game-code bytes (928 of 1,178 functions) byte-exact, with the Psy-Q libraries out of scope. The port compiles a separate fork of that code in game/; decomp/ stays the byte-matching reference and is not built into the port, so the playable executable is not itself a matching build. - **Testing evidence:** decomp/tools/check_all.mjs recompiles every function in matched.tsv and compares it with the retail bytes; C that replaces hand-written assembly and Sony libraries is checked by replaying recorded game states against the original MIPS code. Port changes are checked with deterministic runs whose frames and saves are compared with an earlier build. README reports all nine career levels playable and an approximate rather than exact PS1 reverb. - **License:** README and the port README describe the project’s own code as MIT under a repository LICENSE, but the reviewed tree has no LICENSE file and GitHub detects none. The port README states that decompiled game code, data and all assets remain © Activision/Neversoft; linked libraries such as SDL 2, PL_MPEG and glad keep their own terms. The tree includes CLAUDE.md project notes and a GhidraMCP configuration. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### P.T. for PC: a behavior-based engine reimplementation that reads the PS4 data > Reimplements P.T.’s game logic in C++ on a new Vulkan engine that reads levels, models, textures, sounds, scripts and cutscenes from the user’s own PS4 copy at run time. The author documents reverse-engineered file formats and used the shadPS4 emulator as a behavior and frame reference. Fidelity to the original is author-reported, and the use of AI coding tools is disclosed. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own copy of P.T.: the port is built and tested with the US release CUSA01127, as a console dump folder or a fake PKG made from it; the EU and Japanese releases install with a note but the author has not seen their data. Store PKGs are encrypted for their console and are not decrypted. The installer copies only chunk1.psarc, texture.qar and pathid_list_ps4.bin, and no game data is in the repository or installer. - **Prerequisites:** Runs on Windows 10/11 x64, Linux x86-64 with glibc 2.38+, or macOS 14+, with a Vulkan 1.3 GPU (MoltenVK on macOS). Building needs CMake and Ninja, plus Visual Studio 2022 Build Tools, clang-cl and the Vulkan SDK on Windows, or GCC 13/clang 17 with glslc on Linux; CMake fetches SDL3, Lua 5.1, whisper.cpp and other dependencies and checks downloaded models and SDKs by SHA-256. One section needs a microphone or a configured substitute key. - **Scope:** This is an engine reimplementation, not an emulator, decompilation or static recompilation: the README says the logic was rebuilt from the original’s behavior. It reports the whole teaser as playable, including the voice section, and adds optional upscalers, ray-traced effects, photo mode, a museum, mods, extra languages and experimental VR and third-person views. VR has run only against a simulated runtime, the Intel Mac build has not been run, and the tree contains unreleased 1.0.2 changes. - **Testing evidence:** Verification is author-run: CMake unit-test targets, a windowless walkthrough script that plays scripted routes and checks the log, and frame comparisons against shadPS4. - **License:** MIT covers the port’s own code; the bundled Noto fonts (OFL), the LGPL LibOrbisPkg installer helper and other dependencies keep their own licenses, and P.T. content belongs to Konami. The README discloses AI coding tools in development and debugging. ##### Primary sources 1. 2. 3. 4. 5. 6. #### SpaghettiKart: a native Mario Kart 64 port built on decompiled source > Builds a native Mario Kart 64 port for Windows, Linux, macOS and Switch from source that keeps the Mario Kart 64 decompilation’s file layout, running on libultraship’s reimplemented N64 SDK. Its bundled Torch extractor converts the user’s US ROM into an asset archive, and the port adds mods, custom tracks and an editor. The README does not name its upstream decompilation, and no matching or fidelity checks are published. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supports only the US ROM with SHA-1 579C48E211AE952530FFC8738709F078D5DD215E in .z64 byte order. The bundled extractor converts that user-supplied ROM into mk64.o2r; the README states that SpaghettiKart includes no copyrighted assets, and the Switch build reuses an archive generated by a PC release. - **Prerequisites:** Source builds need submodules (libultraship, Torch, fast64 and others), CMake 3.16+ and Python 3. Windows uses Visual Studio 2022 with the v143 toolset and at least 8 GB of RAM; Linux needs GCC or Clang with SDL2, libzip, tinyxml2, spdlog, Boost and Ogg/Vorbis packages. Rendering backends are DirectX 11 on Windows, OpenGL on all platforms and Metal on macOS. - **Scope:** The README does not name its upstream, but the tree keeps the Mario Kart 64 decompilation’s src/, course, extraction and progress-tooling layout, while new engine and port directories add C++ systems, mod loading, custom tracks and the unfinished HM64 Labs editor. Release 1.0.0 “Bolognese Alfa” (February 2026) is the latest stable release; nightly CI builds are for playtesting only. - **Testing evidence:** CI compiles Windows, Linux and macOS packages and packs the project’s own spaghetti.o2r; no ROM-based test, matching check or gameplay comparison is published. The FAQ records limits such as eight racers and eight selectable characters, limited HD texture support and no online play. - **License:** The reviewed tree has no top-level license file, so reuse terms for the project’s code are unstated; libultraship and Torch declare MIT, and Nintendo content retains separate rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Animal Crossing: Wild World: matching Korean DS decompilation with differential runtime checks > Reconstructs the ARM9 game code of Animal Crossing: Wild World’s Korean DS release as one C or C++ source per function, checked against the user’s ROM with the original Metrowerks compiler and linker. Each function also has a readable Clean rewrite, and an included DS interpreter compares the ROM code, natively compiled sources and rewrites on recorded play. Data sections, the ARM7 binary, the linked SDK libraries and regrouping into original source files remain outside the reconstruction. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own Korean ROM matching SHA-1 1fffd601d3439e37cd934e72d08e487a93fc449b and the Metrowerks CodeWarrior for DS compiler (mwccarm); neither is distributed. NitroSDK, NitroSystem, NitroDWC with the GameSpy SDK, NitroWiFi and the Metrowerks runtime (4,083 functions) are excluded, and the tools count them as not decompiled when absent. - **Prerequisites:** Python 3.11+ drives extraction, verification and linking, and ds-decomp’s dsd v0.12.1 performs the whole-program link and module comparison. Linux and macOS run the Windows compiler through wibo. The PC runtime builds as a 32-bit program with clang on Windows or gcc on Linux. - **Scope:** Covers only the Korean release (ADMK) ARM9 code. The verification page, dated 2026-10-18, reports all 25,247 game functions passing byte and relocation checks, 24,767 linked with mwldarm into modules that match the ROM, and 17 marked FAKEMATCH. Data sections mostly still come from the ROM through ds-decomp objects; the ARM7 binary, .bss pointers and source-file regrouping are not covered, and most names are placeholders. - **Testing evidence:** CI runs in a private container that holds the ROM and compiler. runtime.md reports Reference, Native and Clean runs agreeing on a 1,300-frame title recording, a 13,760-frame new-game recording and eight scenes from a save that is not in the repository, while three scenes still differ. The GitHub Actions build for the reviewed commit passed verification, linking and the Native checks but failed its Clean-function differential check. - **License:** The repository is dedicated under CC0 1.0 and states that it is not affiliated with Nintendo. The ROM, compiler, SDK libraries and test save keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### King Kong Recompiled: an AI-developed Xbox 360 static recompilation > Translates the Xbox 360 release of Peter Jackson's King Kong into native Windows code with the ReXGlue static-recompilation SDK, adding a launcher and display, control and graphics options. Project code completes streamed disc reads the way the console does, which README credits with getting past an opening freeze seen under Xenia. The author discloses that the port was made almost entirely with Claude Code, directed and tested by the repository owner. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a full disc image made from the player's own copy of that release; README gives its expected size and SHA-1, and the launcher checks the title ID before copying about 6.3 GB of game files next to the program. No game files are included, and the recompiled C++ derived from the game's code is regenerated locally and excluded from the repository. - **Prerequisites:** Playing needs 64-bit Windows 10 or 11, a DirectX 12 graphics card and about 7 GB of space. Source builds need Visual Studio 2022 Build Tools with Clang, CMake and Ninja; setup.ps1 downloads ReXGlue SDK 0.10.0 and generates the recompiled sources from the player's disc image before kk/build.bat compiles them. - **Scope:** README and .recomp.json describe a static recompilation of the USA/Europe Xbox 360 disc (title ID 555307D3, version 0.0.0.1) with ReXGlue, which credits Xenia and XenonRecomp. Release v1.9.11 ships only a Windows x64 package; Linux and Steam Deck run it through Proton experimentally, while a native Linux build and a native Vulkan/DirectX 12 renderer are described as in progress. README says a full play-through has not been confirmed. - **Testing evidence:** Reported checks are the owner's testing and developer autoplay builds that also collect shader packs; the reviewed tree has no CI workflow. Known issues include wrong character animations above 30 fps and periodic pauses in pre-rendered videos. The launcher's anonymous online-player check-in is on by default. - **License:** No license file is present, so reuse terms for the port's code are unstated; the bundled upscaler notices are MIT, and ReXGlue and other dependencies keep their own terms. Game code, assets and trademarks remain their owners', and the project disclaims affiliation with Ubisoft, Universal, Microsoft and others. The AI disclosure names Claude Code. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### splat > Binary splitter for decompilation and modding projects: a YAML config says where and how to cut an N64 ROM or PSX, PS2 or PSP binary into code, data and asset segments. A scan phase disassembles code and data, with MIPS handled by spimdisasm; a split phase writes the files and a linker script for rebuilding the input. Custom segment types can extend the pipeline. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python 3.9+; install the splat64 package with the mips extra, which the N64, PSX, PS2 and PSP platforms require. The PyPI release at review was 0.50.1, uploaded 2026-10-10; 0.50.0 introduced breaking symbol and overlay changes. The repository has no GitHub releases. - Only the n64, psx, ps2 and psp platforms are documented; the overview calls PSX and PS2 support limited, the ELF quickstart excludes relocatable ELFs, and the README points GameCube/Wii projects to decomp-toolkit. create_config generates a starting YAML from a user-supplied ROM or ELF, which must then be refined segment by segment. - MIT license. splat splits, disassembles and emits a linker script; it does not decompile to C or by itself produce a matching build, and symbol names and types come from the analyst's optional symbol_addrs file. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Mario Party 4: matching GameCube decompilation of the USA releases > Reconstructs Mario Party 4’s GameCube main executable and REL modules as C source that rebuilds both USA releases. The build analyzes the user’s own disc image and checks every linked output against version-specific SHA-1 lists. PAL and Japanese work is stale and no PC port exists yet; matching results remain project-reported here. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own disc image for a supported game ID; README lists ISO (GCM), RVZ, WIA, WBFS, CISO, NFS, GCZ and TGC containers. The repository says it contains no game assets or assembly, and each version’s config checks the original main.dol hash before analysis. - **Prerequisites:** Documented hosts are native Windows (Python and ninja), macOS (ninja and Wine Crossover) and Linux (ninja, with wibo fetched automatically on x86 or Wine elsewhere). configure.py pins decomp-toolkit, GameCube binutils, a Metrowerks CodeWarrior compiler bundle, objdiff, sjiswrap and wibo releases that the build downloads; the MusyX audio library is a pinned submodule. - **Scope:** README describes a work-in-progress decompilation whose two USA versions, GMPE01_00 (Rev 0) and GMPE01_01 (Rev 1), are completely matching; three PAL revisions and the Japanese release are unfinished and their work is stale. Most non-engine code is undocumented, and README states there is no working PC port yet. - **Testing evidence:** The default build’s check step runs decomp-toolkit SHA-1 verification over main.dol and 99 REL modules listed for the selected version; objdiff supports per-object comparison. The mutable decomp.dev page reports GMPE01_00 as 100.00% decompiled and fully linked at the reviewed commit. - **License:** The repository is dedicated under CC0 1.0; the pinned MusyX submodule carries its own MIT license, and downloaded compilers and tools keep their own terms. The disc image and game content retain separate rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### SpeedBreaker: statically recompiling Need for Speed: Most Wanted for Xbox 360 > Translates the Xbox 360 executable of Need for Speed: Most Wanted (2005) into native C++ with a patched XenonRecomp and runs it on a project runtime that stands in for the console’s kernel, Xenos GPU, XMA audio and controllers. Releases target SteamOS, Linux and Apple silicon Macs, with an experimental iPhone and iPad build, while all game data comes from the player’s own US disc. Rendering and frame-pacing improvements are project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a disc image or extracted files from the player’s own USA (NTSC-U) Xbox 360 disc; the installer verifies 49 files, and PAL, Japanese, re-release and Games on Demand copies are untested or unsupported. Source builds recompile the player’s default.xex, identified by size and SHA-256. Game files and the generated ppc/ code are git-ignored, and the README states that no game data or assets are distributed. - **Prerequisites:** Running needs a Vulkan 1.2 GPU and an AVX2 x86-64 CPU on SteamOS or Linux, macOS 15+ on Apple silicon (Metal through MoltenVK), or iOS/iPadOS 17+ on an A15-class chip. Builds use Clang 18+ with lld, CMake and Ninja (on SteamOS inside an Arch distrobox), plus setup scripts for XenonRecomp with eight project patches, extract-xiso and a decoder-only FFmpeg for XMA; SDL3 and Dear ImGui provide the platform layer and UI. - **Limits:** README describes an unofficial static recompilation of the Xbox 360 release, not an emulator, at v0.1.7 (October 2026). Windows and Android builds are announced but unavailable, there is no Intel Mac build, Xbox 360 saves cannot be imported, and the PC edition of the game is unsupported. - **Testing evidence:** Optional unit tests and instruction tests for the XenonRecomp patches need no game files, although one test needs the generated code; the instruction tests have so far run only on a Mac. Download tables list author- and player-reported devices, and several behaviors, including the IPA install and real 120 Hz displays, are marked untested. - **License:** GPL-3.0-or-later with a NOTICE file; adapted Unleashed Recompiled runtime code, XenonRecomp, Xenia-derived headers, FFmpeg and other components keep the licenses listed in THIRD_PARTY_NOTICES. The project disclaims affiliation with EA and Valve. CONTRIBUTING accepts AI-assisted changes only when the contributor has read, understood and tested them. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### The Sims: Bustin' Out: an AI-driven partial GBA matching decompilation > Rebuilds the USA/Europe Game Boy Advance release of The Sims: Bustin' Out byte for byte while gradually replacing ROM regions with matching C compiled by agbcc. The README calls it an AI-driven experiment in which almost all code, analysis and tooling are AI-generated. Most of the ROM is still copied from the user’s dump, so whole-ROM equality does not mean the game has been decompiled. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own USA/Europe revision 0 ROM (game code ASIE) matching SHA-1 fb5662172fadebf4577f6f6f163741fc041c11e6; unconverted regions in the built ROM come from that dump. A USA revision 1 dump serves only as an audit and comparison reference. ROMs, extracted assets and game binaries are not included. - **Prerequisites:** The documented build host is macOS with Python 3.10+ and Xcode’s command line tools. The pinned toolchain uses pret/agbcc as the matching C compiler, selected GCC 3.0.2 and Binutils 2.10.1 builds with host-compatibility patches, Binutils 2.43.1, Capstone, pyelftools and Pillow. The README notes that choosing these tools does not establish the original game’s toolchain. - **Scope:** The progress report at this commit (verified 18 Oct 2026) counts 2,285 matching C functions covering 288,700 bytes and 4,060 bytes of assembly glue, while 16,484,456 of the 16,777,216 ROM bytes remain unconverted. It marks the code inventory as incomplete, and the README treats function boundaries in the ROM map as provisional. - **Testing evidence:** make build fails if any byte differs, and each verified build includes changed-source negative controls that must be rejected; make test runs tests without a ROM. mGBA is listed only for optional bounded runtime observations, and no gameplay equivalence is claimed. - **License:** MIT covers the project’s own source, tools and documentation, not original game code, assets, trademarks or Nintendo’s header logo. Adapted Krawall routines (LGPL-2.1), selected GCC runtime sources (GPL-2.0 with exceptions) and Newlib string functions keep their own notices. The project accepts no contributions; the agents or models used are not named. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### m2c > Decompiler for matching projects that turns GNU as-format 32-bit MIPS, ARM, PowerPC and SuperH assembly into draft C, with partial C++ support. A target combines platform, compiler (IDO, GCC or MetroWerks CodeWarrior) and language; context files supply types, and it can infer unknown struct fields and emit global initializers. The README places it alongside splat, asm-differ and decomp-permuter, and decomp.me calls it for initial decompilations. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python 3.8+ with graphviz. Run m2c.py from a checkout or install it from the Git repository as a Python package; the package named m2c on PyPI is an unrelated project. There are no releases or tags. - Input must match the GNU as assembly format, such as spimdisasm output. The README lists the mips, mipsel, mipsee (eabi64), ppc, arm, gba (APCS) and sh2 platforms, the ido, gcc and mwcc compilers, and the c and c++ languages. Struct-field inference skips structs with bitfields or unnamed union fields, and initializers cannot be generated for bitfield structs or symbols of unknown type. - GPL-3.0-only. The README warns that output is sometimes suboptimal, especially for loops; it is a starting point to refine and check with a compiler and diff tool, not byte-identical source. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Destiny 2 build 86657: Sunrise/Dawn reconstruction research report > A dated research report on the Sunrise/Dawn reconstruction of the archived Destiny 2 build 86657 client, which emulates platform sign-on and the examined Bungie service contracts locally and adds reconstructed mission host policy. It records transport, decoding, object creation, presentation and gameplay results separately, and keeps superseded conclusions with their cited sources. It documents the case rather than shipping the runtime implementation or a recovered Bungie backend; playthroughs and native results remain project-reported. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Native work needs your own copy of the archived 86657 client and its game packages; the report neither supplies them nor explains how to obtain them. Game binaries, payloads, artwork, the manifest database, credentials, saves, raw captures, the two supplied PDFs and several referenced fixtures and traces are unpublished. - **Scope:** The reviewed edition (21 September 2026) has 20 chapters, 289 source records and hash inventories of 2,832 implementation and 336 lanes-archive files for build 86657.20.08.23.1800.d2_rc. - **Scope:** It runs as a proxy DLL inside the game process; ATTRIBUTION.md credits the separate Dawn project, building on Sunrise and Sundial. Files captured from a modified e801e23e worktree are identified by hash; checking the report needs only Python and two bundled scripts. - **Testing evidence:** Bundled checks cover report assembly, 1,191 local links, citations, evidence hashes and 37 claim references, with no game or native runtime test. Spark live testing, native-world resume and detached camera remain unverified or unimplemented, and the Eater of Worlds slice excludes the barrier and Argos fights. - **License:** No repository-wide license; ATTRIBUTION.md keeps Dawn’s GPL-3.0 text for included excerpts, claims no Bungie endorsement and relicenses no third-party material. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### SVR2011-Recomp: a ReXGlue recompilation of WWE SmackDown vs. Raw 2011 > Translates the Xbox 360 executable of WWE SmackDown vs. Raw 2011 to C++ ahead of time with ReXGlue and builds it as a Windows program on a Vulkan runtime derived from Xenia. A hand-maintained manifest adds function entry points the automatic pass misses, and project patches address frame pacing, a music-player delay and pipeline stalls. Exhibition play is author-tested on one AMD GPU; career mode and online remain untested. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The player supplies an Xbox 360 disc image of the USA/Europe release. The launcher checks all 366 files against that release, refuses other images and copies the files into gamedata once. README states that the repository contains no game code or data and that the build generates both from the user’s image; the player zip carries the built executable, ReXGlue runtime DLLs and prebuilt shaders, but no disc files. - **Prerequisites:** Play needs 64-bit Windows 10 or 11 (only Windows 11 was tested), a Vulkan GPU with a current driver and about 6 GB of space. Source builds need about 25 GB, PowerShell 7, Python 3, Git, 7-Zip and Visual Studio 2026 Build Tools with CMake, Ninja and the Windows SDK; bootstrap.ps1 downloads SHA-256-pinned ReXGlue 0.10.0 and LLVM 21.1.8. The Vulkan renderer must be selected, because the default D3D12 path hangs on the tested GPU. - **Scope:** The reviewed main branch (the v0.5.0 release commit) is a static recompilation, not a decompilation; its feasibility notes stress that translated code is not recovered developer source. The build accepts only the default.xex with SHA-256 6aead4cb…d3ebc1, and svr2011_manifest.toml seeds indirect-call targets that ReXGlue v0.10.0 misses. README reports exhibition matches, entrances, menus, backstage brawls and the Create a Superstar tools as playable; Road to WrestleMania, other create modes, Universe and online are untested and may crash. - **Testing evidence:** Testing is reported on Windows 11 with an AMD Radeon RX 7900 XT; other GPUs and Windows 10 have not been tried. Python and PowerShell tests cover disc inspection, shader-cache merging, the launcher and portable setup with a synthetic image, and dated notes record the boot and frame-time investigations. These are author reports. - **License:** The project’s own code is BSD 3-Clause; ReXGlue is used under its own license, and the project scaffold and generated/rexglue.cmake come from ReXGlue templates. The game remains with its rights holders, and README asks users not to share gamedata, assets or disc images. A docs/agents work-tracking note exists. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### decomp-toolkit > GameCube/Wii matching-decompilation toolkit that analyzes DOL and REL executables and, from a project configuration, splits them into relocatable objects plus an ldscript.lcf for CodeWarrior's linker, so decompiled objects can replace original ones while the relinked binary is checked against the original. Analysis covers function boundaries, a Metrowerks/SDK signature database, relocations, sections and data objects, and objects are written without an assembler. Its CLI also handles disc images, archives, compression formats, CodeWarrior demangling and DWARF dumps. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Distributed as a single portable binary: release v1.8.4, published 2026-09-09, provides Linux x86_64/i686/aarch64, macOS arm64/x86_64 and Windows x86_64/x86/arm64 builds. The reviewed main commit is one commit ahead of that tag, restoring a metroidbuildinfo command. Building from source needs Rust 1.85+. - dol split is intended to run inside a decompilation project's build system; the README points new projects to dtk-template for project structure and configuration documentation. Matching builds often need the original game's compiler, Metrowerks CodeWarrior on GameCube/Wii, and the generated linker script targets mwldeppc.exe. DOL/REL files and disc images must come from the user's own game copies. - Dual-licensed MIT OR Apache-2.0. It analyzes, splits and relinks binaries; it does not decompile to C, and dol diff only reports the most obvious difference in a linked ELF, so per-function matching is checked with tools such as objdiff. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Snap64 Recomp: a static-recompilation port of Pokémon Snap > Uses N64Recomp to statically recompile the US Nintendo 64 release of Pokémon Snap into a native Windows, Linux, Steam Deck and macOS port rendered with RT64. The recompiler reads a relocatable ELF linked from the matching ethteck/pokemonsnap decompilation together with the user’s ROM, and game-side patches are modified copies of decompiled functions. The author reports building the port with Claude Code; results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own US ROM matching the SHA-1 in README, the checksum the decompilation publishes; .z64, .v64 and .n64 files are accepted and a wrong file is refused. The repository and releases contain no game assets. Building also needs that ROM for the matching decompilation build, the recompiler inputs and the RSP audio-microcode translation. - **Prerequisites:** Releases need 64-bit Windows 10 (1809+) or 11 with Direct3D 12 Shader Model 6.3, Linux or Steam Deck with Vulkan 1.2 (experimental), or macOS 14+, on an SSE4.1 x86-64 CPU or the ARM builds provided. BUILDING.md records a two-machine build: WSL Ubuntu 24.04 with MIPS binutils, the decompilation, its downloaded IDO compilers and N64Recomp, then Visual Studio 2019, CMake 3.20+ and Python 3 on Windows after tools/fetch_deps.py checks out the pinned submodules. - **Scope:** The reviewed tree is version 1.1.5, published as release v1.1.5 on 2026-10-17, and targets only the US cartridge; README says the Japanese, European and Australian releases are different builds. Cartridge behavior is the default and every enhancement is opt-in. Listed known issues include some 2D elements stepping at the game’s rate at higher frame rates, estimated Snap Station printer details and lightly tested Vulkan on Windows. - **Testing evidence:** VERIFICATION.md reports a full Windows play-through, partial Steam Deck and GitHub-hosted virtual Mac runs, and 33 of 33 headless-suite checks plus 5 of 5 Snap Station checks on the author’s 1.1.5 executable from recorded replays. No physical Mac or Linux desktop report is recorded. - **License:** Port code is GPLv3, with third-party components listed in NOTICE.md. NOTICE.md says no tracked file carries ROM bytes, but the distributed executable is compiled from C that N64Recomp translates from the game’s instructions, and patches are modified decompiled functions; the game remains its owners’. The author reports writing the port with Claude Code under their direction. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Dead Rising 2: Case Zero — an Xbox 360 XBLA static recompilation port > Builds a native Windows, Linux, Steam Deck and Apple Silicon port of the XBLA game Dead Rising 2: Case Zero by statically recompiling its Xbox 360 code with patched XenonRecomp and translating its shaders with patched XenosRecomp. A purpose-built runtime supplies a Vulkan renderer, XMA audio, keyboard/mouse input and online co-op through the author’s XenonLive service. Completion and platform results are project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own XBLA package for title 58410A8D (about 825 MB, no file extension) in assets/package; the first run unpacks it and prepares the 1,367 shaders and the menu and prompt assets locally. No game data is committed or shipped: assets/ and the ppc/ C++ generated from the retail executable are gitignored, and the committed key-cap prompt chips are the project’s own art. - **Prerequisites:** Releases need a Vulkan 1.3 GPU with Windows 10+ x86-64, Linux x86-64 with glibc 2.35+, the Steam Deck archive, or macOS 13+ on Apple Silicon; Intel Macs are unsupported, and about 2 GB is needed after unpacking. Source builds need hedge-dev XenonRecomp and XenosRecomp at the base commits in patches/README.md with the 14 and 23 exported patches, a sibling XenonLive checkout at configure time, CMake and Ninja; ppc/ must first be regenerated from config/CaseZero.toml. - **Scope:** The README declares the project finished at v1.1.3 (October 2026) and completable solo and in two-player online co-op on Windows and Linux, with a raised level cap, 60 fps, a restored PC options screen and ultrawide support. The Steam Deck and macOS builds are the least tested; the macOS build can freeze after about 15 idle minutes, and streaming pop-in and sign holes remain open. The maintainer has stopped work, so issues may go unanswered. - **Testing evidence:** CI builds the host runtime on Linux and Windows and smoke-tests it against a stub image; that run succeeded for the reviewed commit. Playthroughs are maintainer reports. The patch notes say both exported patch sets reproduce the recompiler checkouts used for v1.1.3. - **License:** Project code is under PolyForm Noncommercial 1.0.0, which permits noncommercial use, modification and forks but not sale; XenonRecomp and XenosRecomp are MIT, and Capcom retains the game’s rights. THIRD_PARTY.md says UnleashedRecomp served only as a structural reference, with no GPL code copied. The development journal is committed as CLAUDE.md. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### OpenRA: an engine reimplementation reimagining early Westwood RTS games > Provides a C# engine for early Westwood real-time strategy games, with mods that reimagine Command & Conquer: Red Alert, Tiberian Dawn and Dune 2000. It loads the original games’ content through its own file-system, MiniYAML rules and Lua mission layers rather than running or recovering Westwood code. Gameplay and interface deliberately follow OpenRA’s own design, so it is not a faithful recreation of the original executables. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** INSTALL states that several files from the original game disks are needed; for Red Alert, the content manifest checks for archives such as allies.mix and conquer.mix. The content installers recognise original discs, The First Decade and the Steam or Origin editions, including the Remastered Collection, or install a minimal asset pack hosted by the project. Commit history shows that some supplementary sounds and icons under mods/*/bits came from Westwood games such as Sole Survivor, and the reviewed sources state no separate licence for them. - **Prerequisites:** Building needs the .NET 10 SDK: make on Linux and macOS, or make.ps1 and dotnet on Windows. On x86_64 Linux the build fetches prebuilt native libraries through NuGet by default; other systems use system SDL 2, FreeType, OpenAL and Lua 5.1. - **Scope:** The reviewed bleed (development) snapshot postdates release-20250330 and carries a development version placeholder. The README lists the Red Alert, Tiberian Dawn and Dune 2000 mods as reimaginings, and INSTALL calls the Tiberian Sun mod experimental. No Westwood source code is recovered or reproduced. - **Testing evidence:** CI on Linux and Windows runs code checks, the OpenRA.Test unit tests, Lua script checks and MiniYAML validation for every mod. - **License:** COPYING applies GPL-3.0-or-later to OpenRA, and AUTHORS lists bundled libraries under their own terms, such as zlib for SDL2-CS and OpenAL-CS and MIT for Eluant. The README states that EA has not endorsed and does not support the project. Original game content keeps its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Cheat Engine MCP Bridge > Connects MCP clients to Cheat Engine through a Lua bridge script and a Python MCP server, so an agent can inspect a process the user runs under Cheat Engine: memory reads and value scans, pointer-chain resolution, structure dissection, RTTI class names, disassembly, cross-references and hardware or DBVM breakpoints. Further tool groups write memory, inject DLLs or code, automate input and use Cheat Engine's kernel-mode driver. The README limits it to educational and research use and disclaims multiplayer cheating and Terms of Service violations. - Type: Integration - Targets: Binary · Game - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows with Cheat Engine; the bridge is loaded by executing MCP_Server/ce_mcp_bridge.lua from Cheat Engine, and the repository's bundled Lua reference documents Cheat Engine 7.6. The Python MCP server needs Python 3.10+, mcp>=1.28,<2 (the MCP SDK v2 API is not yet supported) and pywin32 for the native named-pipe mode, which is Windows-only. There are no GitHub releases; the README labels the code v12.0.0, and the reviewed main commit is dated 2026-08-14. - A TCP relay (ce_tcp_relay.py, default 127.0.0.1:9876) lets the MCP server run outside the Windows host. The README warns that anyone who can reach the relay can control the bridge and says to bind it to trusted interfaces only. run_command and shell_execute stay disabled in the Python MCP server unless CE_MCP_ALLOW_SHELL=1 is set at startup. - Before use, disable Settings → Extra → Query memory region routines in Cheat Engine; the README warns that leaving it enabled causes CLOCK_WATCHDOG_TIMEOUT blue screens with DBVM or anti-cheat software. DBVM tools need DBVM enabled, and kernel-mode tools rely on Cheat Engine's DBK driver. - Memory-write, allocation, injection, process-creation, window-message and key-press tools change the target or the desktop session. MIT. The project's test script needs a live Cheat Engine session. ##### Primary sources 1. 2. 3. 4. 5. #### Dead Rising 2: Case West — a sibling Xbox 360 XBLA static recompilation port > Builds a native Windows, Linux, Steam Deck and Apple Silicon port of the XBLA epilogue Dead Rising 2: Case West by statically recompiling its Xbox 360 code with patched XenonRecomp and translating its shaders with patched XenosRecomp. It shares most of its runtime with the author’s separate Case Zero port, executing the console GPU command stream on Vulkan with XMA audio and keyboard/mouse input. Completion and platform results are project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own XBLA package for title 58410B00 (about 1.2 GB, no file extension) in assets/package; the first run unpacks it and prepares the 1,322 shaders and the keyboard prompt art locally. No game data is committed or shipped: assets/ and the ppc/ C++ generated from the retail executable are gitignored, and the committed key-cap chips are the project’s own art. - **Prerequisites:** Releases need a Vulkan 1.3 GPU with Windows 10+ x86-64, Linux x86-64 with glibc 2.35+, the Steam Deck archive, or macOS 13+ on Apple Silicon; Intel Macs are unsupported, and about 3 GB is needed after unpacking. Source builds apply the two combined patches in tools/ci to hedge-dev XenonRecomp and XenosRecomp at the base commits pinned in the CI workflow, need a sibling XenonLive checkout, CMake and Ninja, and first regenerate ppc/ from config/CaseWest.toml. - **Scope:** The README declares v1.1.2 (October 2026) the final build: single-player is completable start to finish, and two-player online co-op works only when started from the XenonLive launcher. It reports 58,345 recompiled PowerPC functions, 60 fps, an in-game graphics menu and ultrawide and 16:10 support. Shading differences and an AMD-only black square remain known issues, and the Steam Deck build has not been tested on Deck hardware. - **Testing evidence:** CI is meant to build the host runtime on Linux and Windows against a stub ppc/ tree, but its run for the reviewed commit skipped both build jobs because the XenonLive deploy key was unavailable. Playthroughs and fixes imported from Case Zero are the maintainer’s reports. - **License:** Project code is under PolyForm Noncommercial 1.0.0, which permits noncommercial use, modification and forks but not sale; XenonRecomp and XenosRecomp are MIT, and Capcom retains the game’s rights. THIRD_PARTY.md was copied from the Case Zero port and says no UnleashedRecomp GPL code is used. The development journal is committed as CLAUDE.md. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### The Simpsons Wrestling Recompiled: a psxrecomp PlayStation static recompilation > Translates the PlayStation game’s MIPS code to C with a pinned psxrecomp fork and builds Windows and Linux programs on its hardware-modelling runtime, with a launcher and a game-specific plugin. Without patching game code, the plugin adds 16:9 matches, 60 FPS by raising the emulated CPU clock and rescaling movement, intro skipping and unlocks. The user’s own NTSC-U disc image is required, and the measurements are author-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The user supplies The Simpsons Wrestling (PlayStation, North America, SLUS-01227) as a .cue with its .bin. game.toml records the expected data-track size and hashes; the launcher checks the disc before play and reads it in place. Building also needs that disc to generate the C code. README states that the repository holds no game code and that the download contains no game files. - **Prerequisites:** Play needs 64-bit Windows 10/11 or 64-bit Linux with glibc 2.38, plus OpenGL 3.3. Windows builds use Visual Studio 2022 Build Tools, CMake, Ninja and the bundled clang-cl with ThinLTO and a committed PGO profile; Linux builds use gcc with X11, Wayland, GL, ALSA, PulseAudio and udev development packages. The launcher is a separate SDL2 program from the TRG Launcher submodule, while the runtime uses SDL3. - **Scope:** The reviewed master branch (VERSION 1.0.0, matching the v1.0.0 release) is a static recompilation, not a decompilation: psxrecomp translates SLUS_012.27’s R3000A code into a local generated/ tree using Ghidra-derived function seeds. psxrecomp is a pinned submodule from TekRantGaming’s fork of RetroPortingToolKit/psxrecomp, whose README describes a hardware-accurate runtime with bundled OpenBIOS as the default, so a retail BIOS is not normally required. Known issues include misplaced widescreen pause-screen HUD elements and uneven experimental 120 FPS. - **Testing evidence:** TECHNICAL.md reports attract-demo matches in two arenas at 1.00x speed and a steady 60 FPS on one Ryzen 7 7800X3D/RTX 4070 Ti PC, plus jump-height and walking-distance comparisons with stock timing. Linux was checked only under WSL2; the AppImage is untested on native Linux and Steam Deck. These are author measurements. - **License:** GitHub detects no license and the reviewed tree has no LICENSE file, so reuse terms for the project’s own code are not stated; the pinned psxrecomp fork carries the PolyForm Noncommercial 1.0.0 license. The game and its trademarks remain with Fox Interactive, Activision and the other named owners. README discloses that the port was made almost entirely with Claude Code under the owner’s direction. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### OpenRCT2: an open re-implementation of RollerCoaster Tycoon 2 > Re-implements RollerCoaster Tycoon 2, originally written in x86 assembly, as a C++ engine that runs on the original game’s data. It loads RCT2 saves and scenarios, and RCT1 scenarios when those files are present, while saving to its own documented park format. Modern-platform support, interface and AI changes, higher limits and multiplayer are deliberate extensions, not reproductions of the original. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Playing requires the user’s own RollerCoaster Tycoon 2 files; the README names Steam and GOG.com editions. Original RollerCoaster Tycoon files are optional and enable its scenarios. By default, installation downloads OpenRCT2’s own objects, title sequences, OpenSoundEffects and OpenMusic packs, and test builds also fetch replays, each pinned by SHA-256. - **Prerequisites:** Source builds use CMake 3.24+ and a C++20 compiler, with wiki guides for Linux, macOS, Windows, WSL and MSYS2 MinGW and an option to force 32-bit builds. Portable builds, installers, a launcher and several Linux and BSD packages are listed for players. - **Scope:** The reviewed develop snapshot follows the v0.5.6 release of 2026-10-10. The README says OpenRCT2 attempts to provide everything from RCT2 plus many improvements, and restores some RollerCoaster Tycoon mechanics, so intentional differences are part of the design. No original source is recovered. - **Testing evidence:** CI checks formatting, builds on several platforms and runs the GoogleTest suite, including replay, RCT2 save import/export, ride-rating, pathfinding and scenario-decryption tests on project test data. These guard OpenRCT2’s own behaviour and file compatibility. - **License:** licence.txt applies GPL-3.0-or-later to OpenRCT2; original game data and purchased editions keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Touhou 6: reconstructing Embodiment of Scarlet Devil 1.02h source > Reconstructs C++ source for the Windows executable of Touhou 6: Embodiment of Scarlet Devil version 1.02h, aiming at an exact rebuild with the original Visual Studio .NET 2002 and DirectX 8 toolchain. reccmp and objdiff compare the rebuilt binary with the user’s original executable function by function. The committed progress badge reports every function implemented but 98.03% byte accuracy, so whole-binary identity is not claimed. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own original 東方紅魔郷.exe version 1.02h matching the SHA-256 in README, copied to resources/th06.exe; reccmp checks the same hash, and the build extracts the game icon from that file. The repository contains no game executable or data; the comparison workflow fetches the original binary from a secret-configured URL. - **Prerequisites:** Builds need Python 3.4+, plus msiextract and Wine outside Windows (CrossOver is suggested on macOS); aria2c is optional. scripts/create_devenv.py downloads Visual Studio .NET 2002 and the DirectX 8.0 SDK from web archives, along with ninja, objdiff, Ghidra and helper tools, and scripts/build.py generates and runs a ninja build. - **Scope:** README states the aim of perfectly reconstructing the 1.02h source; the committed, mutable progress badge reports 100.0% implemented and 98.03% byte accuracy for TH06.EXE. README points to a separate portable branch for Linux and modern Windows. The team’s Ghidra work is exported as XML to the companion happyhavoc/th06-re repository. - **Testing evidence:** Contributors diff with reccmp, which reports per-function accuracy of the rebuilt executable against the original as an HTML report. CI builds on Windows and compares an objdiff build with objects delinked from the original through Ghidra; a small munit suite reads the user’s game archive. Badge figures are project-generated. - **License:** The repository is dedicated under CC0 1.0; the original game, the downloaded Microsoft toolchain and third-party tools keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Driver Recompiled: a psxrecomp setup host that builds the game locally > Packages a psxrecomp static-recompilation project for Driver (PlayStation, USA) as a setup host: releases carry the recompiler, runtime and a recomp-ui launcher, and the player’s machine generates and compiles the game from the user’s own disc image. The repository holds configuration, Ghidra-derived function seeds and release automation rather than game code. Its documented status is thin: an operator-confirmed private build reaches gameplay, while package release gates remain open. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The player supplies an owned disc image of Driver (USA, SLUS-00842); game.toml records the expected data-track size and hashes. Release CI packages a setup host without game C, BIOS backends, disc images or a prebuilt playable executable. The workflow says users generate OpenBIOS, with a retail BIOS optional, while FEASIBILITY.md mentions the player supplying a BIOS; generated code and the executable stay on the user’s machine. - **Prerequisites:** v0.3.6 publishes packages for Windows x64, Linux x64, macOS Apple Silicon and macOS Intel, but the documentation keeps each platform claim pending exact-package setup, startup and clean-exit gates; the README describes 0.3.0 as Windows x64 only. Local builds use the psxrecomp CLI, CMake, Ninja, Python and C/C++ toolchains, with Windows on the framework’s portable toolchain route. - **Scope:** The reviewed main branch (VERSION 0.3.6) targets only the USA release SLUS-00842 and pins Alexbeav’s psxrecomp fork at 08ec704a and recomp-ui at be8ac1d0. FEASIBILITY.md records the status bootstrap_verified: the operator confirmed that a private promoted build reaches gameplay. No mode or feature coverage is documented, and the README notes that public v0.3.0 can relaunch the wrong executable after its first build. - **Testing evidence:** Reported checks are setup executable-name and source-parity tests and YAML and release-workflow audits. The README also describes boot gates and A/B comparisons against Beetle and DuckStation across the author’s ports, but the reviewed tree publishes no comparison results for this title. These are project reports. - **License:** Project-owned files are GPL-3.0-only; psxrecomp keeps PolyForm Noncommercial 1.0.0 and recomp-ui MIT, and the GPL does not cover retail content or generated retail code. The README says the ports are developed with substantial AI assistance, with AI writing most of the code. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Himuro: a matching Fatal Frame PS2 decompilation > Reconstructs Fatal Frame’s PS2 executable as C for the US, EU and Japanese releases, built with the original EE-GCC 2.9 toolchain and checked by SHA-1 against the user’s own executables. Committed objdiff reports list the US and EU code as fully matched and the Japanese code as partial, and a few routines still rely on assembly or byte patches. Porting to modern hardware is a stated later goal, not part of this repository. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Copy the matching main executable from your own disc or ISO into config//; the README gives the required SHA-1 for each region. Data extraction, splitting and the expected assembly are generated locally, and no game assets are committed. - **Prerequisites:** Linux is required: Python 3.8+ in a virtual environment, make, i386 libc/libstdc++ for the committed 32-bit EE-GCC 2.9-991111-01 compiler, and the decompals PS2 binutils v0.10 installed separately; objdiff-cli is also committed. Each region is extracted, configured and built separately. - **Scope:** Covers SLUS_203.88 (US), SLES_508.21 (EU) and SLPS_250.74 (JP); the output is a rebuilt PS2 ELF, not a PC port, which the README names only as a later goal. After the project’s own report-adjustment script, the committed objdiff reports list 3,437 of 3,437 US and 3,464 of 3,464 EU functions with all code and data matched, but 2,712 of 3,394 JP functions (73.64% of code). The README’s decomp.dev badges are mutable. - **Testing evidence:** The ninja build runs sha1sum against config//checksum.sha1, so a successful build reproduces the supplied executable. To reach that hash, the build rewrites selected compiler output from asm_patches.json and copies listed byte ranges from the original executable into the built file (PhotoScoreCount in US and EU, DspSpData in EU). CI only uploads the committed reports and cannot build without the executables. - **License:** MIT license for the project; Fatal Frame and its executables retain separate rights, and the committed compiler binaries keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### DOAXVB Native PC Port: statically recompiling Dead or Alive Xtreme Beach Volleyball > Lifts the original Xbox executable of Dead or Alive Xtreme Beach Volleyball to C with a fork of xboxrecomp and links it with a hand-written runtime that replaces kernel imports, audio and key Direct3D 8 and DirectSound APIs. Setup builds the runner locally from the user’s USA disc image and checks generated files against hashes in an authenticated recipe; releases carry only tools and source. Rewriting game logic as readable source has so far reached only the startup thread entry. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own USA Xbox disc image; setup extracts it, checks the XBE and stops if any recipe input or generated file differs from the recorded hashes. Generated game C, extracted files, saves and run evidence stay in an ignored private folder, and NOTICE states that the repository distributes no game, generated game code, assets or console firmware. - **Prerequisites:** Windows release setup bundles Python, Capstone, Git, CMake and extract-xiso and downloads a pinned llvm-mingw clang release. macOS and Linux/SteamOS builds need CMake, Ninja, SDL3, Python with Capstone 5.0.9 and a self-built extract-xiso, with Vulkan through SDL3 and shaderc on Linux. The lifter is a pinned branch of NoRain211’s fork of sp00nznet/xboxrecomp. - **Scope:** The README calls the port fully playable as of 0.4 Beta: long player sessions covered every stage, the Casino, Hotel and Shops, saving and reloading, and a vacation’s end, the last starting from an edited save. Lighting, camera and full rendering fidelity remain incomplete, three known issues are open, and the 0.6.0 RC1 prerelease has had only macOS and Steam Deck smoke runs. Hand-written game logic covers only the startup thread entry. - **Testing evidence:** Public CI checks the recipe, setup and ISO-extraction scripts with synthetic inputs and builds and runs the runtime tests on Windows without game files. The status page states that these tests do not show the game boots or plays; playability rests on owner and contributor sessions, and PlayStation pads are unconfirmed on hardware. - **License:** Original code is GPL-3.0-or-later, and NOTICE grants no rights to the game; xboxrecomp is MIT and other components keep their own licenses. The README and NOTICE state substantial use of LLMs and AI coding agents for code, reverse-engineering analysis, debugging, tests and documentation, with changes reviewed and tested. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### ido-static-recomp > Statically recompiles the IRIX MIPS programs of SGI's IDO 5.3 and 7.1 C toolchain, such as cc, cfe, uopt, ugen and as1, into native Linux, macOS and Windows executables, so matching decompilation projects can build with the original compiler code on modern hosts. It recompiles compilers, not games: it neither decompiles nor translates game code. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building needs make and a C11/C++17 compiler (build-essential on Debian/Ubuntu, Homebrew make on macOS). make setup builds the vendored rabbitizer disassembler and the recompiler; make VERSION=5.3 or VERSION=7.1 then emits the toolchain under build//out, with RELEASE=1 for optimized builds and TARGET=universal for universal macOS binaries. Release v1.2 (2024-11-12) ships IDO 5.3 and 7.1 archives for Linux, Linux ARM, macOS and Windows; the reviewed main commit dates from 2025-07-05. - Recompiled programs expect a flattened directory beside cc, with USR_LIB and USR_INCLUDE environment overrides for the /usr/lib and /usr/include redirection. The IDO 5.3 program list includes copt, ld and strip, which the 7.1 list lacks. - Perfect Dark pins github.com/Emill/ido-static-recomp at 421e546 (per-function branch, 2021-11-03) as its tools/recomp submodule. GitHub compares that commit with this entry's pin as diverged, 87 commits ahead and 2 behind, and Emill is among the decompals contributors; neither repository is marked as a fork. Other matching decompilations, such as Majora's Mask, download builds from decompals. - The repository bundles the original IRIX compiler binaries under ido/5.3 and ido/7.1. Only ido/5.3 carries an SGI freeware notice; no license file covers the recompiler or the IDO 7.1 binaries at the reviewed commit, GitHub detects no repository license, and the vendored rabbitizer keeps its own MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### TH08 Web: a WebAssembly port built from reconstructed source > Compiles the reconstructed C++ source of the Japanese Touhou 8 1.00d release to WebAssembly with Emscripten, adding WebGL 2 rendering, Web Audio, browser input and IndexedDB saves behind the game’s D3D8-, DirectSound- and DirectInput-shaped interfaces. Players select their own retail DAT files locally. The web build makes no binary-exact claim and is a separate port from the curated TH08 reconstruction. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** README reports the game playable from title to ending in desktop browsers and recommends current Chrome; Firefox automatically uses a dedicated no-readback build, while Safari and mobile browsers are not verified. The page needs WebAssembly threads, SharedArrayBuffer, WebGL 2, Web Audio and cross-origin-isolated HTTPS. Listed remaining work includes Firefox hardware profiling, replay endurance and memory-ceiling measurement. - **Prerequisites:** Select th08.dat and thbgm.dat from your own legally obtained TH08 installation. The launcher copies th08.dat into session memory and range-reads thbgm.dat; README says neither is uploaded, bundled or persisted. The repository, deployment and release v0.1.0 contain no retail data or executable, and a provenance script rejects forbidden payloads and any artifact outside the nine-file allowlist. - **Prerequisites:** Local builds need Docker, Python 3 and a desktop browser: scripts/build-web-game.sh uses a digest-pinned Emscripten 6.0.8 image, and scripts/serve-web.py supplies the COOP, COEP and CORP headers a generic static server lacks. The public site is a Cloudflare Pages deployment from main, and self-hosting the release archive needs the same isolation headers. - **Testing evidence:** WEB_ARCHITECTURE.md records author-run checks with user-selected retail files: a complete Lunatic Final-B route in Chromium and on an earlier Firefox bridge, a Stage 6B practice run, persistence tests showing no DAT in IndexedDB, and replay-driven pacing samples near 60 Hz under the SwiftShader and llvmpipe software renderers. - **License:** MIT covers repository code and documentation, not the original game, DAT files, music or graphics; the pinned Detours submodule keeps its own terms. README describes this repository as the web-focused fork of N0zoM1z0/th08 with its history retained. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### OpenXcom: an open-source clone of X-COM: UFO Defense and Terror from the Deep > Reimplements MicroProse’s UFO: Enemy Unknown (X-COM: UFO Defense) and X-COM: Terror from the Deep as a C++/SDL engine that runs on the user’s original game resources. Game data such as items, craft, research and missions is expressed in YAML rulesets, which also carry its standard mods and a wider modding ecosystem. It is a clone that reuses original content, not recovered MicroProse code. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an unmodified copy of the resources from either or both original games. For UFO these include the GEODATA, GEOGRAPH, MAPS, ROUTES, SOUND, TERRAIN, UFOGRAPH and UNITS folders, and TFTD needs a similar set. The README warns against modded copies such as XcomUtil-patched data; the Windows installer can detect Steam editions. - **Prerequisites:** Building targets C++11 with CMake 3.5+, Visual C++, Xcode or a plain Makefile, against SDL 1.2, SDL_mixer, SDL_gfx 2.0.22+, SDL_image and yaml-cpp 0.5.3+. CI compiles debug builds on Linux, 32-bit Windows and macOS. - **Scope:** The reviewed master snapshot reports version 1.0 Dev; the last tagged release is v1.0 from 2014, and a nightly workflow builds later Windows, Linux and macOS versions. It covers both games and can import saved games from the originals, while standard mods based on XcomUtil and UFOExtender add optional changes. - **Testing evidence:** CI only compiles the code, and the repository has no automated behaviour tests. - **License:** Source headers apply GPL-3.0-or-later, and the README notes modified SDL_gfx code (LGPL) used with its author’s permission. Original game resources keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Skate 3 Recomp: a native Xbox 360 recompilation through ReXGlue > Recompiles the Xbox 360 version of Skate 3 into native Windows, Linux and macOS builds with a Skate-specific fork of the ReXGlue SDK. Since v2.0.0 a native Direct3D 12 and Vulkan renderer with ports of the game’s own material shading replaces emulation of the Xbox 360 GPU, which remains as a fallback. Game files come from the user’s disc image; the author calls the native renderer early and has not tested the game end to end. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Players choose an ISO of their own Xbox 360 copy of Skate 3 for the built-in installer, and DLC needs the user’s own package files. Source codegen reads default.xex and data/webkit/EAWebkit.xex from an extracted dump and should also be given the Title Update 3 package, whose patched executables release builds require. Retail files and generated recompilation sources are git-ignored. - **Prerequisites:** Builds need CMake 3.25+, Ninja and Clang 18 or newer (Clang 20 is recommended on Ubuntu 24.04); MSVC and Apple Clang are unsupported. The pinned rexglue-sdk submodule is the author’s fork on the rexglue 0.8.0 line, holding the runtime, codegen, input, timing and both graphics backends. Vulkan SPIR-V shader binaries are committed, and macOS uses Homebrew LLVM with MoltenVK. - **Scope:** The latest reviewed release is v2.0.2 (July 2026) for Windows, Linux and experimental Apple-silicon macOS; the README calls Windows the most tested platform. Known native-renderer issues include streaming pop-in, skater-customization rendering, Hall of Meat highlights and skate-park parity; frame-rate and power gains over the emulated renderer are author-reported. - **Testing evidence:** The reviewed tree contains no CI workflow, test suite or fidelity comparison, and the README says the game has not been played through on the native renderer. Visual-parity statements are project claims. - **License:** Neither the repository nor its GitHub metadata declares a license for the project’s code; the rexglue fork carries a Xenia-derived BSD-3-Clause notice, and Skate 3 content retains Electronic Arts’ rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Uncharted: The Nathan Drake Collection native Windows port > Runs the PS4 Uncharted: The Nathan Drake Collection’s own x86-64 executables natively on Windows: a runtime supplies the PS4 system libraries and a shadPS4-derived Vulkan renderer executes the GPU work. The port adds a per-game launcher, resolution patches and modern upscaling, and its status table reports all three games playable with listed open issues. It is a compatibility-runtime port rather than a decompilation, and its results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own dumped copy of the PS4 game CUSA02344, the folder holding eboot.bin and sce_sys; game update 1.02 is optional and recommended. README says no game files are in the repository or its builds, and the preparation script patches the game executables locally for resolution and update handling. The project disclaims affiliation with Sony, Naughty Dog and Bluepoint Games, and the games keep their own rights. - **Prerequisites:** Play needs 64-bit Windows 10 or 11, a CPU with AVX, F16C, BMI1, MOVBE and LZCNT (Intel Haswell or newer, or any AMD Ryzen), a Vulkan 1.3 GPU and about 6 GB of free RAM, with 16 GB recommended. Local builds use an MSYS2 CLANG64 toolchain with CMake, Ninja, the Vulkan stack, SDL3, FFmpeg, Boost and other listed packages, plus a Windows Python 3.10+ with Pillow for packaging. GitHub Actions builds the Windows package on each push, and the launcher’s updater checks release SHA-256 digests. - **Scope:** Reviewed at the commit of release v0.2.3 (2026-10-18); v0.1.0 was published on 2026-10-15. README reports Drake’s Fortune, Among Thieves and Drake’s Deception playable, with the Collection menu, game switching, saves, audio, movies and controllers working. Known issues include a Drake’s Fortune grenade-launcher fault, cropped ultrawide views, single-core GPU-command limits on slower CPUs, experimental multithreaded rendering and less play-testing for Uncharted 3. The original game code is run with local patches, not rebuilt from recovered source. - **Testing evidence:** STATUS.md records native runtime tests for fibers, services, video decoding, buffered input and clock timing, with the cause and user confirmation of individual fixes. README frame rates come from the author’s RTX 5080 and integrated Radeon tests plus one player report. The CI workflow builds and publishes packages without automated game tests. - **License:** README declares GPL v2 or later. The runtime started from FelipePrado0’s GPL-2.0 gow3_pc and the shadPS4 video core, and the TAA camera approach credits SuperMedo’s GPL v2 Uncharted port. Packages bundle third-party libraries; NVIDIA’s DLSS DLL, fetched by a build script from NVIDIA’s DLSS repository, stays under NVIDIA’s license. STATUS.md mentions REA as unable to decompile the prepared ELF on Windows. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### TH095: function-level reconstruction of Shoot the Bullet 1.02a > Reconstructs source for the original Japanese Touhou 9.5: Shoot the Bullet 1.02a executable, accepting function exactness only through reproducible byte comparison of pinned Visual C++ .NET 2003 builds against one hash-attested target. The whole program also compiles and links into a playable Windows i386 executable, while README keeps playability, function matching and whole-executable identity as separate statuses. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own original Japanese 1.02a th095.exe matching the size, SHA-256 and MD5 in README, imported as resources/th095.exe; playing also needs the game’s data. README says copyrighted executables, game data and private analysis databases are not included, and public CI runs only target-independent checks. - **Prerequisites:** scripts/bootstrap-tools.sh needs curl, git, sha256sum, tar, unzip, uv and Wine, then fetches checksum-pinned Ghidra 12.1.3, Temurin JDK 21, objdiff 3.8.0 and Microsoft Visual C++ .NET 2003 (13.10.3077) binaries from a third-party archive repository; reccmp 0.1.6 is also pinned. scripts/build-whole.py cold-compiles and links the production graph and refuses stubbed or force-linked images. - **Testing evidence:** Generated PROGRESS.md reports 697 confirmed authored functions among 1,880 candidates, all with source, and 696 canonically exact, covering 99.22% of confirmed authored bytes; Controller::GetInput keeps one differing byte. README lists semantic reconstruction as active and Windows x86-64, Linux and Web ports as planned, and tags the playable baseline v0.1.0-windows-i386 without release binaries. - **Testing evidence:** Exact credit requires a zero-difference COFF function comparison recorded in the match ledgers; Ghidra, IDA MCP and runtime observation count only as supporting evidence. README cites a full-game runtime video using a test-only no-death launcher plus separate normal-build tests, and RUNTIME_ISSUES.md notes those checks used 2026-09-10 source, with later semantic changes only compile- and link-validated. - **License:** MIT covers repository code and documentation, not the game or its assets; the downloaded compiler and tools keep their own terms. The repository carries coding-agent rules and skills and a GPT web Ghidra bridge; REA’s separately published Touhou essay discusses this project. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### PS2Recomp > Experimental static recompiler that translates MIPS R5900 code from PlayStation 2 ELF executables into C++ and links it with a bundled runtime. ps2xAnalyzer or a Ghidra export script produces a per-game TOML of functions, stubs, skips and instruction patches; ps2xRecomp emits a literal instruction-by-instruction translation; ps2xRuntime and ps2xIOP supply guest memory, syscall dispatch, IOP module execution with HLE fallbacks and partial, largely stubbed GS/VU hardware. Output is not decompiled source, and getting a game to run remains per-game porting work. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building needs CMake 3.20+ and a C++20 compiler; the README says it is tested mainly with MSVC, and some vector paths need SSE4/AVX host support. CMake fetches ELFIO, toml11, fmt, libdwarf and raylib at configure time, plus Dear ImGui when the debug UI is enabled. GitHub lists five source-only prereleases, v0.0 to v0.4 (the latest from 2026-04-05), with no binaries attached; the reviewed main commit (2026-10-14) is 36 commits after v0.4. - The user supplies the game ELF; the project ships no game code, and its project-description guidance names the original release as one the user must own. The preferred workflow exports functions from Ghidra with the bundled ExportPS2Functions.java script, while ps2_analyzer suits ELFs with debug symbols. Stub address bindings and game overrides target one exact ELF build and are not portable across games, regions or builds. - The README lists very poor VU and GS performance and partial, often stubbed hardware emulation as limitations. The tree also holds Android and PS Vita build directories and a ps2xStudio front end. - GPL-3.0; fetched dependencies keep their own licenses, and the README cites PCSX2 as a runtime reference. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### CorsixTH: an open reimplementation of Theme Hospital > Reimplements the engine of Bullfrog’s 1997 Theme Hospital, with game logic in Lua and C++ for graphics, sound, movies and pathfinding, on top of the original game’s data files. The README reports that the full campaign can be completed, lists features that are still missing, and adds extensions such as high resolutions and a map editor. It recreates the game’s behaviour on original content rather than recovering Bullfrog source code. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs the user’s Theme Hospital data from the original CD, the GOG.com or EA editions, or the Theme Hospital demo, including the resource folder with ANIMS and LEVELS (sometimes named HOSP). The original graphics lack complete sets for some patient types, so enabling their regular spawning may cause anomalies. - **Prerequisites:** Source builds use CMake 3.16+ with a C++17 compiler, SDL3, SDL3_mixer, Lua (or optionally LuaJIT) and zlib; FFmpeg enables in-game movies, and vcpkg manages dependencies for preset builds. The README lists builds for Windows and macOS, a Linux AppImage, Flatpak and Snap, and distribution packages for Linux and BSD. - **Limits:** The reviewed master snapshot follows the v0.70.1 release of 2026-08-28. The README lists multiplayer/LAN, AI hospitals, rats and the bonus rat level, vomit waves and the win-level video or letter as missing, and warns that some objects may glitch with walls. Custom campaigns, 4K support, the level editor and improved game logic are deliberate extensions. - **Testing evidence:** CI runs luacheck and busted Lua unit tests on Linux, plus CMake builds with CTest on Windows. - **License:** LICENSE.txt grants MIT terms for CorsixTH and includes notices for bundled components such as Lua 5.5, LPeg and LuaFileSystem, so GitHub does not classify it as one licence. Original Theme Hospital data keeps its own rights. AGENTS.md gives instructions for AI coding agents. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### OpenRiseOfNations: a native macOS engine reimplementation > Reimplements the Rise of Nations: Extended Edition engine as a native macOS app with a Metal renderer, a deterministic simulation, a computer opponent and a compatible BigHugeScript compiler and virtual machine, loading art, maps, rules and scripts from the user’s own Windows installation. Subsystem specifications written from Ghidra study of the symbol-bearing executable, together with JavaScript reference tools, guided a C++17 implementation built with heavy Claude Code assistance. The alpha plays tutorials and scenarios, and its bit-exactness checks remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Users must own Rise of Nations: Extended Edition and supply the Windows version’s game folder, whose Data and scenario directories provide the art, maps, rules, scripts and audio; README names SteamCMD or a copy from a Windows PC as routes. The repository and the un-notarised DMG ship no game files or original program code, with a fan-adapted main-menu logo as the stated exception. Building from source needs only Apple’s Command Line Tools and build-mac.sh. - **Scope:** The reviewed pin is version 0.1.1; releases v0.1.0 and v0.1.1 are dated 2026-10-14. README calls the C++17 engine early but playable on macOS 12+ with Metal and AppKit, covering tutorials and stock scenarios, unit control, economy, construction, combat, a computer opponent and the game’s scripts. Random maps and the skirmish setup screen, the Conquer the World campaign, multiplayer, saves and replays, garrisons, heroes and several other systems are not yet implemented. - **Attribution:** README says the executable ships with full debug symbols, which enabled Ghidra study; about thirty specifications in docs/ describe each subsystem in paraphrase, citing original functions by name and address, and JavaScript reference tools in re/tools read the game data. README credits heavy use of Claude Code, directed and reviewed by the maintainer. STATUS.md says the reverse engineering ran as background agents that each produced a spec, while the author’s reply says he reverse-engineered in Ghidra and wrote the specs himself. - **Testing evidence:** Verification is project-reported. C++ checkers compare damage on all 169,312 attacker/target pairs, prices, income and interface layouts with the reference tools, rules tables with a recorded game’s memory image and world grids across 156 stock scenarios, and a headless harness checks determinism. The simulation targets bit-identical lockstep behavior but has not yet been compared with recorded games, and rendering was checked by reading snapshots. - **License:** The engine is GPL-3.0; the menu logo is excluded, and its rights stay with the original owners. The project states that it is unaffiliated with Microsoft, Big Huge Games and SkyBox Labs. .gitignore keeps decompiler output, symbol dumps and extracted data out of the repository, although two small instruction-search outputs listing original addresses are committed under re/jobs. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### TH04: rebuilding Lotus Land Story’s four PC-98 programs from source > Reconstructs source for the Japanese PC-98 Touhou 4: Lotus Land Story and rebuilds all four DOS programs, MAIN.EXE, OP.EXE, MAINE.EXE and ZUN.COM, with a pinned Borland toolchain under Wine. Function acceptance against the original binaries is tracked separately from emulator replays that compare inputs, RNG, object pools and video with the original game. Complete-campaign, original-timing and byte-identity goals remain open. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own legal copy containing the Japanese zun.hdi; the importer requires OP.EXE, MAIN.EXE, MAINE.EXE and ZUN.COM matching the sizes and SHA-256 values in README, whose provenance is marked candidate-local-attested pending an independent pristine dump. Image preparation modifies a disposable copy of that image, and original executables and assets are never committed. - **Prerequisites:** Builds use Turbo C++ 4.0J, TASM 5.0 and TLINK under Wine; the bootstrapper fetches them from third-party mirrors that TOOLCHAIN.md does not treat as authoritative, and takes MS-DOS Player from a pinned ReC98 checkout. The tested host is Debian 12 x86-64 with Python 3.11. Runtime checks also need DOSBox-X 2024.03.01, Xvfb, xdotool and ImageMagick, and the Windows build entry point uses a WSL toolchain bridge. - **Testing evidence:** Generated PROGRESS.md reports 661 of 663 reviewed authored functions exact across the four artifacts and 99.97% of confirmed MAIN authored bytes, with two MAIN cases deferred. README says the rebuilt products need not reproduce the original executable bytes and that complete-game and original-timing acceptance are unfinished. A 64-bit native port on the port/modern-64 branch is reported with scoped Linux clears. - **Testing evidence:** README reports original-versus-reconstructed DOS replays agreeing on consumed input, score, RNG, nine actor pools, 22 state blocks and configured video regions across the four bundled demos and longer Stage 1–3 routes, while raw GDC timing and some post-reset input samples still differ. A 2026-10-16 audit found frozen native programs and candidate MAIN files missing from local storage, so historical replay first needs recovery. Public CI runs target-independent checks only. - **License:** MIT covers repository-authored code and documentation, not the game, its assets or third-party work; ReC98, credited as a migration input, has no license file at the pinned revision, and the Borland tools stay proprietary. The repository is organized around coding-agent handoffs; REA’s TH04 helper showcase and Touhou essay cover parts of it. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Xenosaga I Decomp Compatibility Kit > Checks a PS2 matching decompilation from outside its own build: the C is recompiled with a stock, unpatched ee-gcc 2.96 and assembler, then each function is byte-compared against the original and every difference is classified by its likely toolchain cause. Companion scripts export ELF symbol tables to CSV and convert them to splat symbol files. Defaults target Xenosaga Episode I; the README says the method generalises but the defaults do not. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed commit d9bb53d is the second of two commits, both made on 2026-09-25; there are no releases or tests. It holds three Python tools and symbol data for the NTSC-U Xenosaga Episode I executable SLUS_204.69 and its five overlays, built with SCE ee-gcc 2.96. Tool docstrings still refer to out/ paths and a TOOLCHAIN.md that are not in the repository. - verify_decomp.py needs a checkout of the decompilation under test, your own SLUS_204.69 and extracted originals (located through DECOMP_GAME_DIR), and an i386 root filesystem with stock ee-gcc 2.96 and ee-as run through Docker under linux/386 emulation, plus clang for preprocessing. The README points to decompme/compilers for the compiler, which is not vendored, and documents a colima and binfmt route for Apple-silicon Macs. - It compiles each C translation unit with -DSKIP_ASM, compares every defined function against the original bytes, labels differences hazard-nop, reorder, mixed, immediate or unexplained, and exits nonzero only for unexplained ones. The README warns that the mixed class masks branch and call targets, so a wrong target there is not flagged; functions whose relocations need the tested project's data layout are reported as unverifiable. - The README's case study against an anonymised PS2 matching decompilation reports 817 of 857 functions identical, 40 differences all in toolchain classes, 195 unverifiable and one compiler crash. It also reports 5,927 shared names with no address disagreements against another decompilation's symbol file. Neither result is published with its inputs. - MIT-licensed. The repository includes a 15,132-entry symbol table that its README says comes from the unstripped retail executables, but no game binaries, extracted assets or decompiled game code; the game remains its rights holders' property. ##### Primary sources 1. 2. 3. 4. 5. 6. #### inFAMOUS Second Son native PC port > Runs the PS4 inFAMOUS Second Son’s own x86-64 code natively on Windows and Linux: a runtime reimplements the PS4 system libraries the game uses, and a shadPS4-derived core translates its GPU commands and shaders to Vulkan. The project reports a playable, in-development port that reaches gameplay and the first chapters, with unstable performance and remaining graphics glitches. It is a compatibility-runtime port rather than a decompilation, and its results remain project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply your own copy of the US PS4 release CUSA00223, base game 1.00 merged with update 1.07 (about 33 GB), including the 1.07 eboot.bin and the game’s own libc and Fios2 modules; README reports that CUSA00004 also boots but is not tested in depth. No PS4 firmware modules are needed, and README states that no game code, files or art are distributed. The project disclaims affiliation with Sony Interactive Entertainment and Sucker Punch Productions. - **Prerequisites:** Play needs 64-bit Windows 10 (1903+) or 11, or x86-64 Linux with glibc 2.39+, and a Vulkan 1.3 GPU, with 6 GB of VRAM recommended; CPUs lacking F16C or SSE4A get instruction emulation at start-up. Building uses a recursive clone with the listed submodules and port/build.sh, with SDL3, Vulkan, FFmpeg, FreeType, Boost, fmt, Zydis and glslang on Linux and an MSYS2 CLANG64 toolchain on Windows; the Qt launcher needs PySide6. - **Scope:** Reviewed at the commit of release v2026.10.19-d3995fe (2026-10-19); the repository was created on 2026-10-13 and changes quickly. README marks the port playable and in development: boot, intro, gameplay up to a named early mission, saves, audio, controllers and motion-sensor substitutes work, while performance is typically 20–30 FPS on an RTX 2060, first-time shader compilation stutters and some fog, water and fire effects flicker. Full-game completion is not confirmed, and a crash on AMD Polaris GPUs under Windows remains open. - **Testing evidence:** Evidence is play-testing, issue reports and logs: README cites Linux tests on Nobara/Fedora 44, player tests on Windows and a seven-minute RTX 2060 session with a median of 27 FPS. The CI workflow builds Linux and Windows packages for pull requests and authorized manual releases, and its Linux job runs C, Python and GPU-library unit tests without game content or automated gameplay tests. - **License:** README declares GPL-2.0 for the project and credits code from HayatoG’s earlier The Last Guardian and Gravity Rush 2 ports, gow3_pc, bloodborne_pc, shadPS4 and a fork of it, and a Shadow of the Colossus port; experimental fixes are traced to their source commits. The game and its assets keep their owners’ rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### xoreos: an open reimplementation of BioWare’s Aurora engine family > Reimplements BioWare’s Aurora engine and its later derivatives as a portable C++ engine that runs on the user’s installed game data, targeting nine games from Neverwinter Nights to Dragon Age II. Resource management, many Aurora file formats, graphics and sound are in place, and every target shows partial in-game areas in a free-flying spectator mode. README states that normal gameplay is not implemented yet, so this is an early-stage engine case, not a playable replacement. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs the user’s own copy of a supported game, fully installed or copied to disk; xoreos reads its resources from that directory, and the repository contains no game files. There is no launcher GUI: a game starts from the command line with its path, or with a target section that xoreos saves in its xoreos.conf configuration file. - **Prerequisites:** Builds use CMake 3.1+ with C++17, or autotools, against the libraries in BUILDDEP.md, including Boost 1.53+, SDL2 2.0.4+, OpenGL 2.1+, FreeType 2, OpenAL Soft and the MAD, Vorbis, FAAD, Xvid and libvpx codecs. README points to release binaries for Windows, Mac OS X and GNU/Linux on 32- and 64-bit x86; the FAQ says mobile devices lack an OpenGL ES renderer and console ports are highly unlikely. - **Scope:** The reviewed master snapshot (2026-09-04) still reports version 0.0.6; release v0.0.6 dates from 2020-08-03, and the repository calls itself pre-pre-alpha. README targets Neverwinter Nights 1 and 2, Knights of the Old Republic I and II, Jade Empire, Sonic Chronicles: The Dark Brotherhood, The Witcher, and Dragon Age: Origins and II; the 0.0.6 notes report a partially playable KotOR tutorial and partial menus in other games. - **Testing evidence:** CI builds with autotools and CMake on Linux (GCC and Clang), macOS and Windows (MSVC) and runs the Google Test unit tests, which cover Aurora file formats and shared engine code. No comparison with the original executables is published, and per-game progress is tracked on the project wiki. - **License:** README and COPYING apply GPL-3.0-or-later; doc/ adds GPLv2, LGPL-2.1 and font licence texts for incorporated components, and the games keep their publishers’ rights. CONTRIBUTING.md forbids AI-generated code, comments and commit messages. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### librw: a re-implementation of the RenderWare Graphics engine > Re-implements a large part of the RenderWare Graphics middleware API as a portable C++ library that reads and writes its DFF model and TXD texture files for PS2, D3D8, D3D9 and Xbox and is meant to convert them between platforms. Direct3D 9 and OpenGL backends render the scenes, while PS2 rendering works only as a test. README names rendering GTA as its use; BSP world files are not supported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** As a library, librw needs no particular original files: applications hand it RenderWare DFF models and TXD texture dictionaries, such as those of the games they render. The repository ships no game data, but its demo tools include four small DFF sample models whose provenance it does not state. - **Prerequisites:** Builds use premake5 (a premake5.exe is committed) or CMake 3.8+, selecting a NULL, GL3 or D3D9 platform and, for GL3 (OpenGL 2.1+ or ES 2.0+), GLFW, SDL2 or SDL3 for windowing. premake targets Windows x86/amd64, Linux x86/amd64/ARM and PS2, and the CMake files add PS2 and Nintendo Switch toolchains; a skeleton application framework with bundled Dear ImGui accompanies the demo tools. - **Scope:** The reviewed master snapshot dates from 2026-08-26; CMake reports version 0.0.1 and the repository has no tagged releases. README calls librw a re-implementation of RenderWare graphics, “or a good part of it”: not all pre-instanced PS2 DFFs load and BSP is unsupported, and TODO lists morphing, several pipelines and PS2 rendering as open. ARCHITECTURE.MD says some design decisions follow the original RW and others are the author’s own. - **Testing evidence:** The GitHub Actions workflow builds and packages 14 configurations: Windows D3D9, GL3 and null, macOS and Ubuntu GL3 and null, PS2 in a ps2dev container and Switch in a devkitPro container. It runs no tests, and the repository has no test suite or comparison with original RenderWare output. - **License:** LICENSE applies MIT to librw; the bundled Dear ImGui and ImGuizmo code carries its own licence files, and RenderWare itself and any game assets keep their owners’ rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Super Mario Odyssey: per-function matching decompilation of the Switch executable > Reconstructs C++ source for Super Mario Odyssey’s Switch 1.0 main executable and checks each function against the original AArch64 machine code with the shared nx-decomp-tools checker. At the pinned commit its function list marks 18,996 of 74,171 functions matching. The README warns that the build is not a playable game, the repository ships no game assets, and Nintendo libraries such as sead and agl come from open-ead’s separate reconstructions. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Setup needs the user’s own original 1.0 main NSO executable, compressed or not; setup.py accepts only two SHA-256 hashes, converts it to an ELF and checks that result’s hash too. Only the ExeFS is needed, though README notes that RomFS files help cross-reference names. The repository holds no game assets, while data/ carries the function list and address, symbol and string-literal tables for the 1.0 executable; contributors work from Hex-Rays or Ghidra output. - **Prerequisites:** The documented setup is Linux, WSL or macOS, with a VS Code dev container and a Nix flake as alternatives; it needs Python 3.6+, Ninja, CMake 3.13+, ccache, llvm-objdump, a Rust toolchain and the listed Python modules. setup.py downloads prebuilt clang, ld.lld and the viking checker from the project’s tools-cache release v1.2.6, or builds them from source, and fetches LLVM 3.9.1 libc++ headers. Submodules supply open-ead’s sead, agl, eui, NintendoSDK and NEX headers, a musl build and nx-decomp-tools. - **Scope:** The reviewed master pin is dated 2026-09-29. README describes a work-in-progress decompilation of Super Mario Odyssey 1.0.0 that recreates a source base from scratch and warns that it will not produce a playable game. The GitHub description says all versions, but setup.py builds only 1.0 and skips 1.0.1, 1.1, 1.2 and 1.3 as a to-do, and README lists cross-version comparison and 1.3.0’s different optimisation as open work. Functions are matched individually. - **Testing evidence:** tools/check compares every function marked in data/file_list.yml with the original executable. At the pin the list marks 18,996 functions matching, 47 with minor and 252 with major differences and 54,876 not decompiled, and decomp.dev’s report for the commit gives the same 25.61% of functions, or 15.77% of code bytes. CI fetches the executable through a repository secret, builds and requires the check to pass, and separately checks that every header compiles on its own. - **License:** GitHub detects no license and the pinned root has no license file, so no reuse terms are stated; submodules and Nintendo content keep their own terms. A workflow adds an ai label to new pull requests from authors who, in its own words, usually use AI. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### GB Recompiled > Static recompiler that turns Game Boy and Game Boy Color ROMs into portable C projects: it decodes and analyzes banked LR35902 code, emits C with machine-readable metadata, and links it with a shared SDL2 runtime for video, audio, input, saves and hardware timing. Jump targets that static analysis missed fall back to an interpreter. The repository also carries differential, replay and frame and audio capture tooling, plus a Pokémon Crystal port that builds native features on hooks into the exact ROM. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README calls it an experimental recompiler and says successful code generation does not guarantee that every scene runs correctly. ACCURACY.md (generated 2026-07-13) reports 8 of 8 Blargg and 63 of 67 Mooneye test ROMs passing and states that this is not a measure of commercial-game compatibility. - Users supply their own .gb or .gbc ROMs; the repository contains no ROMs. The bundled Crystal Recompiled port is ROM-free: it requires the user's exact US/Europe Rev 1 ROM, checks its hash before writing any ROM-derived output, and keeps generated projects in ignored local or private-cache paths, and its distribution policy forbids releasing ROMs, generated C or extracted assets. That port's alpha is verified end to end only on macOS arm64. - Release v0.1.0 (2026-08-03) ships prebuilt gbrecomp archives for Linux x64, macOS Intel and Apple silicon, and Windows x64; the reviewed main commit is 13 commits ahead, last committed 2026-09-10. Building from source needs CMake 3.20+, Ninja, SDL2 development files and a C11/C++20 compiler, and generated projects build with CMake and Ninja. ANDROID.md documents a separate single-ROM APK workflow. - A CTest suite covers isolated invariants. The README notes that differential mode shares runtime devices with the interpreter, leaving SameBoy comparisons and frame, audio and state captures as separate evidence. The only GitHub workflow builds release archives and smoke-tests them with a generated fixture ROM; an optional manual job checks the Crystal port against a privately held ROM without publishing. - MIT-licensed; the vendored Dear ImGui keeps its own license. The README states no affiliation with Nintendo, and the Crystal port none with Nintendo, The Pokémon Company, Game Freak or Creatures. The README points contributors and coding agents to AGENTS.md. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### dtk-template > Project template for starting GameCube and Wii matching-decompilation repositories around decomp-toolkit. Its configure.py generates a ninja build that analyzes and splits the game's DOL and REL files from per-version config.yml, symbols.txt and splits.txt files, compiles the decompiled C/C++ with period Metrowerks compilers, relinks the result and checks it against recorded SHA-1 hashes. It also wires in objdiff for per-object diffing, progress reporting for decomp.dev and an example GitHub Actions workflow. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A scaffold rather than a finished project: users rename the GAMEID placeholders, write each version's configuration and refine symbols and splits after the initial analysis. The README says nearly all active GameCube and Wii decompilation projects use this structure. There are no releases or tags; the reviewed commit (2026-04-26) pins decomp-toolkit v1.8.3, objdiff v3.6.1, binutils 2.42-2 and the 20251118 compilers package. - Users place their own disc image or extracted game files in the ignored orig/[GAMEID] directory, and no game assets are committed. The CI guide has the game files needed for a build stored in a separate build-container repository and warns that it must stay private to avoid exposing the game's assets. - Needs Python and ninja on Windows, macOS or Linux; outside Windows a downloaded wibo wrapper runs the 32-bit Windows compilers, or a user-supplied Wine. configure.py downloads pinned decomp-toolkit, GameCube/Wii binutils, objdiff, sjiswrap and wibo releases plus a Metrowerks CodeWarrior compiler archive hosted by decomp.dev rather than by this repository. - Verification happens per project: the build compares the rebuilt DOL and REL files with the hashes in build.sha1, and objdiff and decomp.dev report per-object matching progress. The template ships no game configuration. - Released under CC0-1.0, which the README suggests replacing with the project's own license; downloaded tools keep their own licenses, and the CodeWarrior compilers are proprietary. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### N64ModernRuntime > Runtime for N64Recomp static recompilations and traditional source ports of N64 games, made of two libraries. ultramodern reimplements core libultra services (threads, message queues, timers, controllers, audio, RSP task handling and VI timing) and leaves controller input, audio playback and the graphics renderer, with RT64 recommended, to callbacks the host project registers. librecomp bridges N64Recomp-generated code to ultramodern and adds overlay handling, PI DMA ROM reads, and EEPROM, SRAM and Flash RAM saves. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags at review; the README recommends including the libraries in a project's own CMake build with add_subdirectory. The reviewed main commit (2026-08-30) needs CMake 3.20+ and C++20; the README says it was developed with Clang 15, older Clang versions may not work, and recent MSVC and GCC should work but are not regularly tested. N64Recomp, miniz, xxHash and o1heap are pinned submodules. - The runtime contains no game code: the host project supplies the recompiled code, the renderer and the platform callbacks, and the user supplies the game ROM. The reviewed librecomp source checks a user-selected ROM against a per-game hash and also loads .nrm mod packages; the README does not describe either feature. - The README covers library scope only and has no compatibility list. - GPL-3.0 (COPYING); submodules keep their own licenses. CONTRIBUTING.md states that AI-generated code contributions are not accepted. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### REDscript > Compiler and decompiler toolkit for REDscript, a statically typed, object-oriented language for writing scripts for REDengine, CD Projekt's engine used in Cyberpunk 2077. Its Rust crates parse and analyze source, generate bytecode with monomorphization of generics, decompile .redscripts bytecode bundles back into REDscript source, read and write REDengine's native binary format, and provide a drop-in replacement for CD Projekt's scc script compiler plus a C API with source mapping. The CLI exposes decompile, compile, lint and format commands; the language server and debugger live in a separate redscript-ide repository. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - GitHub's latest stable release is v0.5.31 (2025-08-28), with Windows and macOS archives and standalone CLI binaries for Windows and macOS arm64. The default 1.0.x branch declares 1.0.0-preview.22, the newest prerelease (2025-09-07); the reviewed commit (2026-05-27) is 26 commits after that tag, and older lines live on the 0.5.x and 0.6.x branches. Source builds use Cargo with a Rust toolchain that supports the 2024 edition. - Installation targets the user's own Cyberpunk 2077 installation: the Windows archive is extracted into the game directory so scripts compile at game startup, with logs under r6/logs. On native macOS the game does not compile scripts at startup, so the README uses a bundled launch_modded.sh, and downloaded binaries must first be removed from quarantine. The decompiler reads a .redscripts bundle from the user's game, compilation uses one as its base, and the reviewed tree contains no game scripts or bundles. - Language documentation is on the REDmodding community wiki, and editor support for VS Code, neovim, IntelliJ IDEA, Zed and Helix is in the separate redscript-ide repository. The README states no supported game patch range. - MIT. The game's license terms are separate. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Spice86 > PC emulator for executing, reverse engineering and rewriting real-mode DOS programs whose source code is unavailable. While a program runs it builds a control-flow graph, and on exit it dumps memory, execution flow, Ghidra-compatible symbols and a self-contained, runnable C# project whose generated functions override the original assembly, so analysts can rewrite them function by function into readable code while the program keeps working. It also provides a GDB remote server with custom analysis commands, a built-in debugger with a C-header structure viewer, an optional HTTP memory API and an MCP server whose tools cover CPU, memory, breakpoints, CFG and device state; an optional Ghidra plugin imports the dumps. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Releases are published on NuGet (16.1.0 at review, published 2026-08-05); the GitHub release tagged latest is a rolling development prerelease built from master with debug and release archives. The reviewed master commit (2026-10-13) declares 16.1.0. The project is a C# port and continuation of the original Java Spice86. Running and building need .NET 10 on Windows, macOS or Linux; source builds use dotnet build. - The README lists 8086/8088 as fully implemented, with partial 80186, 80286 and 80386 support (no protected mode or paging, and no FPU beyond detection); 1 MB segmented memory with EMS, XMS and HMA; text, CGA, EGA, VGA and VESA VBE 1.2 graphics, with CGA and EGA best effort; a largely complete DOS 5.0 INT 21h; and Sound Blaster, OPL and Adlib Gold audio ported from DOSBox Staging, with MT-32 partial and unavailable on macOS. COMPATIBILITY.md says many programs do not run and lists tested games individually. - The analyst supplies the DOS program and its files; the emulated C: drive defaults to the program folder. Dumps go to a subfolder named by the program's SHA-256 hash, and the generated project passes the expected checksum so overrides cannot run against a different binary. The GDB server starts by default on port 10000, and the MCP HTTP server is documented as enabled by default on port 8081. The Ghidra plugin is a separate repository that needs Java 17. The README suggests LLM assistance for rewriting generated functions and points to the project's Cryogenic rewrite of Cryo's Dune as a worked example. - Apache-2.0; NOTICE credits the Aeon project, the README credits DOSBox Staging for ported sound code and as the model for CD and floppy emulation, and a prebuilt FastExpressionCompiler DLL is vendored in 3rdparty. Test resources are small DOS test programs, most with assembly sources in the repository. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### PS2 Web Recomp > Statically recompiles PlayStation 2 games for the browser: eerecomp translates the Emotion Engine code of a game's boot executable into C++ that is compiled to WebAssembly, and a runtime emulates the rest of the console, including a high-level EE kernel, an interpreted I/O processor running the disc's IRX modules, the vector units, SPU2 sound and the Graphics Synthesizer on WebGPU compute shaders. Its port script repeats headless runs to find functions reached through pointers and vector-unit microprograms to compile ahead of time, then builds the web page and a native runner. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README reports two titles brought up so far: the PAL Gran Turismo 4, playable from boot through races at full speed in Chrome, and God of War II from its menus into combat, which needed no game-specific code but exposed a recompiler bug and a vector-unit timing bug. It warns that another game will most likely stop at an unimplemented system call, IOP library function or GS feature, and that vector-unit results can differ from the console's in the last bit. - Users bring a disc image of a game they own; the repository contains no game code or data. The README states that the generated C++ and the built WebAssembly are translations of the game's executable that belong to its owners, asks users to keep them on their own machine and not publish them, and warns that anyone who can reach the local server can load the game. - Porting needs Git, CMake 3.20+, Ninja, a C++20 compiler (Clang preferred), Python 3 and 7-Zip for .7z images; the first run installs the Emscripten SDK and downloads wgpu-native, and the native window needs SDL2. Everything has been run on x86-64 Linux, and the scripts also build on Apple-silicon macOS; expect about 300 MB of disk per game. The page needs WebGPU, which Linux Chrome enables only behind flags (the software renderer fallback is too slow for 3D), plus cross-origin isolation headers and HTTP Range support. - There is no release, tag or CI workflow. scripts/test_vu_codegen.py exercises native and WebAssembly vector-unit code generation without a game disc, and a software GS rasterizer is kept as the reference for the GPU output. Frame rates are the author's measurements on one laptop. Last commit at review: 2026-10-19. - MIT-licensed; the MPEG decoder's VLC tables adapted from Play! keep its BSD 2-clause notice, and the README names PCSX2, Play! and the ps2sdk headers as behavior references. It states no affiliation with Sony or the games' publishers. ##### Primary sources 1. 2. 3. 4. 5. 6. #### xboxrecomp > Static-recompilation toolkit for original Xbox games: a Python pipeline parses a retail XBE, disassembles it, classifies library functions, recovers calling conventions and lifts every x86 function to C. The generated code is compiled in a separate game project that links the toolkit's runtime libraries, which stand in for the Xbox kernel and translate Direct3D 8, NV2A, audio and input to Direct3D 11 and Win32 APIs, or to SDL2 and OpenGL on Linux and macOS. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README for v0.14.0 (2026-10-16, the reviewed commit) calls the toolkit title-agnostic but built against Burnout 3: Takedown, and says a first run of a recompiled game will crash and needs iterative stubbing, indirect-call fixes and runtime work for each title. The author's own ports are early: the README retires an earlier playable claim for Burnout 3, whose recompiled path reaches engine initialization, and lists Wreckless and Blood Wake as booting or scaffolded. - Users supply default.xbe and the game's data files from their own original Xbox disc image. The repository contains no game code or assets and builds only libraries, never a game executable; the generated C, often millions of lines, is written into the user's own game project created from the bundled template. - The pipeline needs Python 3.10+ with Capstone (pytest for tests); Ghidra or IDA are optional and only recover symbol names. The runtime builds with CMake 3.20+ and Visual Studio 2022 or MinGW-w64 on Windows (D3D11, XInput, XAudio2, Media Foundation), or Clang/GCC with SDL2, libepoxy and pkg-config on x86-64 and arm64 Linux and macOS, where FMV decoding is not available. The v0.14.0 release has no binary assets. - Unit tests need no game files, and several compile the lifter's output and check it against x86 definitions with paired negative controls; the README gives 812 passed and 0 skipped as a clean run. A conformance suite runs lifted C and the original instructions on a real 32-bit x86 CPU over the same inputs, with Docker images supplying GCC and MSVC under Wine on Linux and macOS. The README calls lifter coverage good but unquantified, and the repository has no CI workflow. - MIT-licensed, except the MCPX APU sources and NV2A register definitions extracted from xemu, which stay LGPL-2.1-or-later as listed in NOTICE. The README credits Claude Code for AI-assisted development. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### PCSX-Redux > PlayStation 1 emulator forked from PCSX and built around development and reverse engineering, with an interpreter and dynamic recompiler, software and OpenGL renderers, a MIPS debugger, VRAM viewer, SPU and GPU debugging tools, and a built-in GDB server that its documentation connects to gdb, IDA Pro and Ghidra's debugger. A LuaJIT API exposes breakpoints, memory and registers, an assembler and an ISO builder, and an optional REST web server can dump RAM and VRAM. The repository also holds the OpenBIOS replacement BIOS, PS-EXE conversion and packing tools, a Psy-Q object-file converter, Ghidra scripts for exchanging symbols and overlays with the emulator, and PS1 hardware designs. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No tagged GitHub releases at review: the README links rolling development builds for Windows x64 (GUI and CLI), Linux x64 and arm64 AppImages and macOS Arm, and says the codebase is still experimental and has not reached its first stable release. Builds are 64-bit only and need a GPU and driver that can create at least an OpenGL 3.0 context; the macOS build is unsigned. The reviewed main commit is from 2026-10-19. - Source builds need a recursive clone: Visual Studio 2022 with NuGet on Windows; Docker for the AppImage, or make with clang and packages such as Capstone, FFmpeg, libuv, SDL3 and curl, on Linux; macOS Catalina or later with Xcode and Homebrew packages. OpenBIOS and other PS1 code need a mipsel-none-elf GCC toolchain, for which the repository provides install scripts. - Game discs and executables come from the user. The README presents OpenBIOS, built separately, as an alternative to the copyrighted retail BIOS, and the reviewed trees contain no retail BIOS, Psy-Q libraries or game files. The docs say most CPU debugging features need the dynarec disabled and the debugger enabled, and Ghidra debugging needs gdb-multiarch and Ghidra 10.3+. When enabled, the web server listens on port 8080 on all network interfaces by default, which the docs note makes it reachable from other machines. - GPL-2.0 for PCSX-Redux; OpenBIOS lives in the MIT-licensed nugget submodule, and LICENSES.md lists third-party libraries with their own licenses, some vendored with modifications. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Il2CppInspector > Static analysis tool for Unity IL2CPP applications that reads an IL2CPP binary with its global-metadata.dat and outputs the application's type structure and method addresses as C# stub code, .NET assembly shim DLLs for decompilers such as ILSpy and dnSpy, IDA and Ghidra Python scripts that apply symbols and types, C++ type scaffolding and JSON address maps. Three APIs, also published as a NuGet package, and a plugin SDK expose the binary metadata, .NET type model and C++ model for custom analysis. The README states that it is not a decompiler and does not recover method source code. - Type: Tool - Targets: App · Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README announces that development is suspended for the foreseeable future and that the author will not respond to issues or pull requests. The reviewed master commit, which added that notice, dates from 2021-11-23, 16 commits after the last release, 2021.1 (2021-01-31). The README recommends Cpp2IL instead. - Its version table marks Unity 5.3.0 through 2020.3.x (IL2CPP 16 to 27.1) as working and 2021.1 (27.2) as partial; later Unity versions are not covered. Documented inputs are ELF, PE, Mach-O, Universal Binary and PS4 FSELF images, 32- and 64-bit, for ARMv7, Thumb-2, ARMv8, x86 and x64, plus APK, AAB, XAPK, Zip and decrypted IPA packages. - The analyst supplies the IL2CPP binary and its matching global-metadata.dat; IPA executables must already be decrypted, and the README says packed, encrypted or obfuscated IL2CPP files are not its intended input. It warns that loading a packed PE file runs the DLL's entry point and initialization code, so untrusted DLLs should not be loaded and the tool should never run as administrator. - Builds use dotnet publish from a recursive clone and target .NET Core 3.1; the CLI builds for Windows, macOS and Linux, while the WPF GUI is Windows-only, and plugins are fetched separately with the get-plugins scripts. AGPL-3.0; the Bin2Object submodule and libraries such as dnlib and CxxDemangler keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### MelonLoader > Mod loader for Unity games on both the Mono and IL2CPP runtimes, which loads plugins and mods from folders in a locally installed game; on Windows a proxy DLL, version.dll by default, starts it with the game. For IL2CPP games its assembly generator runs Cpp2IL and Il2CppInterop to produce managed interop assemblies, and HarmonyX and MonoMod are bundled for runtime patching. Its logs can capture Unity player output and Harmony messages, and debug options provide a Mono debug server for Mono games and a wait-for-debugger option for IL2CPP games. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.7.3, published 2026-05-14, with Windows x64/x86, Linux x64 and macOS x64 archives plus Windows, Linux and macOS installers; the README also links nightly builds. The reviewed master commit (2026-10-01) declares the unreleased 0.7.4, 69 commits after v0.7.3, and its pending release notes add macOS arm64 support. The README links Linux instructions for Wine, Proton and native games, and marks Android and Oculus Quest support as work in progress. - The README lists the .NET 6.0 Desktop Runtime as a requirement for IL2CPP games, installed automatically on Windows. The installer or a manual install places MelonLoader and its proxy DLL in the user's own game folder, where the Plugins, Mods, logs and UserData/Loader.cfg configuration are created; some games need one of the alternative proxy file names. Source builds use the dotnet SDK, and the projects target Mono, Mono bleeding-edge and .NET frameworks. - On IL2CPP games the assembly generator queries MelonLoader's remote API by game name for settings such as a Cpp2IL version, obfuscation regex or deobfuscation mapping, and the README lists Cpp2IL, Unity runtime libraries and the .NET runtime as downloaded at run time. Configuration and launch options can force offline generation, a dumper version or regeneration. - Apache-2.0; bundled libraries such as Dobby, plthook, HarmonyX, MonoMod, Mono.Cecil, AsmResolver and Il2CppInterop (LGPL-3.0) keep their own licenses, and the README says the downloaded Unity runtime libraries are subject to Unity's terms of service. Game license terms are separate. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### BepInEx > Plugin and patching framework for Unity Mono, Unity IL2CPP and .NET Framework games such as XNA, FNA and MonoGame titles, which loads mods and analysis plugins into a locally installed game. Plugins patch methods at runtime with the bundled HarmonyX and MonoMod.RuntimeDetour, while preloader patchers rewrite managed assemblies with Mono.Cecil before the game loads them; on IL2CPP games it runs Cpp2IL and Il2CppInterop to generate interop assemblies from the game binary and global-metadata.dat. Its guides also cover configuration, logging, and debugging plugins and game assemblies with dnSpy. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest stable release at review: v5.4.23.5, published 2026-02-08 from the v5-lts branch, with Windows x86/x64, Linux x86/x64, macOS universal and patcher archives; the README says only Unity Mono has stable releases. The reviewed master commit (2026-10-16) declares the unreleased 6.0.0 and is 75 commits after the latest 6.x prerelease, v6.0.0-pre.2 from 2024-08-27, which ships Unity Mono, Unity IL2CPP and .NET builds; newer bleeding-edge builds are published separately. The guides note that the preloader-patcher contract changed between v5 and v6. - The README's compatibility chart lists Unity Mono on Windows, macOS and Linux, Unity IL2CPP on Windows and Linux but not macOS or ARM, and .NET/XNA games on Windows or through Mono on macOS and Linux. The master installation guide lists Windows 7–10, Linux distributions with GCC 10+, macOS 10.13+ and Unity 3 or newer. Source builds use the bundled Cake script and need .NET 6.0 or newer. - BepInEx installs into the user's own game directory: the guide identifies Unity Mono games by a Managed folder and IL2CPP games by il2cpp_data. IL2CPP interop generation reads the game's binary and global-metadata.dat and, by default, downloads managed Unity base libraries for the game's Unity version from unity.bepinex.dev; a configuration option points it to a locally placed archive instead. Some games need the documented troubleshooting steps. - LGPL-2.1 (LGPL-2.1-only in the package metadata); the libraries it uses, including UnityDoorstop, HarmonyX, MonoMod, Mono.Cecil, Cpp2IL and Il2CppInterop, keep their own licenses. Game license terms are separate from the framework's license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Star Fox 64: a complete matching Nintendo 64 decompilation > Reconstructs C source for the US 1.1 (Rev A) Nintendo 64 release of Star Fox 64 that, compiled with the IDO compiler through a static recompilation, rebuilds a ROM with the published MD5; the README badge counts all 2,951 functions as matching. Code and assets are split from the user’s own ROM at build time, and the repository contains no assets or assembly. The separately curated Starship PC port compiles this C code, while Starfox 64: Recompiled takes headers and some functions from it for its patches. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building needs the user’s own US 1.1 Rev A ROM, placed in the project root as baserom.us.rev1.z64. README says the repository includes no assets or assembly code; make init decompresses the ROM, splits code, data and assets with splat, then builds. config.yml and assets/yaml also hold the Torch asset definitions that write starship.otr for the Starship port. - **Prerequisites:** README documents Linux, natively or under WSL or a VM, with make, Git, build-essential, MIPS binutils, Python 3 with pip, libpng and the listed clang tools, or macOS with Homebrew’s coreutils, make, pkg-config and mips64-elf binutils; native Windows builds are unsupported. make toolchain downloads decompals’ ido-static-recomp build of the IDO compiler and builds the mio0 tool and Torch, while submodules add splat, asm-processor, asm-differ, m2c and Torch. A GCC build is available but defines NON_MATCHING. - **Scope:** The reviewed master pin of 2026-09-28 is a clean-up commit after the July 2026 commits announcing 100% completion. README calls this a complete matching decompilation of the US 1.1 (Rev A) ROM, MD5 741a94eee093c4c8684e66b89f8685e8, and says it is not a PC port. Splat configurations and linker scripts also exist for US 1.0, Japanese and European releases, with checksum files for uncompressed Japanese and European 1.0 ROMs, but README does not document building them. - **Testing evidence:** With COMPARE=1 by default, the build checks the output against starfox64.us.rev1.md5, and README reads a mismatch as a bad base ROM or non-matching code. CI runs make init on the US ROM, fetched from a private repository through secrets, and a separate workflow checks formatting. - **License:** The repository carries CC0-1.0, which does not cover Nintendo’s game, the ROM or extracted assets; the IDO compiler and the submodules keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Metroid Prime: the PrimeDecomp matching GameCube decompilation > Reconstructs C++ source for Metroid Prime’s GameCube executable and its NES-emulator module so that CodeWarrior builds match the originals, across the USA, Korean, PAL and Japanese releases, with early configurations for demo discs and three Wii releases. Matched units are compiled from source and linked with objects split from the user’s disc, then checked against per-version SHA-1 hashes; the repository contains no game assets or assembly. The separately curated Metaforce and Metroid Prime Port build their native ports on this code. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building needs the user’s own disc image of the chosen version in its orig/ folder, in ISO (GCM), RVZ, WIA, WBFS, CISO, NFS, GCZ or TGC format, which can be deleted after the first build. The repository contains no game assets or assembly; decomp-toolkit splits the original executable and its embedded data locally. CONTRIBUTING lists Metaforce, a shared Ghidra server and a symbol map from an early demo disc as references for contributors. - **Prerequisites:** Builds run natively on Windows with Python and ninja; macOS needs ninja and Wine Crossover, and Linux uses ninja with the automatically downloaded wibo wrapper on x86 or Wine elsewhere. configure.py pins decomp-toolkit v1.8.4, objdiff v3.8.2, binutils 2.42-1, sjiswrap v1.2.2, wibo 1.0.3 and a 20251118 compiler bundle from files.decomp.dev, compiling game code with CodeWarrior GC/1.3.2, or Wii/1.0a for the Wii releases. The MusyX audio library comes from a submodule. - **Scope:** The reviewed main pin of 2026-10-19 updates objdiff to v3.8.2. README describes a work-in-progress decompilation supporting GM8E01_00 (USA v1.088), GM8E01_01 (USA v1.093), GM8E01_48 (Korea v1.097), GM8P01_00 (PAL v1.110), GM8J01_00 (Japan v1.111) and GM8E01_02 (USA v1.111); configure.py and CI also cover the Multi-Game Demo Disc, a Japanese demo and the Wii New Play Control and Trilogy releases. Output is the original main.dol and, for the six retail GameCube versions, the NES emulator REL, not a port; docs/metaforce.md explains how to convert code from Metaforce into matching C++98. - **Testing evidence:** The default build links source-built objects only for units marked Matching, uses original extracted objects for the rest and checks main.dol and the NES REL against the version’s build.sha1. decomp.dev’s reports for the pinned commit list 93.89% of GM8E01_00 code (16,478 of 16,685 functions) and 98.47% of its data matched, with 739 of 829 units complete; the other USA and Korean releases report 92.5–93.83% of code, PAL 84.37%, Japan 82.91%, and the demo and Wii builds early figures. CI builds all eleven configurations in a container that supplies the original files. - **License:** The repository carries CC0-1.0, which does not cover Nintendo’s game, the disc content or the downloaded compilers; the vendored zlib 1.1.3 keeps its own license and MusyX is a separate repository. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. #### Batla 3D server emulator (2015 client) > C# server emulator for the 2015 Steam client of Batla 3D, covering HTTP account, shop and room services and Lidgren UDP gameplay. It includes a client-assembly patcher and protocol notes that distinguish recovered client evidence from emulator rules. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an owned Unity 4.6.9f1 Steam client and .NET 10 SDK. The patcher uses dnlib; strict Steam validation requires Windows x86 Steam libraries. - **License:** MIT covers the repository code; game files must come from your own installation. Client patches also change packet fields and gameplay behavior beyond the server address. - **Limits:** Some combat, economy and objective values are emulator policies. - **Limits:** The README declares this stack frozen and unsupported. The referenced Batla.UdpSmoke harness is absent from the reviewed tree. ##### Primary sources 1. 2. 3. 4. 5. #### RSDKv4 Decompilation: Retro Engine v4 and the Sonic 1 & 2 (2013) menus > Decompiles Retro Engine (RSDK) v4, the engine behind Sonic the Hedgehog and Sonic the Hedgehog 2 (2013), together with the games’ natively coded menus, and builds it for Windows, Linux and Android. The engine runs the game scripts contained in the official releases’ data files, which users must supply. The project adds a script compiler, a mod loader and an experimental online mode for Sonic 2’s 2P VS; it is the predecessor of the same group’s RSDKv5 decompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** It will not run without assets from an official release of Sonic 1 or Sonic 2: README names Sonic Origins on Steam, the Epic Games Store and Switch, and the now-delisted iOS and Android releases. The FAQ notes that Origins data files are packed as RSDKv5 datapacks and lack the games’ music and sound effects, and that release builds and autobuilds disable the DLC and block Origins’ Amy; the repository ships no game data. - **Prerequisites:** Clone recursively, because GitHub’s source ZIPs omit the stb, tinyxml2, asio and Flatpak submodules. CMake 3.10+ builds use Visual Studio with vcpkg (GLEW, SDL2, libogg, libvorbis) on Windows, the listed GLEW, SDL2 and Ogg/Vorbis packages on Linux, and a separate Android guide; Xcode, UWP and Flatpak projects are included, while Vita, Switch, 3DS and WebAssembly ports are unofficial forks. Sonic 2’s online 2P VS needs a Python 3.8+ server that README calls a very unstable proof of concept. - **Scope:** Reviewed at the 2026-09-06 main head, 13 commits after release 1.3.3 (2025-11-02). README calls it a complete decompilation of Retro Engine v4 and the menus from Sonic 1 and 2 (2013); the licence says most code is meant to be functionally the same as the specified RSDK version. RETRO_REVISION defaults to 3 (Origins), and RETRO_ORIGINAL_CODE removes the project’s changes but, per CMake, cannot build a playable game. - **Testing evidence:** CI builds Windows x86 and x64, Android and Linux binaries with the Plus DLC disabled; it runs no tests, and the project publishes no comparison with the original engine binaries. The FAQ says bugs present in official releases will mostly not be fixed. - **License:** The custom RSDKv3/v4 Decompilation Source Code License v2 requires distributed prebuilt executables to default to DLC off, forbids commercial use and distributing game assets other than unique modded ones, requires crediting the original RSDK author Christian “Taxman” Whitehead and the decompilation authors Rubberduckycooly and st×tic, and binds forks to the same terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### OpenRW: an open re-implementation of the Grand Theft Auto III engine > Re-implements Rockstar Games’ Grand Theft Auto III (2001) as a cross-platform C++ engine that runs on the data of a legitimate PC copy. It has its own loaders for the game’s RenderWare models, textures and archives, a script machine for the original mission scripts, and an optional Qt data viewer. Playability is partial: the project’s mission tracker marks six early Portland story missions as completable. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** README requires a legitimate copy of the original PC game, and the FAQ says the original assets cannot be distributed; the repository contains no game data. rwgame reads the game directory set in its openrw.ini configuration file, and the optional rwviewer opens objects and models from the same data. - **Prerequisites:** Builds use CMake 3.8+ and a C++17 compiler against Boost (program_options and system, plus unit_test_framework for tests), OpenAL, Bullet, GLM, FFmpeg, SDL2 and OpenGL, with FreeType for the tools and Qt 5 for the viewer; Conan is an optional package manager. The FAQ names C++17 and OpenGL 3.3 Core as hard requirements, and README reports ports to Linux, macOS, Windows and several BSDs. - **Scope:** The reviewed main snapshot dates from 2025-06-18; the repository has no tagged releases and the wiki says there are no official builds, so OpenRW is built from source. The playable-missions tracker (issue #52, last updated 2024-07-24) checks six story missions, all in Portland, and notes missing AI, broken cutscenes or unimplemented opcodes for many others; the FAQ says Vice City and San Andreas are not supported yet. - **Testing evidence:** GitHub Actions jobs on Arch Linux, Fedora and Ubuntu and an AppVeyor Visual Studio 2017 job run a CTest script that builds the code and its Boost.Test unit suite; tests that need game data sit behind the TEST_DATA option, which that script does not enable. No comparison with the original executable is published. - **License:** README applies GPL-3.0-or-later and lists FFmpeg (LGPL-2.1 or later), Bullet and SDL 2.0 (zlib) as third-party licences; the microprofile and imgui submodules are separate projects, and the game’s own assets keep their rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. #### ReXGlue SDK > Experimental SDK for statically recompiling Xbox 360 executables into portable C++23 that runs natively on Windows, Linux and macOS. Its rexglue CLI scaffolds a per-game CMake project and, from a TOML config, analyzes a XEX binary (import resolution, PDATA, block discovery, gap filling, jump resolution and call-target validation) before translating each PowerPC instruction into C++; a runtime derived from Xenia's emulator core, with D3D12 or Vulkan graphics, hosts the generated code. Generated functions are weak aliases that native C++ overrides or mid-function hooks can replace, so a port can be refined one function at a time. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README cautions that the project is in early development with breaking API changes, and the wiki calls it experimental and pre-1.0, not a turnkey way to play Xbox 360 games or an alternative to Xenia. Users must specify function boundaries, implement missing kernel imports and iterate on the codegen output; unresolved calls stop generation as validation errors unless --force is passed. - Release at review: v0.10.0, published 2026-08-21, with SDK archives for Windows amd64, Linux amd64/arm64 and macOS amd64/arm64; the default main branch holds that release, while nightly prereleases are built from the development branch, 24 commits ahead. Building needs a recursive clone, CMake 3.25+, Ninja and Clang 18+ or AppleClang 16+ on a 64-bit x86_64 or ARM64 host, and other compilers are rejected; the wiki's Windows setup uses Visual Studio 2022 with its Clang toolset and its Linux setup Clang 20+ with GTK3 headers. - Each project's TOML config points at the user's own Xbox 360 XEX; the SDK ships no game code. Documentation is the GitHub wiki, last edited 2026-06-04, whose status section still describes v0.3.x and calls the graphics, audio and input backends in flux. - LICENSE is a BSD-3-Clause text that credits Xenia-derived portions (GitHub reports NOASSERTION); submodules and the bundled PowerPC binutils executables keep their own licenses. The README disclaims affiliation with Microsoft and prohibits use for piracy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### ps3recomp > Toolkit and runtime for statically recompiling PlayStation 3 games into native executables. Python tools parse PS3 ELF and PRX files, find functions and firmware imports, and lift PPU and SPU code to C/C++; a project template links that code with a C/C++ runtime providing LV2 system calls, high-level emulation of the system libraries and RSX graphics translation to Direct3D 12, Metal or Vulkan. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README for v0.15.0 (released 2026-10-16; the reviewed master commit is two commits ahead) reports about 93 complete and 5 partial high-level-emulated system-library modules, with media decoding and SPURS still partial. Only Windows with Direct3D 12 runs a recompiled game from this tree; macOS and Linux build the runtime and pass its tests, but no title has yet booted to gameplay there. - Users supply a decrypted ELF of the game executable (EBOOT.BIN) from their own legally obtained copy; the repository ships no keys, firmware or game files and does not decrypt retail executables. The optional firmware low-level-emulation path also needs decrypted firmware modules that the user provides. Each game is ported in its own project: the README lists The Simpsons Arcade Game and Tornado Outbreak as in game in separate repositories. - Building from source needs Python (3.10+ in the README, 3.9+ in the build guides), CMake 3.20+ and a C17/C++20 compiler (MSVC or clang-cl, GCC 12+ or Clang 15+). SDL2 is required off Windows, and FFmpeg is optional and loaded at run time for video and ATRAC3plus decoding. Releases ship prebuilt SDK bundles with the runtime library, headers and Python pipeline for Windows x64, macOS arm64 and Linux x64. Last commit at review: 2026-10-16. - CI builds the runtime and runs the lifter test suites and C unit tests on Windows, macOS arm64 and Linux, plus the Vulkan backend on lavapipe; the README states that a passing check does not mean a game ran. A lifter conformance suite checks the C emitted for single instructions against expectations derived from the PowerISA, and a regression gate compares five ports with recorded milestone logs before shared-runtime changes land. - MIT-licensed; the vendored ATRAC3/ATRAC3plus decoder taken from PPSSPP stays LGPL-2.1-or-later. The README states that the project contains no Sony code, firmware, keys or copyrighted material and that its system-library modules are written from documented behavior, with RPCS3 used as a behavioral reference rather than a code source. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Nebula (NebulaFD) > Work-in-progress decompiler for games made with Clickteam Fusion 2.5, with fixes for older Multimedia Fusion 1.5 files. Its .NET console app reads Windows executables, Android APKs, iOS IPAs, CCN data files and existing MFA projects, then runs plug-in tools: an MFA Parser that writes the game back out as an editable Fusion project, and an Asset Dumper for images, sounds, music, fonts, icons, shaders and packed files. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README is a placeholder that calls itself a work in progress and documents no usage, build steps or supported formats. The latest release, september_2026_update (2026-09-28, the reviewed commit), lists fixes for Multimedia Fusion 1.5 files and Fusion 2.5 build 296 events plus experimental Android support, and notes that console-exporter detection breaks with custom exporters. - Users supply a compiled Fusion game: the console asks for a file path and picks a reader from the extension (EXE, APK, IPA, MFA, ZIP, ANM, TMP or GAM, with other files read as CCN data) or from the user's choice. The MFA Parser and Asset Dumper load as DLLs from the program's Tools folder and write to a Dumps folder. - Release archives require the .NET 6.0 Desktop Runtime, and the projects target net6.0. The only GitHub workflow compiles the solution with MSBuild on Windows and uploads the build as an artifact, and the dumper's post-build step uses the Windows robocopy command; no other platform is documented. The repository contains no test project. - There is no license file and GitHub detects none, so reuse terms are not stated. The README credits Kostya for the image bank. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### CoD4 Rewrite: Rust/Bevy reconstruction > A Rust/Bevy reconstruction of Call of Duty 4 multiplayer systems, using assets from a local game installation. Source covers menus, local bots, movement and combat, and connects custom relay-based netplay to the game. - Type: Case study - Targets: Binary · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Windows, a Vulkan-capable GPU and an owned CoD4 patch 1.7 installation. Optional Black Ops, Modern Warfare 2 and World at War content requires their separate installations; game assets are not supplied. - Current source connects the multiplayer dependency and NetplayPlugin despite README statements that networking is pending. - Rendering and gameplay include deliberate extensions. - Cargo declares MIT OR Apache-2.0, inherited by the game and multiplayer crates. No standalone license text was found in the reviewed tree. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### libd2: Diablo II 1.14d engine-core libraries > Zig libraries reconstructing Diablo II 1.14d seeded maps, item generation, saves, simulation rules and network formats. Selected components expose native and WebAssembly interfaces; verification notes distinguish retail map comparisons from weaker subsystem evidence. - Type: Case study - Targets: Binary · Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Builds require Zig 0.16.0. These are modular engine libraries, not a complete playable client; basic generation uses embedded data and fixtures. - MIT covers the Zig source. Included Blizzard-derived binary blobs and map fixtures are expressly excluded from that grant; the repository is not asset-free. - The authors report cell-level comparisons for five Nightmare seeds and two holdouts, plus per-level CRC checks for 200 seeds at three difficulties. - The game and net packages are checked against recovered rules and packet layouts, not a live server; save, item and pathfinding checks have different depth. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Underworld Exhumed: reconstructing Ultima Underworld I and II > Pairs reconstructed DOS sources with native ports of Ultima Underworld I and II. The upstream documents Exhume-based byte-matching builds, routine-level comparisons and recorded-session replay against DOS. - Type: Case study - Targets: Binary · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Native ports target macOS, Windows and Linux. Playing and checking against the originals requires your own matching game files (the README targets GOG releases); byte-matching builds additionally require the documented Turbo C++ 1.01 and TASM 2.0 inputs. Native-port compilation itself does not require game data. - The MIT license covers the project’s own tools, documentation and added annotations/structure. NOTICE explicitly excludes rights in the original games and derived game code; optional MT-32 playback requires separately obtained ROMs. - Recorded sessions and routine tests provide bounded upstream evidence. Full tests require licensed inputs absent from the public repository. ##### Primary sources 1. 2. 3. 4. 5. 6. #### LineWars II: a portable SDL3 reconstruction > Provides an SDL3 backend for a portable-C reconstruction of the 1994 DOS game. Its build configuration links the reconstructed engine to video, input and audio adapters; the upstream documents differential gates against original machine code. - Type: Case study - Targets: Binary · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Builds target Windows and Linux using C99, CMake 3.16+ and SDL3; the reviewed build notes specify SDL 3.4.12 built with the same compiler as the game. This is a port of the separate LineWarsII-DOS reconstruction. - The reconstructed/ported source uses PolyForm Noncommercial 1.0.0. NOTICE reports original-author Patrick Aalto’s July 16, 2026 permission for freeware distribution of the original game material; it does not grant commercial-use permission. SDL keeps its separate zlib license. - The upstream reports renderer and menu comparisons and captured PCM levels within about 10% of its DOS reference; higher-resolution rendering changes the presentation. ##### Primary sources 1. 2. 3. 4. 5. 6. #### BFM-decomp: Brave Fencer Musashi matching decompilation > Documents an agent-assisted reconstruction of the USA PlayStation game with a pinned compiler and whole-binary SHA-1 gates. The verification recipe covers the main executable, resident engine and disc-loaded code modules, with explicit library and assembly exceptions. - Type: Case study - Targets: Binary · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires an owned USA SLUS-00726 disc dump, Linux/WSL2, Python 3.12 and the documented pinned GCC 2.7.2/MIPS toolchain. Optional PsyQ SDK objects must be supplied separately. - AGPL-3.0 applies to the project’s tools and documentation. src/NOTICE.md asserts no license over the reconstructed game code, whose original rights belong to Square/Square Enix; third-party components retain their own licenses. - The 218-binary matching contract is an upstream claim backed by its recipe and a recorded full run dated September 7, 2026. That log is for an earlier tree, not this reviewed HEAD. SDK/assembly exceptions and unfinished readability remain documented; public no-ROM CI audits and compiles but cannot perform the original-byte comparison. ##### Primary sources 1. 2. 3. 4. 5. 6. #### swe1r-assets-unity: Racer model-block editor sample > Work-in-progress Unity editor sample for importing and modifying Star Wars Episode I: Racer model blocks, then serializing them back through swe1r-assets. Its editor includes an unmodified import/export byte-comparison command; it is an asset-format workflow rather than a reimplementation of the game. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README explicitly says this is currently a sample project. The package and sample pin Unity 2022.3.30f1; packages.config references SWE1R.Assets.Blocks 0.0.1-alpha.15 and ByteSerialization 0.0.1-alpha.9. Required game block files are read from a user-selected local game-data directory. - Model import/export is wired in the editor and importer/exporter classes. Texture, spline and sprite sections currently expose filenames without equivalent operation controls; spline importer/exporter subclasses are empty. - Test Re-Export compares the original and serialized model-item byte arrays with SequenceEqual, and Test Re-Export All loops over the loaded model block. The README claims bit-perfect unchanged round trips, but the tree contains no saved corpus/result report. - Repository code has an MIT LICENSE and source SPDX headers. That code license is not evidence of permission to redistribute the original game data. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Snowboard Kids: an agent-assisted N64 matching decompilation > A matching decompilation of the original Nintendo 64 Snowboard Kids that rebuilds SHA1-identical North American and Japanese ROMs from a user-supplied ROM. The author’s 84-day post-mortem describes coding agents run through his Nigel harness alongside m2c, the permuter and a shared file of compiler learnings, and declines to credit LLMs alone for the speed-up. It is a separate project from the Snowboard Kids 2 decompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The 2026-08-26 post reports the game 100% decompiled: every function has C that compiles to identical machine code, apart from a small amount of handwritten system-library assembly that was original source. It dates the repository from 28 May 2026 to the final matching function on 19 August 2026 and counts 2,145 functions, against 596 days and 2,995 functions for Snowboard Kids 2. The README says the Japanese version currently builds from extracted assembly; reports/jp-exact-functions.md lists 120 JP functions compiled from C. - Building requires the user’s own North American or Japanese ROM, named snowboardkids.z64 or snowboardkids.jp.z64 with the SHA1 listed in the README; the build extracts assembly and assets from it into git-ignored directories. The README says the repository contains no game assets or assembly, although the reviewed tree tracks libultra .s files and a box-art image. CI builds both regions from a baserom checked out of a separate private repository. - The verified host is x86-64 Linux with make, git, Python 3, clang, wget, tar and binutils-mips-linux-gnu; a macOS setup is documented but still needs validation. make -C tools sets up the recompiled IDO 5.3 toolchain (IDO_DIR can point to another), submodules supply asm-processor, asm-differ and decomp-permuter, and optional matching helpers need requirements.txt. - tools/build-and-verify.sh cleans, extracts, builds and checks the output ROM’s SHA1 against the original for the selected region, and reports/region-functions.md aligns 1,293 of 2,110 US functions with the JP ROM by exact or address-normalized matches. The post describes agents writing C function by function, a script running m2c on every unmatched function, permuter runs with deadlines and four parallel worktrees; it calls its comparison of GPT-5.5/5.6, Claude 4.5, Fable and GLM 5.2 unscientific. - The author estimates that roughly 4.8% of matching commits involved expert intervention, says the figure does not measure effort, credits contributors for many difficult IDO matches and calls attributing the whole speed-up to LLMs a gross oversimplification. A 100% match still leaves generated names, unknown structure fields and data to document. No license file is present at the reviewed commit, and the README states commercial use is a non-goal. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Sonic Advance 3: an AI-assisted match of one enemy module > Macabeus’s dated study describes prompting Claude Sonnet 3.5 and DeepSeek R1 with assembly, similar decompiled functions and structs to write matching C for Marun, one enemy module of the community Sonic Advance 3 GBA decompilation. The resulting pull request replaced that module’s assembly and was merged; the author calls the setting unusually AI-friendly, and the project now bars LLM-origin contributions. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-20 - Original resource: - Catalog page: ##### Requirements & limits - The post, dated 20 May 2025 and subtitled an ongoing study, covers a single module: Marun, an enemy in the community Sonic Advance 3 GBA matching decompilation. Work began on 6 January 2025, and pull request #4, which replaced the module’s 1,154-line assembly file with 494 lines of C, was merged on 31 January; the post equates it to 0.3% of the project’s total progress. It is a bounded contribution study, not a whole-game decompilation. - Building the SA3 decompilation requires the user’s own European Sonic Advance 3 ROM, named baserom_sa3.gba and matching the release the README identifies by SHA1, plus a sufficiently recent agbcc compiler fork. The study itself worked in decomp.me scratches, putting assembly, similar decompiled functions and relevant structs into prompts for Claude Sonnet 3.5 and DeepSeek R1. - Match percentages come from decomp.me: the post reports a 96% first Sonnet 3.5 attempt that later prompts could not reproduce, a 74% DeepSeek R1 result raised to 100% by replacing memset with CpuFill16, and R1 output that usually matched at least about 60%. The merged pull request is the project-level outcome; the post reports no separate build or test. - The author calls the setting very AI-friendly because similar modules were already decompiled for use as examples and the GBA compiler is simpler and more predictable; generated C lacked project-specific macros and needed readability work. The author’s decomp.me AI-panel pull request was closed unmerged; the post says user benefit was unclear and it required a paid API key. - At the reviewed SA3 commit, the README states a strict no-LLM/no-AI policy for issues and pull requests, so that project no longer accepts this workflow. The SA3 repository has no license file at that commit, and the ROM and its assets retain their own rights. ##### Primary sources 1. 2. 3. 4. #### LuaJIT Decompiler v2 > Decompiles LuaJIT bytecode files back into Lua source, written as a replacement for the older Python LuaJIT decompiler. The README reports full support for gotos and for stripped bytecode, including reconstructed locals and upvalues, and its boolean-expression recovery follows a published decompilation algorithm. It processes single files or whole folders and writes .lua output. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Users supply LuaJIT bytecode files or a folder containing them, by drag and drop or on the command line; decompiled .lua files go to an output folder beside the executable unless overridden. Options filter by extension, ignore debug info, skip files that fail instead of showing an assertion pop-up, and format output to minimize diffs. - The reader accepts bytecode format versions 1 and 2 and rejects big-endian bytecode, which the README lists as future work along with better decompilation of conditional assignments. The repository has no tests, CI or published accuracy results; the program reports how many files failed to decompile. - Windows only: the README directs users to a release executable (the Mar_24_2024 release, whose notes say it was rebuilt on 2026-05-14), and main.h lists Visual Studio, C++20, the Windows API and an unsigned default char as build requirements, with no project or build files included. A Call-of-Duty branch, four commits ahead of master, has its own release executable. Last commit at review: 2026-05-14. - MIT license text that also carries the LuaJIT and Lua copyright notices; GitHub does not classify it. ##### Primary sources 1. 2. 3. 4. 5. 6. #### pw: a matching decompilation of the Pokéwalker firmware > Reconstructs as C the firmware of the Pokéwalker, the pedometer accessory for Pokémon HeartGold and SoulSilver, for its Renesas H8/38606 microcontroller. With artwork from the user’s retail firmware image and a supported Renesas compiler suite, the README reports a byte-identical rebuild of the 48 KiB image; without that image, original placeholder art gives a non-matching reference build. The author describes disassembling and decompiling the retail binary, the HeartGold/SoulSilver ROMs and the candidate compilers, alongside published hardware research. - Type: Case study - Targets: Firmware · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main branch is a single initial-release commit of 2026-09-14 with no tags or releases. The README calls the matching reconstruction complete for one image, 49,152 bytes with SHA-256 f9e210a3…d15607, and assumes it is the only Pokéwalker firmware. The source keeps 40 C90 modules whose file names encode the observed link order, and changes must preserve matching. - Users supply a lawfully obtained Pokéwalker firmware image, used only for artwork, and the Renesas H8, H8S, H8SX family C compiler package; neither is distributed, and the README withholds acquisition instructions. Only suites 6.02.01 and 6.02.02 are reported to reproduce the image. Missing artwork falls back to the bundled placeholders, which normally changes the output hash. - Builds are reported on macOS Arm64, where the 32-bit Windows compiler runs through Wibo and Rosetta, and natively on Windows x86_64; other hosts are unverified. uv supplies Python 3.11+ (3.12 by default), Ninja and Pillow from uv.lock, configure.py generates build.ninja, and macOS configuration downloads and validates the recorded Wibo release. - ninja verify requires the retail size and SHA-256 and writes verified.json; the build guide asks for that check under both compiler suites and records per-module input and output hashes to catch stale objects. Host unit tests cover the build utilities, a development check adds clang-format, Ruff and Cppcheck, and there is no CI workflow. Matching is author-reported. - Original project material is dedicated to the public domain under CC0 1.0, and the placeholder artwork carries its own CC0 notice; retail firmware and extracted artwork keep their rights. include/startup/iodefine.h is a retained Renesas HEW device header outside the CC0 dedication with no license grant, and the compiler-archive reader credits MIT-licensed ISx and Unshield. The project states no affiliation with Nintendo, The Pokémon Company, GAME FREAK or Renesas. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### wii-ipl: a decompilation of the Wii Menu (System Menu 4.3) > A work-in-progress decompilation of the Wii Menu, the console’s System Menu (IPL), targeting version 4.3 in its USA, European, Japanese and Korean builds. It recovers the menu’s own code together with the Revolution SDK, NintendoWare (NW4R), EGG and middleware libraries linked into it, matched unit by unit against the original executable with decomp-toolkit and objdiff. The repository holds no assets or assembly; a build needs the user’s own Wii Menu WAD and yields only main.dol. - Type: Case study - Targets: Firmware · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit has no releases or tags. decomp.dev’s report for that commit puts 4.3U at 58.5% matched code, 8,837 of 12,563 functions (70.3%) and 45.2% fully linked code, with the menu’s own code at 53.6% matched; library READMEs mark each RVL_SDK, NW4R, EGG, RevoEX and middleware component as matching, equivalent or not yet matching. The build yields main.dol, not a WAD, and the README warns that the code is not fully shiftable because no SEL file is generated. - Users supply their own Wii Menu 4.3 WAD for the selected version (4.3U by default, or 4.3E, 4.3J or 4.3K); the README states that the repository contains no assets or assembly of the executable. Each version’s configuration pins the SHA-1 of the target main.dol. - Builds need Python and Ninja on Windows, macOS or Linux. configure.py pins decomp-toolkit v1.7.5, objdiff v3.4.5, binutils 2.42-1 and the 20251118 compiler bundle for Metrowerks CodeWarrior (GC/3.0a5.2 as the linker version), and wibo runs the 32-bit Windows tools on macOS and Linux. CONTRIBUTING lists Ghidra with a shared project, IDA/Hex-Rays, m2c and decomp.me as decompiling aids and objdiff for diffing. - CI builds all four versions in a private container that supplies the original files, then uploads map files and progress reports; the percentages above come from those reports. - LICENSE is CC0 1.0. The BTE Bluetooth library notes code taken from Android’s bluedroid under Apache-2.0, and the GameSpy SDK subset is BSD-3-Clause. The decompiled third-party middleware (JustSystems ATOK, Zi eZiText, TMC JPEG, eSOL PrFILE2) and the Opera WWW headers carry no separate grants, and the Wii Menu keeps Nintendo’s rights. CONTRIBUTING forbids using AI to decompile code and asks contributors to avoid AI-only matching forks. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### sead: a decompilation of Nintendo’s first-party C++ standard library > Decompiles sead, the C++ standard library that Nintendo statically links into its first-party games, covering containers, heaps, strings, math, file devices, threads, the game framework and graphics. Compile-time presets target the recent versions used by Breath of the Wild, Super Mario Odyssey, Splatoon 3, Tears of the Kingdom and Super Mario Bros. Wonder, and game decompilations such as Breath of the Wild pull it in as a submodule. Names come from debugging symbols and assertions in retail titles, and the README warns that many inlined and templated names are guesses. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit (2026-10-11, no releases) derives from aboood40091/sead but targets newer sead versions. The README says several modules currently fail to build for Switch and points to a GitHub project page for progress; seadVersion.h adds a Super Mario Maker 2 preset and a custom feature set alongside the README’s list. - Building needs no game files. Checking accuracy needs the original sead, which ships only statically linked in games: the README advises legally owning a recent first-party title with debugging symbols, naming Super Mario Odyssey 1.0.0, Splatoon 2 up to 3.1.0 and the Nintendo Labo pilot build. - The README asks for a partially C++17-capable compiler such as Clang 3.9 or newer and CMake 3.10+. CMakeLists builds an object library only for the nin (nnSdk, Switch) platform and links NintendoSDK headers supplied by the host project, the old or new open-ead header repository depending on a migration option. The README also describes Wii U (cafe) sources and declares other platforms unsupported. - The README asks contributors to match non-inlined functions against the original assembly, tolerating only register-allocation or obviously harmless reordering differences marked NOT_MATCHING, and to undo inlining with help from pilot builds and assertions; MATCHING_HACK_NX_CLANG guards codegen hacks. The repository has no checker or progress data of its own, and CI only runs clang-format, so matching is checked in consumer projects. - No license file is present and GitHub detects none; the README says nobody outside Nintendo has sead’s source. res/ holds the decompiled primitive-renderer shader sources plus a 2 KB compiled Wii U shader binary that was updated alongside them. Nintendo’s games keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Animal Forest: an in-progress matching N64 decompilation > Rebuilds the Japanese Nintendo 64 release of Animal Forest (Dōbutsu no Mori) from C code reverse-engineered from the ROM, combined with assets and assembly extracted from a user-supplied ROM. Default builds compare the uncompressed and recompressed ROMs with stored MD5 checksums. The README rules out use as a port base or for commercial purposes, and decomp.dev reported 18.52% of code matched at the reviewed commit. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls this a work-in-progress decompilation whose codebase could change drastically and warns that some parts of the ROM may not yet be shiftable. The only configured version is jp, the Japanese N64 release, in both the Makefile and CI. The output is an N64 ROM; README states that the project is not a port and that serving as a port base or any commercial use is explicitly a non-goal. The GameCube Animal Crossing decompilation it links to is a separate project. - Supply your own Japanese Animal Forest ROM as the base ROM in baseroms/jp; .z64, .n64 and .v64 files are accepted. make setup decompresses it and checks the result against baseroms/jp/checksum.md5, then make extract uses splat to derive assembly and assets locally. The reviewed tree holds no ROM, graphics or binary asset files; game-derived content is limited to tables such as the DMA file table header and small address tables under src/objects. - README documents Linux, preferably Debian or Ubuntu, with make, Git, build-essential, clang, MIPS binutils and Python 3 with pip and venv; make venv installs pinned splat64 0.24.0 plus spimdisasm and mapfile-parser. The tools Makefile downloads static recompilations of IDO 5.3 and 7.1 from decompals/ido-static-recomp v1.2 and pigment64 0.6.3, and the build compiles libultra from the bundled ultralib subrepo. NON_MATCHING builds turn the checksum comparison off. - With COMPARE at its default, make rom and make compress check both ROMs against the stored MD5 values. Functions not yet decompiled remain extracted assembly included through GLOBAL_ASM. CI builds jp in a private container that supplies the base ROM and compiler archives, compares warning counts and uploads an objdiff-format report. decomp.dev's report for the pinned commit lists 465,796 of 2,515,744 code bytes (18.52%) and 2,998 of 14,415 functions matched, with no unit complete. - README licenses src and include, as far as possible, and other files that state no other license under CC0-1.0, excluding subrepos such as asm-differ, asm-processor, fado and ultralib. Nintendo's game, ROM contents and the downloaded compilers keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Phantom Hourglass: an early-stage matching Nintendo DS decompilation > Recreates C++ source for The Legend of Zelda: Phantom Hourglass by hand-decompiling its European and US Nintendo DS releases, using the dsd toolkit to delink code from a user-supplied ROM and rebuild the ROM. objdiff tracks matches function by function, and the default build compares the output ROM with a stored SHA-1. The work is at an early stage: decomp.dev reported 2.82% of code matched at the reviewed commit. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README marks the project as a work in progress that targets the European and American versions, with other versions possibly supported later; configure.py takes eur or usa. Decompilation covers the ARM9 program, its TCM modules and overlays, while docs/build_system.md says the ARM7 program is not decompiled. The output is a Nintendo DS ROM, not a PC port. - Supply your own decrypted base ROM for each version in extract/ as baserom_ph_eur.nds or baserom_ph_usa.nds, matching the SHA-1 values in extract/README.md; dsd then extracts code and assets from it locally. INSTALL.md calls a byte-matching ROM optional and requires the user’s own DS ARM7 BIOS file, matching one of two listed SHA-1 values, to produce one. README says the repository contains no assets or assembly; config/ does commit game-derived dsd delink, symbol and relocation tables for 65 modules per version. - INSTALL.md lists Windows (recommended) or Linux with Python 3.11+ and pip, GCC 9+, Ninja and pre-commit hooks; on Linux the Windows compiler runs through wibo by default, or Wine on request. configure.py downloads dsd v0.11.0, objdiff v3.4.0, sjiswrap v1.2.2 and wibo 0.6.16 from GitHub releases, and a Metrowerks mwccarm bundle (version 2.0/sp1p5 is used) from decomp.aetias.com. - The default ninja targets generate objdiff data, run dsd’s module and symbol checks and compare the built ROM with ph_eur.sha1 or ph_usa.sha1. CI builds both versions in a build container that supplies extracted files and the compiler, running the ARM9 link, objdiff report and checks but not the ROM hash. decomp.dev’s default usa report for the pinned commit lists 102,202 of 3,622,306 code bytes (2.82%) and 1,351 of 24,610 functions matched, with 28 of 190 units complete. - The repository carries CC0-1.0; that dedication does not cover Nintendo’s game, its extracted files, the BIOS or the downloaded Metrowerks compiler. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Kinoko: reimplementing Mario Kart Wii’s physics engine for exact ghost replay > Re-implements Mario Kart Wii’s physics engine in C++ as a command-line simulator, continuing stblr/Hanachan’s goal of perfectly accurate time-trial ghost replay. Each test case replays a recorded ghost through the engine and compares kart position, rotation, velocities, speed and checkpoint state frame by frame with a trace captured from the original game. It is a behavioural reimplementation of the physics only, not a matching decompilation, and has no graphical frontend. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README describes a C++ reimplementation of Mario Kart Wii’s physics engine aiming at perfectly accurate ghost replay. At the reviewed commit STATUS.md lists 55 time-trial ghost test cases, each marked synchronized for every frame; the latest GitHub release, 0.6 (2025-09-04), adds x86-64 Linux, macOS and Windows binaries of the simulator. Source comments name addresses in the original game, but nothing rebuilds its executable; README points to the separate riidefi/mkw matching decompilation for that. - Running needs the Race folder (the Common and course archives) from your own Mario Kart Wii disc, placed relative to the executable; the repository ships no game files, and README requires any contributed frontend not to distribute in-game assets. The committed samples are time-trial ghost files (.rkg) with per-frame .krkg reference traces that README says come from a custom vabold/mkw-sp build running the PAL release; such traces are verification data captured from the game, as is common for reconstruction projects. - README lists g++ 13.1 with C++23, ninja 1.3 and Python 3.6; configure.py generates the ninja build and compiles testCases.json into the binary suite file. CMakeLists.txt also exposes a libkinoko library target for embedding the engine in other C++23 projects. CI builds with GCC 14 on Ubuntu; the program is a command-line host with test and replay modes, and README says no GUI is planned. - kinoko test compares position, rotation, internal and external velocity, speed, acceleration, soft speed limit, race completion and checkpoint values with every .krkg frame by exact equality and reports the first desynchronized frame; kinoko replay checks whether a ghost finishes with the time in its .rkg header. CI runs the suite with runtime files fetched from a secret-configured URL and checks that STATUS.md is current. These are project-reported results. - LICENSE applies MIT (copyright vabold, 2022–2026) to the project; Mario Kart Wii and its game data keep Nintendo’s rights, and the bundled doxygen-awesome-css theme has its own license file. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Mario Kart: Double Dash!!: a matching GameCube decompilation of the debug build > A work-in-progress 1:1 decompilation of Mario Kart: Double Dash!! that rebuilds the GameCube main.dol of the US debug build (MarioClub_us) from C and C++ with the original Metrowerks compilers, checking it against a stored SHA-1. The build splits the binary from a user-supplied disc image, and objdiff compares objects during development. decomp.dev reported 47.09% of code matched at the reviewed commit; a European retail target is configured but marked as not working yet. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls this a WIP 1:1 decompilation and says only the debug version is supported: the default MarioClub_us (USA) target, whose main.dol SHA-1 config/MarioClub_us/build.sha1 records. configure.py also lists Release_eu, but its config.yml is marked as not working yet, and CI builds only MarioClub_us. The output is a GameCube DOL, not a PC executable or port. - Copy your own disc image of that build to orig/MarioClub_us; ISO (GCM), RVZ, WIA, WBFS, CISO, NFS, GCZ and TGC images are accepted. README says the repository contains no game assets or assembly: decomp-toolkit splits the user’s DOL using the committed symbol and split tables, and during the build extracts a font, system.arc and build-time data from that DOL locally. - Builds need Python and ninja on Windows (native tooling recommended), macOS (with wine-crossover) or Linux (an automatically downloaded wibo on x86, Wine elsewhere). configure.py pins decomp-toolkit v1.6.2, objdiff v3.3.1, binutils 2.42-1, sjiswrap v1.2.1, wibo 0.7.0 and the 20250812 compiler bundle, using Metrowerks GC/2.6 for game, JSystem, MSL and TRK code and GC/1.2.5n for the Dolphin SDK libraries. - Objects marked Matching (518 in configure.py; 277 remain NonMatching and 13 Equivalent) are compiled from source, the rest are taken from the split DOL, and the build checks main.dol against build.sha1. CI builds MarioClub_us in a container that supplies the disc files and compilers, uploads a progress report and validates symbol order for changed C++ files. decomp.dev’s report for the pinned commit lists 1,517,644 of 3,222,748 code bytes (47.09%) and 8,695 of 15,357 functions matched, with 518 of 807 units complete. - The repository carries CC0-1.0; Nintendo’s game, disc contents and the downloaded compilers keep their own rights. README credits JSystem and SDK code reused from other decompilations, including Metroid Prime, Pikmin 2, Super Mario Galaxy, Super Mario Sunshine and Twilight Princess. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### 3S Decomp: a byte-compared PS2 decompilation of Street Fighter III: 3rd Strike > Decompiles the PlayStation 2 executable of Street Fighter III: 3rd Strike from Street Fighter Anniversary Collection into C that period Metrowerks and EE GCC compilers rebuild, then compares the rebuilt executable word by word with the user’s original. README reports the game code fully decompiled and the CRI middleware partly so. The separate 3SX native port describes itself as this project’s continuation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README reports the game code fully decompiled and the CRI middleware partly decompiled, with most file-system and sound functions the game uses matching; cri-progress.md checks off 497 of the 503 CRI functions it lists. At the reviewed commit, two game functions (sea_write and mlt_obj_trans_rgb_ext) and 39 of 52 CRI C files still include assembly in the PS2 build, and PS2 SDK and GCC library code is out of scope. The output is the PS2 executable, not a PC port. - Building needs THIRD_U.BIN from the user’s own copy of the game; the split configuration records its SHA-1 as cf58495054c31ad852175c66e9ca04d5094f000e, and make split derives the assembly and linker script from it. The decompiling guide also relies on the executable’s DWARF debug data, dumped with decomp-toolkit, for signatures and local variables. A separate split_cps3 target for the CPS3 arcade version needs a user-supplied arcade ROM set and has only a code-segment configuration. - The build guide covers Linux (Debian packages with i386 support, MIPS binutils, and a Python venv with splat64 0.29.0 and spimdisasm 1.35.0) and macOS through the provided Dockerfile. make setup_tools downloads Metrowerks mwccps2 3.0b38 and EE GCC 2.96 from decomp.me’s compiler releases plus the wibo loader for Windows tools; m2c, asm-differ, mwccgap and saturn-splitter are git submodules. - A successful build ends with compare_bytes.py checking the rebuilt executable against the original from offset 0x80 to 0x478A00 and printing “Files match ✅”. That check tolerates 163 listed words in about 20 game and CRI functions, attributed to register and operand swaps, assert line numbers, string encoding, a misplaced nop and a call misalignment, so equivalence is near-byte-level by the project’s own check rather than a whole-file hash. The latest commit removed the GitHub Actions workflows. - LICENSE is AGPL-3.0 for the project’s code. The original executable and game content keep their own rights; include/cri carries headers marked “CRI Middleware SDK” and “Copyright (c) … CRI-MW”, and the vendored zlib keeps its own license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### Halo: Combat Evolved: an incremental re-implementation patched into the original Xbox executable > A research project re-implementing the original Xbox Halo: Combat Evolved in C, one function at a time. Rewritten functions are compiled into a separate image and patched into the user’s original executable with redirects from the original implementations, so the hybrid game can be run and debugged in xemu or on an Xbox as work progresses. The project reports an early stage, and its sources document no byte-for-byte comparison with the original code. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README describes studying and creating a free, open-source re-implementation of the Xbox launch title; its current-state list reports that the patched game runs, the main loop and several more functions are re-implemented, and there is a long way to go. The linked progress page, whose data file was last modified in November 2022, reports 0.37% of the .text section’s game code across 40 functions. The last default-branch commit is dated 2023-07-07. - Supply the retail disc’s game files and the original executable version 01.10.12.2276, identified by MD5 in README and kb.json and placed as cachebeta.xbe in a halo-patched directory; tools/patch.py checks that hash. The repository includes no game executable or assets, and README says they must come from your own copy. The build writes a patched default.xbe beside them as the user’s local modified copy; the project distributes no game build. - Builds use CMake 3.16+, Python 3 with libclang, pefile and pyxbe, and either 32-bit MSVC on Windows or Clang and LLD targeting i386-pc-win32 on Linux and macOS; a Dockerfile provides an Ubuntu 22.04 build image. The result targets the original Xbox and runs in the xemu emulator or on console hardware, and the build generates a .gdbinit for debugging with GDB through xemu’s GDB server. - kb.json declares 323 original functions and 71 data items with addresses, grouped by original object file; tools/knowledge.py generates headers, thunks and an import library from it, and gen-struct-checks.py emits static size checks for types.h. CI builds only the re-implementation image (Debug and Release on Ubuntu, Windows and macOS) without original files, so it checks compilation, not behaviour. - The repository has no license file and GitHub detects none, so reuse terms for the project’s code are not stated; src/xboxkrnl.exe.def carries a CC0-1.0 notice (2017, Stefan Schmidt). README presents the work as educational research, the progress page says it is not affiliated with Microsoft or Bungie, and the game keeps its rights holders’ terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Paper Mario: The Thousand-Year Door: an early matching GameCube decompilation > A work-in-progress matching decompilation of Paper Mario: The Thousand-Year Door that targets the Japanese Rev 0 GameCube release (G8MJ01), rebuilding MarioSt.dol and 31 REL modules with the original Metrowerks compilers and checking each against a stored SHA-1. The build splits these binaries from a user-supplied disc image, and objdiff compares objects during development. decomp.dev reported 12.10% of code matched at the reviewed commit. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README lists one supported version, G8MJ01 (Rev 0, JP); configure.py defines no other version and CI builds only G8MJ01. README still carries template leftovers: its badges point at another project, its clone command names NWPlayer123/G8MJ01-dtk and one line calls G8MJ01 the USA version. The output is a GameCube DOL and REL set, not a PC port. - Copy your own G8MJ01 disc image to orig/G8MJ01; ISO (GCM), RVZ, WIA, WBFS, CISO, NFS, GCZ and TGC images are accepted. README says the repository contains no game assets or assembly: decomp-toolkit splits main.dol and the RELs using committed symbol and split tables, and extracts the memory-card icon and banner textures from the DOL into local headers. Decompiled sources such as src/pmario_sound.c also carry game data tables reconstructed as C. - Builds need Python and ninja on Windows (native tooling recommended), macOS (with wine-crossover) or Linux (an automatically downloaded wibo on x86, Wine elsewhere). configure.py pins decomp-toolkit v1.8.3, objdiff v3.7.1, binutils 2.42-2, sjiswrap v1.2.2, wibo 1.1.0 and the 20260305 compiler bundle, using Metrowerks GC/2.6 for game and REL code and GC/1.2.5n for the Dolphin SDK. tools/ttydasm is a Rust helper that decodes a named event script from the linked DOL or REL outputs in build/G8MJ01. - Objects marked Matching (100 of 547 in configure.py) are compiled from source and the rest come from the split originals; the default ninja target checks the DOL and all RELs against config/G8MJ01/build.sha1 before reporting progress. CI builds G8MJ01 in a container that supplies the disc files and compilers and uploads a progress report. decomp.dev’s report for the pinned commit lists 457,800 of 3,784,980 code bytes (12.10%) and 2,029 of 9,770 functions matched, with 100 of 1,239 units complete. - The repository carries the MIT License (copyright NWPlayer123), and libs/musyx has its own MIT license; neither covers Nintendo’s game, disc contents or the downloaded compilers. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### 3SX: a native Street Fighter III: 3rd Strike port continuing the PS2 decompilation > Builds Street Fighter III: 3rd Strike as native C for Windows, macOS and Linux, continuing the 3s-decomp PS2 decompilation, with SDL3 for video, input and audio and GekkoNet for rollback netplay. README stresses that it is neither a recompilation nor emulation. The port needs the player’s own PS2 game files and works toward arcade-accurate balance, which an optional Statcheck build tests against CPS3 RAM states recorded from Fightcade replays. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls 3SX a native port and a continuation of 3s-decomp, explicitly neither a recompilation nor emulation. At the reviewed commit the game code under src/sf33rd has no remaining INCLUDE_ASM stubs, and src/port supplies SDL3 platform, input and sound layers, including its own ADX decoder. This is a modified port: its goals include fixing balance regressions the PS2 version introduced, and the arcade-balance option is marked work in progress. The only release is a rolling pre-release rebuilt from main, and goals such as stable PC play and the arcade ROM as sole dependency remain on the 1.0 milestone. - Play requires a legally obtained PS2 copy of Street Fighter III: 3rd Strike or Street Fighter Anniversary Collection: a startup wizard reads the user’s disc image, or SF33RD.AFS from it is placed in the resources folder, and release builds compare that file with a SHA-256 in resources.c. The arcade-balance option also needs the user’s sfiii3nr1.zip CPS3 ROM set. The tree ships no game archives, but src/bin2obj carries large C data tables from the decompilation. - Prebuilt rolling releases cover Windows, macOS, and x86_64 and arm64 Linux. Source builds use CMake 3.24+ with Clang, after MSYS2 MinGW64 packages on Windows, the listed Ubuntu packages or Xcode Command Line Tools on macOS; build-deps.sh fetches and builds SDL3, SDL_net, GekkoNet, libcdio, minizip-ng and TF-PSA-Crypto. CMake and CI also carry a PSP branch built with Docker tooling. - Pull-request CI only builds the Windows, macOS, Linux and PSP targets. Arcade accuracy is checked with the optional Statcheck build: tools/fcade-replays, described as a reverse-engineering helper for Fightcade’s replay stream, downloads replays; a custom FBNeo fork records per-frame CPS3 RAM dumps; and Statcheck stops at the first mismatch in health, positions, stun, super-art meter, timer or round phase. The reviewed tree publishes no Statcheck results. - The repository carries an agent skill with a Codex interface file. It directs a coding agent to compare local functions with a CPS3 program through a read-only Ghidra MCP server, mark each function’s parity and add CPS3 behaviour behind the arcade-balance flag. LICENSE is AGPL-3.0. THIRD_PARTY_NOTICES lists GPLv3+ libcdio with zlib, BSD-2-Clause, MIT and Apache-2.0 components, the game and its assets keep their own rights, and README says the project does not condone piracy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. #### re4: a byte-identical decompilation of the Resident Evil 4 GameCube debug build > Reconstructs C and C++ source for the two-disc Resident Evil 4 GameCube debug prototype (G4BE08) and rebuilds main.dol and all 114 REL overlays with the compilers the README names, checking every output against a SHA-1 list. Function names are Capcom’s own from the debug build’s Bio4.sym files, and most struct and field names are aligned from the PS2 debug build’s debug information. The project’s research log says AI agents did the matching work; byte identity is project-reported. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-10-02 head, under four weeks after the first commit of 2026-09-07. README calls the decompilation complete: every unit compiles to the original bytes, src/ holds about 570,000 lines of C and C++ with no assembly files, and 526 `// COMPILER-DIFF:` spots coax the compiler’s register or instruction choices without emitting code. Nearly all remaining inline assembly is in routines the vendors also wrote in assembly. The output is the debug prototype’s DOL and RELs, not a retail build or PC port. - Supply your own images of both debug discs in orig/G4BE08/: disc 1 provides main.dol and most RELs, disc 2 the four island-stage RELs, and configure.py also reads the matching Bio4 symbol files from them. The game code’s compiler is built from SN Systems’ GPL source release of its ProDG 3.9.3 GCC port, which the user also supplies. The repository contains no game assets. - The documented host is Linux with Python 3 and ninja. tools/sn-gcc/build.sh builds SN’s GCC 2.95.3 (SN BUILD v1.79) natively once with the project’s Linux-host and memory-flag patches; CRI middleware builds with Metrowerks CodeWarrior 2.4.7 and the Nintendo SDK, taken from dolsdk2004, with GC/1.2.5n. The first configure run downloads pinned decomp-toolkit, objdiff, wibo and CodeWarrior compiler releases. - A successful build should end with ninja reporting 100% matched and linked, and dtk shasum against config/G4BE08/build.sha1 should print OK for all 115 binaries; tools/bytecmp.py compares single units and tools/asmcheck.py --all counts instructions emitted from asm templates, a total changes must not alter. The repository has no CI workflow or release, so these results are project-reported. - LICENSE applies CC0 only to the project’s build scripts, tools, configuration and documentation. README and LICENSE state that the reconstructed game, SDK and middleware source in src/ and include/ remains the property of Capcom, Nintendo and CRI Middleware and is published for research and preservation only. docs/research/README.md describes its matching notes as written by the AI agents that did the matching work. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Super Smash Bros. Brawl: an early matching Wii decompilation > A work-in-progress matching decompilation of Super Smash Bros. Brawl that targets the USA Rev 2 Wii release (RSBE01_02), splitting main.dol and 126 REL modules from a user-supplied disc image and checking the rebuilt binaries against stored SHA-1 values. objdiff compares objects during development, and six other regional revisions are listed but commented out of the supported set. decomp.dev reported 1.27% of code matched at the reviewed commit. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README lists one supported version, RSBE01_02 (USA Rev 2), with the Japan, USA Rev 1, PAL and Korea revisions commented out; configure.py names all seven, but only RSBE01_02 has a configuration and CI builds only it. The output is a Wii main.dol and REL set, not a PC port. - Copy your own disc image to orig/RSBE01_02; ISO (GCM), RVZ, WIA, WBFS, CISO, NFS, GCZ and TGC images are accepted. README says the repository contains no game assets or assembly: decomp-toolkit splits the DOL and RELs using committed per-module symbol and split tables, and extracts one embedded binary (HomeBtnIcon) from the DOL locally. Game headers come from the BrawlHeaders submodule (Sammi-Husky/BrawlHeaders), which README says to initialize before building. - Builds need Python and ninja on Windows (native tooling recommended), macOS (with wine-crossover) or Linux (an automatically downloaded wibo on x86, Wine elsewhere). configure.py pins decomp-toolkit v1.7.5, objdiff v3.4.4, binutils 2.42-1, sjiswrap v1.2.2, wibo 1.0.0 and the 20250812 compiler bundle, compiling and linking with Metrowerks GC/3.0a5.2. - Objects marked Matching (184 in configure.py; 20 remain NonMatching) are compiled from source and the rest come from the split originals; the default ninja target checks main.dol and the RELs against config/RSBE01_02/build.sha1 before reporting progress. CI builds RSBE01_02 in a container that supplies the disc files and compilers and uploads a progress report. decomp.dev’s report for the pinned commit lists 201,252 of 15,833,548 code bytes (1.27%) and 2,504 of 92,523 functions matched, with 516 of 4,415 units complete. - The repository carries CC0-1.0; Nintendo’s game, disc contents and the downloaded compilers fall outside that dedication, and the BrawlHeaders submodule declares no license on GitHub. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### re-plants-vs-zombies: decompiling and modernizing Plants vs. Zombies GOTY > Reconstructs C++ source for Plants vs. Zombies on PopCap’s open-source SexyAppFramework, starting from an earlier community decompilation of version 0.9.9 and adding functionality reversed from the Game of the Year edition, with functions annotated by GOTY addresses. The project also modernizes the engine with current C++ and is replacing the DirectDraw and Direct3D 7 renderers with GLFW. It builds a fan executable that runs from an original game folder, aiming at a modernized, extensible game rather than an identical binary. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README describes decompiling the latest functionality of the first PvZ title and expanding the game and its engine, building on a since-deleted 0.9.9 decompilation by Miya (rspforhp) that it credits ruslan831 with archiving. Its roadmap marks x64 support and achievements as partial, the GLFW renderer and cross-platform replacements as in progress, and Zombatar and a modding API as not done. There are no releases; the last commit is dated 2026-07-11. - Playing needs the original game files from a purchased copy; README links the Steam Game of the Year Edition but names no exact executable version. The built executable is run from that game folder, and the audio code loads bass.dll or fmod.dll at runtime instead of linking a committed copy. README says the repository includes no PopCap IP beyond the open-source engine; Resources.cpp/.h reconstruct the game’s generated resource-ID tables, data derived from the game as is usual for such projects. - Builds use CMake 3.16+ and C++23. README documents Visual Studio Community, whose CMakeSettings.json has x86 and x64 MSVC configurations, or CMake with Ninja; toolchain.cmake cross-compiles with x86_64-w64-mingw32 Clang and windres. The reviewed build produces a Windows executable, and the repository has no CI workflow. - The sources document no tests, CI or comparison with the original executable; contributors annotate reversed functions and class members with their GOTY addresses. Fidelity to the original game is not measured. - LICENSE dedicates the repository under CC0 1.0. The SexyAppFramework code derives from the engine PopCap made public, but PopCap’s license text is not included; the ogg code keeps Xiph.org’s BSD-style notice, and the FMOD 3 (Firelight, 1999–2002) and BASS 2.4 (Un4seen, 1999–2022) API headers keep their vendors’ copyrights. The original game and its files keep their rights holders’ terms. README says the project does not condone piracy. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Sonic Advance 1 & 2: a matching GBA decompilation with widescreen ports > Reconstructs Sonic Advance and Sonic Advance 2 for the Game Boy Advance as C that rebuilds six hash-listed ROMs with SAT-R’s agbcc fork, and compiles the same code into widescreen SDL ports for Linux, macOS and Windows plus PSP and PS2 builds. README reports Sonic Advance 2 built entirely from C with about 60 functions still non-matching. Extracted graphics, music and data are committed, so the builds read no original ROM. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README marks the project unfinished and under active development. It lists six ROM targets with SHA-1 values: Sonic Advance (Europe) and Sonic Advance 2 (USA, Europe, Japan, Japanese Virtual Console and a 2002-10-25 USA beta). README reports that SA2 builds 100% from C with about 60 non-matching functions pulled in from asm/non_matching, which at the reviewed commit holds 64 SA2, 99 SA1, 17 shared and 8 engine files, and that over 600 SA2 functions are unnamed. The Tiny Chao Garden and Collect Rings multiboot sub-games are built for matching and only partly decompiled. - The documented builds read no original ROM. The tree commits over 12,000 PNG sprite frames and tiles, 474 MIDI songs, tilemaps and other raw data, including a 191 KB data file included piecewise into the Tiny Chao Garden multiboot ROM. Port CI jobs still download a base ROM from private storage, which the Makefile does not reference. - INSTALL.md targets Linux (with WSL for Windows users) and macOS: ARM GCC and binutils, libpng, SDL2 and MinGW-w64, plus mkisofs or cdrtools for PS2. Matching GBA builds need SAT-R’s agbcc fork built and installed into the tree. Ports build with make sdl (Linux/macOS), sdl_win32 (Windows), sdl_psp (PSPDEV) and ps2 (PS2DEV) at a 426×240 widescreen resolution; README marks the Win32 OpenGL target not functional, and no GitHub release is published. - On the GBA platform, make runs a SHA-1 check of the built ROM against its listed hash. CI checks formatting, then builds and hash-checks SA2 USA, SA1 Europe and the four other SA2 variants; it also builds SDL, Win32, PSP and PS2 port targets for both games on Ubuntu and macOS, and replays a committed any% speedrun input recording through a headless SDL build. Matching applies to the GBA ROMs, not to the widescreen ports. - The repository has no license file and GitHub detects none. The extracted graphics, music and data, and the Nintendo SDK libraries rebuilt in libagbsyscall, m4a and agb_flash, keep their rights holders’ terms. README sets a strict no-LLM/no-AI policy for issues and pull requests. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Paleblood: a functional decompilation of Bloodborne with its own runtime > Rewrites code from Bloodborne’s PS4 executable (CUSA03173 with update 1.09) as readable C++, one function at a time, aiming at a native PC source port on a clean-room runtime of its own. It is a functional rather than matching decompilation: each replacement is hooked in, compared with the original machine code on recorded and generated inputs, and independently reviewed. Work is at an early stage: README reports 21 of 157,757 functions verified, and the game does not yet run on Paleblood’s own runtime. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-10-19 head, 12 days after the first commit. The generated status reports 31 functions replaced and 21 verified out of a 157,757-function Ghidra export; the project’s loader maps the executable, and its boot stops at the first unimplemented system call with 247 of 686 system imports implemented. Replacements cover parts of the frame loop and the event, kernel, input, AI, character, physics and render layers, and BB_TARGET_FPS reproduces three community frame-rate patches in code. - Requires Bloodborne CUSA03173 (EU) with the 1.09 update, dumped from the user’s own PS4; the executables converted from it must match target.sha256. README says the repository holds no game code, assets, binaries, decompiler output or extracted data, a check rejects game data in the pre-commit hook and CI, and the project does not provide or point to game files, pkgs, firmware, keys or decryption tools. - Development is documented on Linux with CMake 3.20+ and CTest, plus Ghidra 12.0.3 with the GhidraOrbis loader for analysis. Full game runs still use an external scaffold: third_party/bbport, the project’s fork of the GPL-2.0-or-later bloodborne_pc port, which runs the original executable natively with shadPS4-derived Vulkan rendering. CI does not fetch that submodule. - README says tools/verify.py runs the original code and a replacement side by side, comparing return values, registers, every byte written and every library call, and that deliberately wrong versions must fail; options that replace a community patch are checked against the original with that patch applied. CI builds with GCC and Clang and runs unit, harness and policy checks without game data, so verification against the game is contributor-run and project-reported. - GPL-2.0-or-later per LICENSE; the bbport scaffold has its own GPL-2.0-or-later notice, which README says grants no right in the game or its code. README calls Paleblood a fan project unaffiliated with Sony Interactive Entertainment or FromSoftware and describes the runtime as clean-room. CONTRIBUTING.md allows disclosed, verified AI-assisted work, and recent commits carry Co-Authored-By trailers naming Claude Opus 5.5 and Codex. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Pikmin 2: a fully matched GameCube decompilation across five releases > A fan decompilation of Pikmin 2 that rebuilds main.dol for five GameCube releases (USA retail, two USA demos, PAL and Japan) with the original Metrowerks compilers, checking each against a stored SHA-1. The build reads main.dol from the user’s own copy of each release. decomp.dev reported all code matched and fully linked for every version at the reviewed commit, and a non-matching mode builds the US DOL entirely from C++ for modding. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README still calls this a work-in-progress decompilation and lists five supported versions: GPVE01 (USA retail, the default), GPVE01_D17 and GPVE01_D18 (USA demos 17 and 18), GPVP01 (PAL) and GPVJ01 (Japan). Each has its own configuration and SHA-1 file, and CI builds all five. Outputs are GameCube DOLs, not a PC executable or port. - Each version needs main.dol from the user’s own copy of that release at orig//sys/main.dol, and decomp-toolkit checks it against the hash in that version’s config.yml before splitting. The repository commits game-derived symbol and split tables for every version; config comments say the GPVE01 symbols were generated from a pikmin2UP.MAP linker map and the Japanese and PAL tables were recovered from those DOLs using the US symbols. No disc images or extracted game files are included. - Builds need Python and ninja on Windows (native tooling recommended), macOS (with wine-crossover) or Linux (an automatically downloaded wibo on x86, Wine elsewhere). configure.py pins decomp-toolkit v1.7.5, objdiff v3.4.1, binutils 2.42-1, sjiswrap v1.2.2, wibo 1.0.0-beta.5 and the 20250812 compiler bundle, using Metrowerks GC/2.6 for game, JSystem and runtime code and GC/1.2.5n for the Dolphin SDK libraries. - configure.py marks 1,154 objects Matching for every supported version and one more for Japan only; none is NonMatching. The default ninja target checks the linked DOL against config//build.sha1 before reporting progress, and CI builds all five versions in a container that supplies the original files and compilers. decomp.dev’s reports for the pinned commit list 100.00% of code matched and fully linked for each version (24,957 functions and 1,153 units for GPVE01). - With --non-matching, README says the final hash check is disabled and the US DOL builds completely from C++ source that is, to the team’s knowledge, functionally equivalent, so every file can be edited for modding. The repository carries CC0-1.0 in LICENSE.MD; Nintendo’s game, its files and the downloaded compilers fall outside that dedication. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Gran Turismo 4: an agent-assisted PS2 engine matching decompilation > Decompiles Gran Turismo 4’s PS2 engine executable (CORE.GT4, NTSC-U v1.01) into one C or C++ source per function for Sony’s ee-gcc 2.96, matching public libraries such as newlib and Expat from their own source. The README credits AI agents (Anthropic’s Claude) driving the project’s tools with most of the matching, each function accepted only on a compiler-and-judge comparison, and reports 95.4% of functions and 83.6% of code bytes matched for an October 2026 commit. A local full build links sources at their original addresses, fills the rest from disassembly and compares SHA-1 with the user’s executable. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README describes a work-in-progress matching decompilation of the engine executable only: most game logic lives in Adhoc scripts, which the separate OpenAdhoc project re-creates, and the separate GT4 Native PC port is described as not playable. The progress-branch report for commit ba5d800 (2026-10-19), which decomp.dev also shows for the reviewed commit, gives 29,551 of 30,962 functions and 83.55% of code matched, 82.08% of code linked from source and 2.13% of data placed from source; 202 hand-written assembly functions are not counted. - Supply your own Gran Turismo 4 (USA) v1.01 disc image (SCUS-97328); orig/README.md lists SHA-1 values for SCUS_973.28, CORE.GT4 and the ELF converted from it. Nothing from the game is committed, so the SHA-1 build check and the progress reports run only where those files are present, not in CI. - Documented for Linux or WSL (Ubuntu) with Python 3.11+ and rabbitizer. tools/setup_linux.sh installs MIPS binutils and 32-bit libc, downloads decomp.me’s ee-gcc 2.96 build, clones decomp-permuter and installs splat in a virtual environment; project.toml names further decomp.me compilers, including ee-gcc 2.9 for about 270 Sony SDK functions. - A function counts as matched when tools/match.py (or the agents’ tools/swarm.py) prints MATCH, and tools/build.py links every function at its original address and compares SHA-1 of the loaded segments. CI runs unit tests, an assembly-in-C policy check and layout checks and compiles every source, but cannot link or compare without the game; matching figures are author-reported. - MIT for the project’s tools, documentation and source. THIRD_PARTY.md lists matched public libraries under their own terms (Expat, newlib, GNU libio and the GCC runtime under GPL with exceptions, SGI STL headers, MT19937), which build.py --without can leave out, and records proprietary SCE-RT/Medius, Logitech and Sony SDK code as identified but not copied. Gran Turismo 4 belongs to Sony Interactive Entertainment. Agent instructions are in AGENTS.md, CLAUDE.md and .claude/. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Mario Kart Wii: an in-progress matching decompilation of the PAL release > A work-in-progress matching decompilation of Mario Kart Wii that targets the PAL release (RMCP01), rebuilding main.dol and the StaticR.rel module from C and C++ with Metrowerks compilers and checking both against stored SHA-1 values. The build splits these binaries from a user-supplied disc image, and objdiff compares objects during development. The README’s progress badges point to a decomp.dev page that did not resolve at review, and the default branch was last updated in September 2025. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README lists one supported version, RMCP01 (PAL); configure.py defines no other and CI builds only RMCP01. The repository was renamed from riidefi/mkw, which README’s badges and clone command still use, and CONTRIBUTING.md and HACK.md still describe an earlier mkwutil and ppcdis build layout that the pinned tree no longer contains. The output is a Wii main.dol and StaticR.rel, not a PC port. - Copy your own RMCP01 disc image to orig/RMCP01; ISO (GCM), RVZ, WIA, WBFS, CISO, NFS, GCZ and TGC images are accepted, and config.yml records the expected SHA-1 of both binaries. README says the repository contains no game assets or assembly; decomp-toolkit splits main.dol and StaticR.rel locally using the committed, game-derived symbol and split tables. - Builds need Python and ninja on Windows (native tooling recommended), macOS (with wine-crossover) or Linux (an automatically downloaded wibo on x86, Wine elsewhere). configure.py pins decomp-toolkit v1.3.0, objdiff v2.4.0, binutils 2.42-1, sjiswrap v1.2.0, wibo 0.6.16 and the 20240706 compiler bundle, using Metrowerks Wii/0x4201_127 for the game, NW4R, EGG, RFL and MSL code and as the linker, and GC/3.0a5.2 for the Revolution SDK, TRK, DWC and GameSpy libraries. - Objects marked Matching (106 of the 213 listed in configure.py; 105 NonMatching, 2 Equivalent) are compiled from source and the rest of each binary comes from the split originals; the default ninja target checks main.dol and StaticR.rel against config/RMCP01/build.sha1 before reporting progress. CI builds RMCP01 in a private container holding the original files and uploads a progress report. decomp.dev had no report for the repository under either name at review. - The repository carries CC0-1.0; lib/gamespy keeps the GameSpy SDK’s own BSD-style license from IGN Entertainment, and Nintendo’s game, disc contents and the downloaded compilers keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Pinyon Shift: a ShiftGlue static recompilation of Forza Horizon for PC > Builds a native port of the Xbox 360 release of Forza Horizon by translating its PowerPC executable ahead of time into C++ with ShiftGlue, the author’s fork of ReXGlue, and compiling it on the player’s machine from their own disc. A renderer written for this game runs its GPU commands on Vulkan, and some translated library code, such as FMOD Ex DSP units, is replaced by independently written native code checked against the translated original. README presents it as a playable preview with rendering bugs and slowdowns. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-10-17 head, tagged v0.6.0; the repository was created on 2026-08-25. It holds the launcher, build tools, host code and configuration, and README says it contains no game, assets, generated translations or prebuilt executable; the v0.6.0 Windows launcher archive holds only the launcher and a source archive. This is static recompilation with native replacements, not recovered authored source. - Requires an ISO dumped from the user’s own USA retail disc (serial MS-2505, title ID 4D5309C9) or an unmodified folder extracted from it; setup checks its exact size and SHA-256 against config/supported-dumps.json and rejects unknown dumps. Owned DLC packages are verified before import, and the Rally and 1000 Club add-ons need the optional title update v4 build. - Players need Windows 10/11 x64, x86-64 Linux including SteamOS, or macOS 13+ on Apple silicon, with a Vulkan 1.3 GPU; NVIDIA is tested, while AMD and Intel are not yet qualified. The launcher installs pinned build tools and builds the game locally, which takes 20–60 minutes and about 30 GB the first time; the Windows source path needs Visual Studio 2022 C++ Build Tools 17.1+. An Android 13+ arm64 build is a developer alpha cross-compiled on the PC. - CI checks the repository boundary, runs release-tooling and host tests, builds the launchers and cross-builds the Android runtime, all without the game. Scripted render-test routes, golden frame replays and README’s performance figures, such as a 119 fps median at 1x on an RTX 4080, come from the project’s local runs. - BSD-3-Clause covers only independently authored material. docs/LEGAL.md says it grants no rights to Forza Horizon, Xbox software, ReXGlue or user-supplied content, and bars committing generated translations, hand translations of disassembly or decompiler output, and data copied from the executable. README states no affiliation with Microsoft, Xbox, Turn 10 Studios or Playground Games. CLAUDE.md and AGENTS.md agent instructions bar AI attribution in commits. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Touhou 7: reconstructing Perfect Cherry Blossom 1.00b source > Reconstructs C++ source for the Windows executable of Touhou 7: Perfect Cherry Blossom 1.00b and its custom.exe configuration tool, built with the original Visual Studio .NET 2002 and DirectX 8 toolchain and compared function by function with the user’s originals through reccmp. The committed progress badges report th07.exe fully implemented at 99.78% accuracy and custom.exe fully matched. The README says the game should be fully playable, but a matching build trips the game’s integrity check, and the cross-platform ports live on separate branches. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls this a work-in-progress matching decompilation of th07.exe 1.00b and custom.exe; the committed, mutable badges report 694 of 694 th07.exe functions implemented at 99.78% accuracy, and custom.exe at 100% for both. Behaviour is meant to match the original but may differ. The portable and reallyportable branches (desktop, mobile and web ports) are separate. README credits the GensokyoClub th06 and th08 decompilations for shared types, names and code. - Supply your own th07.exe 1.00b (README gives its MD5, reccmp-project.yml its SHA-256), copied to resources/, for icon extraction and as reccmp’s comparison base; custom.exe is needed only for the configuration tool, and --no-icon builds without either. No game executable or game data files are committed; resources/csv holds the function, global, string and float tables reccmp uses. - This branch builds only for 32-bit Windows with the MSVC 2002 toolchain, run under Wine on Linux, and needs uv and ninja. scripts/download_deps.py fetches Visual Studio .NET 2002 and the DirectX 8 SDK from archive.org and EstexNT’s var_order compiler patch from a gist; scripts/build.py generates and runs the ninja build. - Contributors diff with reccmp, which reports per-function accuracy against the original as an HTML page or for one address. Because th07.exe is not yet byte-identical, README says a matching build fails the game’s integrity check and crashes after 3,999 Supervisor cycles; --no-matching disables that check. The repository has no CI; badge figures are project-generated. - CC0 1.0 for the repository; the game and the downloaded Microsoft toolchain and SDK keep their own terms. resources/svgicon.png, embedded in the progress badge, is the game’s cover artwork marked © 2003 Team Shanghai Alice, which the CC0 dedication does not cover. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### DKC1Recomp: static recompilation of Donkey Kong Country > Statically recompiles the North American v1.0 SNES release of Donkey Kong Country into native Windows, macOS and iOS applications with a pinned fork of snesrecomp, which translates 65816 code to C and links it against a modelled SNES hardware runtime. Function boundaries, entry flag states and jump-table targets are ingested from a byte-identical community disassembly instead of discovered heuristically, and the game code is generated locally from the user’s verified ROM. Optional widescreen, CRT filters, MSU-1 music and a Dixie Kong Country variant are host-side additions to what the README calls a playable bring-up. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the main commit tagged v0.0.14 (2026-09-15); releases v0.0.15 to v0.0.17 (through 2026-09-19) are tagged on commits that are not on main. README reports a playable bring-up with fully statically generated game code, a headless validation host and Windows, macOS and iOS hosts. Widescreen, on by default in the desktop host, fails closed to stock output or black margins where a scene is unproven; the generated widescreen coverage report lists 252 of 256 level entrances as never observed, and the Dixie variant is not validated over the full game. - Supply your own headerless Donkey Kong Country (USA) v1.0 ROM of 4 MiB, checked against the SHA-256 in the README; other images are rejected unless a single audited data-only edit is pinned by its hash. The optional Baby Kong mod also verifies the user’s own North American DKC3 ROM in memory. README states that no ROM bytes, extracted assets or generated game code are committed; the Dixie variant embeds the hack author’s public IPS patch, which the project records as a deliberate exception applied only to the verified clean ROM. - A source build initializes the snesrecomp submodule and runs scripts/generate_snesrecomp.py against the ROM, writing C into the git-ignored generated/ directory; recomp/*.cfg holds only names, addresses and structural metadata from the GPL-3 Yoshifanatic1 disassembly. Windows builds need Windows 10/11 x64, Visual Studio 2022 C++ tools, Python 3, Git, CMake, Ninja and an OpenGL 3.3 GPU; the arm64 macOS app targets macOS 26 with CMake, Ninja and SDL2, and the iOS sideload IPA needs iOS/iPadOS 16 or newer and re-signing for the recipient’s device. - Verification is deterministic tooling rather than a matching build: a headless host with input playback, replayable flight-recorder bundles, save-state continuity checks, route recipes and regression contracts, plus C and Python model tests, many of which need the private ROM. The reviewed tree has no CI workflow; the bring-up log reports nine private boot replays and inspection of the live window for the v0.0.10 Windows host. - Project host and tooling code is MIT; the pinned snesrecomp fork is under the PolyForm Noncommercial License 1.0.0, the cfg metadata keeps its GPL-3 provenance, the Windows package adds SDL 2.30.9 (zlib) and miniz 3.0.2 (MIT), and Nintendo and Rare keep their game rights. AGENTS.md sets operating rules for Codex and other coding agents working in the repository. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### San Andreas Unity: a GTA San Andreas engine reimplementation in Unity > Reimplements the Grand Theft Auto: San Andreas engine in Unity (C#), loading the archives, RenderWare models and textures, collision, animations, audio, text and item definitions from the user’s own PC installation. README says it will not be a complete reimplementation; it focuses on gameplay features, multiplayer and a framework for extending and modding the game through C# plugins. Development has stalled: the newest commit on any branch dates from 2022-09-30. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the head of the default dev branch, committed 2022-09-30; no branch has a later commit, GitHub records the last push on 2023-06-16 and the latest release is v4.0 (2022-05-24), so the project appears inactive. README says it will not be a complete reimplementation and focuses on gameplay, multiplayer and a moddable framework; Docs/TODO.md still lists work such as asynchronous geometry loading and unloading distant parts of the world. - Play requires a PC installation of GTA San Andreas that the user owns: on first start the game asks for its path, and config.json points the loaders at data files such as gta.dat, the vehicle, ped and default .ide files, handling.cfg, water.dat, carcols.dat and weapon.dat. The Android build needs those PC files copied to the device, about 5 GB according to the wiki, with the audio folder optional. The repository ships no game data; the NavMeshes submodule holds a precomputed navigation mesh, which the wiki says is generated from the imported game world because the original game has none. - Development uses Unity 2020.3.26 or newer (the project file names 2020.3.26f1), a recursive clone of the MirrorLite, UnityStandardAssets, NavMeshes, NetworkDiscoveryUnity and UGameCoreUtilities submodules and the Startup scene. README reports testing on Linux, Windows, macOS and Android with both Mono and IL2CPP backends; v4.0 provides Windows and Linux archives and an Android APK. Multiplayer runs as a dedicated server, host or client, and game modes load as C# DLL plugins. - There is no CI workflow or automated test suite for the importers or gameplay, and no comparison with the original executable is published. Evidence consists of README claims that multiplayer fully works, the v4.0 release notes, screenshots and videos; Docs/Performance.md records vertex and draw-call counts for one Las Venturas view. - LICENSE is MIT with a 2015 copyright line for James King; the bundled NVorbis and Newtonsoft.Json DLLs and the submodules are separate projects under their own terms, and Rockstar’s game files keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### MinecraftLCE: an early-stage Minecraft: Nintendo Switch Edition decompilation > Decompiles Minecraft: Nintendo Switch Edition v1.0.17, a Legacy Console Edition release, into C++ that is compared function by function with the original executable using a patched Clang 4.0.1 and the open-ead Switch decompilation tools. The README explains the choice of the Switch build for its matchable Clang toolchain and type information, with names ported from the symbol-bearing Wii U Edition. At the reviewed commit the function list marks about 11% of functions decompiled, most of them matching; the result cannot run the game. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README describes a work-in-progress decompilation of Minecraft: Nintendo Switch Edition v1.0.17 that cannot be used to play the game. At the reviewed commit data/mcswitch_functions.csv lists 57,972 functions: 6,279 matching, 224 non-matching and 51,469 not yet decompiled, the 11.217% that a workflow writes into the GitHub description. Matched functions are checked individually; there is no whole-executable rebuild. - Supply the main NSO executable from your own Minecraft: Nintendo Switch Edition v1.0.17 update; the Wii U Edition’s Minecraft.Client.rpx (Patch 35, v560) is recommended only for porting symbols. README says these executables will never be provided in the repository and no game assets are included. - Documented for Linux or WSL (with macOS also intended): Python 3.6+, Ninja, CMake 3.13+, ccache, llvm-objdump, libncurses5, a Rust toolchain and the listed Python modules. tools/setup.py converts the executable, downloads Clang 4.0.1 from the LLVM releases and applies the committed libc++ patches; submodules supply open-ead’s nx-decomp-tools, nnheaders and musl and the stb image library, and lib/ vendors libpng and zlib. - tools/check compares compiled functions with the original and tools/common/progress.py summarises the function list. CI lints, compiles the project without the game and publishes progress counted from the committed function list, so matching status is project-reported. - No license file is present and GitHub detects none; Minecraft belongs to Microsoft and Mojang, and vendored libraries keep their own licenses. README says Microsoft-licensed Java Edition mappings cannot be used and notes that projects whose research was not clean-room have been taken down. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Final Fantasy VII: a matching PlayStation decompilation > Reconstructs C source for the US PlayStation release of Final Fantasy VII, aiming for code that compiles back to the original main executable and its game overlays. The build splits the user’s disc files with splat, compiles with period cc1-psx compilers and checks every rebuilt file against its SHA-1. A native build against the PsyZ PlayStation-library replacement is compiled in CI but is not documented as a playable port. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The project describes itself as a matching decompilation of the PS1 game; config/us.yaml defines the single us version, covering SCUS_941.63 and battle, field, menu, world, minigame, magic and other overlays with 29 SHA-1 entries. Source tables such as the chocobo minigame’s arccosine table are data taken from the game, as is usual for such projects. README states no completion figure; CI uploads a progress report as a build artifact. - Supply disc 1 of Final Fantasy VII (USA) as BIN/CUE under disks/; README lists the USA Interactive Sampler CD as optional, though the reviewed config builds only us. CONTRIBUTING says the repository includes no original game data and is not a playable or standalone version. CI fetches its disc images from a private dependency repository through a secret token. - README documents Debian/Ubuntu and Arch Linux with Go, Python 3 (a venv with splat64, spimdisasm and others), ninja, 7zip, bchunk and mipsel-linux-gnu binutils and GCC; CI notes that Ubuntu 24.04’s binutils 2.42 linker does not match the game. Make downloads the cc1-psx-26 and cc1-psx-272 compiler builds from the project’s init release and checks them against committed SHA-256 files; maspsx, m2c, asm-differ and PsyZ come in as submodules, and a Dockerfile is provided. - make build ends with a ninja rule running sha1sum -c over the expected hashes of every overlay. CI on the upstream repository checks formatting, runs that build, lints for overlapping symbols and compiles the PsyZ build. These checks compare file identity for the US release. - LICENSE is AGPL-3.0; the game discs, extracted data and downloaded compilers keep separate rights. README says the decompiled code is written by humans and rejects LLM-accelerated decompilation, while allowing LLMs for tooling, permuting hard functions or hunting runtime bugs; CONTRIBUTING forbids autonomously generated pull requests and commit messages. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Mega Man X Recompiled: a snesrecomp static recompilation > Statically translates the 65816 CPU code of the SNES Mega Man X (USA Rev 1) to C with the snesrecomp framework; the PPU, audio, DMA and other hardware run in the framework’s runtime, and a LakeSnes-derived interpreter executes whatever the static pass cannot prove. The C is generated locally from the user’s ROM, with function names imported from community DiztinGUIsh annotations. Playable Zero, co-op and rollback netplay, X2/X3 boss weapons and adaptive widescreen are layered on top, using assets extracted locally from the user’s own sequel ROMs. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the main commit of release v2.2.9-alpha (2026-10-18), which offers a Windows ZIP and a Linux AppImage. The snesrecomp README lists the game as fully playable, and this README says the adaptive widescreen renderer was playtested through the ending on Windows. Execution is interpreter-first: compiled bodies replace only code the analysis proves, the rest stays interpreted, and Rockman X (Japan v1.1) is a separate variant that keeps its original view. - Supply your own Mega Man X (USA) Rev 1 ROM as .sfc or .smc, headered or not. Zero, co-op and the X3 weapons also need the user’s Mega Man X3 USA ROM, and the X2 weapons the Mega Man X2 USA ROM; their assets are extracted on the user’s machine. README states that ROMs, extracted assets and the generated src/gen C are neither committed nor in the downloads; the Saber Zero sprites and sounds from the Zashiko Mod are included with permission for non-commercial use. - Source builds clone the snesrecomp, recomp-ui and dizProjects submodules, stage the ROM and run tools/regen.sh, which emits per-bank C from recomp/bank*.cfg. CMake with Ninja and SDL3, or SDL2 as a fallback, is the maintained build: Windows 10+ through MSYS2 mingw64 with Python 3.9+ and rustup, Linux with gcc or clang, and macOS on Apple Silicon or Intel. - CI compiles ROM-free setup hosts and runs the ROM-free CTest regressions; ROM-backed state tests and a replay suite that stops at the first WRAM, co-op, camera or VRAM mismatch need the user’s ROMs. A dated coverage checkpoint reports two 12,000-frame routes matching the control build’s CPU and WRAM traces and final snapshots, without comparing audio, and the v2.2.9 release notes report Windows and Linux checks of all 28 Boss Rush pairs. - The project and the pinned snesrecomp framework are under the PolyForm Noncommercial License 1.0.0; the interpreter is LakeSnes-derived (MIT), vendored dependencies keep their own licenses, and Capcom keeps its game rights. README presents the project as part of R.A.I.D. (Retro AI Development), a Discord community for AI-assisted retro reverse engineering. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### OpenSC4: an early open-source reimplementation of SimCity 4 > Reimplements SimCity 4 as a Godot project in GDScript that reads DBPF archives, region folders and city saves from the user’s own SimCity 4 installation. The code draws a region view with city thumbnails and interface elements built from the game’s UI definitions, opens a saved city’s terrain and water in 3D, and includes a DAT explorer for previewing archive subfiles. It is an early, inactive engine case without simulation gameplay, not a playable replacement. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main snapshot (2024-03-29) only added a README and a Discord invite; the last code change dates from 2023-02-17, and the repository has no releases or tags. README describes an open source “clone” meant to use modern hardware and run on other platforms. The code covers DBPF parsing, a region view for the hard-coded Timbuktu region, a city terrain view and the DAT explorer, with no zoning, budget or growth simulation. - Needs the user’s own SimCity 4 installation: the boot screen asks for its folder and checks for SimCity 4.ini, Sound.dat, Intro.dat, SimCity_1.dat to SimCity_5.dat and EP1.dat, then reads .sc4 city saves, config.bmp and region music from that folder. .gitignore excludes SimCity 4 data, although the tree contains a “Graphics Rules.sgr.backup” text file whose header says SC4Launcher generated it. - Runs from source in the Godot editor: README’s setup is to install Godot, import the cloned project and run it, without naming a version. project.godot uses config_version 4 and the scripts call Godot 3 APIs such as yield and Directory; no export presets or packaged builds are provided. - The repository has no tests or CI workflows and publishes no comparison with SimCity 4’s behaviour or output. - GitHub detects no license and the tree has no license file; nine GDScript files carry AGPL-3.0-or-later headers for “The OpenSC4 contributors” (2023), and utils/logger.gd is MIT-licensed code from KOBUGE Games’ godot-logger. SimCity 4 and its data keep their owners’ rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### R.E.L.I.V.E.: an Oddworld Abe’s Oddysee and Abe’s Exoddus engine reimplementation > Reimplements the engine of Oddworld: Abe’s Oddysee and Abe’s Exoddus as an open-source replacement executable that runs from the user’s own game folder. The team decompiled the original executables and replaced their functions incrementally, using injected DLLs that hook reimplemented code into the patched retail executable, then rewrote the result into a standalone cross-platform engine. The project site says both games are playable in their entirety, with bug fixes and windowed, high-resolution and controller play. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the master commit of 2026-09-01 that merged the SDL3 port; the latest release is github-v1.0.9, labelled “relive stable v1.0.9” (2025-03-21), while CMake still declares project version 0.1. The project site’s FAQ says both games can be played through, over a hundred original bugs are fixed and there should be no noticeable gameplay difference from the retail version; PSX-quality music, deeper modding and an in-game level editor are listed as future work. The FAQ describes the method as decompiling the retail executable and then spending years rewriting the output into readable code. - Play requires the user’s own Abe’s Oddysee or Abe’s Exoddus installation; the FAQ names the Steam, GOG and early disc versions. The executable runs from the game folder that holds the .lvl files, and the Linux launcher scripts look for the default Steam folder or ask for that directory. The repository contains no game data files, though source files embed data tables used by the reimplemented code, such as fonts and video-decompression tables; the FAQ says the team will not provide game files. - Builds use CMake 3.10+, C++17 and SDL3 after a recursive clone of the Detours, googletest, magic_enum, jsonxx, stb, lodepng and nlohmann/json submodules; README documents Visual Studio 2022 on Windows and Ubuntu packages on Linux, and cpack produces a Debian package. MSVC builds also produce the AliveDllAE and AliveDllAO hooking DLLs, linked with Detours on 32-bit Windows. GitHub Actions builds Windows 32-bit, Windows 64-bit and Linux packages; its macOS job is commented out, although the FAQ says the games run on macOS. - The GitHub Actions workflow builds and packages without running tests. The tree has googletest unit and integration tests for the relive_api level-data tool, and the integration test reads .lvl files from hard-coded GOG install paths; older AppVeyor and Azure Pipelines configurations still invoke ctest. The FAQ reports automated replays that record a full play-through with a stable build and flag desyncs in development builds (the recorder saves input, RNG, ticks and sync points), but no replay results are published. - The repository has no license file and GitHub detects none; README only says contributions will be licensed under a GPL-compatible license, most likely MIT, in the future, so reuse terms are currently unstated. 3rdParty/DxOld carries three DirectX 7-era Direct3D headers, one with a Microsoft all-rights-reserved notice, and the submodules keep their own licenses. The FAQ disclaims affiliation with Oddworld Inhabitants, whose games keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### Age of Empires Free Software Remake: a re-implementation on the original data > Re-implements Microsoft’s Age of Empires and its Rise of Rome expansion as a cross-platform C++17 engine on SDL2 and OpenGL that loads the original game’s DRS archives and language.dll resources. README says it mimics the Windows API and the Genie engine for compatibility and reconstructs some code from the disassembly; the repository adds format notes and Python tools for inspecting the original data files. Only very basic gameplay through a multiplayer session exists so far, so it is an early engine case rather than a playable replacement. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master snapshot (2026-09-20) sets CMake version 0.1, and the repository has no releases or tags; the user guide says no binary builds are provided. README reports only very basic gameplay and only multiplayer mode: single-player means hosting a session and adding computer players, which only gather resources until attacked. doc/reverse_engineering documents the DRS archive contents, the Windows API functions the original imports, the scenario format, civilizations and unit statistics. - Needs a legitimate copy of Age of Empires or Rise of Rome, on the CD-ROM or installed: the engine loads Border.drs, graphics.drs, Interfac.drs, sounds.drs and Terrain.drs from the data folder plus language.dll, and expects the game fonts COPRGTB.TTF and COPRGTL.TTF that the original installer adds. The repository contains no game data, and community replacement assets are not supported yet. - README lists Windows 10+, macOS Sequoia 15.7.7, Fedora 44 and Ubuntu 22+ as tested, while INSTALL still warns that Linux builds look for hard-coded legacy TTF font paths. Builds use CMake 3.11+ with C99 and C++17 against SDL2, SDL2_image, SDL2_mixer and OpenGL, plus the imgui, tracy, wepoll and miniz submodules; Windows builds use Visual Studio with vcpkg or MinGW. - GitHub Actions builds the game with Clang on Ubuntu and Fedora and runs the Google Test suite in headless mode; its tests cover networking, the protocol, the server, SDL and a UI menu rather than equivalence with the original executable. No comparison with the original game is published. - LICENSE applies Apache-2.0; the submodules and the bundled headers in game/src/external keep their own licenses. README states that all copyrighted material and trademarks belong to their respective owners and calls the work an educational non-profit project. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### God of War PS2 static recompilation: a native Windows port via PS2Recomp > Statically recompiles the MIPS R5900 code of the NTSC-U PlayStation 2 God of War executable (SCUS-97399) to C++ with PS2Recomp and builds it as a native Windows program. Since October 2026 the port builds on Waffle565’s runtime, which replaces the PS2 hardware with native code: VU1 microprograms and, optionally, the game’s IRX modules are compiled ahead of time, and an OpenGL renderer stands in for the GS. The repository holds only the game-specific function map, recompiler configuration, overrides and runtime patches; the README reports gameplay on the opening ship level, with sustained 60 fps and a full playthrough still pending. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main (2026-10-18); the project has published no release. README marks the port experimental and reports boot, menus, a new game and the ship fight with HUD, native VU1 and IOP, and exact game speed. Sustained 60 fps, saves and movies with sound (so far verified only in Waffle565’s port), a full playthrough and PAL languages remain open, and an intermittent hang of the window thread is under investigation. The .recomp.json metadata still describes an earlier, not-yet-playable state, and most technical documents are in Spanish. - Requires the user’s own NTSC-U God of War disc (SCUS-97399): the build reads its SCUS_973.99 executable, and play reads the IRX modules and PAK data from the user’s disc files kept at their original sectors. README states that the repository contains no game files, IRX modules or generated C++, and .gitignore excludes disc images, the executable, IRX and PAK files and the generated directories. - Builds only on Windows 10/11 x64 with Visual Studio 2022 Build Tools (C++ workload, including CMake and Ninja), Git and Python 3, with about 20 GB free and 16 GB of RAM recommended. scripts/2_compilar.cmd clones PS2Recomp at commit c5a9d02, applies the patches in order, generates about 6,400 C++ files from the user’s executable and builds ps2EntryRunner.exe; the first build takes 20–40 minutes. - CI validates the function map and recompiler configuration, applies every patch to PS2Recomp and runs its ps2x_tests runtime suite against a known-failures list, and runs game-independent GS, VU1, pad and camera tests, plus a Windows job that links an isolated PCSX2 GS module without a GPU. Gameplay and performance figures come from the author’s runs on one Ryzen 7 5800XT and RX 5700 XT machine, recorded in docs/ESTADO.md. - The repository is GPL-3.0, matching PS2Recomp; the applied runtime comes from Waffle565’s God-Of-War-Native-Port, whose repository root has no license file, and brings PCSX2-derived code (GPL-3.0+). Sony Interactive Entertainment and Santa Monica Studio keep their game rights. AGENTS.md says several agents work on main at once, CLAUDE.md points Claude to those conventions and the status log credits fixes to Claude. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### RaceWave46: an AI-assisted Wave Race 64 recompilation for Windows > Recompiles the USA Rev 1 Nintendo 64 release of Wave Race 64 into a native Windows application with N64Recomp and RSPRecomp, on modified copies of the N64ModernRuntime, RecompFrontend and RT64 stacks. Game and microcode C is generated locally from the user’s ROM, after an included widescreen patch is applied to a temporary copy, and checked against recorded checksums. The port adds higher resolutions, frame interpolation, ultrawide views, rasterized and ray-traced reflections and shadows, split-screen or separate-window two-player play and RetroAchievements; the maintainer calls it an AI-assisted recompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the repository’s single public commit, tagged v1.0.0 (release published 2026-09-16) with a Windows x64 build and a source ZIP. README targets 64-bit Windows 10/11 with Direct3D 12 and Vulkan back ends; the added reflections, shadows and separate player windows need Direct3D 12, and ray tracing needs DXR 1.1 / Shader Model 6.5. Controller Pak save and load are not implemented, multiplayer is local only, RetroAchievements lacks hardcore mode and leaderboards, and performance requirements are still being evaluated. - Building and playing need the user’s own unmodified Wave Race 64 (USA) Rev 1 ROM, in big-endian .z64 form for the build; players import it in the frontend. Generation verifies the ROM, patches a temporary copy with the included widescreen IPS patch, and installs the verified output into git-ignored directories. README states that no ROM, saves, texture packs or account data are included. - Builds use Visual Studio 2022 C++ Build Tools with the Windows 10/11 SDK and C++ CMake tools (MSVC x64, CMake 3.20+, Ninja), Python 3.11+, and N64Recomp and RSPRecomp built from the bundled, modified source. The first configuration downloads Microsoft DXC 1.8.2502 and 1.9.2607 compilers pinned by SHA-256, and BUILDING.md warns against substituting unmodified upstream dependencies. - The tree holds 84 CMake regression suites run individually through BUILD-TEST.ps1, some needing the user’s ROM, but no CI workflow; generation checks every generated file against the hashes in config/generated-code.json. README reports repeated hands-on testing of races, menus, course introductions and the championship ending. - The project’s original contributions are GPL-3.0-only; N64ModernRuntime is GPLv3, other vendored components keep their own notices, and Nintendo keeps its game assets and trademarks. README states that AI tools were used for code implementation, debugging, research and documentation, while project direction, review and gameplay testing stay with the maintainer. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Jazz² Resurrection: a native C++ reimplementation of Jazz Jackrabbit 2 > Reimplements Jazz Jackrabbit 2 (1998) as a native C++ game on an extensively modified nCine engine, converting the user’s original game files into its own cache on first start. It runs on desktop, mobile, web and many homebrew console targets, with multiplayer, an enhanced Reforged mode and partial JJ2+ and MLLE support. A two-sided trajectory probe checks its non-Reforged movement against the original game, and the project reports 376 of 406 scenarios within 25 px/s. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the master commit of 2026-10-17, just after release 3.9.0 of the same day, which reworked physics; release packages are published in the older deathkiller/jazz2 repository. README lists the Shareware Demo, Holiday Hare ’98, The Secret Files and Christmas Chronicles as supported, with partial JJ2+ and MLLE features, and marks the Nintendo 64, Dreamcast, Wii, GameCube and PlayStation 3 ports as not yet tested on real hardware. README calls the game fully rewritten in C++ and does not describe decompiling the original executable; the non-Reforged movement constants come from measurements of the original game. - Every build needs the contents of the user’s original Jazz Jackrabbit 2 directory, a retail version or the Shareware Demo, placed in a Source folder and converted into a cache on first start. On Nintendo 64, Dreamcast, PlayStation 2, GameCube and 3DS the content must first be converted with the project’s AssetPacker, and README says the resulting images can’t be distributed. The repository’s Content directory holds the game’s own fonts, extra animations, metadata and translations; the Windows 3.9.0 package contains it with an empty Source placeholder, and README says the Docker server image never contains original files. - README documents Windows, Linux, macOS, iOS, Android, Nintendo Switch, Web (Emscripten), a libretro core, Xbox (UWP), AmigaOS 3.x, AmigaOS 4.1 and MorphOS, Nintendo 64, Dreamcast, Wii, GameCube, 3DS, PSP, PS2, PS3 and Vita, plus a Docker dedicated server; desktop builds need an OpenGL 3.3 or OpenGL ES 3.0 GPU. Builds use CMake 3.15+, which downloads the prebuilt dependency set by default unless system libraries are used. Console builds use their own homebrew SDKs and toolchain files, and several console targets need custom firmware. - The Linux and Windows workflows build and package without running a test suite. An optional physics probe (WITH_PHYSICS_PROBE) drives the same scripted scenarios in this engine and in the original game with JJ2+ and logs every tick; the committed traces and comparison scripts let changes be checked without the original. For the 144 FPS engine capture, Results/README.md reports a median speed-distribution error of 0.1 px/s, 376 of 406 scenarios within 25 px/s and 70 of 397 scenarios whose animation-segment counts differ by over 25%. These are project-reported figures. - LICENSE is GPL-3.0; Docs/ThirdParty.dox lists the third-party components, including parts of nCine (MIT), with their own licenses. Jazz Jackrabbit 2 and its data keep their owners’ rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### LBA2 Remake: a Little Big Adventure 1 and 2 reimplementation in TypeScript and Three.js > Reimplements the engine of Little Big Adventure 2, and now also Little Big Adventure 1, in TypeScript, Three.js and React so that it runs in a browser on resources imported from the user’s copy of the game. README calls it a full re-engineering rather than a disassembly-based approach: every island and building can be explored and most graphics and part of the gameplay work, but the game cannot yet be completed. It adds an editor with an actor-script debugger, VR support and fan-made 3D replacement models for the isometric scenes. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the master commit of 2026-04-17, the day after tag v0.6.8; recent changelog entries are mostly bug fixes, VR controller mappings and added replacement 3D models. README says every island and building of the original can be visited and most graphics and part of the gameplay are implemented, but the game is not completable. It describes the method only as full re-engineering instead of disassembly. - Local play requires the user’s own Little Big Adventure 2 from GOG, Steam or itch.io: npm run import (import:win on Windows) unpacks the installation and converts its music, samples, voices and video into the git-ignored www/data folder, and other versions or Linux need the manual import route. The repository holds no original game files; its www/models and assetsSource trees contain replacement 3D models, textures and generated scene meshes, which the art workflow describes as newly made. The FAQ says the hosted live demo is shared publicly with Frederick Raynal’s agreement while the game is a work in progress and will require a legal copy once it is fully playable; its Netlify build downloads game assets from a location outside the repository. - It runs in a browser with WebGL. Development uses Node.js (README asks for 9 or newer and the Netlify build sets 18), npm, webpack and TypeScript, served by npm run dev on localhost:8080. The apps folder holds Android, iOS and Windows 10 app prototypes, and VR controllers work through WebXR. - CircleCI runs lint, type-checking and a production bundle build, and a CodeQL workflow scans the code; there are no engine or gameplay tests and no comparison with the original executable. The live demo, editor and gameplay videos are the project’s own demonstrations. - LICENSE is MIT for the project’s code (copyright 2018 Adrien Grandemange and Alexandre Fontoura). README states that the original game executable, assets and intellectual property belong to [2.21] and asks users to buy the original games. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### OpenAWE: an open reimplementation of Remedy’s Alan Wake engine > Reimplements Remedy Entertainment’s Alan Wake engine, later known as Northlight, in C++ and OpenGL, aiming to run Alan Wake and Alan Wake’s American Nightmare portably from the user’s game data, with Quantum Break and possibly Control as later goals. README documents only a free camera for moving through loaded game data, and the American Nightmare script table implements 16 of its 278 native functions. The repository also includes command-line tools for the games’ archive, texture, Havok and sound formats. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the master commit of 2026-10-11; there are no releases or tags, and CMake declares version 0.0.1. README states the goals but gives no gameplay status beyond a keyboard-and-mouse free camera, and the game selector rejects Quantum Break and Alan Wake Remastered as not yet supported. In the reviewed American Nightmare native-function table, 16 of 278 script functions are implemented and the rest are placeholders. - OpenAWE runs from the data directory of the user’s own Alan Wake or Alan Wake’s American Nightmare installation, passed with -p, together with the shaders compiled during the build, passed with -s. The repository contains no game data: the archive tests use small synthetic byte arrays, and data/ holds a single XML file that carries the project’s GPL header. - Builds use CMake 3.21+ and C++20 with development packages for zlib, GLFW 3.4+, GLM, TinyXML2, OpenAL, Bullet, fmt 9+, Ogg, Theora, Vorbis and spdlog, GTest for the optional tests, the EnTT and CLI11 submodules or system copies, and the glslc shader compiler. CI builds with GCC and Clang on Linux, MSVC on Windows and Clang on Intel macOS. - Each CI job runs ctest with GoogleTest unit tests for the archive readers, streams, compression, XML and TOML parsing and geometry utilities, then packages the build with cpack. No test reads the games’ data or compares behaviour with the original executables; the README screenshot shows an American Nightmare scene. - README places the code under GPL-3.0-or-later except the libraries in 3rdparty, which keep their own licenses. Alan Wake and its data keep their owners’ rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### CPS-2 Recomp: static recompilation of Capcom CPS-2 and CPS-1 arcade games > Translates the 68000 game programs and Z80 sound programs of Capcom arcade boards ahead of time into C++ and runs them on a machine model written for the project, with an interpreter for code that has not been translated. One launcher covers Street Fighter Alpha and Alpha 2, Super Puzzle Fighter II Turbo, Vampire Savior and its variants, Vampire Hunter 2, Alien vs. Predator and the CPS-1 Cadillacs and Dinosaurs, adding training modes, widescreen and three-player options. Translated code is generated from the user’s own ROM sets, and a check build compares it block by block with the interpreter. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main (2026-10-19), eight commits after release v0.4.0-beta.3, published the same day for macOS 13+, Linux x86_64 including Steam Deck, and 64-bit Windows 10/11. README labels the collection beta: the fighting games play from start to ending, the beat-’em-ups have been run through their first stages under automated play, and few machines and controllers have been tried; Street Fighter Alpha has no training mode or widescreen yet. - Each game needs the user’s own copy of one specific MAME-style ROM set, such as sfa2u (USA 960430) or vsavj (Japan 970519), with its key file for CPS-2 titles; each game.cfg lists the expected files and checksums. THIRD_PARTY_NOTICES states that nothing from any game or board is in the repository and that translated code is made on the machine of someone who has the ROM set; RELEASING.md adds that each released game program contains that game’s translated and compiled 68000 and Z80 code, a risk the maintainer accepted on 2026-10-12. - Source builds use make with CMake, Ninja, Python 3 and SDL 3.4.16 or later: Apple clang on macOS, GCC 13+ or Clang 16+ with CMake 3.28+ on Linux, and MinGW-w64 cross-compilation or an MSYS2 UCRT64 shell for Windows. The first build writes the deciphered program, and an explore step of about ten minutes finds code through automated play before translating it; code it does not find keeps running on the interpreter. - docs/VERIFYING.md documents a check build that runs each translated block beside the interpreter and stops at the first difference in registers, flags, cycles, control flow or memory writes, plus per-frame state-hash comparisons between run modes; the optional arcade timing was compared with a simulated jtcps2 model of the board. CI runs an audit for committed game files, keys and unlisted third-party code, and builds and starts each platform’s package with a stand-in game and no game code. - The project is GPL-3.0; machine/cps2crypt.cpp is MAME’s BSD-3-Clause CPS-2 cipher code, the launcher descends from wiiparty-recomp (GPL-3.0-or-later) through the author’s recomp-common, and sound/driver.cpp is a hand rewrite of Capcom’s QSound sound program that reads its tables and samples from the user’s ROMs. Capcom and the other rights holders keep their game rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### impacto: a reimplementation of the MAGES. visual-novel engine > Reimplements the MAGES. visual-novel engine, used by the Science Adventure and Memories Off series, in C++ with OpenGL, running supported titles from the user’s original data files through per-game Lua profiles in one binary. README says all endings can be reached in at least one game, Memories Off 6 T-Wave, but no game is fully complete. The project’s tracking issue lists partial support for titles including Chaos;Head Love Chu Chu, Chaos;Child Love Chu Chu, Steins;Gate and Robotics;Notes Elite. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the master commit of 2026-10-17, which CI published as prerelease 0.10.8.887; all published releases are automatic prereleases. README says impacto is in active development: all endings are reachable in at least Memories Off 6 T-Wave, but some functionality and architecture are missing and no game is fully complete. The support-tracking issue (#1, last updated 2026-02-20) lists per-title progress, from story progression and saving in the Love Chu Chu titles to only graphics and sound in others, and names missing features such as some 2D special effects. - Each game needs the resource files of a supported version, mostly console releases such as the PS3 Memories Off 6 T-Wave, the PS4 Chaos;Child Love Chu Chu or the Japanese Switch Robotics;Notes DaSH, placed under gamedata/ as listed in that profile’s vfs.lua. The repository holds no game resource files; its resources include font atlases generated with the project’s font tool, Noto CJK fonts, and per-game application icons and cursors, with the icons showing official character artwork. The reviewed Windows prerelease package contains the executable, libraries, profiles, shaders and those resources, but no game data. - README targets 64-bit Windows 10 and desktop Linux, with experimental runs on macOS, Android, Switch (homebrew and Linux) and WebAssembly; OpenGL is the main renderer, with experimental Vulkan and DirectX 9 options. Builds use CMake 3.28+ presets, C++20 and a vcpkg manifest, with Visual Studio 2019 or newer on Windows and documented Ubuntu and devkitPro Switch builds. CI produces Windows, Linux, macOS (arm64 and x64), Android and Switch packages. - CI runs clang-format linting and builds the packages; the reviewed workflow has no automated test suite, and no comparison with the original engine is published. README invites both black-box observation of the original’s behaviour and white-box inspection of its internals, without documenting specific methods or tools. - LICENSE is ISC for the source as a whole; THIRDPARTY.md lists code based on vgmstream, Ryujinx, OpenImageIO, FFplay and others, plus external libraries, and warns that binary distributions may fall under more restrictive terms. The games, their data and the official artwork used in the icons belong to their rights holders. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Wind Waker HD decompilation: functions verified against the recompiled Wii U game > Decompiles the USA Wii U release of The Wind Waker HD function by function into readable C++ in zeldaret/tww’s style, and verifies each function by running it beside the original, statically recompiled from the user’s own copy, comparing return values, memory writes and calls on generated and recorded inputs, with coverage and mutation checks. README reports 28,244 of the game’s 39,713 functions verified, including 22,068 of 22,215 GameCube-derived functions. The code calls undecompiled functions by address, so it runs only inside the ZeldaWWHDRecomp port, not as a standalone game build. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README describes a hybrid decompilation of cking.rpx (USA, version 0): decompiled functions call others through their original addresses, so the tree builds no game on its own and runs only with the port’s recompiled code. It reports the HD UI decompiled, while about 11,400 generic-library functions (sead, agl, NW4F, most of JSystem, the Cafe SDK and the C runtime) are not planned. zeldaret/tww is the reference for names and structure, and the docs record HD differences for 838 units compared with the GameCube version. - Building or verifying needs the user’s own legally obtained game, extracted with the port’s tool from a disc image with its disc key and the Wii U common key. README states that the repository contains no machine code, recompiled code, game assets or keys; small data tables used by the code are included, while model data, the RPX image, recompiled output, game-derived names and recorded inputs are generated locally and git-ignored. The recommended GameCube signature checks also use zeldaret/tww built from the user’s own GameCube disc. - The harness runs inside a ZeldaWWHDRecomp checkout at the tested commit df2cf51b (v0.2.3), replacing the port’s older tools/verify. It needs Python 3, clang/clang++ with C++20 and the port’s game-extraction requirements; building the port itself is needed only for recording inputs. A full verify_all.py run is long, and some units need tens of GB of memory. - Each function runs on 10,000 generated inputs on each of two seeds, must reach nearly all basic blocks of the original and is mutation-tested; README reports the whole tree re-verified after the October 2026 readability rewrite. tools/verify/README.md says equivalence is to the recompiled code’s model of the Espresso CPU, not the console, and that timing, threading and the exact stack layout are not checked. The in-game swap-test build is not part of the release, and the repository has no CI workflow. - CC0 1.0 covers the decompiled source, tools and documentation; the game, Nintendo data and the port runtime keep their own terms. README calls it an unofficial, non-commercial fan project with no donations or paid builds. tools/verify/README.md reports pilot timings for an agent using the tools and two functions written by parallel agents. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### SiegeFX: a Dungeon Siege engine reimplementation in alpha > A C#/.NET 10 engine loads Dungeon Siege's original archives, scripts and models, with published alpha builds and an audit/parity ledger. The project also provides SiegeSmith modding tools, while describing remaining fidelity and playthrough risks. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an owned Dungeon Siege installation; Windows and Linux builds are linked. Source builds need .NET 10; Linux needs OpenGL 3.3 and internet multiplayer additionally needs OpenSSL 3. - **Testing evidence:** The README calls this alpha software. It reports campaign progression to the final boss since v0.4.0, with Bink movies, interior lighting fidelity and combat balance still open. - **License:** Code is GPL-3.0-only; original game assets are not bundled. Multiplayer uses Epic Online Services under separate SDK terms. ##### Primary sources 1. 2. #### Legend of Legaia: a Rust port with disc-local browser tooling > A from-scratch Rust port of the North American PlayStation Legend of Legaia includes native/browser play, asset extraction and disc patching. The author documents Ghidra/emulator research and a full-game ladder; this is a fresh implementation, not a matching decompilation or static recompilation. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply an owned North American SCUS-94254 disc image; browser tooling reads the image locally. Source builds require a Rust toolchain supporting edition 2024. - **Testing evidence:** The README reports New Game-to-credits coverage and parity oracles, but disc-dependent tests skip and pass without LEGAIA_DISC_BIN. - **Limits:** Enhancements can differ from retail behavior; the README describes a retail-faithful mode. No Sony game executable, ROM or asset data is distributed. - **License:** Project code and documentation offer Unlicense or MIT; these licenses do not grant rights to the original game. ##### Primary sources 1. 2. #### RSDKv3 Decompilation: Sonic CD (2011) on a reconstructed Retro Engine v3 > Reconstructs Retro Engine v3, the engine behind the 2011 Sonic CD remaster, as a native C++ source port for Windows, Linux, macOS and Android. The engine runs the game's own scripts and assets from an official release, which the repository does not ship, and adds a mod loader, a settings file with remappable controls, support for the mobile versions' updated scripts and extra developer-menu debug keys. Its license describes the code as mostly functionally the same as the original rather than byte-matching; the same team's RSDKv5 decompilation is listed as a separate case. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README calls it a complete decompilation of Retro Engine v3; its license says the repository also contains original code and that most code is meant to be functionally the same as the specified RSDK version. The RETRO_ORIGINAL_CODE option strips the custom code but, per the README and CMake file, cannot build a playable game. The reviewed commit is 19 commits after release 1.3.3 (2025-11-02), which attaches prebuilt Windows x86 and x64, Linux, macOS and Android builds of the engine. - It does not run without assets from an official Sonic CD release: the original Steam release, Sonic Origins on Steam, Epic or Switch, or the delisted iOS and Android versions. The engine loads the game's Data.rsdk datapack, and full-motion video works only with the original Steam release's video files. The FAQ notes that the Sonic Origins datafile uses the RSDKv5 datapack format and contains no music or sound effects, and that the Origins-only playable characters are blocked in release builds. The repository commits no game data or game scripts; the separate script decompilation is its own repository. - Clone recursively, because GitHub's source ZIPs omit the tinyxml2 and flatpak shared-modules submodules. CMake builds use Visual Studio with vcpkg (GLEW, SDL2, libogg, libtheora, libvorbis) on Windows, distribution packages on Linux and separate guides for macOS and Android; the tree also carries iOS, UWP and PS Vita project files that the README does not document, and the Switch and New 3DS ports are unofficial forks the project does not support. - CI builds Windows x86 and x64, Linux, macOS and Android binaries with RETRO_DISABLE_PLUS on. The project publishes no comparison with the original engine binaries; the FAQ says bugs present in official releases will mostly not be fixed and that menu buttons such as leaderboards and achievements stay unimplemented. - The custom RSDKv3/v4 Decompilation Source Code License v2 requires every prebuilt executable given to anyone to have DLC disabled by default, forbids commercial use and distributing game assets other than unique modded ones, requires crediting the original and decompilation developers, and binds forks to the same terms. It names Christian Whitehead as the original RSDK author and Rubberduckycooly and st×tic as the decompilation authors. Sega's game and assets keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### ICO decompilation: byte-identical PAL and Japanese PlayStation 2 boot ELFs > Rebuilds the boot ELFs of ICO’s PAL (SCES-50760) and Japanese (SCPS-11003) PlayStation 2 discs from one source tree with the game’s original compiler versions, and checks that every loaded byte and the whole ELF file match the disc’s SHA-1. The 73 data-only archive members are generated at build time from the user’s own ELF, so most read-only data still comes from the disc rather than from source. Separate branches target the USA, Korean and August 2001 prototype builds, and the catalog’s ICO PC port is a fork of this tree. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README reports every section of both targets identical to its base ELF; .rodata is about 9.5% from source and 90.5% generated from the disc, and .data about 73% from source. The Japanese build is an earlier link of the same program, kept as VERSION_JPN blocks in the shared PAL-based tree, while kor, ntsc and aug6 are separate single-target branches not yet merged into main. The output is a PS2 boot ELF and ROM image, not a PC port. - Each target needs the user’s own disc image, the PAL .iso or the Japanese .bin/.cue, from which the build extracts the boot ELF and checks it against config/sha1sums. docs/LEGAL.md excludes disc images, boot ELFs, assets, data tables and bulk symbol or map tables from the repository, and forbids leaked SDKs and leaked source as inputs. It says the Sony runtime libraries reconstructed under sce/ were written from the shipped instructions using the SDK’s public naming, and the newlib and libgcc members follow their published source. - Builds on 64-bit Linux with 32-bit libraries and multilib gcc, Python 3, mips-linux-gnu-objcopy and network access on the first run. tools/setup.sh fetches ee-gcc 2.9-991111-01 and the SCE ee-as from decomp.me’s compiler releases, builds GNU ld 2.10 with two patches and builds a patched ps2dev dvp-as for the five VU1 microprograms; README says nothing comes from a Sony SDK. - ./build.sh ends with tools/check_elf.py --gate, which compares every allocated section with the base ELF by address and requires the whole-file SHA-1 to match; progress badges and the dashboard are regenerated from the built ELF and link map. The only CI workflow publishes that dashboard, and building needs a disc that CI does not have. - MIT covers the project’s own code, scripts and documentation and grants no rights in the game, its data or Sony and Team Ico property; the toolchain components keep their GPL licences. README states the project is unaffiliated with Sony Interactive Entertainment or Team Ico. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### game-and-watch-patch: Nintendo Game & Watch custom firmware > Custom firmware for the Mario and Zelda Game & Watch consoles that patches new C code into the user's own stock firmware backups, so the original firmware runs alongside the retro-go emulator. A Python patcher hooks stock function calls, relocates and LZMA-compresses stock code and data to free flash, and can merge both models' firmware into one image. Committed symbol maps, a cross-reference mapper and an analysis-ELF builder support the reverse engineering, and a journal records the author's first firmware-patching work. - Type: Case study - Targets: Firmware · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit (2026-10-19) is 111 commits past the last tag, v0.12 of 2025-02-25, and no release attaches binaries; the relocation, merged-image, analysis tooling and most tests arrived after that tag. The README lists more Mario features (whole firmware in internal flash, removable song and sleep illustrations, timeouts, clock graphics mods) than Zelda ones and says Zelda's external-flash savings are still to come. - Requires the user's own internal and external flash backups of a Mario or Zelda unit, placed as internal_flash_backup_.bin and flash_backup_.bin; the patcher rejects images whose SHA-1 does not match the stock firmware. The repository commits no firmware, ROMs or keys: tools/re/README.md says the .syms files hold only the project's annotations and that ELFs derived from Nintendo's firmware must never be committed, and docs/mario.md says no ROMs or ROM-hack patches are hosted. - Targets the consoles' STM32H7B0 microcontroller. Builds need GNU Make, the arm-none-eabi GCC toolchain and Python 3.6+ with Pillow, NumPy, pycryptodome, pyelftools, capstone and colorama; flashing uses gnwmanager, and the Mario internal-only mode also needs a patched OpenOCD for an undocumented extra 128 KB of internal flash. An Ubuntu 22.04 Dockerfile installs gnwmanager's OpenOCD and Arm toolchain for x86-64 Linux hosts. - tests/test_golden.py rebuilds fixed option sets and compares output SHA-1 hashes with tests/golden.json, recorded for Arm GNU Toolchain 15.2.Rel1; it skips without the stock backups or under another GCC version. Other unit tests cover relocation, Thumb assembly, layout and symbols, and tools/emu runs patched images through menu tests in the GWemu emulator. CI only runs pre-commit lint checks and builds the Docker image. - COPYING is BSD-3-Clause (2020, Konrad Beckmann, Thomas Roth, STMicroelectronics); the vendored ST CMSIS and HAL sources keep their own notices, and the stock firmware and games remain Nintendo's. The repository's CLAUDE.md is guidance for Claude Code. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. #### IW4L: a Rust runtime that plays Modern Warfare 2 from the user’s installed game > Implements a standalone runtime for Call of Duty: Modern Warfare 2 (2009) in Rust on Bevy and wgpu, loading maps, models, textures and weapons from the user’s installed game through native FastFile readers and translating its Direct3D 9 shaders to WGSL. Bots, demo recording and replay, and multiplayer over custom UDP with a QUIC master are implemented, while README warns that gameplay remains incomplete, with missing behavior, bugs and desyncs. README states that the whole project is written by an LLM; NOTICE names the community projects consulted and says the original binaries were read with Ghidra. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs the user’s own MW2 Multiplayer installation, which BUILD.md describes as the Windows depot of a Steam copy; Black Ops and MW3 data are optional. The repository and release archives contain no game data, and CONTRIBUTING.md forbids attaching, committing or linking original game files. - **Prerequisites:** Builds with stable Rust through rustup and GNU Make. Linux needs a C/C++ toolchain and X11, Wayland, ALSA, udev and xkbcommon development packages; macOS needs only the Xcode command-line tools. The Windows release is a password-protected iw4l-windows.zip; given a server operator’s .iw4l-server descriptor, iw4l.exe installs SHA-256-verified executable updates from that operator. - **Limits:** Releases are tagged demo builds, v0.1.0-demo.23 at review. APIs, caches and the wire protocol change between commits, so multiplayer peers must run the same build. - **Testing evidence:** No CI workflow or cargo test suite: make publish-check rejects test modules, and the only permanent checks are two owner-approved end-to-end scenarios driving real clients on MW2 maps with the user’s game data. Fidelity to the original game is not measured. - **License:** Apache-2.0 source with two bundled OFL fonts; game assets and trademarks remain their owners’. - **Attribution:** NOTICE says no third-party source is vendored and names references read during development, including OpenAssetTools, IW4x, KisakCOD and Plutonium’s decompiled Black Ops II scripts. A provenance note records replacing a movement module after reported similarities to GPL code. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Skate 3 Rust Engine: a Bevy rewrite built on Skate 3 reverse-engineering research > Reimplements Skate 3’s skating, tricks, grinds and offboard movement in a new Rust and Bevy engine that runs on assets converted from the user’s own Xbox 360 copy, adding difficulty settings and a .skate custom-map format. Physics notes cite functions and constants read from the original executable in IDA, and audio research reads traces from a research-hooks branch of a separate Skate 3 static recompilation. README says gameplay parity is still a work in progress, credits dumbad’s years of format research and states that AI coding tools were used to write the rewrite. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Play needs the user’s Skate 3 Xbox 360 ISO, or an extracted default.xex with its data folder; setup converts the skater, animations, disc maps and HUD assets into a local data folder, and ISO extraction needs internet access. Skate 3 assets are not included; the bundled format-demo map is described as original procedural content. - **Prerequisites:** Runs on Windows: the release ZIP starts skate3rust.exe and needs an SDL3-compatible gamepad. Source builds need Rust with the MSVC toolchain and LLVM, using BUILD.bat and PLAY.bat; the portable package script needs Python 3.13. - **Limits:** tools/recomp-trace reads traces from the research-hooks branch of Hailey-Ross/skate3recomp, which users must build from their own copy of the game; its README warns that the recompilation’s timing and threading differ from the console game. - **Testing evidence:** The Windows release workflow runs Python tests for the updater, setup and asset pipeline, but not the Rust crates’ own tests. tools/regression-checks compares maps, spawns and customiser output with a user-recorded baseline. Parity results are project-reported. - **License:** Original code is GPL-3.0-only, copyright dumbad and contributors; the vendored, patched Bevy crates and tools under tools/vendor/ keep their own licenses, and no rights are granted to Electronic Arts’ code, data, assets or trademarks or to third-party maps and mods. Unofficial and unaffiliated with EA. - **Attribution:** tools/claude-skills holds Claude Code skills for developing the engine. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Bravo: a reverse-engineered Minecraft server > Reimplements the server side of Minecraft’s Alpha- and Beta-era multiplayer in Python on Twisted; its documentation calls it a reverse-engineered implementation written from scratch, credits network traffic dumps and says general Minecraft data went to a community wiki. The final 2.0 release speaks the 1.4.x client protocol for login, chunk transfer, entities, server-side inventories, lighting, physics and Anvil saves, while deliberately changing behaviour such as chunk loading and item stacking. A pluggable architecture adds terrain generation, seasons and commands, and small scripts inspect packets, NBT and region files. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Unmaintained: the GitHub description marks the project UNMAINTAINED, and the reviewed master commit dates from 2014-09-09, 90 commits after the 2.0 tag (2013-01-10, also the latest PyPI release). The 2.0 changelog adds 1.4.x protocol support without server-side encryption, disables broken online authentication and replaces the Alpha and Beta save formats with Anvil; source pins protocol version 78. The introduction says creative games are probably safe but some Survival-Multiplayer elements are missing, and older pages such as the feature list predate these 2.0 changes. - The server needs no original game files; clients connect with the matching Minecraft client the player owns, which the FAQ says Bravo will not replace. The repository commits no game assets or Mojang code: block, item and recipe definitions are written as Python tables, and the documentation says Bravo inherits no code from other Minecraft projects. - Python 2.6 or 2.7 (CPython or PyPy); requirements.txt pins construct 2.0.6 and Pillow 2.4.0 and needs Twisted 11.0+, including Twisted Conch, with Twisted Words or Web for the IRC and web plugins. It runs as the twistd bravo plugin, configured from bravo.ini.example with a world path, creative or survival mode and the anvil serializer; the packet-parser script still imports a pre-2.0 module path. - Travis CI ran trial over the in-tree tests for protocol packets, chunks, inventories, plugins and serializers on Python 2.6, 2.7 and PyPy. MIT/X11 license, with bravo/nbt.py taken from Thomas Woolford’s MIT NBT library; Minecraft and its client keep Mojang’s rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### NTRGhidra > Ghidra loader and plugin for Nintendo DS programs. It checks the .nds header, maps either the ARM9 or the ARM7 binary at its RAM address together with the console's memory regions and I/O register labels, decompresses SDK-compressed ARM9 code and overlays, and fills the overlays the user selects at import, while an optional overlay-manager plugin swaps overlays in and out afterwards. The repository also keeps a small Ghidra Function ID database of NitroSDK 3.0 routines for function identification. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.5.1, published 2026-03-24 as NTRGhidra-build.zip for Ghidra 12.0.4, and its tag is the reviewed master commit; earlier releases were built for individual Ghidra 10.x and 11.x versions, and the README names 12.0.4 as the latest supported Ghidra version. The zip installs from the Ghidra project window's File → Install Extensions, and the overlay manager is enabled separately under CodeBrowser's File → Configure → Miscellaneous. The README says the project is looking for maintainers and contributors. - Source builds need a Ghidra installation: build.gradle applies Ghidra's buildExtension.gradle from GHIDRA_INSTALL_DIR, the README describes an Eclipse build with the GhidraDev extension, and a GitHub Actions workflow builds the zip with Gradle on every push and attaches it to new releases. The repository has no tests; src/test holds only a placeholder README. - Input is a .nds file the user supplies; the repository contains no ROMs or BIOS files. On import the loader rejects files whose header CRC does not match, asks whether the file is a commercial Nintendo SDK title or homebrew, and asks whether to load the ARM9 or the ARM7 code; commercial titles must carry the expected Nintendo logo CRC and have their ARM9 binary decompressed. The overlay manager re-reads overlays only from the original file at its import path, or from a substitute whose MD5 and SHA-256 match it. - The fidb folder holds nitrosdk3.0.fidb, a 2 KB Function ID database that its README describes as hashes of NitroSDK 3.0.0 functions from commercial games, covering crt0 and file-system routines in ARM code but not Thumb; the loader does not apply it automatically. The loader names its format Nintendo DS (NTR) and DSi (TWL), and the source carries DSi register and memory-region lists, but import maps only the DS ARM9 and ARM7 lists, and CRT0 autoload handling is marked as a TODO. - Apache-2.0. The README credits GBATEK for DS technical information and Gericom's Every File Explorer for the original header and ARM9 decompression code. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### mgbdis > Python disassembler that turns a Game Boy or Game Boy Color ROM, including multi-bank ROMs, into RGBDS-compatible assembly plus a Makefile that reassembles it, so the rebuilt ROM can be compared with the input. An optional .sym file beside the ROM supplies labels and marks code, data, text, padding and 1bpp/2bpp tile-image blocks; images are written as PNG files that rgbgfx converts back, text can use custom character maps, and hardware registers get hardware.inc names. The README explains that SM83 instructions vary in length and data is interleaved with code, so marked code blocks keep it from disassembling mid-instruction. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v3.0, published 2025-04-22; the reviewed master commit of 2026-07-31 is 15 commits ahead of that tag and still reports version 3.0. It is a single Python script that needs Python 3.6+, and the generated assembly targets RGBDS v0.8.0 or later, whose rgbasm, rgblink, rgbfix and rgbgfx the generated Makefile calls. Options control hexadecimal case, indentation, operand alignment and mnemonic variants, and a --tiny mode handles unbanked 32 KiB ROMs. - The input is a ROM file the user supplies, optionally with a same-named .sym file; the repository ships no game ROMs. It bundles PyPNG's png.py and a copy of gbdev's hardware.inc, and its only test ROM is assembled during testing from the project's own assembly sources. The README suggests generating code-block symbol files with the author's separate Beaten Dying Moon emulator, which records the instructions actually executed. - GitHub Actions installs the latest RGBDS release, builds the test ROM, disassembles it, diffs the output against committed expected files, then reassembles the disassembly and compares it byte for byte with the test ROM. This checks the tool on its own fixture, not on commercial games. The README notes that RGBDS inserts a NOP after STOP, so a STOP not followed by NOP is emitted as a data byte, and calls the tool slow on large ROMs. - MIT license; png.py carries its own MIT notice. mgbdis produces assembly rather than C, and labels and block boundaries come from the analyst's symbol file. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### ghidra-allegrex > Ghidra processor module for the Allegrex CPU of the PlayStation Portable, derived from Ghidra's MIPS module. It adds Allegrex-specific instructions, VFPU disassembly and basic decompilation, the PSP calling convention, and an ELF loader that detects PSP executables and applies the PSP-specific type A and B relocation sections, with rebasing after import. Bundled scripts import and export PPSSPP .sym function-label files, and an exporter writes kernel modules as relocatable object files for linking. - Type: Tool - Targets: Binary · Firmware · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v21.5, published 2026-10-25, built for Ghidra 12.2 and requiring JVM 25; the reviewed master commit is that tag. Each release zip targets one Ghidra version, so v21.4 of 2026-08-25 remains the build for Ghidra 12.1.3 and 12.1.4. Extension v19 and later install through Ghidra's File > Install Extensions; v18 and earlier are unpacked into Ghidra's Processors directory. - Source builds set GHIDRA_INSTALL_DIR and run the Gradle wrapper's buildExtension task, compiling Kotlin and Java against the local Ghidra installation with a JVM 25 toolchain. CI builds the extension against Ghidra 12.2 on Ubuntu and uploads the zip; the repository has no automated tests. The two PPSSPP scripts are written in Ghidra's Python 2 (Jython) dialect, and the .sym file comes from the user's own PPSSPP debugging session. - Inputs are PSP executables in ELF/PRX form, kernel modules or raw binaries that the user supplies; the README notes that game executables must already be decrypted, and the repository contains no PSP software or firmware. Raw binaries need the processor and image base set by hand, and some kernel modules need the reboot.bin type B relocation option at import. - The README lists limits: almost every VFPU operation decompiles to a function call such as vadd_q(...), the vpfxs, vpfxt and vpfxd prefix semantics are not modeled, vfim.s shows its half-float operand as an integer, object files cannot be rebased after import, and functions with 64-bit arguments need custom storage because of a Ghidra issue. - Apache-2.0; the README says it is derived from Ghidra's Apache-2.0 MIPS module and that type B relocation parsing is based on prxtool under AFL v2.0. Separately, REA's PSP static ELF guide uses it as a caller-installed extension and pairs v21.4 with Ghidra 12.1.3. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### GM8Decompiler > Command-line tool that turns games built with GameMaker 8.0 or 8.1 back into editable .gmk or .gm81 project files. It reads the gamedata section that a built executable carries next to the runner and writes its settings, sprites, sounds, backgrounds, paths, scripts, fonts, timelines, objects, rooms, extensions, included files and GML code in the project format matching the game's version. A Rust rewrite on the OpenGMK project's gm8exe library that replaced the team's fork of WastedMeerkat's gm81decompiler, it is now developed in the OpenGMK repository alongside the GM8Emulator runner reimplementation. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.2.0, published 2024-02-12 with i686 and x86_64 Windows MSVC builds. Its tag points at the January 2022 commit that leaves only the README and licence in this repository, because development moved to OpenGMK while releases are still published here. The release notes list a Rust update from 1.59 to 1.76, a fix for executables written by gm82, and support for the 810 and 811 room formats; the OpenGMK gm8decompiler crate is also at 2.2.0, and its later commits only raise the Rust version and update dependencies. - Source builds use the OpenGMK Cargo workspace, cloned with submodules and built with cargo build --release, which also builds GM8Emulator. rust-toolchain.toml pins Rust 1.77 to keep Windows 7 support, and the OpenGMK README says only MSVC targets are supported on Windows and, because releases are rarely updated, recommends building it yourself. The decompiler crate has no tests, and neither repository has CI workflows at the reviewed commits. - Input is a GameMaker 8.0 or 8.1 game executable the user supplies; neither repository includes games. Usage is gm8decompiler FILENAME: -o names the output, which otherwise is the input path with the .gmk or .gm81 extension for the detected version; -l disables data-integrity checks; -s decompiles on one thread to lower memory use; -p keeps broken custom Execute Code actions instead of converting them to standard ones; and -d sets deobfuscation of GML code processed by Schreib's GM Obfuscator, which the default auto mode enables when assets have empty names. - The README reports the Rust loader as over ten times faster than the old gm81decompiler fork, safer, more thorough and able to read more games; these are project claims, and no per-game compatibility list or output check is published. GPL-2.0-only per Cargo.toml, with the GPL v2 text in LICENCE.md. Recovered projects contain the game's own assets and code, which remain subject to the rights of the game's owner. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### UELib (Unreal-Library) > C# library that reads Unreal Engine 1, 2 and 3 package files such as .u, .upk and .udk, auto-detects a matching game build and deserializes their exports, imports and properties. Its main goal is decompiling UnrealScript bytecode back to source by reconstructing classes, states, functions, structs, enums and default properties; it also deserializes fonts, sounds, palettes and textures. The README’s per-game compatibility table runs from Unreal and Deus Ex to Splinter Cell, Mass Effect and the Batman: Arkham games, and the separate UE Explorer GUI is built on it. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Published on NuGet as Eliot.UELib: the latest stable package at review is 1.13.7, published 2026-07-17, targeting .NET Framework 4.8, .NET Standard 2.0 and 2.1 and .NET 10, while the newest GitHub release page is 1.12.0 from 2025-09-22. Versions come from Nerdbank.GitVersioning, and the reviewed master commit (2026-10-16) is later than both. The repository also holds a small .NET 10 command-line client, a separate decompiler project and a work-in-progress T3D decompiler. - Input is package files from the user’s own game installations. The README warns that opening an unsupported package could crash the system, that production UE3 packages are often compressed and must first be decompressed with a separate tool, and that some games need third-party decompression or extraction. Textures in .tfc caches, models and animations are not supported, and audio and texture output is expected to work for most games but not confirmed. - Compatibility rows are the author’s and contributors’ reports per game and package version, including known problems such as bad output at function starts for X-COM: Alliance, wrong UStruct offsets for Duke Nukem Forever (2001) and bad byte-codes for Medal of Honor (2010); some rows are marked unverified. The MSTest suite reads TestUC1–TestUC3 packages compiled from the project’s own UnrealScript test classes, and some tests point at local Unreal Tournament or UT2004 installations. - MIT license (Eliot van Uytfanghe). Game packages, scripts and assets keep their rights holders’ terms, and decompiled UnrealScript is a reconstruction, not the original source files. The GitHub description also mentions .uasset, but the README’s compatibility table covers only Unreal Engine 1–3 games. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### DiztinGUIsh > Windows disassembler for Super NES ROMs in which the user marks bytes as code or data, steps through 65816 code while the tool tracks the M and X flags and the data bank and direct page registers, adds labels and comments, and exports assembly for the asar assembler that the README says compiles back into the original binary. Execution context can come from BizHawk or BSNES trace logs, BSNES usage maps and BizHawk code/data logs, or live capture over a socket from a custom bsnes-plus build. Project files keep the annotations in merge-friendly XML with a link and checksum for the ROM rather than the ROM itself, so several people can work on one disassembly. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.5.1.0, published 2025-12-07 as a self-contained Windows x64 build; the reviewed master commit of 2026-08-09 is 106 commits later and adds, among other changes, Avalonia versions of several dialogs and a second Diz.AvaloniaUI-Beta executable. The WinForms app targets net10.0-windows, and CI builds, tests and publishes it on Windows with the .NET 10 SDK, while contributing.md still asks for Windows 10+ and .NET SDK 8 or higher. - Input is a SNES ROM file the user supplies; the repository includes no ROMs. HELP.md says project files (.diz, which is gzip-compressed XML, or uncompressed .dizraw) store a link to the ROM with its internal name and checksum instead of the ROM, so they can be shared without it. Live trace capture needs the custom bsnes-plus build from binary1230/bsnes-plus, which listens on port 27015, rather than stock BSNES+, and the README suggests an asar fork with a relative-addressing fix. - The test project bundles small .asm samples, a 4 MB binary trace-log fixture (ct-binary-tracelog7.758s-60fps-locked.bin) from a 7.8-second emulator capture that only commented-out performance-test code references, and SuperFamicheck 1.0's superfamicheck.exe as a helper; tools/dizpack holds Python packing scripts and tools/dizpack-game/ct a Chrono Trigger (US) LZSS codec. Disassembly depends on the user's marking and stepping: the README says the program pauses for input whenever it cannot disassemble accurately, and lists SPC700 and SuperFX support as planned. CI runs the repository's xUnit tests, but no per-game results confirm that exported assembly rebuilds the original. - GPL-3.0 per LICENSE.md, with third-party library licenses listed in Diz.App.Winforms/dist/docs. Exported assembly contains the ROM's code and data and remains subject to the rights of the game's owner. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Zygisk-Il2CppDumper > Zygisk module by Perfare, the Il2CppDumper author, that dumps type metadata from inside a Unity IL2CPP Android app while it runs. Built for one package name, it waits for the app to load libil2cpp.so, resolves the runtime's il2cpp API exports, walks the classes of every loaded assembly and writes dump.cs to the app's files directory, listing namespaces, classes, interfaces and enums with field offsets, properties and method signatures annotated with RVA and virtual addresses. On x86 devices running an ARM build of the app, it loads its ARM library through the Houdini native bridge. - Type: Tool - Targets: App · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-02 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs a rooted Android device with Magisk v24 or later and Zygisk enabled, and an app the user supplies that uses Unity's IL2CPP backend. There are no published releases: the module is built for one package name, either by running the repository's manual Build workflow in a fork with that name or by editing GamePackageName in game.h and running the Gradle task :module:assembleRelease (NDK 25.2.9519653; CI uses Java 11), then installed through Magisk. dump.cs appears under /data/data//files/ once the app starts. - **Limits:** It writes only dump.cs; unlike the desktop Il2CppDumper, it produces no dummy assemblies or disassembler scripts. The latest master commit is from 2023-05-22, with the module at v1.2.0. - **Testing evidence:** The repository has no tests, and its only CI workflow builds the module on manual dispatch. - **License:** MIT per LICENSE, whose copyright line names Rikka; the bundled xDL symbol-lookup library carries its own MIT notice from the HexHacking Team. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### UABEA > Cross-platform reader and writer for the asset bundles and serialized asset files of Unity games, originally based on, though not a fork of, the archived UABE. Its README presents it as a modding and research tool rather than an extractor and points users who only want to extract assets to AssetRipper or AssetStudio; it opens bundles from Unity's Addressables system, whose CRC checks must be cleared with a separate tool before edited bundles load. It builds on AssetsTools.NET with Cpp2IL and Mono.Cecil, and the repository includes texture, audio-clip, font and text-asset plugins. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows and Linux builds come from the releases or from nightly CI artifacts, and the project targets .NET 8. Release at review: v8, published 2024-11-03; the reviewed master commit dates from 2026-05-11. The README also points to UABEANext, a successor with docking and multi-bundle opening that is still a work in progress. - **Limits:** Bundles that belong to Addressables need their CRC checks cleared with the separate AddressablesTools patchcrc command before edited bundles are used, as the README describes. - **License:** MIT per the license file; bundled libraries keep their own terms, including the PVRTexTool license for PVRTexLib, zlib for Unity crnlib and CC BY 4.0 for Font Awesome. ##### Primary sources 1. 2. 3. 4. 5. 6. #### AssetStudio > Tool for exploring, extracting and exporting the assets and asset bundles of Unity versions 3.4 to 2022.1. It converts Texture2D and Sprite images to PNG, TGA, JPEG or BMP and AudioClip to MP3, OGG, WAV, M4A or FSB, with FSB-to-WAV conversion, and exports fonts, meshes as OBJ, text assets, shaders, movie and video clips and MonoBehaviour data as JSON; models export from the scene hierarchy, and Animators export to FBX with their bound AnimationClips. MonoBehaviour export asks for the folder holding the assemblies, such as Managed, or, for IL2CPP builds, the dummy DLLs that Il2CppDumper generates. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Builds target .NET Framework 4.7.2, .NET Desktop Runtime 5.0 or .NET Desktop Runtime 6.0. Building needs Visual Studio 2022 or newer, and the native FBX exporter needs Autodesk's FBX SDK 2020.2.1. The latest release is v0.16.47 (2022-06-16), and the repository is archived on GitHub. - **Limits:** Loading asset bundles decompresses and reads them in memory, which can use a large amount of memory; the README suggests extracting them to a folder first and reading them from there. - **License:** The README states that neither the repository, the tool nor its owner is affiliated with, sponsored or authorized by Unity Technologies. MIT per LICENSE; the bundled texture decoders come from separately licensed open-source projects. ##### Primary sources 1. 2. 3. #### vgmstream > Library and tools that decode streamed, prerecorded video game audio in hundreds of formats and codecs, from common game engine files to single-game codecs, including looped music, subsongs, companion files, custom containers and encryption keys. TXTH text descriptors add support for further formats, including raw audio, and TXTP files set per-file options such as forced looping or merging files. It ships as the vgmstream-cli decoder, which converts supported files to WAV, the vgmstream123 player and plugins for Winamp, foobar2000, XMPlay and Audacious, and an online web player is available at vgmstream.org. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Numbered releases are on GitHub and nightly builds on vgmstream.org; release at review: r2168, published 2026-10-25, and the reviewed master commit dates from 2026-11-05. Users supply the game audio files; doc/FORMATS.md lists the supported formats. - **License:** An ISC-style permissive license in COPYING, with portions under their own copyright notices. ##### Primary sources 1. 2. 3. 4. 5. #### Weeping of the Empire: statically recompiling Tears of the Kingdom for Windows > Weeping of the Empire builds a native Windows port of The Legend of Zelda: Tears of the Kingdom from the user's Switch game dump. It recompiles ARM64 code ahead of time to x86-64, supplies Switch services through a host runtime and renders through Vulkan. The engine documentation credits totk-recomp as the starting point and identifies the added Windows port, renderer, controls and menus. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows 10 or 11 x64, a Vulkan 1.3 GPU driver and the user's game dump are required; encrypted dumps also require the user's keys. Installation needs internet access. - **Limits:** Game version 1.0.0 is supported, with 1.4.3 in beta; first visits may stutter while shaders are built. - **License:** MIT License. ##### Primary sources 1. 2. #### GTA Mode: reverse-engineering SimCity 3000 Unlimited for a native plugin > GTA Mode is a native plugin that adds direct control of spawned citizens and cars to SimCity 3000 Unlimited. It uses findings from Ghidra analysis of the game's binaries, GZCOM plugin loading, in-memory city structures and sprite archives. The C plugin runs in the original game, reads city data from its memory and decodes art from the user's installation; MODLOG.md records addresses, formats and dead ends. - Type: Case study - Targets: Binary · Game - Category: Game analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A user's copy of SimCity 3000 Unlimited is required; the supported game DLLs are the Steam release's April 2000 builds. - **Prerequisites:** Building requires a 32-bit mingw-w64 compiler; the HUD uses cnc-ddraw's OpenGL renderer. - **Limits:** The game's own traffic cannot yet be stolen and its own pedestrians cannot yet be punched; water does not block movement. - **License:** MIT License. ##### Primary sources 1. 2. #### FH2MP: reconstructed Forza Horizon 2 online services > FH2MP restores Forza Horizon 2 multiplayer with a replacement server based on protocol behavior recovered from the Xbox One game client. An in-game shim redirects sockets and web-service calls, while Python and Go servers handle lobbies, worlds and online features; a launcher manages setup and updates. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A legitimately owned Forza Horizon 2 Xbox One build 1.0.0.64 and Azimuth are required. - **Limits:** The source warns of crashes, desynchronization and rough edges. - **License:** GPL-3.0 licence. ##### Primary sources 1. 2. #### Cursed Lands: a Godot engine for Evil Islands and Lost in Astral > Cursed Lands reimplements the engine for Evil Islands and Lost in Astral in Godot, reading maps, models, audio, scripts and tables from the player's own game copy. Its native rendering, combat, AI, scripting and interface systems follow the original game's rules, with releases for desktop, Android and browsers. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An owned copy of Evil Islands or Lost in Astral is required; the GOG base-game edition is the main tested version. - **Prerequisites:** The browser version requires WebGL 2. - **License:** Apache License 2.0. ##### Primary sources 1. #### pkg-to-anyps5 > pkg-to-anyps5 extracts PS5 debug game packages or game folders into the layout expected by the AnyPS5 relinker. It parses FIH, PFS and NAPS structures, decodes supported Kraken blocks, and unwraps fake-signed SELF executables and modules into ELF files. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Rust 1.88 or newer to build from source; input is a PS5 debug package or extracted game folder. - **Limits:** Retail packages, encrypted filesystems and encrypted SELF segments are refused; several Kraken entropy types are unimplemented. - **License:** GPL-3.0-or-later license. ##### Primary sources 1. 2. #### nfs-mw: a Rust reconstruction of Need for Speed: Most Wanted > nfs-mw reconstructs Need for Speed: Most Wanted 2005 PC v1.3 in Rust using data read from the user's installation. Its format readers decode bChunk, JDLZ, HUFF, cars, textures, and the streamed city; the current runtime provides viewers, driving, menus, and free roam. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Rust stable and an installed copy of Need for Speed: Most Wanted PC v1.3 / Black Edition are required. - **Limits:** Windows and Linux are documented; gameplay beyond the listed menus and free roam remains on the roadmap. - **License:** Apache-2.0 and MIT license files are present. ##### Primary sources 1. 2. #### bf-private-server: a Brave Frontier revival server > bf-private-server recreates a self-hosted server for Brave Frontier client version 2.19.6. Its C++23 service answers the game's HTTP requests, stores saves in SQLite and works with CDN workers and a patcher for the user's Android client; request tables and boot-flow notes document the protocol investigation. The server builds on an earlier emulator fork. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Git and Docker or a native C++23 toolchain are required for the server. - **Prerequisites:** Game data and a copy of the Android client must be obtained separately. - **Limits:** Some client requests remain unimplemented and return a not-available response. - **License:** AGPL-3.0 license. ##### Primary sources 1. 2. #### OpenLF2: a Little Fighter 2 engine reimplementation > OpenLF2 reimplements Little Fighter 2 v2.0a as a playable C++ and Lua engine. It loads resources from the original game installer and provides local modes, replays, mods and network matches between OpenLF2 players. The author states that gameplay compatibility is still being refined. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The Little Fighter 2 v2.0a installer is needed for original game data; Flatpak downloads it during installation, while other platforms prompt users to provide a copy. - **Prerequisites:** Building requires CMake 3.25+, Ninja, a C++23 compiler, and the development libraries listed in BUILDING.md. - **Limits:** Gameplay compatibility is still under development; original LF2 network compatibility is unsupported. - **License:** MIT license covers OpenLF2 code, scripts and documentation, not the original game assets. ##### Primary sources 1. 2. #### Atlantis Native: porting the Atlantis and Atlantis II engines to Rust > Atlantis Native ports the reverse-engineered CryOmni3D Atlantis engine to Rust for Atlantis: The Lost Tales and Atlantis II. It reads files from the user's own game copies and runs their scripts, panoramas, cinematics and puzzles on desktop systems and in browsers, with optional display and bug fixes. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Users supply their own copies of Atlantis: The Lost Tales or Atlantis II; game data is not included. - **Scope:** Desktop builds cover Windows, macOS and Linux; a browser build is also described. - **License:** GPL-3.0-or-later license. ##### Primary sources 1. 2. #### SF2Recomp: statically recompiling Shadow Fight 2 for native platforms > SF2Recomp converts a user's Shadow Fight 2 Nintendo Switch game files into native builds for Linux, Windows, macOS, and Android. Its converter combines translated game code with a runtime and user-supplied assets, adding controls, graphics options, sparring, and LAN play. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply a combined base plus v1.1.0/update v131072 NSP with sidecars and prod.keys, or already extracted updated game files. - **Prerequisites:** A Vulkan 1.3 compatible GPU and driver are required; platform version requirements vary. - **Limits:** macOS Apple Silicon support is experimental, with gameplay and GPU validation pending. - **License:** Project code is MIT licensed; dependencies and the project icon have separate terms. ##### Primary sources 1. 2. #### dfsdk > dfsdk dumps Delta Force object metadata by enumerating its object array, decoding per-entry XOR-encrypted names and walking class super chains and property lists. The README documents name-pool addressing, pointer masking, selected field offsets and example output. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Delta Force process with the documented object and name-pool layout is the target input. - **Scope:** The documented offsets are specific to the investigated layout. - **License:** No licence file in the repository. ##### Primary sources 1. #### KBot > KBot inspects and transforms Total Annihilation and TA: Kingdoms game files, pairing a Go CLI with a proprietary format reference. It decompiles COB bytecode to BOS source, disassembles scripts, checks round trips and examines formats including HPI archives, GAF sprites, TNT maps and 3DO models. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Go is needed to install or build the CLI. - **Prerequisites:** Asset inspection requires files from Total Annihilation or TA: Kingdoms; an installed game can provide them. - **License:** MIT license. ##### Primary sources 1. 2. #### Devil May Cry: an experimental PS2 static recompilation > dmc-recomp translates the PlayStation 2 PAL release of Devil May Cry into native PC code through PS2Recomp and a project runtime. Its pipeline rebuilds generated code locally from the user’s own game executable, while research notes and patches track boot, CD services, MPEG playback, rendering and gameplay behavior. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A user-supplied copy of the PAL Europe Devil May Cry version 1.02 executable or disc image. - **Prerequisites:** PS2Recomp at the pinned upstream commit and the documented build toolchain. - **Limits:** The source describes the port as experimental, with incomplete rendering and gameplay. - **License:** GPL-3.0 licence. ##### Primary sources 1. 2. #### Sin & Punishment: a work-in-progress N64 static recompilation > Sin & Punishment: Recompiled uses N64Recomp and RSPRecomp to build an experimental native C++ port from a user-supplied Japanese N64 ROM and the repository's symbol maps, with RT64 rendering. The author reports that it reaches the title screen; menu navigation, gameplay, audio validation, and a public pipeline for its patched working image remain unfinished. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A legally obtained Japanese Sin & Punishment ROM, Python 3, the pinned submodules, and the platform build toolchain described in the README. - **Limits:** The current recompilation configuration also expects a patched working image whose preparation pipeline is absent from the public repository. - **License:** No licence file in the repository. ##### Primary sources 1. #### scvk: replacing SimCity 4's renderer with Vulkan > scvk reconstructs SimCity 4's renderer interface as a native Vulkan DLL loaded through the game's GZCOM plugin system. It claims existing renderer class IDs and emulates the cIGZGDriver fixed-function API with pipeline state and shaders for terrain, buildings, lighting, textures and interface drawing. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** SimCity 4 with the documented GZCOM plugin interface and Vulkan-capable graphics hardware. - **Limits:** SCGL cannot be installed concurrently because it claims the same renderer class ID; Intel graphics are untested. - **License:** LGPL-2.1-or-later license. ##### Primary sources 1. #### Salamander UEFI: a disassembly-based UEFI port of the NES game > Salamander UEFI ports the NES game Salamander to a native UEFI Shell application by translating its 6502 disassembly into a platform-independent C core. The repository includes a 6502 disassembler, a user-ROM resource extractor, host tests and a fidelity checklist. UEFI GOP, input and timing services replace the original console environment. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A legally held Salamander NES ROM is required to generate game-resource headers. - **Prerequisites:** Building requires Windows, Visual Studio 2019, EDK2 and Python 3.10 or newer; QEMU/OVMF is used for emulated runs. - **Limits:** The app has no audio, and the source lists score display and some boss sprite differences. - **License:** No licence file in the repository. ##### Primary sources 1. 2. 3. #### BNDExtract > BNDExtract is a Go command-line tool for extracting the ALL.BND archive used by Kuon and some other FromSoftware PlayStation 2 games. It takes a .bnd file and an output directory, providing access to the archive's contents for inspection. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A supported .bnd archive and Go to build the tool. - **Scope:** The documented support centres on Kuon's ALL.BND and some other FromSoftware PS2 releases. - **License:** No licence file in the repository. ##### Primary sources 1. #### RE4METoolbox > RE4METoolbox provides command-line utilities for examining and modifying Resident Evil 4 Mobile Edition files. RE4MEAcvTool unpacks and repacks ACV .bin archives, while RE4METextTool converts Mission and Resource .bin text files to TSV and repacks edited text. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Resident Evil 4 Mobile Edition .bin files; the text tool requires a Mission or Resource format flag. - **License:** MIT license. ##### Primary sources 1. #### Aspyr Archive Tool > Aspyr Archive Tool unpacks and rebuilds Android OBB archives used by three Aspyr game ports: Star Wars: Knights of the Old Republic II, Jade Empire: Special Edition and Fahrenheit: Indigo Prophecy Remastered. Its command-line options support full or selective compression and a CRC64 checksum for Jade Empire. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An OBB archive from one of the listed games is required. - **License:** MIT. ##### Primary sources 1. #### ScriptSource-Dumper > ScriptSource-Dumper extracts scripts from Call of Duty: Black Ops II scriptsrc.clump archives. Its C++ parser reads the archive table of contents and data chunks, locates the internal name table, and writes files under their recovered names and directories. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A scriptsrc.clump archive from Call of Duty: Black Ops II. - **Prerequisites:** Visual Studio 2022 or newer and the MSVC v145 toolset to build. - **License:** No licence file in the repository. ##### Primary sources 1. #### .AUP-File-Type-Decryptor-and-Viewer > .AUP-File-Type-Decryptor-and-Viewer is a local browser tool for inspecting Dragon Soul .aup game asset files. It implements the documented LZSS variant, previews image, audio and text formats, and exports files while preserving folder structure. The README specifies the four-byte size header and ring-buffer command stream. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A browser and Dragon Soul .aup files are required for use. - **Limits:** Encoding and compression of raw files back into .aup is listed as unfinished. - **License:** MIT license. ##### Primary sources 1. #### tMock-Server: reconstructing Terraria server handshakes > tMock-Server is an unfinished C++ reimplementation of the Terraria server's initial network flow. It uses socket code and packet classes to accept connections, check protocol versions, request passwords, and assign player slots; the README records packet IDs, fields, directions, and structures informed by traffic analysis. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** GNU/Linux is currently required because the server relies on its socket support. - **Prerequisites:** CMake 4.1 and a C++26 toolchain are specified by the build file. - **Limits:** Player and world information handling remain unfinished. - **License:** GPL-3.0 license. ##### Primary sources 1. 2. #### NuVelocity Engine: reimplementing Reflexive's Velocity Engine > NuVelocity Engine reimplements Reflexive Entertainment's Velocity Engine as a C++ and SDL3 game engine. It provides modular 2D rendering, asset and resource loading, audio playback, screen management, and a property-based object system, with decoder source included in the repository. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** SDL3, SDL3_image, SDL3_mixer, SDL3_ttf, zlib, physfs, CMake, and submodules are required for the documented build. - **License:** Mozilla Public License 2.0 applies to the engine and main code. ##### Primary sources 1. 2. #### FreeRS42: reimplementing Ricochet Xtreme > FreeRS42 is a C++ project to reimplement the PC game Ricochet Xtreme using the NuVelocity engine. The repository contains source for game objects, playfield behavior and screens, with a CMake build that includes the engine submodule. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Clone the repository with submodules and install the engine dependencies documented by the project. - MPL-2.0 license for the main code and engine. ##### Primary sources 1. 2. 3. #### Universal GBA Pokedex > Universal GBA Pokedex scans Game Boy Advance Pokémon ROMs to locate and display evolution, name and item tables. It searches byte signatures, scores candidate tables using text and pointer patterns, and aligns entries against known anchors instead of requiring fixed offsets. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a Game Boy Advance Pokémon ROM supplied by the user. - **Prerequisites:** Running from source requires Python 3.x and Tkinter. - **Limits:** Support for expanded Pokédex hacks such as Radical Red is experimental. - **License:** MIT licence. ##### Primary sources 1. #### VG Reverse Engineering > VG Reverse Engineering decodes Vainglory: Community Edition replay files into recorded player names, heroes, K/D/A, items, gold and scoreboard counters. Its offline tools also export JSON and CSV, maintain a SQLite catalog and document VGR record and event interpretation. Output records provenance and leaves unsupported values unresolved. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.12 or newer for the offline decoder; the complete regression suite also requires Node.js 18 or newer. - **Prerequisites:** A user's own .0.vgr recording and numbered sibling files are needed for decoding a match. - **Limits:** The source says recordings lack a client build identifier and currently cannot enter its definitive-analysis subset. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### Chip-8 Emulator and c8-disassembler > The c8-disassembler in Chip-8 Emulator translates CHIP-8 ROM opcodes into assembly instructions. Its source and sample Pong ROM listing show the supported output; the repository also contains a companion emulator whose SDL2 display is marked as work in progress. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** CMake 3.9 or newer is required to build the disassembler; the emulator also requires SDL2. - **Limits:** Super Chip-48 instructions are listed as unsupported. - **License:** GPL-3.0 license. ##### Primary sources 1. 2. #### BGI Converter TGA > BGI Converter TGA analyzes BGI-Ethornell game image files and converts custom RGB or RGBA layouts and BMP images into 32-bit TGA. Its C++17 utility detects formats from headers, reports dimensions and offsets, and supports single-file or batch conversion. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a C++17 compiler with std::filesystem support. - **Scope:** Inputs are the documented BMP 24-bit, BMP 32-bit, BGI custom RGBA or BGI custom RGB layouts. - **License:** MIT license. ##### Primary sources 1. #### Xenus DT1 Decompiler > Xenus DT1 Decompiler extracts DT1 and DT2 texture caches from Xenus 2: White Gold and Boiling Point: Road to Hell; its current decoder has not been tested with The Precursors. Its C# decoder reimplements behavior recovered from VELoader.dll, handles zlib and UCL NRV2E streams, and exports DDS or converted image formats. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The release targets 64-bit Windows; building requires .NET SDK 8.0 or later. - **Limits:** The Precursors has not been checked with the decoder used since version 3.0; method 7's additional encryption is unsupported. - **License:** MIT license. ##### Primary sources 1. #### Metroid Dread: a hand decompilation in progress > DreadComp is an in-progress hand decompilation of Metroid Dread that recreates game source code in C++. The repository includes initial source files, build tooling and symbol data; building requires assets and the version 2.1.0 executable from the user's own game copy. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An owned copy of Metroid Dread and its original 2.1.0 main NSO executable are required. - **Prerequisites:** Windows users are directed to use WSL; installation lists Python, Ninja, CMake, ccache, xdelta3, Clang and a Rust toolchain. - **Limits:** The decompilation is a work in progress. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### MTG Arena Collection Export: reconstructing the Frontdoor collection request > MTG Arena Collection Export reconstructs the Frontdoor request needed to export owned cards from Magic: The Gathering Arena. The Python client uses an account refresh token, opens a TLS Frontdoor socket, authenticates with the 2026 version 4 frame and protobuf command envelope, and requests Card_GetAllCards. A separate protocol document records the recovered wire format. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python 3.8 or newer and a captured refresh token from the user's own Arena account. - Requires a captured doorbell response or a Frontdoor URI; the source says Arena should be closed during export. - MIT licence. ##### Primary sources 1. 2. #### Void Client: rebuilding the Starblast.io client > Void Client is an unfinished JavaScript rewrite of the Starblast.io browser game client based on study of its network protocol. Its current Node.js and browser components provide game-mode selection, server discovery, local WebSocket communication, and parsing and JSON export of some received packets. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Node.js and the package.json dependencies are required. - **Limits:** The client is a work in progress; current functionality covers menus, network helpers, and basic packet parsing. - **License:** The package.json declares an ISC license; the repository has no separate license file. ##### Primary sources 1. 2. #### GRB Modding Knowledgebase > GRB Modding Knowledgebase documents Ghost Recon: Breakpoint’s Anvil .forge archives, nested .data resources and asset replacement workflow. Its Python inspectors examine MotionCloth files, list resource types, compare forge indexes and diff gameplay database records to explore field layouts. - Type: Project - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Inspection requires Ghost Recon: Breakpoint game data; the Data Inspector uses the game’s DLL for Oodle decompression. - **Limits:** The project describes itself as a living research project with open questions. - **License:** No licence file in the repository. ##### Primary sources 1. #### psp-media-slopkit > psp-media-slopkit analyses PSP XMB ICON1.PMF and SND0.AT3 files using format findings derived from retail game samples. Its Python CLI checks media against documented XMB limits, converts video and audio into icon media, and inserts the results into a homebrew EBOOT.PBP. FINDINGS.md records PSMF container fields, H.264 constraints and AT3 playback behaviour. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.8 or newer; video conversion requires ffmpeg and ffprobe with libx264. - **Prerequisites:** SND0.AT3 creation requires atracdenc; ATRAC3+ output requires Sony's at3tool.exe. - **Prerequisites:** PBP repacking requires an existing homebrew EBOOT.PBP. - **Testing evidence:** The author reports hardware checks of generated ICON1.PMF and SND0.AT3 media. - **License:** MIT license. ##### Primary sources 1. 2. #### DualRip > DualRip extracts Nintendo DS sound effects and music from SDAT archives and Nintendo 3DS audio from CSAR archives, including ROM inputs. It parses sequence, wave and stream formats, emulates the consoles' sound drivers for rendering and exports WAV files with loop points through CLI and GUI frontends. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10+ with NumPy, ndspy and pyctr is required; the GUI additionally uses PySide6 and sounddevice. - **Prerequisites:** Encrypted 3DS ROMs require the user's boot9.bin dump; no game data is included. - **License:** MIT License. ##### Primary sources 1. #### OpenPigeon: reconstructing GamePigeon iMessage game messages > OpenPigeon is a TypeScript codec for reading GamePigeon iMessage game state and encoding caller-supplied moves for eleven turn-based games. Its protocol documentation describes balloon identity, encrypted move URLs, the length-seeded cipher and the state envelope; captured-message vectors support codec tests. - Type: Case study - Targets: Game · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Node.js 22 or newer. - **Prerequisites:** Sending through Linq or Photon requires an account and host; Linq webhooks require a public endpoint. - **Limits:** The SDK handles turn-based payloads; live Play Now mode and move selection are outside its scope. - **License:** MIT license. ##### Primary sources 1. 2. #### YGO-PoC Toolset > YGO-PoC Toolset handles resource and save formats from Yu-Gi-Oh! Power of Chaos – Joey the Passion. Its unpacker extracts compressed game resource files such as data.dat, while PoCTools decrypts, edits and re-encrypts system.dat saves; the repository also includes a card editor and DLL mod loader. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Its editor is a .NET MAUI client for PoCTools. - **Scope:** The toolset targets the game's No-CD/Fixed executable version. - **License:** MIT license. ##### Primary sources 1. #### FH6 Model Tools > FH6 Model Tools parses reverse-engineered Forza Horizon 6 asset formats, including burG model and texture containers. Python converters export car meshes to GLB or OBJ, textures to DDS, and selected material, palette, lighting, and ambient-occlusion data to readable outputs. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.8 or newer and user-supplied game assets are required. - **Limits:** The research-status document leaves animation formats, carbin, physics data, and some material and UV semantics unresolved. - **License:** PolyForm Noncommercial License 1.0.0. ##### Primary sources 1. 2. 3. #### Cosmo: a native port of Cosmo's Cosmic Adventure > Cosmo ports the reconstructed source of Cosmo's Cosmic Adventure: Forbidden Planet to macOS, Linux and Windows. It retains the game's logic and supplies an emulated EGA adapter, timer, keyboard controller, PC speaker and AdLib layer for the original code. The build uses the user's game data files. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A source build requires CMake 3.21+ and C11 and C++17 compilers. SDL3 can be installed or fetched by CMake; the documented Windows builds use MinGW. - **Prerequisites:** A source build requires the original game data files; Episodes 2 and 3 require the user's own copies. - **Limits:** Joystick support is unimplemented, and frame-by-frame comparison against DOSBox remains incomplete. - **License:** MIT License. ##### Primary sources 1. 2. 3. #### Ed1th's PvZ Toolkit > Ed1th's PvZ Toolkit inspects and edits Plants vs. Zombies resource archives and files through a desktop or web interface backed by Rust format libraries. Its workspaces cover RSB/RSG, PAK and DZip archives, RTON and NEWTON data, PAM animation, Compiled Text and Wwise WEM audio, among other formats. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Provide Plants vs. Zombies resource files for inspection or editing. - **Limits:** PAM editing does not implement curve-based tween authoring or new artwork drawing. - **Limits:** The BNK SoundBank browser is experimental. - **License:** AGPL-3.0 license. ##### Primary sources 1. 2. #### kenshi-modkit > kenshi-modkit parses and writes Kenshi .mod and .base files and reads its .save, .zone and .platoon files using Python. Its format notes document filetypes 15–17 and inferred typecodes, while utilities dump records, compare saves, detect mod conflicts and check byte-identical round trips. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.12; standard library only. - **Prerequisites:** Kenshi files are required for parsing and round-trip checks. - **Limits:** The author reports byte-identical round trips for 52,445 files; some typecodes remain unidentified and writing over saves is deliberately avoided. - **License:** MIT license. ##### Primary sources 1. 2. #### Left 4 Dead 2: recovering the AI Director's behavior > This Left 4 Dead 2 study reconstructs the AI Director's pacing, intensity, encounter placement and music rules from an identified x86 server.dll and sanitized runtime traces. It publishes disassembly-derived findings, analysis scripts, evidence files and implementation specifications; a reference game library is in a separate repository. - Type: Case study - Targets: Binary · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Reproducing the analysis requires an installed copy of Left 4 Dead 2, Python 3 and Capstone for disassembly scripts. - **Prerequisites:** Matching RVAs require the specified June 30, 2026 x86 server.dll build. - **Limits:** The retail binary is stripped, leaving some private names and engine-specific helper behavior unresolved. - **License:** No licence file in the repository. ##### Primary sources 1. 2. 3. #### MechRewired: rebuilding MechWarrior 2 from original game data > MechRewired rebuilds the MechWarrior 2: 31st Century Combat experience around data imported from a user's DOS copy. Its code loads original resources and missions, while providing a new cockpit, terrain rendering and combat simulation for modern platforms. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user's own MechWarrior 2 DOS game data; the author identifies PC English MS-DOS v1.1 as the checked package. - **License:** MIT License for the project source. ##### Primary sources 1. #### d2mac-linux: porting the Diablo II Mac executable to 32-bit Linux > d2mac-linux ports the Diablo II 1.14d Mac executable to 32-bit Linux by converting its i386 Mach-O container to ELF and reimplementing imported Darwin, Carbon and AGL interfaces in Zig. The shim translates graphics to GLX and adapts threading, files and sockets. The author reports that the game reaches its menu and character creation. - Type: Case study - Targets: Binary · Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A legitimate copy of the original Diablo II Mac client and its game data is required. - **Prerequisites:** Execution needs a 32-bit-capable Linux userland, Mesa GL and an X server. - **Limits:** Right-click handling and sound remain unimplemented. - **License:** MIT. ##### Primary sources 1. 2. 3. #### Spider-Man 2 PS2 Recomp: a static recompilation checkpoint > Spider-Man 2 PS2 Recomp applies static recompilation to the USA PlayStation 2 release SLUS-20776 for native PC execution. It combines a game-specific Ghidra function map with PS2Recomp source, runtime fixes and hardware comparison tests. The author reports that a native Windows build reaches the legal splash; the port is not playable. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A personally obtained USA Spider-Man 2 PS2 disc image and local extraction are required. - **Prerequisites:** The documented Windows workflow requires Ghidra with a PS2 Emotion Engine extension, CMake and Visual Studio 2022 C++ Build Tools. - **Limits:** The port is not playable; legal-splash rendering remains incomplete. - **License:** GPL-3.0 License. ##### Primary sources 1. 2. #### ffxii-tza-tools > ffxii-tza-tools documents and processes FINAL FANTASY XII The Zodiac Age character formats, including .ca animations, .cm models and .phyre assets. Its Python tools decode chunk structures, export models and animations to glTF, edit curves and repack @FRP containers from files extracted from the user’s game copy. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.9 or newer and game files extracted from the user’s copy of FFXII_TZA.vbf; Pillow is needed for PNG output. - **Testing evidence:** The author reports checking the documented .ca and .cm formats across the matching game files. - **Limits:** Blender round-trip editing and embedded .efx effect images are outside the current scope. - **License:** MIT licence. ##### Primary sources 1. 2. #### sims-package2glb > sims-package2glb extracts models from The Sims 2, 3 and 4 .package files into glTF binary files. Its Rust parsers handle DBPF containers, RefPack compression, RCOL and GMDC geometry, textures, materials and recolours. The documentation records format findings including Sims 4 DST texture planes and relative RCOL chunk references. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows is the supported platform. - **Prerequisites:** The input must be a Sims 2, 3 or 4 .package file; building from source requires Rust and Node. - **License:** MIT. ##### Primary sources 1. #### vc64_240p > vc64_240p analyses and patches the N64 Virtual Console emulator inside Wii WAD channels to output 240p. It finds render-mode structures by pattern, changes video fields and disables deflicker; an optional patch removes the emulator's dark filter. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A user-supplied N64 Virtual Console WAD and a separately generated Wii common key are required. - **Prerequisites:** Installing output on Wii requires cIOS 249 and Priiloader or BootMii. - **Limits:** PAL is unsupported, and the author reports live checks on five emulator builds. - **License:** MIT. ##### Primary sources 1. 2. #### touhou-engine: a Python reimplementation of Touhou gameplay > touhou-engine reimplements Touhou danmaku gameplay in Python, with TH07: Perfect Cherry Blossom as its reference game. The author says its engine logic was ported frame by frame against a decompilation, while the new architecture supplies an event stream, replay handling, headless stepping, and a pygame renderer. It reads original game archives supplied by the user. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python 3.12 or newer and the documented numpy, pillow, pygame, loguru, and msgspec dependencies. - Requires the user's own TH07 data archive; BGM uses thbgm.dat from the same directory. - The source attributes its decompilation reference to some100/th07. ##### Primary sources 1. #### Unrpyc > Unrpyc is a tool that decompiles compiled Ren'Py game scripts into readable script files. It runs from the command line or through files placed in a game's directory; it does not extract RPA archives. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use Python 3.9 or later for Unrpyc v2, or Python 2.7 for v1. - Choose the version for the game's Ren'Py release; v2 game injection supports Ren'Py 8, while v1 supports Ren'Py 6 and 7. - MIT per the README and LICENSE. ##### Primary sources 1. #### BSPSource > Java map decompiler that turns Source engine .bsp map files back into .vmf files that can be loaded in Hammer. It also has an integrated pakfile extractor. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The cross-platform JAR package requires Java 24 or later, installed and configured. - GoldSrc and Source 2 maps are unsupported. - Some internal entities cannot be restored perfectly. - Released into the public domain per LICENSE.md. ##### Primary sources 1. #### OpenLara: Tomb Raider engine reimplementation > Open-source engine for classic Tomb Raider, with a WebGL build and a standalone release. Its format code defines object types for Tomb Raider 1 through 4. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository declares the BSD-2-Clause license. ##### Primary sources 1. 2. #### Thyme: Command & Conquer Generals: Zero Hour reimplementation > Thyme is an open source reimplementation of Command & Conquer Generals: Zero Hour. It rewrites the game from the ground up and uses the original binary for functions it has not yet replaced. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Running Thyme requires an installed copy of Command & Conquer Generals: Zero Hour. - Building a working binary requires Microsoft Visual Studio 2017 or later. - Thyme currently runs only on Windows; its custom launcher supports the English disc version patched to 1.04. - The repository is archived. - License: GPL-2.0. ##### Primary sources 1. #### Chariot: Age of Empires engine reimplementation > Chariot is an open-source effort to reimplement the engine of the original Age of Empires (1997). It aims to support ports and enhancements; the README describes it as a work in progress with asset-loading demonstrations, not a playable game. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building requires Rust, a supported C/C++ compiler, and SDL2. - Running requires an original Age of Empires CD for game data. - The README reports that the project was not yet playable as of 2016-07-08. - The README declares an MIT license. ##### Primary sources 1. #### OpenDiablo2: Diablo 2 engine reimplementation > OpenDiablo2 is a cross-platform ARPG engine written in Go that supports playing Diablo 2. The project is being split into a separate engine and toolset, called Abyss Engine, and a game project retaining the OpenDiablo2 name. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Playing Diablo 2 requires a legally purchased copy of Diablo 2 and its Lord of Destruction expansion installed on the computer. - The project does not include the assets or content needed to play Diablo 2. - The repository is archived. - License: GPL-3.0. ##### Primary sources 1. #### PKHeX > PKHeX is a C# Windows Forms editor for Pokémon core-series save data. It can edit and save supported files, import Pokémon and teams, and convert data between game generations. - Type: Tool - Targets: Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires .NET 10. - Save files must be free of console-specific encryption; a save-data manager is needed to move saves to and from a console. - License: GPLv3. ##### Primary sources 1. #### OpenTomb: Tomb Raider engine reimplementation > OpenTomb is an open-source reimplementation of the classic Tomb Raider engine for playing levels from Tomb Raider 1–5 and custom TRLE levels. It is no longer maintained. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Playing original game levels requires assets from the corresponding games. - Building from source requires C++11 and the development dependencies listed in the README. - CD audio is supported only in OGG format. - License: LGPL-3.0. ##### Primary sources 1. #### Savage Wind Recomp: statically recompiling The Legend of Zelda: Breath of the Wild > Savage Wind Recomp is an in-progress static recompilation of the Nintendo Switch version of The Legend of Zelda: Breath of the Wild for Windows and Linux. It builds native game code locally from the player's extracted files; the README reports playable early areas but says the full story remains unconfirmed. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a personally obtained and extracted Nintendo Switch copy of the game with update 1.9.0; game files are not included. - Requires Windows 10 or later or Linux, a 64-bit CPU with SSE4.2, a Vulkan 1.3 GPU, 16 GB of RAM, and about 20 GB of free disk space. - The project is in alpha; later parts of the main story may have bugs or crashes. - MIT per LICENSE. ##### Primary sources 1. #### retruxx: reverse-engineered Hard Truck Apocalypse > retruxx is a reverse-engineered Hard Truck Apocalypse project that builds the game executable and separate renderer, input, and sound DLLs. Its 32-bit build matches the original game's memory layouts. - Type: Case study - Targets: Game - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building requires Windows, Visual Studio C++ build tools, CMake, Git, the DirectX SDK (June 2010), and the FMOD Core SDK. - Running the game requires an installed copy of Ex Machina / Hard Truck Apocalypse for its game data. - The executable and driver DLLs must have compatible bitness. - The repository has no license file. ##### Primary sources 1. #### nxnative > nxnative is a tool that packages Nintendo Switch games as apps that run their code natively on Apple hardware, with graphics translated to Metal. It builds iPhone, iPad, or Mac apps from supported Switch games; Switch 2 builds are documented for Mac only. - Type: Tool - Targets: Binary · Game - Category: Game analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building requires a Mac with macOS 26.6 or later, Xcode 27.2, Homebrew, and arm64 Python 3.12 or later. - Switch game builds require the user's game files and prod.keys; Switch 2 builds use a NUP file or extracted game files and do not require prod.keys. - iPhone and iPad play requires iOS or iPadOS 26 or later and the specified newer hardware; Switch 2 games are documented for Mac only. - License: MIT. ##### Primary sources 1. ### Apps (174) #### Aegis: trace a login-code calculation > An official APK investigation follows TOTP methods in Aegis and publishes artifact identities and selected Evidence. - Type: Case study - Targets: App - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Upstream case: Aegis 3.4.3, REA 6.1.0, jadx-headless-mcp 0.7.1 and OpenJDK 21 on Linux x64. - **Prerequisites:** Use the matching official APK for reproduction. ##### Primary sources 1. #### Notion: trace the clipboard bridge > Trace a packaged Electron clipboard path using REA findings and separate source inspection; the dynamic wrapper remains a stated limit. - Type: Case study - Targets: App - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** Upstream case uses Notion Desktop 7.6.1 packaged JavaScript and REA 4.1.0. - **Limits:** The full clipboard route was not automatically paired or observed as a desktop execution. ##### Primary sources 1. #### PicoPrint: LX-D02 printer investigation > The author describes REA-assisted Android investigation followed by separate Hermes decompilation to support a Windows BLE printer. - Type: Case study - Targets: App · Protocol - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Project README lists Windows 10/11, Bluetooth LE, an LX-D02 printer and Go 1.25+ to build. - **Attribution:** REA's stated role was readiness/device discovery and investigation framing; hermes-dec handled Hermes v98. - **Testing evidence:** Author-reported results. ##### Primary sources 1. #### ReaCut: video-editor reconstruction > An independent video editor whose authors document REA-assisted investigation of Jianying/CapCut behavior and project formats. The public implementation includes a local timeline, FFmpeg export and an experimental, lossy draft importer. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Testing evidence:** The v0.5.0 preview reports macOS Apple Silicon testing; Windows/Linux builds still need device validation. The macOS package is ad-hoc signed and not notarized. - **Limits:** The experimental importer is documented against controlled Jianying 11.0.12922 drafts. Basic conversions are lossy: effects, keyframes and styles can be lost, and projects cannot be written back. - **Attribution:** REA supports the reported research workflow but is not a runtime dependency. The project uses its own code and format; MIT source and bundled third-party components retain separate licenses. ##### Primary sources 1. 2. 3. #### CF632BLE: a local client from scale-protocol research > Reimplements the CF632BLE scale’s BLE protocol and body-composition calculations from research on the vendor’s Unique Health Android app. A static Web Bluetooth client receives measurements, manages device profiles and keeps its history in browser storage. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the CF632BLE hardware and a Chromium browser supporting Web Bluetooth in a secure context. Firefox and Safari/iOS cannot connect to the scale through this app. - **Prerequisites:** The SvelteKit/Vite application builds with npm and a static adapter. Its documented measurement path has no application server or vendor backend dependency. - **Scope:** Single-user browser storage is localStorage. The Device tab can explicitly write device profiles and settings; local history and scale memory are different stores. - **License:** The reviewed README and package manifest give no project license, and no root LICENSE file was present at the pinned commit. - **Testing evidence:** Device compatibility and formula accuracy are project claims. ##### Primary sources 1. 2. #### zee-rp: reconstructing supported Axure RP 11 document operations > Reads and rewrites supported native Axure RP 11 documents through a binary-record codec, reference-aware cloning and constrained interaction writers. CLI and MCP interfaces expose inspected edits while keeping offline structure checks separate from native application acceptance. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Package 0.1.1 requires Node.js 18+; MCP additionally uses the optional SDK dependency. Native creation needs the user’s Axure blank template and compatible libraries. - **Testing evidence:** Recorded native acceptance uses macOS arm64 and Axure RP 11.0.0.4137. Linux CI covers public core checks; native GUI jobs require macOS and Accessibility permission. - **Limits:** Unsupported document forms, external references and interaction expressions may be rejected. Numbered lists and true native merged table cells are not supported. - **Testing evidence:** Release evidence separates public/generated tests from historical assertions needing an unpublished exact fixture pack. One GUI sample checked load/save/close/reopen, not preview behavior or manual editing; newly synchronized features still need native acceptance. - **License:** Authored code/docs are MIT; Axure, its libraries and third-party assets are separate. ##### Primary sources 1. 2. 3. 4. 5. #### Virtual Desktop Streamer: rehosting the platform layer on Linux > An author-reported Claude Code and REA workflow replaces the macOS streamer’s capture, encoding, audio and input layer with Linux implementations while reusing vendor protocol libraries. The documented result targets desktop streaming and video playback, not Windows-only VR game streaming. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the official macOS Virtual Desktop installer for proprietary libraries and the user’s Virtual Desktop headset application. It is not a complete protocol reimplementation or an official vendor port. - **Prerequisites:** The build uses .NET 8. Linux runtime dependencies include GStreamer 1.16+, PulseAudio/PipeWire, X11 or an appropriate Wayland portal, OpenSSL 1.1 or 3 and uinput access; video-file playback additionally needs FFmpeg 7. - **Testing evidence:** Published testing used a simulated headset, mock portal and container networking. No real headset, real Wi-Fi or GPU encoder was available; internet matchmaking and same-address network changes were untested. - **Testing evidence:** The scroll fix was checked at device/libinput level without directly observing the receiving X11 app. - **License:** MIT applies to this repository’s code only. Vendor libraries remain proprietary; the project limits redistribution of packages containing them and does not grant rights to the headset application. ##### Primary sources 1. 2. #### Open Claude UI: REA-informed interface reference components > Publishes React components, motion helpers and design-system notes derived from the author’s reported REA investigation of Claude Desktop. It is useful as an interface-reconstruction case, with version-specific observations rather than proof of a complete assistant application or backend clone. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Package 1.0.0 declares React/React DOM 18+, Framer Motion 10+ and lucide-react 0.280+ peer dependencies; its development setup uses TypeScript 5.5 and Framer Motion 11. - **Scope:** Versioned analysis explicitly targets Claude Desktop v2.37337.1 and reports REA v6.5.0. - **Testing evidence:** The package exposes build/typecheck and a component preview; production-grade or high-fidelity wording remains the author’s assertion. - **Limits:** UI component examples do not supply Claude model access, account services or a recovered complete desktop application. Native desktop effects require their own host integration. - **License:** MIT repository license. The asset policy documents system-font fallbacks and synthesized audio instead of bundled proprietary font/audio files; it does not grant rights in upstream Claude assets or branding. ##### Primary sources 1. 2. 3. 4. 5. #### PlxNative: reconstructing a native webOS media-client interface > An unofficial Plex client built after the author investigated LG webOS native media interfaces with Ghidra and coding agents. It draws its own Rust/OpenGL interface and uses the television’s decoder, with documented host, simulator and real-device test tiers. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a Plex account/server and a compatible LG TV. The baseline is webOS 4.0+, with explicitly documented 3.4.3/3.9.3 exceptions; the latter needs a newer source build than prebuilt v0.8.0. - **Prerequisites:** Product builds need macOS (x86_64 or arm64) or arm64 Linux, the webOS NDK, the pinned Rust toolchain and CMake. The desktop simulator has a different host/setup path. - **Limits:** Developer Mode normally needs no root but requires renewal. Some k5lp/k3lp devices cannot play under its sandbox, and k6hp crashes remain unresolved. - **Scope:** The scope is movies and TV shows, excluding music, photos, live TV and DVR. Selected relay/encrypted-server paths lack end-to-end viewing tests; timing and playback results remain author/device-specific. - **License:** GPL-3.0-or-later for project code, with separate brand and third-party terms including bundled FFmpeg. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Windows Calculator: reconstructing percentage rules > REA’s case traces the installed Windows Calculator model DLL to explain different percentage behavior for multiplication/division and other operations. An analyst-selected function is interpreted against public Microsoft source and demonstrated with fixed browser examples. - Type: Case study - Targets: App · Binary - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The documented target is Calculator 11.2508.4.0 x64. The public source commit is an interpretation cross-check, not an identified build commit for that installed DLL. - **Attribution:** Function selection was analyst-assisted. - **License:** This reconstructs a bounded arithmetic rule, not the Calculator application. Public Microsoft source is MIT-licensed; access and rights to the installed target remain separate. ##### Primary sources 1. 2. #### Feishu: an author-reported isolated second app instance > The author reports using Codex and REA analysis to adapt a separate macOS Feishu copy with its own application identity, data directory and single-instance lock. The account describes local signing and separation checks while retaining the original app unchanged. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Catalog page: ##### Requirements & limits - **Scope:** The report targets Feishu 8.1.17 with REA 6.5.0 on the author’s Mac; reported elapsed times and isolation results. - **Scope:** The modified copy is locally signed and has automatic updates disabled. The article does not publish a redistributable replacement app or original-source reconstruction. - **Attribution:** The author attributes some architecture tracing directly to Codex and cites prior feishu-clone work. - **Limits:** Original hash/signature and process/data separation checks are author-reported. ##### Primary sources 1. #### PhotoCraft: editor workflow reconstruction and PSD round-trip boundaries > The authors describe this Rust image editor as a clean-room reimplementation of Photoshop-style workflows. Its document engine, UI and automation interfaces share editing commands, while the source distinguishes PSD editor round trips from byte preservation in the standalone file codec. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The pinned workspace identifies version 0.9.0 and declares Rust 1.95+ for source builds with Cargo. Native and WebAssembly paths have platform-specific dependencies; optional font inputs and reference documents are separate. - **Scope:** This is an implemented document/compositing engine and editing interface, not merely a screenshot mockup. - **Testing evidence:** The editor-level corpus tests compare rendering before and after export/reimport. Separate PSD codec tests compare bytes for parseable files, with a named malformed-file exception. Editor saves are explicitly not byte-identical to their inputs. - **Limits:** The project remains alpha and distinguishes menu-command coverage from behavioral fidelity. Its dated parity assessment retains gaps in PSD exchange, typography, professional workflows, performance and plug-in compatibility. - **License:** Project code is MIT OR Apache-2.0, subject to NOTICE; fonts, artwork and other assets retain separate terms. ArtCraft branding is excluded; published modified versions must remove it, apart from contribution-only forks. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### WordCraft: document workflow reconstruction and bounded DOCX compatibility > The authors describe WordCraft as a clean-room Rust implementation of familiar Microsoft Word workflows. It provides its own document model, layout engine and DOCX reader/writer, with desktop and browser interfaces; source tests exercise selected editing and file-preservation behavior. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The pinned workspace identifies version 0.7.0 and declares Rust 1.95+ with Cargo. The documented browser build uses Trunk; native builds and faithful layout require the relevant platform dependencies and fonts. - **Scope:** The outcome is a document-engine and interaction implementation. CLI/MCP and control-channel support are automation surfaces. - **Testing evidence:** The reviewed DOCX tests use constructed documents and specification-based XML fixtures to check modeled properties and passthrough parts. The dated assessment against Word for Mac 16.113.4 explicitly says real-world side-by-side file/page comparisons were not performed in that assessment pass. - **Limits:** The project is alpha. File fidelity, page layout, advanced typography, stability and ecosystem compatibility remain limited; ribbon-command counts and author readiness estimates are not acceptance-test pass rates. - **License:** Code is MIT OR Apache-2.0 with NOTICE obligations; fonts and other assets retain separate rights, and ArtCraft branding has separate restricted terms. Clean-room is the authors’ characterization. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### GridCraft: spreadsheet workflow reconstruction and XLSX round-trip limits > The authors describe GridCraft as a clean-room Rust implementation of Excel-style spreadsheet workflows. A workbook model, formula parser and dependency-driven recalculation are connected to XLSX I/O and a shared editing-command layer for desktop, browser and automation interfaces. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The pinned workspace identifies version 0.7.0 and declares Rust 1.90+ with Cargo. Browser builds use Trunk and wasm32-unknown-unknown; native Linux CI lists X11/Wayland, GTK, fontconfig/FreeType and graphics dependencies. Fonts and input workbooks are separate. - **Testing evidence:** Reviewed XLSX tests construct workbooks and OOXML packages, compare modeled values after writing and reading, and check selected unmodeled parts and relationships. - **Testing evidence:** Calculation tests use expected values for selected formulas, dependency changes and spilled arrays. The dated assessment against Excel for Mac 16.113.4 records the absence of Excel-computed conformance oracles. - **Limits:** The project remains alpha. File fidelity, advanced workflows, performance and ecosystem compatibility remain bounded, and the README documents graphics-driver startup issues. - **License:** Code is MIT OR Apache-2.0 with NOTICE obligations; optional fonts and ArtCraft branding have separate terms. Published modified versions must remove the ArtCraft marks, except contribution-only forks. Clean-room is the authors’ characterization. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### DeckCraft: presentation workflow reconstruction and bounded PPTX interchange > The authors describe DeckCraft as a clean-room Rust implementation of PowerPoint-style presentation workflows. Its slide model, rendering and command layers support desktop/browser editing and PPTX interchange; reviewed source tests check constructed decks and selected preserved package parts. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The pinned workspace identifies version 0.7.0 and declares Rust 1.95+ with Cargo. Linux source builds need ALSA headers and display/window dependencies; the browser path uses Trunk and wasm32-unknown-unknown. Optional craft-fonts inputs affect rendering, with system-font fallback documented. - **Testing evidence:** The reviewed PPTX corpus is authored in code, not collected from PowerPoint. Tests check retained text and content-part counts after saving, then part names and text after another save. Separate tests preserve selected XML metadata. - **Testing evidence:** The dated assessment against PowerPoint for Mac 16.113.4 explicitly says rendering fidelity, performance against PowerPoint and end-to-end workflows with real users’ decks were not measured in that assessment. Feature breadth and readiness percentages are checklist counts or author estimates. - **Limits:** The project is alpha and has documented file-exchange, presentation-workflow, stability and ecosystem gaps. Source snapshots and older assessment rows differ. - **License:** Code is MIT OR Apache-2.0 with NOTICE obligations. Fonts/icons retain separate terms, and NOTICE lists the Symphonia audio decoder under MPL-2.0. ArtCraft marks have restricted terms and must be removed from published modified versions except contribution-only forks. Clean-room remains author-attributed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Ledger Reborn: an independent accounting app informed by QuickBooks study > The maintainer reports using REA and Ghidra to study selected QuickBooks Desktop for Mac behavior, then independently implements a local accounting application. Its Python/SQLite engine persists double-entry journals, invoices, inventory and payments, while public synthetic fixtures test bounded accounting and rollback behavior. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The reviewed release is 2026.10.12-preview.1. The local browser edition needs Python 3.11+; the accounting core uses the standard library and SQLite. Native desktop builds use pywebview 6.2.1, PyInstaller 6.22.3 and Pillow 12.3.0, built on the target OS; Windows additionally needs the separately installed WebView2 runtime. - **Attribution:** The maintainer identifies QuickBooks Desktop for Mac 2024 Trial, version 23.1.13.962 R14 Trial, as the investigation target. REA 6.4.0 with Ghidra, NIB decoding and selected runtime observations informed inventory arithmetic, budget signs, reconciliation paths and layouts. The Python/SQLite engine and frontend are independently written, not recovered Intuit source. - **Testing evidence:** Public synthetic fixtures contain frozen, independently specified integer-cent expectations. Reviewed tests compare reports and check atomic rollback of invalid journals, bills and inventory operations. These are implementation checks. - **Testing evidence:** The separate original-software comparison reportedly matched three official-sample reports account-by-account to the cent. The vendor sample company and exports are not public here, so that result remains author-reported. - **Limits:** The preview is single-user, local and USD-only. Payroll, tax filing, live bank/payment services, multicurrency and complete QuickBooks migration are outside the implementation. Its cash-basis output is a defined management cash view. - **License:** MIT covers the authored application; vendor inputs and bundled runtime dependencies keep separate terms. The preview is not Developer ID-signed or notarized on macOS and lacks Windows publisher signing. Package smoke tests and selected native-window observations have separate scopes. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Pocket Tasks: reconstructing task state and persistence > A teaching case with disclosed prior source access carries a REA-assisted investigation of a small command-line app into a separate Node implementation. It preserves observed task editing, persistence and selection behavior, then compares scoped outputs against fixed expectations and captured reference sessions. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** Pocket Tasks 1.0.0 is an authored local command-line app, not a commercial app or native-binary benchmark. The Node.js 20+ candidate implements nine commands and schema-1 JSON storage with only the standard library and disposable local stores; there is no GUI or network backend. - **Attribution:** The REA excerpt identifies the target bytes but keeps semantic coverage unknown, with 230 semantic unknowns; it is not a canonical Evidence bundle, and the later Node validator does not repeat the REA session. - **Attribution:** The author saw the target source, scenarios, tests and prior answers before implementing. - **Testing evidence:** Reported 16/16 checker sessions (12 scenarios) and 10/10 replays (seven scenarios) overlap; expectations are hand-authored, and the report keeps humanReview=pending, reaTrial=unverified and independentEvaluation=false. - **Testing evidence:** Six recorded hashes and the oracle digest match the reviewed source, but the TASK.md packet hash matches an earlier wording-only revision, so the packet is historical evidence. A restricted-Windows attempt (five passes, four failures) preceded nine passes with unchanged code. - **Limits:** Limits: 64 commands and 65,536 UTF-8 bytes per invocation, 32 tasks and 80 UTF-16 code units per title. Concurrent writers, crash durability, filesystem races, UI, hidden backends and production performance are outside the parity claim. MIT covers the authored example only. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### Open Scrantic: reconstructing the Johnny Castaway screensaver engine > Reconstructs the Johnny Castaway screensaver engine in Rust, with author-disclosed REA and Claude Code use. It reads original files to run recovered animation scripts and calendar-based story state on modern desktops; documented deviations and limited tests stop short of complete behavioral equivalence. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Builds pin Rust 1.99.1; Cargo declares minimum Rust 1.99 and edition 2024. The project targets Windows, macOS and Linux using winit, softbuffer and rodio. Linux builds also require ALSA development headers and pkg-config. - **Prerequisites:** Runtime requires separately obtained SCRANTIC.SCR, RESOURCE.MAP and RESOURCE.001 beside the executable. README sizes and SHA-256 values identify the expected original files; the loader instead checks known executable strings/layout, not whole-file hashes. Arbitrary original builds are unsupported. Options and story state use SCRANTIC.INI, saved on normal exit. - **Scope:** Reviewed at v0.3.0: this is a Windows 3.1 screensaver-engine reconstruction, not a game port. The author reports recovering formats and TTM/ADS script semantics from disassembly, with human-directed REA/Claude Code work and comparisons against the original. - **Limits:** Deliberate differences include full-frame redraw, potentially one-pixel line/ellipse differences, bounded final-scene selection and a fixed two-second title display. Optional dedithering and softened audio default off. The original settings dialog and password feature are absent, as are unused animated-palette, 256-color and ADS-variable features. - **Testing evidence:** The headless test runs 6,000 steps and requires three completed scenes, without original-frame comparison. Data-dependent tests silently return when OPEN_SCRANTIC_DATA is unset; other tests cover parsing and arithmetic. CI checks formatting, lint, three-platform builds and --version, not cargo test or original-data playback. Snapshot output supports inspection, not an automated original-output oracle. - **License:** MIT covers project source, not original executable content, art, scripts or sounds, which users must supply with appropriate authorization. The author describes independent, non-commercial interoperability without Sierra/Dynamix endorsement. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### Screen Studio: an author-reported REA study of auto-zoom rules > The author reports using REA to map Screen Studio’s Electron package, reading six auto-zoom and cursor rules from its obfuscated code with Claude Code’s help, and having Claude Code write an independent recorder and renderer from those rules. The article describes the commands, evidence, a cursor-alignment check and the clone’s gaps; neither the clone nor the decoded code is published. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Catalog page: ##### Requirements & limits - **Scope:** The 2026-10-13 article targets the macOS Screen Studio app’s app.asar with REA’s JavaScript application analyzer, run from the command line on the author’s Mac with a supported Node.js version and Xcode Command Line Tools; it names neither the REA nor the Screen Studio version. The author reports a 101-second run producing a 124 MB evidence file over 3,695 files, using an integrity policy that records, rather than stops on, 25 bundled native programs whose fingerprints no longer matched. - **Attribution:** The relevant code was obfuscated. The author says REA’s source-recovery command was unavailable on macOS, so Claude Code wrote a separate script to make it readable; that step is the agent’s work, not REA output. The decoded code is deliberately unpublished. - **Testing evidence:** From the six rules, Claude Code reportedly wrote about 1,300 lines from scratch: a Swift ScreenCaptureKit recorder that logs cursor positions separately, and a Remotion renderer. The author reports 60 fps capture without dropped frames and a 22-second clip rendered in about 50 seconds on an M4 Pro, and says a redrawn cursor overlaid on a recording of the system cursor matched in most frames, with one fast-motion frame off by a few pixels. - **Limits:** The author lists gaps: no graphical editor, three cursor types, simplified motion blur, no typing zoom or click sounds, and camera and microphone code that has not been tested with a real camera; the clone is far from replacing Screen Studio. Its source is unpublished. - **License:** The author says the clone uses no Screen Studio code or assets and advises reading a product’s user agreement first. ##### Primary sources 1. 2. #### Claude Code background lab: an REA-informed reimplementation of a desktop animation > Reimplements the glyph-wind background of the Claude desktop app’s Claude Code New session view as an offline WebGL2 page with a 38-slider control panel. The author reports a static REA investigation of the desktop shell and its remote web bundle, followed by a newly written renderer that reuses recovered timing and layout values. It shares the original’s visual vocabulary and interaction model but is not a pixel-identical extraction. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Running it needs only a WebGL2 browser opening index.html, or a local static server where the browser restricts local files; there is no Canvas2D fallback, and system monospace fonts change glyph metrics. Development needs Python 3 and Node.js 18+, with no third-party runtime or build dependencies. - **Scope:** The reviewed pin is the repository’s single public commit, dated 16 October 2026. PROVENANCE.md reports that the study targeted Claude desktop 2.37337.1, began with REA’s analyze_javascript_application, traced the shell’s remote page to the background module and stayed static: Claude was not launched or inspected at runtime. It records SHA-256 hashes of the retained ASAR and the decoded module and lists local REA evidence IDs whose archives are not published. - **Scope:** The public edition reuses recovered factual parameters, including 6.5 × 13 CSS-pixel cells, a nominal 9 px font, a 3 s entrance delay and fade-in, a 4 s wind reveal, a 500 ms focus fade-out and 42–64 px/s wind speeds. Its shaders, noise field, random generator, glyph sequences and single-pass instanced rendering are newly written. The author states that an earlier private prototype used extracted source and a bundled font. - **Testing evidence:** CI runs six Node tests of deterministic helpers, rebuilds the offline page, checks that it is current and runs a release check for offline output, syntax, local links and excluded extracted assets and local paths. VALIDATION.md reports manual Chrome-on-macOS checks of rendering and controls, but not a browser-verified settings import, runtime testing of Claude or a pixel comparison with the original. The reference recording’s remote build, seed, theme and font are unknown. - **License:** MIT covers the original code and documentation. The repository states that it distributes no recovered Anthropic source, shaders, fonts, ASAR files, screenshots of the original, recordings or account data, and that its license grants no rights in Anthropic’s software, fonts or trademarks. It is unofficial and unaffiliated with Anthropic; REA is credited as the investigation tool rather than bundled, and the author also credits AI-assisted development. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Notes CSV export: an author-reported REA check of reconstruction oracles > A Chinese article breaks three versions of a Python CSV exporter that reproduces the Notes teaching app shipped with REA. It shows that a simple export-and-read-back test passes all three, while byte comparisons against the official JavaScript formatter on 215 fixed inputs catch each one. The author also connects REA 6.5.0 over MCP, reruns its JavaScript analysis and checks that an edited evidence record is rejected on import; this is a study of acceptance checks, not a new reconstruction. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-27 - Original resource: - Catalog page: ##### Requirements & limits - The 2026-10-16 article by @superfang119 follows the author’s earlier walkthrough, in which a Python reimplementation of the Notes app’s CSV export reportedly matched the original byte for byte on 215 inputs. It used Windows, Node 22.19.0 and rea-agents 6.5.0 through a temporary stdio client that listed 207 tools; the JavaScript analysis returned 6 files, 32 nodes and 45 edges. The author notes that this static graph locates the export path. - The frozen byte contract quotes every title, doubles inner quotes and ends lines and the file with LF, for safe-integer ids and string titles. Each mutant changes one rule: quoting only when needed, leaving inner quotes unescaped, or dropping the final LF. A one-note read-back test passed all three. Against references from running the official JavaScript formatter on 15 fixed edge cases and 200 seeded inputs, the baseline matched 215/215 and the mutants differed on 26, 166 and 215 inputs. - Changing one evidence field from 6 to 999 while keeping its evidence_id made the same REA server reject the import with evidence_integrity_mismatch and leave session evidence unchanged; the author adds that this detects tampering but cannot show an interpretation is correct. The article also cites, without rerunning it, a TH08 project fix in which a comparator missed a 128.0 constant written as 0.0. - Analysis and implementation ran in the same Codex context, so the author states this is not clean-room separation, and the handoff prompts offered are proposals rather than a tested protocol. Scripts, mutants and outputs are not published; the three probes do not cover permissions, write failures, concurrency or the full interface. The target is REA’s own teaching sample, not a third-party product. ##### Primary sources 1. 2. #### Sofa TV Browser: a remote-friendly BrowseHere alternative > An Android TV browser follows BrowseHere's remote-control interaction design with its own implementation. The author reports using REA to inspect the BrowseHere APK and Claude to build Sofa; the repository documents APK releases, screenshots and current feature limits. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Android 7.0+ with Android System WebView; APKs are linked from GitHub releases. Source builds need the documented JDK/Android SDK or Nix environment. - **Attribution:** The author's REA attribution is in the linked Reddit report, rather than a published REA evidence bundle; this is an author-reported mixed workflow. - **Limits:** Tabs, reader mode, phone typing, translations and user scripts are listed as missing or planned. DRM playback and frame-rate switching depend on the TV and WebView. - **License:** GPL-3.0-only; the README states that BrowseHere code, assets and text are not included. Third-party components retain their own notices. ##### Primary sources 1. 2. 3. #### FastView-REA: a Rust reconstruction of Fast View 5 > A Rust desktop reconstruction of Mekhanotronika Fast View 5 uses REA and Ghidra research to reproduce oscillogram analysis and relay-characteristic views. The project publishes behavioral specifications, factual indexes, screenshots and cross-platform builds, with explicit format and visual-fidelity gaps. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Source builds need the documented Rust toolchain; release archives target Linux, Windows and macOS. Linux needs GTK 3 and a Wayland or X11 session. - **Testing evidence:** The README attributes the reverse engineering to REA and Ghidra 12.1.3. Its behavioral-identity and validation statements are author-reported. - **Limits:** Native .sto input lacks a supplied sample, and the egui interface is not pixel-identical to original GDI/MFC rendering; original bitmaps are replaced. - **License:** Reconstruction code offers MIT or Apache-2.0. Embedded fonts and Intel-derived trigonometry keep separate licenses; the bundled FastView.fvb characteristic data remains original-vendor data. ##### Primary sources 1. 2. #### DiskLens: a WinDirStat-derived disk usage analyzer > A Rust/Tauri disk analyzer combines REA/Ghidra investigation of WinDirStat 2.5.0 with source-code ports of its treemap and color handling. Its documentation distinguishes binary-confirmed findings from source-derived algorithms and leaves several file actions and Windows integrations untested. - Type: Case study - Targets: App · Binary - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires Windows 10/11, Rust MSVC/Visual Studio build tools and Node.js for source builds; Mica styling needs Windows 11. - **Attribution:** REA/Ghidra cross-checked the installed WinDirStat binary, while much algorithm work used its public source. - **Testing evidence:** The author reports engine tests and drive scans, but new file-action routes, cleanup integrations and several dialogs are untested in the app. Fast MFT scanning is absent and hard links are counted repeatedly. - **License:** README states GPL-3.0-or-later for DiskLens and credits GPL-2.0-or-later WinDirStat code ports; third-party components keep separate licenses. ##### Primary sources 1. 2. #### SoundConnect Desktop: a Windows client reusing a reviewed headset engine > A Windows Sony-headphone client adopts existing libmdr/libmdr-bt engine DLLs after a documented REA-assisted binary inventory and source review. The desktop interface is modeled on Sound Connect, while protocol implementation and device support are inherited rather than newly reconstructed. - Type: Case study - Targets: App · Binary - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires Windows 10/11 and compatible Bluetooth headphones. Source builds need Node 24, pnpm 10, Rust MSVC and pinned engine DLLs or their Visual Studio/CMake build environment. - **Attribution:** REA inspected upstream PE resources, strings and provenance before engine adoption. - **Limits:** Only WH-1000XM4 hardware is reported tested; other models rely on upstream support. Concurrent phone-app control, XM4 paired-device mutations and 360 Reality Audio setup are unsupported; the installer is unsigned. - **License:** MIT covers the app and credited engine; Sony identification images retain Sony rights. ##### Primary sources 1. 2. #### rec-rs: an OBS-informed Rust recorder for macOS > A macOS recorder is informed by OBS architecture research using REA package inspection, platform tools and public source references. It offers screen/camera recording and streaming with a deliberately smaller scene/source feature set; the research notes record unavailable native-analysis providers. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Universal releases target macOS 15+; building needs the documented Rust/macOS toolchain. Screen, microphone and camera capture depend on the relevant system permissions. - **Attribution:** REA 6.4.0 plist/signature inspection succeeded, but native analyze/layout operations failed or were unavailable; notes also studied OBS source and used separate macOS inspection tools. - **Limits:** No free scene-layout editor, transitions, application/multi-display capture or audio filters; output is 8-bit SDR and the webcam overlay is baked in. Region capture is CLI-only. - **Testing evidence:** The README supplies self-test/soak tooling; YouTube HEVC streaming was checked only against a local server. - **License:** Code is documented as MIT OR Apache-2.0; the author states that original OBS code/assets are not included. ##### Primary sources 1. 2. 3. #### Sketch: a Paper-shell-informed native Rust canvas > A Rust canvas models Paper-like editing behavior after REA investigation of the Paper Desktop shell. The hosted editor was not recovered: research separates observed shell integration from inferred editor features, and the new geometric document model differs from Paper HTML/CSS. - Type: Case study - Targets: App - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires Rust 1.95+ for source builds; macOS releases target 11+, Linux uses the documented graphics libraries and XDG portal for file dialogs. - **Attribution:** Research targeted licensed Paper Desktop 0.5.15. The hosted editor was absent from the bundle; several editor-level capabilities were inferred from shell integration or the implementation brief. - **Limits:** No HTML/CSS document model, CSS/code export, rotation or complex-script shaping; several blend, clipping and SVG-import behaviors are approximations. - **Testing evidence:** Linux window tests used Xvfb; macOS smoke evidence is narrower than complete input/menu/Intel testing. - **License:** Code is MIT OR Apache-2.0; Inter fonts retain SIL OFL 1.1 and bundled agent skills have separate notices. ##### Primary sources 1. 2. 3. #### JADX-AI-MCP > JADX plugin paired with a Python MCP server to inspect decompiled Android classes, resources, cross-references and debugger context. - Type: Integration - Targets: App - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - JADX with the plugin and the separate JADX MCP Server component; upstream lists Java 11+ and Python 3.10+. ##### Primary sources 1. #### apktool-mcp-server > Python MCP server that drives a local Apktool install so agents can decode APKs; list, read, search and edit smali and resource files; read AndroidManifest.xml and apktool.yml; and rebuild the project. - Type: Integration - Targets: App - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Apktool must be installed and available on PATH. Reviewed release: V3.0.2, published 2026-07-02 and identical to the default branch at review. Run it with uv; the README and script header state Python 3.10+, while pyproject.toml declares >=3.13. Apache-2.0. - MCP is served over stdio by default, or over streamable HTTP on port 8652 with --http. The README lists 13 tools; the reviewed script also registers health_check, analyze_project_structure and get_workspace_info. Project paths must stay inside the workspace directory (apktool_mcp_server_workspace by default). - modify_smali_file, modify_resource_file, clean_project and build_apk change the decoded project, so work on copies; the modify tools keep timestamped backups by default. ##### Primary sources 1. 2. 3. 4. 5. #### frida-mcp (yfe404) > Frida MCP server with persistent instrumentation sessions, runtime inspection and Android static-to-dynamic navigation. - Type: Integration - Targets: App · Game - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Node.js 20+, Frida 17 and an accessible target; on-device operations require the documented device/frida-server setup. - The README’s License heading names MIT, but the pinned commit has no LICENSE file and package.json has no license field; the declaration appears only in the README. ##### Primary sources 1. 2. 3. #### Super Trouper > Single-binary Frida MCP server for discovering devices, managing process sessions and loading instrumentation scripts. - Type: Integration - Targets: App · Game - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Published host binaries target macOS/Linux; target connectivity must support Frida. Source builds need Go, CGO and a matching Frida Core DevKit. ##### Primary sources 1. #### Frida > Dynamic instrumentation toolkit for observing and scripting the behavior of live native and managed processes. - Type: Tool - Targets: App · Game - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Host bindings or CLI tools and a supported target setup; mobile/server/Gadget and signing requirements vary by platform. ##### Primary sources 1. #### JADX > Dex-to-Java decompiler with CLI/GUI navigation, resource decoding and cross-reference search for Android packages. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - 64-bit Java 11+ unless using a bundled runtime; decompilation can be incomplete and should be checked against bytecode. ##### Primary sources 1. #### Apktool > Decodes Android resources and smali into a project-like tree and can rebuild modified packages. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A supported Java runtime and the release-specific launcher; rebuilding is distinct from recovering original Java source. ##### Primary sources 1. #### Androguard > Python toolkit for APK/DEX metadata, bytecode and reference analysis; the v5 source branch also documents agent skills and MCP. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Version-sensitive: the reviewed README distinguishes the v5 source tree from PyPI 4.1.4; v5 extras require additional Rust/Python components. ##### Primary sources 1. #### ILSpy > .NET assembly browser and C# decompiler with whole-project export, metadata inspection and a scriptable command-line frontend. - Type: Tool - Targets: App - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Choose a desktop or ILSpyCmd release and its matching .NET runtime; frontend and operating-system support are release-dependent. ##### Primary sources 1. #### dnSpyEx > Community continuation of dnSpy for debugging and editing .NET assemblies without the original source. - Type: Tool - Targets: App - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows desktop workflow; Unity debugging requires the companion runtime setup documented by the project. ##### Primary sources 1. #### @electron/asar > Electron's archive tool lists and extracts ASAR contents so packaged JavaScript and application assets can be inspected. - Type: Tool - Targets: App · Website - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed release requires Node.js 22.12+. ##### Primary sources 1. #### Mobile Security Framework (MobSF) > Inspect mobile application packages with static analysis and supported-device dynamic testing, including runtime behavior and network traffic, through a web interface and APIs. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The documented container setup recommends Docker 20.10+; dynamic analysis additionally needs a supported device or emulator accessible from the container. - Android dynamic analysis is documented for rooted Android 4.1–11, up to API 30; Android 12+ is not supported by that workflow. - iOS dynamic analysis uses Corellium or a jailbroken device; the physical-device route is marked beta. ##### Primary sources 1. 2. #### objection > Explore running Android and iOS apps with a Frida-backed command interface for inspecting app storage, memory, runtime objects, and instrumented behavior. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Current package metadata requires Python 3.11+ and Frida 16+; this supersedes the older Python minimum still shown in the installation wiki. - The target must support the documented Frida attachment or patched-app workflow. Android patching requires Android build tools and Apktool 2.9.0+; iOS patching requires the documented Xcode and signing tools. ##### Primary sources 1. #### Grapefruit > Inspect and hook running iOS and Android apps from a Frida-based web interface, with method and crypto-API hooks, filesystem and SQLite browsers, iOS keychain and UI-hierarchy views, and HTTP capture from common networking libraries. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a Frida server running on the target device, set up through Frida's iOS or Android guides; the reviewed release works with Frida 16 or 17 (default 17). - Reviewed release: v1.1.2 (npm package igf), published 2026-03-30. The npm package requires Node.js >=22.18.0 and is not compatible with bunx; prebuilt binaries cover macOS arm64/x64, Linux x64 and Windows x64. The server binds to localhost port 31337 by default; the default-branch README warns that it has no built-in authentication. - Optional AI features, including hook-script generation, use an LLM configured through LLM_* environment variables: Anthropic, OpenAI, Gemini, OpenRouter or an OpenAI-compatible endpoint such as local Ollama. Prompts are sent to the configured endpoint. - Upstream deliberately ships no Frida-detection, certificate-pinning or jailbreak/root-detection bypasses and suggests combining it with dedicated bypass tooling for authorized assessments. The default branch was 47 commits ahead of v1.1.2 and adds Dart AOT snapshot exploration that the release README does not list. MIT-licensed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Blutter > Analyze Flutter Android ARM64 AOT binaries using the matching Dart runtime. Produces annotated assembly, object-pool dumps and a target-specific Frida script template for investigating compiled Dart application logic. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Provide extracted Android ARM64 libraries, including libapp.so and the Flutter engine; only recent Dart versions are supported. Direct APK/IPA input and iOS binary reading remain TODOs. - Requires Python 3 and a C++20-capable toolchain such as GCC 13+ or Clang 16+, with the documented native dependencies. The wrapper may download and compile matching Dart sources. - Linux is recommended; Windows and macOS setup is documented. MIT-licensed. Obfuscated applications can still have missing functions, and this is not a complete Dart source decompiler. ##### Primary sources 1. 2. #### hermes-dec > Parse, disassemble and partially decompile React Native Hermes bytecode bundles. Makes HBC headers and instructions inspectable and emits pseudocode for understanding compiled application logic. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Current package metadata requires Python 3.10+; the application uses the Python standard library. Supply an extracted Hermes HBC bundle, not a plain-text minified JavaScript bundle. - Decompiler output is not executable JavaScript: loop and conditional structure reconstruction is incomplete. Bytecode compatibility depends on the supported opcode definitions. - The tool is AGPL-3.0-or-later, distinct from the Hermes VM's license. ##### Primary sources 1. 2. 3. 4. 5. #### Recaf > Inspect and modify compiled JVM applications with integrated decompilers, bytecode assembly, reference search, mappings and deobfuscation tools. The reviewed 4.0 preview also provides basic read-only Android bytecode inspection. - Type: Tool - Targets: App · Binary - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires JDK 22+ and JavaFX 22+; the recommended launcher downloads compatible JavaFX artifacts. Select a build matching the operating system and CPU. - The 4.0.0-alpha GitHub release is explicitly a preview despite being listed as a regular release. Its Android support is read-only; do not assume JVM editing features apply to Android. - MIT-licensed. Provide compiled application inputs; recovered decompiled text is an analysis view, not guaranteed original source. ##### Primary sources 1. 2. 3. 4. 5. #### nibkit > Decode compiled iOS/macOS interface archives into object trees, Outlet/Action connections, custom classes and navigation relationships. Exports JSON or Mermaid diagrams and exposes read-only inspection commands through MCP. - Type: Tool - Targets: App - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supply supported .nib/.storyboardc files, an .app/directory, or an .ipa for automatic extraction. The reviewed README lists NIBArchive coder versions 9, 10 and 11 plus older binary-plist/NSKeyedArchive formats. - Source builds require Go 1.22 or later according to go.mod. The README states a standard-library-only implementation and advertises darwin/linux arm64/amd64 prebuilt binaries with no runtime dependencies; a Windows release was not verified. - Recovery concerns compiled interface structure and wiring. Format documentation is based on reverse-engineered observations. MIT-licensed. ##### Primary sources 1. 2. 3. 4. #### AOTopsy > Statically inspect Flutter/Dart AOT libapp.so files to recover available metadata, class structures, call edges and pseudocode without embedding a Dart VM or compiling a matching SDK. Supports ARM64 and x86_64 analysis paths. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Source builds require Go 1.25.4 according to go.mod (README says 1.25+). Supply a supported libapp.so AOT snapshot; the reviewed README models Dart 2.10–3.13. JIT snapshots are outside scope. - Ghidra/IDA integration is ARM64-only. Most instance-field names and local/captured variable names are removed from release builds; polymorphic dispatch and virtual-call reachability remain limited. Reconstructed Dart output is not guaranteed original or behaviorally equivalent source. - Unbounded --all decompilation can need about 64 GB RAM; use targeted or capped analysis. Accuracy and syntax measurements are author-reported, and the nonredistributable ground-truth corpus tests do not run in public CI. - BSD-3-Clause. AOTopsy credits the original unflutter project and its authors; Dart SDK-derived tables retain their own notices. ##### Primary sources 1. 2. 3. 4. #### hbctool > Disassemble and reassemble supported React Native Hermes bytecode bundles through HASM files, enabling bytecode inspection and editing for the explicitly supported legacy HBC versions. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed package metadata is 0.1.5 and classified Alpha; it declares Python ^3.6 and docopt ^0.6.2. As checked on 2026-10-20, v0.1.5 is the latest tag and PyPI release (uploaded 2021-09-17) and there are no GitHub releases; the reviewed 2023-04-10 commit is still the main head, GitHub’s last recorded push was 2023-12-10, the repository is not archived and the README does not mark it as maintained, superseded or archived. - README support is limited to HBC versions 59, 62, 74 and 76. Supply a compatible Hermes bytecode bundle. - This is a bytecode assembler/disassembler, not complete original-JavaScript recovery. Overflow patching is listed as future work. MIT-licensed. ##### Primary sources 1. 2. 3. 4. #### LSX II Volume Fixer: reconstructing volume behavior > Uses measured USB-volume behavior and a macOS audio proxy to map volume keys to a KEF LSX II’s LAN control. The project reports more even steps while forwarding USB audio; the speaker firmware is unchanged. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an LSX II connected by USB and on the same LAN, macOS 14+, Xcode Command Line Tools and administrator installation. The author reports testing on macOS 27; only LSX II is tested. - **Prerequisites:** Builds from source with ad-hoc signing; Windows support is only proposed. MIT source is available. - **Testing evidence:** The volume curve, latency and audio claims are author-reported. ##### Primary sources 1. 2. 3. #### UU Remote on Linux: an unofficial protocol implementation > Implements an unofficial native Linux host for NetEase UU Remote, using protocol behavior the maintainer says was recovered from official-client traffic and shipped programs. The Rust implementation connects selected desktop, input and auxiliary-tool channels to Linux services; an additional Linux viewer remains experimental. The author attributes development to Claude and Codex, without establishing REA use. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The host needs Linux, stable Rust, a C toolchain, pkg-config, X11 development libraries and FFmpeg. GTK3 supports graphical login; the optional viewer also needs SDL2. Wayland/portal builds require additional libraries and authorized desktop access. Dependencies vary by feature. - **Prerequisites:** UU cloud services remain required; the host and experimental viewer interoperate with supported official clients and hosts. Account connections use the user’s own authorized account; experimental remote assistance requires an explicitly enabled host and recipient-provided connection details. The project is unaffiliated with NetEase. - **Scope:** Reviewed version 0.2.8 implements selected protocol formats and session behavior in native Rust with small C components, without Wine or bundled NetEase binaries. The additional Linux viewer is experimental. Cargo.toml declares GPL-3.0-or-later; dependencies and official clients/services retain separate terms. This is not recovered vendor source or a replacement cloud backend. - **Testing evidence:** Public parsing and initialization code has synthetic checks for malformed inputs, capability replies and echo correlation. Local/virtual WebRTC peers test pending-desktop responses, independent tool connections and session isolation. These are implementation checks. - **Testing evidence:** The README reports real-machine GNOME/X11 use and selected GNOME Wayland checks; other desktop coverage is largely virtual-machine based. Its viewer acceptance matrix is explicitly partial, with different official-host coverage for clipboard, audio, codecs and keyboards. These remain author-reported observations. - **Limits:** Wayland remains experimental, with single-screen and resolution/recovery limits. Multi-monitor switching is under development; HDR, privacy-screen mode, microphone forwarding and the Linux pre-login screen are unsupported. Restrictive-network relay behavior is not thoroughly tested. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### TCLimate: reconstructing selected TCL Home cloud controls > Implements selected TCL Home air-conditioner controls and electricity reporting in a native macOS menu-bar app. It adapts earlier community protocol work and documents an Android-module investigation to recover a separate statistics request. Reported validation checks cloud state, not independent physical operation or complete device equivalence. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Reviewed v0.1.6 beta requires macOS 14+, internet access and a TCL account with already-paired ACs. Building needs Swift 6.0+, Xcode Command Line Tools and a persistent signing certificate for the packaged app. Pairing still uses TCL Home; local LAN control and direct Google sign-in are absent. - **Attribution:** The protocol implementation credits nemesa’s MIT-licensed Home Assistant integration. The electricity API was reportedly identified through Android Flutter-module inspection and a successful request capture; original packages, captures and detailed investigation logs are not included in the repository. - **Scope:** Source guards commands using reported model/state fields, restricts target temperature to whole degrees from 16–30°C, and checks reported state after sending. Unsuccessful confirmation is marked. Extra controls depend on available fields and modes. - **Testing evidence:** Author validation covers a Pakistan account and two Split AC-1 units: authentication, discovery, reported state, power, temperature and daily electricity. Modes, fan, airflow and other optional controls lack physical validation; other regions/models remain unverified. - **Scope:** Energy parsing preserves genuine zeros, excludes invalid readings and leaves missing days as gaps; a seven-day total requires all seven readings. No persistent energy history or cost estimate is implemented. Offline tests are reported but absent from the reviewed tree/package targets. - **License:** MIT covers project code, with attribution retained for the earlier integration. Official services and third-party material retain separate terms. This is an unofficial cloud-dependent client, not recovered TCL source or firmware; APIs may change independently of the app. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Browserbase plugin: re-hosting Claude in Chrome’s browser bridge > Stands in for the Claude in Chrome extension side of Claude Code’s local browser bridge and runs the requested actions in Browserbase cloud browsers. The author’s thread describes the reverse-engineered framing, a 4-byte little-endian length before each JSON tool call, and the plugin maps 17 named tools onto Stagehand/CDP operations. It is an archived interoperability shim with several placeholder tools, not recovered Anthropic code or a verified equivalent of the extension. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires Claude Code with plugin support, the Claude in Chrome extension, Node.js 18+, the Browserbase SDK and Stagehand npm packages, and a Browserbase API key and project ID. As written, the start hook looks for the extension only under the macOS Chrome profile directory and stops when it is missing, so other hosts fail that check. - **Scope:** The reviewed main branch is archived, and its commits are dated 2025-12-27. A SessionStart hook launches a Node forwarding server that moves any existing claude-mcp-browser-bridge- socket in the temporary directory aside and listens in its place. Messages carry a 4-byte little-endian length plus JSON; only the execute_tool method is accepted, with 17 named tool handlers and errors for anything else. - **Limits:** Navigation, input, screenshots, page reading, form filling and JavaScript run through Stagehand on cloud sessions; console and network reads rely on the plugin’s own listeners and page-injected tracking. update_plan only echoes the submitted plan, shortcuts return an empty list or a placeholder, and image upload and GIF export are placeholders. The author’s thread counts 19 extension tools; the reviewed dispatcher names 17. - **Testing evidence:** The protocol account comes from the author’s X thread, not Anthropic documentation, and no captures or comparisons against the real extension are published. package.json declares Node test scripts, but the reviewed tree has no tests directory. The undocumented local interface may change with Claude Code or extension updates. - **License:** README states MIT, but the reviewed tree has no LICENSE file and GitHub detects no license. Claude Code, the Claude in Chrome extension and Browserbase services keep their own terms, and browsed pages are processed on Browserbase infrastructure. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Visor: an independent Ray-Ban Meta glasses client > Implements an Android replacement for the Meta AI companion app that speaks the Ray-Ban Meta glasses’ own Bluetooth and Wi-Fi Direct protocol, imports media, exposes settings and answers “Hey Meta” with a model the user chooses. The project wiki documents the link layers, encryption, services and Meta-side ownership steps, and lists 153 open questions. Testing is on real glasses rather than test suites, so behavior beyond the stated model and firmware remains unverified. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Reviewed just after release v1.3.1 (2026-10-18). README targets Ray-Ban Meta (Gen 2) tested on firmware 72387580077200100; other Meta glasses are untested. It needs an Android 10+ phone, a Meta account using password or email-code login (passkeys do not work) and, for the assistant, an Anthropic or OpenAI-compatible API key. The glasses accept one session at a time, so Visor and the Meta AI app displace each other. - **Prerequisites:** Setup makes Visor the glasses’ owner app through Meta’s login and ownership-receipt services, so it still depends on a Meta account and Meta servers for setup, frame style and language packs. Source builds need three client tokens from the official Meta AI app, which the repository does not include; without them the app builds but login and ownership fail. Release builds read them from CI secrets. - **Prerequisites:** Building needs JDK 21 and the Android SDK with platform 37. CI builds a debug APK with Gradle, and tagged releases publish a signed APK with a SHA-256 file; README lists the release certificate fingerprint. Modules separate wire format and ciphers, transport, session, identity, media, settings and the assistant, which stands in for Meta’s server with Claude or an OpenAI-compatible model. - **Testing evidence:** There are no test suites: CONTRIBUTING asks for hardware trials and wire.log excerpts for protocol changes, and CLAUDE.md says the app works on real glasses as of 2026-10-05. The wiki marks unconfirmed facts and lists open questions, including unread payloads and model-specific values; CLAUDE.md also refers to a desktop Python client snapshot that the repository does not contain. - **License:** Visor is AGPL-3.0 and states it is unaffiliated with Meta or EssilorLuxottica; Meta’s services, app tokens, firmware and trademarks keep their own terms. CONTRIBUTING forbids getting unsigned software past the glasses’ signature checks. Claude is one selectable assistant backend, and the repository’s CLAUDE.md is a contributor guide. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### wine-uwp: running packaged Windows Store apps on a patched Wine > Extends Wine 11.17 so that signed MSIX Store apps, with Shapr3D as the main target, install and run on Linux without their source or symbols. About 49,000 changed lines add a DirectComposition implementation, composition swap chains and an app-model host, while Microsoft’s own XAML and app-model DLLs, harvested from a Windows 11 image on the user’s machine, run unmodified. The author says Claude did most of the reverse engineering and code; app support is uneven and checked by a project regression suite. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs the user’s own app package (.msix or .msixbundle, or Shapr3D’s .appinstaller, from which setup downloads about 1.8 GB) and Windows components extracted from Microsoft’s free Windows 11 evaluation ISO or another Windows 11 image. Neither the repositories nor the release packages contain them, and a commit hook refuses Windows binaries. Shapr3D also needs an account and a browser sign-in. - **Prerequisites:** Building copies the vendored wine/ files over the Wine 11.17 source, then runs autoreconf, configure with --enable-archs=x86_64 and make; the WinRT stand-in shims build with clang-cl and lld-link against Windows SDK headers fetched by xwin. Shapr3D for Linux needs 64-bit Linux with glibc 2.38+, working Vulkan drivers and about 11 GB free during setup, and its releases build with flatpak-builder on the freedesktop 25.08 SDK. - **Testing evidence:** README’s app table reports Shapr3D sketching, modelling, menus, cloud sync, sign-in and STL/PDF export; Solitaire playable; Media Player playing audio from its own UI; Calculator fully working; Feedback Hub interactive; and Camera only reaching its own error page. Shapr3D for Linux (58d9173) packages this same pinned wine-uwp commit as a beta AppImage and Flatpak; it is unofficial and not affiliated with Shapr3D. - **Testing evidence:** regress.sh requires Calculator to stay pixel-identical to a committed baseline and other apps to come up on a private Xvfb display; release.sh smoke-tests that an empty setup reaches Shapr3D’s first screen. The Findings logs record failed approaches as well as fixes. These checks are project-reported. - **License:** Neither repository has a top-level license file, and GitHub detects none. The vendored Wine files carry LGPL-2.1-or-later headers and the setup app’s Cargo manifest declares the same; the shims and investigation tools state no license. Harvested Microsoft components and Store apps keep their own terms, and the plan notes that a distributable product would need clean-room replacements for them. The author’s X posts disclose heavy Claude assistance. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### RKD Telemetry Extractor: decoding Race-Keeper track-day recordings > Documents the proprietary .rkd telemetry format written by Race-Keeper “Instant Video” recorders, whose bundled player runs only on Windows, and implements matching Python and Go parsers that export GPS and IMU channels as Telemetry Overlay CSV and GPX. The author credits Claude Code with the hex-dump analysis and hypothesis testing, anchored by known car IDs, circuit location and speeds. Field meanings rest on physical cross-checks from the author’s own recordings, and several record types remain partly unknown. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Users supply .rkd files from their own Race-Keeper recordings. The repository includes a truncated sample of about 50 GPS fixes from the author’s 2021 session with reference CSV and GPX output, but not the vendor player, the USB-stick contents or full recordings. Python 3.9+ and the Go toolchain use only standard libraries; README says Go 1.21+, while go.mod declares go 1.24.7. - **Scope:** The reviewed pin is Python package version 1.0.0 from February 2026. It decodes the 8-byte signature, meta header, 10-byte record headers and the configuration, GPS, accelerometer, gyroscope, periodic, timestamp and terminator records, then exports 30 Hz Telemetry Overlay CSV, roughly 5 Hz GPX and a session summary. It reads telemetry only; the .mp4 video is used as is, and OBD-II channels are unsupported because the source recordings had no scanner connected. - **Attribution:** Research notes and a session log attribute the analysis to Claude Code (claude-opus-4-6) across three February 2026 sessions plus a fourth for tests, documentation and the Go port. The README and notes give about four hours, while the log’s per-session durations total more. The JSONL transcripts are described but not published, so the dialogue cannot be checked from the repository. - **Testing evidence:** Reported validation compares recorded speed with haversine-derived speed (under 1% error), checks mean vertical acceleration against 1 g, fits a gyroscope divisor of about 28 against GPS heading changes and matches altitude to circuit topography. The CRC polynomial, periodic and timer fields, two terminator fields and the exact gyroscope calibration remain unknown or empirical. CI runs Python 3.9, 3.11 and 3.13 tests with a 100% branch-coverage gate, and Go tests on Ubuntu and macOS that compare Go output with the committed Python reference CSV and GPX. - **License:** The project declares MIT and states that it is independent of and not endorsed by Race-Keeper or Trivinci Systems LLC. Decoding is limited to the hardware revision and recordings the author examined, and other devices or firmware versions may differ. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Elgato HDR: a userspace capture path for the Elgato 4K X’s 10-bit mode > A native macOS app that reaches the Elgato 4K X capture card’s 10-bit P010 video mode, which the project says Apple’s built-in webcam driver does not expose to apps. A root helper detaches that driver and runs the card’s USB Video Class streaming directly through libusb, feeding a Metal HDR viewer, an HDR10 recorder and an editor. Latency figures and device coverage remain author-reported. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building needs Xcode Command Line Tools and Homebrew’s libusb: build.sh compiles the C helper against libusb, bundles the library, compiles the Swift app and signs it ad hoc, and releases are not notarized. The helper needs one administrator prompt because detaching the macOS kernel driver requires root; it exits about 20 seconds after the app quits and hands the card back to macOS. - **Scope:** Reviewed at the 2026-10-13 head, after release 1.0.0 (2026-09-08). It targets an Elgato 4K X on macOS 14 or newer; the README reports building and testing on Apple Silicon only, and other Elgato cards with a P010 UVC format are untested. The HDR preview needs an HDR/EDR display. Among the 10-bit modes, 4K is limited to 30 fps by USB bandwidth. - **Scope:** The repository keeps the USB descriptor-dump tools used while reverse-engineering the card and a script that sweeps every capture mode; it contains no vendor firmware or driver binaries. Recordings carry fixed HDR10 mastering metadata because, per the README, the card does not pass the source’s HDMI HDR metadata over USB. - **Testing evidence:** The README and the Game-mode pull request report display delays of about 48, 22 and 5 ms for the Smooth, Game and Lowest Latency modes at 1440p60 on a 120 Hz MacBook Pro, measured from USB transfer completion to display as reported by macOS; the card’s own processing comes on top, and the PR notes that the test card sent silent audio. These are author measurements. - **License:** MIT covers the project code; the bundled libusb library and captured content keep their own terms, and the project states it is not affiliated with Elgato or Corsair. An X post under the same handle credits REA with helping this latency work. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### LGwebOS-menubar: a native macOS remote for LG webOS TVs > A native macOS menu-bar app that pairs with an LG webOS TV over its local encrypted WebSocket interface to launch apps, switch inputs, adjust volume and picture settings, send pointer input and cast selected media. The project credits the public Connect SDK for webOS protocol behavior and reuses PyWebOSTV’s registration manifest. Testing covers one TV on webOS 5.0. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Reviewed at the 2026-10-13 head, when the repository held only this app. By 2026-10-20 GitHub serves it as TVmenubar-MacOS, and its head README splits it into separate LG webOS 5.0 and Roku OS 15.3.4 apps. It needs macOS 14 or later, Xcode Command Line Tools with Swift 5.9 or later, and an LG webOS TV on the same network; the only tested set is an LG 50UN7310PSC on webOS 5.0, and other models and versions are unverified. Pairing must be accepted on the TV, an IPv4 address is required, and Wake-on-LAN needs the TV’s MAC address. - **Prerequisites:** scripts/build.sh produces a locally signed, unnotarized app bundle. Pairing uses encrypted WebSockets on port 3001; the app pins the TV certificate after explicit approval and keeps pairing keys in Keychain. The repository ships no device addresses or pairing keys, and a privacy-check script scans files before publishing. - **Testing evidence:** The offline --self-check runs preference, certificate, pointer, Home, usage, resource and loopback media tests without a TV. - **Limits:** The README narrows the author’s post: screen time is counted locally only while the app is connected, AirPlay support is limited to guidance for macOS Screen Mirroring, picture-setting changes depend on TV permissions, and casting depends on the TV’s codecs and DLNA service. - **License:** MIT covers the project code; the PyWebOSTV manifest keeps its MIT notice, and LG, app and console icons keep their owners’ rights. Commits credit Claude as co-author, and an X post by the same account credits REA. This is an unofficial client. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Vineflower > Fernflower-derived decompiler for Java and other JVM languages that continues the ForgeFlower, Fabric and Quiltflower forks, focused on output quality and modern Java, including records, sealed classes, switch expressions and pattern matching through Java 21+. Its command line takes a JAR, ZIP, folder or class file and writes a folder, an archive or console output, with multithreaded decompilation and automatic formatting. It can also be embedded as a library from Maven Central or used in IntelliJ IDEA through a plugin that replaces Fernflower, and the regular release JAR bundles three plugins, including Kotlin support and variable renaming. - Type: Tool - Targets: App - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 1.12.0, published 2026-04-29 on GitHub and Maven Central (org.vineflower:vineflower). The regular JAR includes the three bundled plugins and the -slim JAR only the decompiler. The reviewed master commit is identical to that tag; pull requests target the develop branches, and develop/1.13.0 was 28 commits ahead. - The README says Vineflower 1.9+ needs Java 11 or newer and 1.11+ needs Java 17 or newer to run; the build uses a Java 17 toolchain with ./gradlew build. The IntelliJ IDEA plugin is a separate Marketplace download. - Inputs are user-supplied JAR, ZIP, folder or class files, with libraries added through -e/--add-external as classpath context. The output comparison on the project website is the project's own; decompiled code is reconstructed and is not the original source. - Apache-2.0. The README calls it a fork of JetBrains' Fernflower, MinecraftForge's ForgeFlower and FabricMC's Fernflower fork and a continuation of Quiltflower; its console entry point keeps Fernflower's org.jetbrains.java.decompiler package. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Droid ASC > Python Android decompiler that answers queries directly against an APK instead of first unpacking and indexing it. It probes compressed DEX entries in place, uses the layout that the R8 compiler’s constant relocation and instruction deduplication leave behind to search string, type, method and field references across DEX files, and for a requested class rebuilds a minimal, self-consistent DEX in memory that a bundled copy of Androguard’s decompiler turns into Java. The droidasc CLI and Tk GUI list classes, decompile single classes, decode AndroidManifest.xml and find subclasses or interface implementations; the README presents it as a lightweight back end for agents analyzing many APKs. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: dev-0.1.2-post2, published 2026-10-14 without binary assets and matching PyPI’s droidasc 0.1.2.post2; the reviewed main commit adds only two README notes. The project began in June 2026. The README now says it has been rewritten 1:1 in Rust as the separate rust_ASC repository, which adds full-APK decompilation and is to be updated in sync. - Install with pip install droidasc or from source. pyproject.toml requires Python 3.10+ with axml and mutf8, and CI runs the unit, integration and GUI suites and gates performance regressions on Ubuntu with Python 3.11 and 3.12. APK and DEX inputs come from the user; the README’s benchmark APKs are not in the repository, and the DEX inside the test fixture holds only AndroidX, Kotlin and Material Components library classes. - Speed and memory figures are author-reported: on Telegram X, WhatsApp, Grab and Lark APKs of 59–352 MB with 10 threads, the README reports string-reference searches 62–302× and single-class decompilation 38–304× faster than JADX while using 36–141 MB, and says JADX ran out of memory on the largest. Java output comes from the bundled Androguard decompiler, one class at a time. The README targets agent workflows but describes no MCP server; agents call the CLI or Python package. - Apache-2.0; the bundled dadguard package carries Androguard code, which is also Apache-2.0. Decompiled code keeps the rights of the app’s owner. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### APKEditor > Command-line APK editor built on ARSCLib that decodes an APK's binary resources and DEX into editable JSON, XML or smali and rebuilds a package from them, independent of aapt and aapt2. It also merges split bundles such as XAPK, APKM and APKS, refactors obfuscated resource names, and prints package information. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs as a single executable JAR on a Java runtime; the Gradle build targets Java 8 source and target compatibility, and the README notes large inputs may need an increased -Xmx heap to avoid an OutOfMemoryError. - Operates on APK files the user supplies; the README documents decoding to XML source for un-obfuscated packages only, and rebuilding a package is distinct from recovering original Java source. Apache-2.0 licensed. ##### Primary sources 1. 2. 3. #### jnitrace > Frida-based dynamic-analysis tool that traces an Android app's use of the JNI API, similar to frida-trace or strace but for the Java Native Interface. It logs the JNI calls that native libraries make through the JNIEnv and JavaVM structures, with include and exclude filters, backtraces and optional JSON output for later post-processing. The tracing engine is also published as a separate jnitrace-engine library. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed from PyPI as jnitrace (setup.py marks version 3.3.1 and Python 3) and runs on a Linux, macOS or Windows host; building from source additionally needs Node.js. - Tracing a target needs an arm, arm64, x86 or x64 Android device running a Frida server, which the README states must provide Frida support greater than 14, with the target package already installed on the device. - Intended for apps the analyst is authorized to inspect. MIT licensed; the repository ships the tool only. The last reviewed upstream commit dates to 2023 and targets the Frida 14-era API. As checked on 2026-10-20, that 2023-04-01 commit is still the master head and the latest release is v3.3.1 from the same day; GitHub’s last recorded push was 2023-07-18, the repository is not archived and the README does not mark it as maintained, superseded or archived. ##### Primary sources 1. 2. 3. 4. #### AsmResolver > C# library for reading, modifying and rebuilding Portable Executable files, covering both native Windows images and images with .NET metadata. It offers three levels of abstraction: raw headers and sections (PEFile); interpreted data directories such as imports, exports, TLS, exceptions, debug data and Win32 resources (PEImage); and a System.Reflection-like model of .NET assemblies and modules with managed, native and dynamic method bodies. It also extracts files from AppHost/single-file bundles, supports ReadyToRun images and reads PDB and Portable PDB symbols without DIA, and upstream designs it to stay robust against malformed or obfuscated binaries. - Type: Tool - Targets: App · Binary - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v6.0.1, published 2026-07-25 on GitHub and NuGet; the reviewed master commit is one contributing-guide commit ahead. Nightly builds come from a separate NuGet feed. Version 6.0 changed the API, and upstream publishes a guide for migrating from v5.x. - Distributed as layered NuGet packages: AsmResolver, AsmResolver.PE.File, AsmResolver.PE, AsmResolver.PE.Win32Resources, AsmResolver.DotNet, AsmResolver.DotNet.Dynamic and AsmResolver.Symbols.Pdb. The libraries target .NET Framework 3.5, 4.6.2 and 4.7.2, .NET Standard 2.0 and 2.1, .NET Core 3.1 and .NET 6, 8, 9 and 10, and the README lists Windows, Unix-like systems, Mono and NixOS. Building uses the .NET SDK; the full test suite needs additional .NET runtimes, plus Mono and Wine on macOS and Linux. - It is a library without a GUI or a C# decompiler: users write .NET code against its API and supply their own PE files or .NET assemblies. Modified or rebuilt images still have to be checked by running them. - MIT license. The test resources are purpose-built sample binaries. Robustness against malformed or obfuscated binaries is an upstream design goal. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### CodemerxDecompile > Cross-platform desktop .NET decompiler maintained by the original JustDecompile creators as a continuation of their JustDecompile Engine, built with Mono.Cecil and an Avalonia UI. It loads assemblies into a tree of namespaces, types, members and resolved references, shows decompiled C#, VB.NET or IL with go-to-definition and back/forward navigation, and searches names, types, string literals and instructions. A create-project command exports an assembly as a Visual Studio 2015, 2017 or 2019 project. - Type: Tool - Targets: App - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 1.5.0, published 2024-11-18, with portable archives for Windows x64 and ARM64, Linux x64 and macOS ARM64 and x64; the reviewed master commit is from the same day and was still the latest at review. The README says the macOS app is unsigned, so macOS reports it as damaged until its quarantine attribute is removed. - Source builds need the JustDecompileEngine and AvaloniaEdit Git submodules and the .NET 7 SDK: the app targets net7.0, and the release workflow publishes one build per runtime with dotnet publish. The main view uses the engine's C# 7 and Visual Basic 10 language modes. - Release builds send usage events, such as start-up, opening files, changing language, searching and creating projects, to a Matomo cloud server together with a hashed device identifier, the app version and OS details, and they query the GitHub API for newer releases; no setting to turn this off was found in the reviewed source. - AGPL-3.0 for the app and the JustDecompile Engine; Mono.Cecil and AvaloniaEdit are MIT-licensed, per the README and THIRD-PARTY-NOTICES.md. Input is the user's own .NET assemblies. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### wxapkg > Desktop GUI for Windows and macOS, built with Wails, that unpacks WeChat mini-program .wxapkg packages for study. It scans the mini-program package folders of local WeChat 3.x and 4.x installations, including per-user folders, or takes a file or folder the user selects; packages that the PC client stores encrypted are decrypted first. Each packaged file is written to its recorded path, with optional beautification of JSON, HTML and JavaScript. - Type: Tool - Targets: App - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v2.0.0, published 2026-04-16, with a Windows x64 executable and a macOS universal app; earlier v1.x releases shipped Windows executables only. The reviewed main commit adds only a settings dialog for the default output directory after that release. - The README names Windows and macOS as the supported platforms. Building from source needs Go 1.25 as declared in go.mod, the Wails v2 CLI and npm for the Vue frontend. - Input is .wxapkg packages already on the machine, found in WeChat's package folders or selected manually. The output is the files stored in the package: the reviewed code has no WXML or WXSS decompilation step, so compiled view code stays compiled, and reading mini-program information is still an unchecked item in the README's feature list. - No license file or license declaration was found. The README disclaimer limits use to learning and researching the design ideas and principles in software, with users bearing all legal responsibility; analyze only packages you are authorized to inspect. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### React Native Decompiler > Alpha-stage Node.js CLI that splits a React Native JavaScript bundle (index.android.bundle or main.jsbundle), an unbundled js-modules folder, or Webpack entrypoint and chunk bundles into one readable file per module. Tagger, editor and decompiler plugins working on a Babel AST undo compilation artifacts such as Babel helpers, comma-operator chains and shortened booleans, turn element calls back into JSX and can rewrite modules as ES6 imports and exports, after which ESLint and Prettier tidy the output. Modules recognized as npm packages are skipped unless requested, and one module ID can limit output to that module and its dependencies. - Type: Tool - Targets: App - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest npm release: react-native-decompiler 0.2.4, published 2023-03-31, providing the react-native-decompiler and rnd commands; the reviewed master commit is from the same day and was still the latest at review. The package declares no Node.js engine range, its publish workflow uses Node.js 12, and it pins Babel 7.12, ESLint 7 and Prettier 2. It continues Richard Fu's original repository, which is now archived. - Input is a plain-JavaScript bundle taken from the user's own React Native app, a js-modules folder, or a Webpack entrypoint bundle or chunk folder. The README states in bold that encrypted or binary bundles are not supported. - The README labels the tool alpha, and the repository has no automated tests; CI only builds and lints it. The README documents the Prettier switch as --prettier, but the source reads --noPrettier. Output is cleaned-up module code for reading, not the original project sources. - AGPL-3.0-or-later. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### hermes-decomp > Rust decompiler and analysis toolkit for Hermes bytecode (.hbc), the compiled form React Native apps ship for the Hermes engine; the README lists HBC versions 40 to 99. Its hermes-decomp CLI shows file information, disassembles, decompiles whole bundles or single functions to JavaScript, with a slower deep mode that recovers more names, and provides a terminal UI, cross-references, call graphs, control-flow graphs, Metro module and closure views and bytecode diffing. A separate hermes-mcp server exposes the read and analysis functions as MCP tools, and the hbc-decomp crate offers them as a Rust library. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v0.2.4, published 2026-10-01, which is the reviewed main commit. Its archives contain hermes-decomp and hermes-mcp for Linux x86_64 and ARM64, macOS ARM64 and Windows x86_64, with SHA256SUMS; the README also lists a macOS x86_64 build, which this release lacks. Source builds need Rust 1.70+, and an update command checks for or installs newer releases. - Input is a Hermes bytecode file from the user's own React Native app, not a plain-JavaScript bundle. Full-bundle decompilation writes an .hdcache file next to the input unless --no-cache is passed. hermes-mcp uses stdio by default; its HTTP transport listens on 127.0.0.1:8744 unless another host is given, and docs/MCP.md lists only read and analysis tools. - Separate CLI write commands assemble or patch bytecode and HASM; they never recompile decompiled JavaScript. USAGE.md reports full write support for HBC 96 and below, verified against the Hermes VM, while HBC 97+ files support only same-length string patches and can be checked only with a macOS helper. - CI checks formatting and Clippy, builds on each platform and runs the test suite with corpus-dependent tests skipped; the repository keeps small jsx_cycle .hbc test fixtures. Local gates compile sample snippets with hermesc toolchains that the scripts fetch or build, run the original and decompiled code under Node and compare output, with five known failures listed, and cap unparsable modules per bundle, at 211 for the one recorded bundle, so decompiled output is not always valid JavaScript. - MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### MEDUSA > Modular Frida-based framework for runtime analysis of Android and iOS apps the analyst is authorized to test. From a single coordinated script it loads plug-in modules to inspect network and WebView activity, trace API calls, examine memory and cryptographic operations, monitor malware behavior, and handle protections such as SSL pinning. The README reports it ships with over 90 reusable modules. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python 3 and runs on Linux or macOS, with the README noting limited functionality on Windows; a preconfigured Dockerfile is also provided. - Instrumenting a target needs a rooted device or emulator with adb and a running Frida server; the tool operates only on apps the analyst is authorized to test. - The README reports 90+ reusable modules and an optional MCP server component; it names capabilities such as SSL-pinning handling. GPL-3.0 licensed; the repository ships the framework and its modules, no application packages. ##### Primary sources 1. 2. #### Android Unpinner > Tool from the mitmproxy project that removes certificate pinning from an Android APK you own or are authorized to test, without a rooted device. It marks the app debuggable, touching only AndroidManifest.xml, and injects a Frida Gadget over ADB so an interception proxy can read the app's traffic, reusing HTTP Toolkit's unpinning script. It bundles the Android SDK helpers it needs and can also handle split APKs delivered as XAPK. - Type: Tool - Targets: App · Protocol - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed with uv or pip and requires Python 3.10+ (pyproject version 1.0); the target device connects to a desktop over USB/ADB, and the tool bundles the adb, apksigner, zipalign and aapt2 helpers for Windows, Linux and macOS. - Patches the target APK and needs active instrumentation from the desktop each time the app launches, so rooting the device is not required; intended only for apps you own or are authorized to test. - The README states the project's own code is MIT-licensed, with no separate LICENSE file for GitHub to detect; bundled components keep their own licenses, including HTTP Toolkit's unpinning script (AGPL-3.0), the Frida gadgets (wxWindows Library Licence) and Android build/platform tools. The repository also ships HTTP Toolkit's open-source SSL-pinning demo APK (Apache-2.0) as a test target. ##### Primary sources 1. 2. #### apk-mitm > Command-line tool that prepares an Android APK you own or are authorized to test for HTTPS traffic inspection. It decodes the package with Apktool, adjusts the network security configuration to trust user-added certificates, disables certificate pinning, then re-encodes and signs the patched APK, so a proxy can read the app's traffic without a rooted device. App bundles supplied as .xapk or .apks are also supported. - Type: Tool - Targets: App · Protocol - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed from npm as a global CLI and requires Node.js 14+ and Java 8+ per the README; patching app bundles on Linux also needs zip and unzip available. - Operates on an APK or app bundle the analyst supplies and is intended only for apps you own or are authorized to test; rooting the device is not required because the changes are applied statically before install. - The README notes the static Apktool-based approach can fail on large or complex apps and cannot address certificate pinning enforced inside native binaries such as Flutter. MIT licensed; the repository ships the tool only, no application packages. - As checked on 2026-10-20, the latest release, v1.3.0 (2024-04-21, also the latest npm version), is the reviewed commit and still the main head; GitHub’s last recorded push was 2024-07-24, the repository is not archived and the README does not mark it as maintained, superseded or archived. ##### Primary sources 1. 2. 3. 4. #### Frida Mobile Interception Scripts > A set of Frida scripts from HTTP Toolkit for inspecting a mobile app's HTTPS traffic while analysing apps you own or are authorized to test. Injected into a running Android or iOS app, they redirect its connections to an interception proxy, add a user-supplied CA certificate to the trust stores, and disable certificate pinning and transparency checks so the proxy can read the traffic. Individual scripts can also be used on their own to hook specific behaviour. - Type: Tool - Targets: App · Protocol - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Delivered as Frida scripts injected into a target app with the Frida CLI; the README's Android workflow requires a rooted device or emulator running frida-server as root, and the iOS workflow requires a jailbroken device with Frida installed. - The analyst supplies their own interception proxy and CA certificate and edits config.js before use; the scripts are intended only for mobile apps you own or are authorized to test, not for circumventing protections on third-party software. - AGPL-3.0 licensed and funded by NLnet as part of the HTTP Toolkit project; the repository ships scripts only and no application packages. ##### Primary sources 1. 2. #### reFlutter > Flutter reverse-engineering framework for apps the analyst is authorized to inspect. It repacks an app with a prebuilt patched Dart engine, or instruments the app's own engine at runtime, to emit a JSONL dump of every function's name, class, library and code offset into the Dart instructions image for Frida or IDA/Ghidra work. It can also route the app's HTTPS traffic through an inspection proxy with Flutter certificate pinning disabled. - Type: Tool - Targets: App · Protocol - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed from PyPI as reflutter (setup.py marks version 0.9.8 and requires Python 3.10+) and runs on Linux, Windows or macOS; the README notes a repacked APK must be re-signed and zip-aligned with an external signer before install. - The README lists support for Android arm64, arm32 and x64 and iOS arm64 across release and profile builds on the stable and beta channels, with engine coverage keyed by snapshot hash in enginehash.csv; pre-monorepo engines (<= 3.27) are built from the archived flutter/engine repository. Frida hooking and dump collection need a matching frida-server on the target device or emulator. - Intended for Flutter applications the analyst owns or is authorized to inspect. GPL-3.0 licensed; the project ships tooling and prebuilt engine assets but no application packages. ##### Primary sources 1. 2. 3. 4. #### ddc > Rust decompiler that turns Android DEX bytecode, versions 035 to 041, from APKs, multi-dex apps and XAPK/APKS/APKM containers into Java, folding lambdas and string concatenation back into Java syntax and giving locals jadx-style names. By default every file also goes through a source-level cleanup pass, described as semantics-preserving, that inlines copy chains, recovers ternaries and for-each loops and drops dead stores; --fast skips it. Alongside full decompilation, 15 query subcommands return app and manifest information, resources, strings, cross-references, class hierarchies, disassembly or single classes and methods on demand, and the same queries are served over REST and MCP. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v0.1.30, published 2026-10-18, which is the reviewed main commit. The repository was created in September 2026 and releases come quickly (v0.1.28 to v0.1.30 within eight days). Releases ship raw binaries for Linux, Windows and macOS on x86_64 and ARM64, the non-macOS builds UPX-compressed, and Homebrew, Scoop and cargo-binstall install them; source builds use stable Rust and the author's jdc-core, cure and xyz-rust crates. - Input is an APK, app container or DEX file from the user's own app; full decompilation writes an -out directory next to the input by default. ddc serve and ddc http default to the listen address :8080, with no host given, and bearer-token authentication is optional; ddc mcp stdio runs as an agent subprocess. - The README reports that all 909,689 files emitted for seven benchmark APKs, and docs/validation.md that 4.08 million files from 39 apps, pass javac's parse phase; this is a syntax check only. Known limitations include erased generic types, separate d8-desugared lambda classes, timeouts on some very large R8 methods whose output can vary between runs, and desugared pattern switches; a full-classpath javac run still finds about 7,500 ddc-attributable errors across 0.91 million files, roughly twice jadx's count on the same set. - CI builds and runs cargo test on Linux, macOS and Windows. The benchmark APKs are not in the repository; its fixtures are small DEX files and one binary AndroidManifest. MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Simplify > Generic Android deobfuscator built on smalivm, a sandboxed Dalvik virtual machine that executes each method and records every possible register and class value along all execution paths, taking both branches when a value such as file or network input is unknown. Simplify then repeatedly applies constant propagation, dead-code removal, unreflection and peephole optimizations to the APK or DEX, which can decrypt strings and remove reflection while keeping behaviour the same; it does not rename classes or methods. smalivm can also be used as a library, and the last release adds sdbg, a step-through Smali debugger built on it. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Development is inactive: the latest release, v1.3.0 of 2020-03-30, ships simplify, smalivm and sdbg jars, and the reviewed master commit dates from 2021-05-23. The project pins smali/dexlib2 2.4.0 and, by default, builds its Android framework reference from android-25 classes, so check results on apps that use newer DEX or API features. - Run it as java -jar simplify.jar on a user-supplied APK or DEX. Building needs JDK 8, a recursive clone for the AndroidFrameworkSmali submodule of reference framework classes, and the Gradle fatjar task. Execution limits on visits, call depth and time apply per method; the README advises narrowing large apps with include and exclude patterns, and output DEX defaults to API level 15. - --remove-weak, on by default, removes code even when it has weak side effects, and --ignore-errors may lead to unexpected behaviour, so compare output with the original code. The repository includes a project-provided obfuscated example app for testing; tests ran through a Travis CI configuration using Oracle JDK 8, the repository has no GitHub Actions workflow. - Dual-licensed: GPL-3.0 for open-source use, or a commercial license that permits binary distribution without source redistribution. Android framework classes and dependencies keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### GDA (GJoy Dex Analyzer) > Windows-native Dalvik decompiler and Android analysis workbench written in C++ that opens APK, DEX, ODEX, OAT, JAR, AAR and class files without installation. Besides Java and Smali views with cross-references, renaming and comments, it identifies packers, deobfuscates and decrypts strings, tracks data flow and taint, solves paths, runs rule-based malicious-behaviour, vulnerability and privacy-leak scans, and can dump device memory or hook methods with Frida. Shell and server CLI modes, Python and Java scripting and a sample malware-triage agent skill expose the same analysis to scripts and agents. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Releases are Windows-only zip archives; the latest, GDA 4.12 of 2026-04-07, adds shell and server CLI modes among fixes. The repository holds no decompiler source: the README says GDA is not an open-source project, at least in the short term, and the repository publishes the free binaries with open scripts, plugin examples, rule samples and colour themes. - The executable runs without setup. Dex-family inputs need no Java, while JAR, AAR and class files need a working Java runtime for the bundled dx tool. The README says GDA is protected with VMProtect and unpacks embedded adb, a gdump memory-dump helper and rule files into the user’s application-data folder, which some antivirus products flag; the author states it has no malicious behaviour. - The skills folder holds a gda-analyze skill in Claude Code’s format that drives a bundled GDA.exe through a Python wrapper to trace code, extract indicators and draft malware reports, plus a server-mode client and test script. Its output, like the built-in rule-based scans, needs manual confirmation. - LICENSE is Apache-2.0, and NOTICE says most of GDA is released under it, with adb and dex libraries taken from the Android SDK and AOSP; this conflicts with the README’s closed-source statement, so the binaries’ terms are unclear. Users supply the apps they analyze. ##### Primary sources 1. 2. 3. 4. 5. 6. #### APKLab > VS Code extension that turns the editor into an Android reverse-engineering workbench around Apktool, Jadx, smali-lsp and uber-apk-signer. It decodes an APK into resources and Smali, decompiles it to Java, gives Smali go-to-definition, references and diagnostics through a language server, and rebuilds, signs and installs the modified app. It can also generate Frida hooks for Smali methods, add a Frida gadget, prepare an app for HTTPS traffic inspection with apk-mitm and produce a Quark-Engine malware-analysis report. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The latest tag, v2.0.0, dated 2026-04-06 in the changelog, added smali-lsp, Frida hook generation and gadget injection and Apktool 3.0+ compatibility; the reviewed master commit of 2026-07-16 is five commits ahead of it. The extension is published on the VS Code Marketplace and Open VSX, and package.json requires VS Code 1.91+. The README lists Linux, macOS and WSL2, and CI also builds and tests it on Windows. - JDK 17+ is required. On first use the extension downloads the tools named in the project’s update configuration into a .apklab folder in the user’s home directory, at review Apktool 3.0.2, smali-lsp 1.5.0, uber-apk-signer 1.3.0 and Jadx 1.5.6, unless the user sets their paths. adb is optional for installing to a device, and Quark-Engine 21.01.6+ is optional for malware reports. Users supply the APKs. - CI lints and packages the extension and runs its test suite on Ubuntu, macOS and Windows against a sample open-source APK from the separate testdata repository. Jadx output can be incomplete, and rebuilt APKs are re-signed with uber-apk-signer, using the configured keystore when one is set. - AGPL-3.0; Apktool, Jadx, smali-lsp, uber-apk-signer, apk-mitm, Frida and Quark-Engine keep their own licenses. HTTPS-inspection patching and gadget injection modify the app under analysis, and the tool grants no rights to analyze, patch or redistribute third-party apps. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Galaxy Buds Client: an unofficial manager built on Samsung’s earbud protocol > Reimplements control of Samsung Galaxy Buds over their proprietary RFCOMM serial protocol in a cross-platform desktop and Android manager. The author reports recovering the message format by analyzing the earbuds’ binary stream and disassembling Samsung’s official Android apps, and publishes partial packet notes for the 2019 Buds and the Buds+. Beyond the official app’s settings, it exposes battery statistics, diagnostics, factory self-tests, hidden debug information and firmware flashing for supported models. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user’s own Galaxy Buds paired over Bluetooth; earbud firmware and Samsung’s official apps are not part of the repository. Firmware flashing and downgrades download builds from the author’s firmware service, behind an in-app disclaimer and a model-compatibility check meant to avoid bricking. Release notes say the app can share protocol data through an on-demand crowdsourcing feature to support models the author does not own, and sends crash dumps to Sentry; both can be disabled in settings. - **Prerequisites:** Builds from one solution with the .NET 10 SDK (global.json pins 10.0.300) and Avalonia, targeting Windows 10 build 19041+, macOS 12+, Linux and Android 7.0+ (API 24); Linux Bluetooth uses a bundled BlueZ D-Bus library. Release 5.2.1 attaches unsigned Windows and macOS installers and Linux x64/ARM portable binaries; the README also lists Flatpak, AUR and winget packages, and the Android version is sold on Google Play. - **Scope:** Reviewed at the 2026-10-01 master head, 72 commits after release 5.2.1 (2026-06-07). Device specifications in source cover Galaxy Buds models from the original 2019 Buds through the Buds4 series. The protocol notes say they are incomplete and point to the source for details; this is an independent client, not recovered Samsung source, and features vary by model. - **Testing evidence:** An NUnit test project decodes captured extended-status packets from seven models and checks message and spatial-audio parsing; the reviewed CI workflows build and publish binaries without running those tests. Protocol and feature behavior on real earbuds remains author-reported. - **License:** GPLv3 (LICENSE); the README states the project is not affiliated with or supervised by Samsung. Samsung firmware, apps and trademarks keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### Wino Mail: recreating Windows Mail and Calendar > Native Windows client that aims to preserve the familiar Windows Mail and Calendar experience while rebuilding its functionality. The upstream README documents a WinUI 3 interface, mail and calendar providers, contacts, tasks and offline workflows. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** Windows application from bkaankose/Wino-Mail; the README links Microsoft Store and App Installer distribution. - **License:** The repository publishes GNU GPL v3 license text for its code; this does not license the original Microsoft application or branding. - **Testing evidence:** Feature coverage and preservation of the original experience are upstream goals and claims. ##### Primary sources 1. 2. #### Fernflower > JetBrains' analytical decompiler that turns Java class files back into Java source; IntelliJ IDEA bundles it to show code when debugging or browsing class files. The standalone console decompiler takes class files, JARs, ZIPs or directories, can load library files with -e only as analysis context, and writes Java sources to an output directory. Options cover generic signatures, lambdas, inner classes, record and switch patterns, per-method time limits and renaming of ambiguous or obfuscated identifiers, optionally through a user-supplied renamer class. - Type: Tool - Targets: App - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No GitHub releases: the README says releases are published in the IntelliJ repository, whose java-decompiler-engine metadata listed 262.10968.63 as the latest release at review. The README describes Fernflower as part of IntelliJ Community, which takes patches as pull requests, and bugs go to JetBrains' YouTrack (subsystem Java. Decompiler. Engine). - The reviewed master commit's Gradle build (wrapper 9.1.0) compiles for Java 21 and produces fernflower.jar, or a fernflower start script with ./gradlew installDist; the README documents the java -jar fernflower.jar command line. - Inputs are user-supplied class, JAR or ZIP files; libraries passed with -e inform analysis of class and method relationships but are not decompiled. The README says most options are aimed at professional reverse engineers. Output is reconstructed Java, not the original source. - Apache-2.0 with a JetBrains NOTICE. The README credits Stiver as the original author and JetBrains as maintainer since 2014, with some ForgeFlower patches merged; Vineflower is a separately maintained fork. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Bytecode Viewer > Desktop suite for inspecting compiled Java and Android programs: drop in a class, JAR, WAR, APK, DEX, XAPK or APKM file to browse its classes and resources, with up to three decompiler or disassembler views side by side. The README lists six bundled Java decompilers (Krakatau, CFR, Procyon, FernFlower, JADX and JD-GUI), Krakatau and Smali/baksmali disassemblers and assemblers plus javap, Dex2Jar and Enjarify for APK/DEX conversion, a built-in Java compiler for editing, and static search. Java and JavaScript plugins receive every loaded class as an ASM ClassNode for jobs such as string deobfuscation or malicious-code searches. - Type: Tool - Targets: App - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v2.13.2, published 2026-01-01 and re-released on 2026-01-06 with Windows APK fixes, as a single runnable JAR started with java -jar. Its notes call it an in-development version whose CLI is being rewritten and is not functional, pointing CLI users to v2.12; the reviewed master commit is ten fix commits ahead of that tag and still declares 2.13.2. - pom.xml targets Java 8 and holds the bundled JADX at 1.4.7 because newer versions need Java 11+; source builds use mvn package. Some tools call external runtimes: the Krakatau decompiler needs a configured Python 2 command and a JRE rt.jar library, and Enjarify needs Python 3. The README suggests a larger -Xmx heap for OutOfMemoryError. - Inputs are user-supplied class, JAR, ZIP, WAR, APK, DEX, XAPK or APKM files. Decompiled Java is reconstructed from bytecode rather than recovered source, and the bundled decompilers can disagree; the side-by-side views are for comparing them. - GPL-3.0 per the LICENSE file; bundled decompilers and converters keep their own licenses. The repository's Zip Slip advisory (CVE-2022-21675) affects v2.10.x and is fixed from v2.11.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### ScooterLink: reconstructing Honda RoadSync’s handlebar-button protocol > Replaces Honda RoadSync’s Apple Music-only media control with an iOS app that pairs with a Honda PCX 2025 TFT dash over Bluetooth Low Energy and turns handlebar presses into system-wide commands for any player. The author documents the dash’s BLE services, key exchange, button registration and event bytes, reportedly worked out from the official Android app and logged traffic. Results are author-reported on one PCX125, and the protocol notes separate confirmed from unverified parts. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** No Honda software is needed at runtime, but RoadSync’s phone pairing must first be deleted on the dash, which keeps one phone key. The protocol was reportedly derived from the official RoadSync Android app and logged traffic; source comments cite decompiled Android app version 26.8.10 and a findings file, but the app, decompiled code, captures and that file are not in the repository. - **Prerequisites:** Building needs a Mac with Xcode 16+, XcodeGen and the user’s own signing team and bundle ID; the app targets iOS 17, and the prebuilt v1.2 IPA must be sideloaded with a personal or developer Apple ID. Controlling other apps’ playback relies on Apple’s private MediaRemote framework, which README says rules out App Store distribution. - **Scope:** The reviewed commit follows the v1.2 release and changes only one README link. It targets a Honda PCX 2025 with the TFT dash and RoadSync support; README reports testing on a PCX125 2025 and calls other RoadSync models untested. Select and Back map to play/pause and Next/Previous to track changes, and the app reconnects at ignition and switches the dash to phone mode. Now-playing text, speed and volume control are unavailable, and no Android version exists. - **Testing evidence:** docs/PROTOCOL.md marks key exchange, per-connection validation, button registration, the phone-screen request and button events as confirmed on a real PCX125 2025, and dash drawing as unverified. A Mac-run Swift self-test checks CRC values, a simulated key exchange, validation parsing and registration and screen byte layouts. README reports that experimental colour slots and a drawn screen left the dash refusing phone mode until re-pairing, keeps that code switched off and warns never to write to the firmware-update service. - **License:** MIT covers the project code. README says the project is independent of Honda and contains no Honda code or files, only original code and a description of the Bluetooth messages written for interoperability; Honda, PCX and RoadSync remain trademarks of their owners. The author’s post credits Claude with the reverse engineering. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Logic-Lens > Experimental JavaScript source-analysis toolkit that classifies AST-token sequences into configured formula families after local training, and produces heuristic structure, call-graph and intent reports. It supports code-comprehension experiments; its predictions do not establish arbitrary program invariants or semantic equivalence. - Type: Tool - Targets: App - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README documents Node.js 18 or newer. Package version 1.1.0 declares TensorFlow.js, its native Node binding and Acorn; the setup first tries the native TensorFlow binding and then falls back to the pure JavaScript CPU backend. - Formula prediction requires local synthetic-data generation and training. The predictor expects model weights and metadata that are absent from the reviewed repository tree. - Predictions select from a configured formula catalogue. The README’s accuracy/confidence examples are author-reported; heuristic intent and quality reports are not behavioral-equivalence proofs. - Standalone semantic-test definitions cover structure, heuristic patterns and report shape. CONTRIBUTING mentions npm test, but package.json has no test script. - README and package metadata declare MIT, but the reviewed commit has no LICENSE file. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Android Security Toolkit > Local Python APK triage tool that drives apktool and strings, checks manifest settings and source/native-library strings, and produces TXT/JSON findings for manual review. Its rules flag possible issues without proving exploitability or reconstructing application behavior. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python 3 standard-library imports, separately installed apktool and strings/binutils, and an authorized local APK are required. Manifest analysis depends on successful apktool decoding. - String and manifest-rule matches require manual verification. A symbol, permission or flag alone does not establish an exploitable execution path. The README distinguishes this initial static pass from manual code review, dynamic/native analysis and library CVE matching. - The reviewed two-file tree contains no automated tests or versioned validation corpus. README sample output is an author-provided illustration. - The README states MIT, but the reviewed tree contains no standalone license file. ##### Primary sources 1. 2. #### ilspy-cli: targeted .NET decompilation for agents > Rust CLI that hosts an ILSpy C# bridge in-process for assembly, type and named-method decompilation, source search and structured JSON output. A separate PE-header detector identifies managed assemblies without loading the .NET runtime. - Type: Tool - Targets: App - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building requires a Rust toolchain and .NET 8 SDK; build.rs invokes dotnet publish for the C# bridge, whose project pins ICSharpCode.Decompiler 9.1.0.7988. Decompilation needs the .NET 8 runtime; the detect command follows a separate Rust-only path. - Method selection matches the first method with the requested name within the named type; it does not disambiguate overloads by signature. Source search skips types whose decompilation throws, so an empty result is not proof that the requested pattern is absent from the complete assembly. - The integration suite builds one small SampleLib fixture and checks command output, including a simple Add method. - README and Cargo metadata declare GPL-3.0, but the complete pinned tree has no separate LICENSE/COPYING text. The upstream ILSpy engine and user-provided assemblies retain their own licensing conditions. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### React-Decode > Static-analysis CLI for compiled React JavaScript that produces readable bundle output and inferred API-request, route and application-constant reports. It can extract embedded source-map contents when available. - Type: Tool - Targets: Website - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed package declares Node.js >=20, but its locked Babel 8 dependencies require ^22.18.0 or >=24.11.0. The lock pins Babel parser/traverse 8.0.7, generator/types 8.0.6 and Prettier 3.9.10. - Provide authorized JavaScript bundles, HTML, source maps or a URL. URL mode retrieves scripts, chunks and maps; source extraction requires strings in sourcesContent, not just mapping coordinates. - API and value inference is bounded and heuristic: wrapper discovery uses at most six rounds, dynamic values can remain placeholders, and inferred request/response fields are not a verified API specification. Control-flow flattening and string-array obfuscation are outside the documented scope. - The MIT LICENSE and package.json agree, but package.json declares 0.1.0 while the root lock metadata says 1.0.0 and ISC. Input bundles retain their own rights. - Reports may contain credential-like strings from the input; --json prints them unmasked. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### iX500 Scan: a macOS client for the reverse-engineered ScanSnap Wi-Fi protocol > Replaces ScanSnap Home for a Fujitsu/PFU ScanSnap iX500 on macOS with a SwiftUI app and Python service that scan over Wi-Fi through the community-reverse-engineered VENS protocol, or over USB through SANE, and produce searchable PDFs. It vendors bramheerink’s GPL-2.0 driver, extends it for macOS, and documents further handshake and hardware-status fields, including the scan-button bit. Results are author-reported; the repository publishes no tests or captures. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed commit 24a5f7c (three commits, all dated 2026-10-15) targets the Fujitsu/PFU ScanSnap iX500. README says ScanSnap Home 3.7 is no longer maintained and hangs on macOS 27; the project offers Wi-Fi scanning started by the device’s scan button, a USB path through SANE, and searchable PDFs with rotation, cropping, blank-page removal and OCR. No release build is published, and other ScanSnap models are not claimed. - The Wi-Fi path needs the user’s own iX500 and two values that README says only ScanSnap Home knows: the scanner’s 12-character pairing key and the paired computer’s 8-byte HostID. They are obtained once from ScanSnap Home’s own connection to that scanner; the repository includes no vendor software, firmware or captures. - Building needs macOS 14+, Xcode 15+ (Swift tools 5.10), the system Python 3 with Pillow, and Homebrew sane-backends, ocrmypdf, img2pdf and tesseract-lang. build.sh bundles the Python service and vendored driver into an ad-hoc-signed app that runs the service with /usr/bin/python3. - The protocol work extends bramheerink/scansnap, whose VENS specification says it was reverse-engineered from captures of ScanSnap Home talking to an iX500. README adds handshake fields for the paired HostID, local time and UTC offset, hardware-status bits for an empty feeder and the scan button, and a session timeout of about 40 s, and notes that Wi-Fi images always arrive as 300 dpi colour, rotated 180° with scanner background. No automated tests, captures or comparisons with ScanSnap Home output are published. - GPL-2.0, matching the vendored driver at commit 5706688, whose file header records the author’s changes. This is an unofficial client, not recovered vendor source or firmware. The repository’s draft social posts credit an evening with Claude Code for closing the remaining protocol gaps. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### WristBeam: reconstructing Garmin’s watch protocol for a Mac companion > Implements a Garmin watch companion as a native macOS menu-bar app that pairs over Bluetooth, receives live health notifications and original FIT files, and can upload them to Garmin Connect. Source comments attribute its GFDI framing, handshake, file-transfer and status fields to analysis of a supplied Garmin Android package, cross-checked against community implementations such as Gadgetbridge. Device verification covers one watch model, and the opt-in MCP and HTTP interfaces expose only locally cached data. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at VERSION 0.3.7 plus unreleased changes. It needs macOS 13+, a Garmin watch prepared with heart-rate broadcast off, and, for cloud features, a Garmin China or Global account signed in through Garmin’s own page; a local mode pauses all Garmin cloud access. Application-level encryption, native MLR/CoreTransfer and desktop widgets are unsupported, and a sleeping Mac cannot sync. - Protocol source comments describe an independent Swift implementation of GFDI framing (COBS, CRC-16), multilink registration, device information, file directories and transfers, battery status and account-identity fields, each tied to named classes of a supplied Garmin Android package. Gadgetbridge, garmin-bridge and garmin-ble are cited as corroborating wire observations that were consulted, not ported. The reviewed tree contains no APK or decompiled listing; cloud history uses Connect client endpoints that the developer guide says are not a published Garmin API contract. - Building needs macOS 13+, Swift 5.9+ and Command Line Tools; native swift test and CodeQL analysis need full Xcode, which CI supplies. CONTRIBUTING lists lint, localization, secret-scan, release-pipeline and core regression scripts. Release packages are ad hoc signed and not Apple notarized. - The device matrix marks pairing, fresh notifications, original FIT download, China upload and daily charts verified only for an Instinct 2 Solar on 2026-10-13, with firmware unrecorded. Other Instinct, fēnix, epix, Forerunner, Venu and vívoactive models and real Global uploads remain unverified. VERIFICATION.md records regression counts run through Command Line Tools rather than full XCTest. - MIT covers the project, which says it is not affiliated with Garmin; Garmin services, the Android package, watch firmware and health data keep their own terms. MCP, the HTTP/HTTPS API and webhooks are off until enabled. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### abc-decompiler > Decompiler for HarmonyOS Ark bytecode (.abc), the format HarmonyOS app packages carry in modules.abc, built by adapting the jadx decompiler and reading files through a patched copy of the abcde library. Because much of Ark bytecode is semantically close to DEX, it reuses jadx's GUI, IR and passes: an .abc file dropped into the jadx-based window is shown as decompiled code. The README reports that all 227 usable instructions of the 282 Ark opcodes are implemented, most special instructions as pseudo-functions. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README describes the project as still in development: decompilation passes for more readable output, a custom IR and data-flow analysis are listed as unfinished. The only release, h1, published 2024-12-20, ships a single jadx-dev-all.jar built from the reviewed master commit, and the repository has had no pushes since. - Building needs JDK 17+; the patched abcde fork must first be published to the local Maven repository and its version substituted into the Gradle files before ./gradlew dist. Input is the modules.abc file from the user's own HarmonyOS HAP package. - The repository is a modified jadx code base: jadx's DEX input, test samples and inherited CI files remain, and it has no GitHub Actions workflow of its own, so no tests of Ark bytecode output are reported. - Apache-2.0, as inherited from jadx; the abcde fork is also Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### slicer > Browser-based Java reverse-engineering tool that loads class files and JAR/ZIP archives and disassembles or decompiles them with Vineflower (the default), CFR, Procyon or JASM, compiled to run in the browser, next to its own bytecode disassembler. It draws inheritance and interface graphs and per-method control-flow graphs, searches constant-pool entries, instructions and member declarations or usages, applies Tiny, SRG/TSRG/CSRG or ProGuard mappings, and offers generic transformers that strip or normalize bytecode attributes so decompilers cope better with obfuscation. A JavaScript scripting API can add disassemblers and manipulate the workspace; the README itself recommends Recaf for serious reverse engineering. - Type: Tool - Targets: App - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs as the hosted web app at slicer.run and can be installed as a PWA. The repository has no releases or tags, so this entry pins the reviewed main commit (2026-09-19); local builds are a Vite and Svelte app built with pnpm, and the repository has no CI workflow. The documentation says slicer is in active development and that features may be missing. - The documentation states that no data is sent to any server and that decompilers run locally in the browser; JDK library classes are fetched on demand from data.slicer.run, and URL parameters can load a JAR, mapping file or script from another site. Input is class files or JAR/ZIP archives from software the user may analyze; HPROF heap dumps and Android binary XML can also be viewed. - The documentation warns that decompiled output is a best-effort approximation that may not be valid Java, especially for code from non-javac compilers or obfuscators. slicer has no obfuscator-specific deobfuscation, and its remapper does not propagate names through inheritance. - MIT license for slicer; bundled components such as the Vineflower and Procyon decompilers are Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### usque: an open reimplementation of Cloudflare WARP’s MASQUE mode > Reimplements the MASQUE mode of Cloudflare’s WARP client in Go, tunnelling IP traffic over QUIC/HTTP/3 with Connect-IP (RFC 9484) and exposing it as a native TUN device, SOCKS5 or HTTP proxies, TCP-only L4 proxies or port forwarding. RESEARCH.md describes how the author worked out device enrollment, TLS client authentication and Cloudflare’s non-standard cf-connect-ip variant by analyzing the official Android client with Frida, mitmproxy, JADX, IDA Free and Wireshark. It registers with and connects to Cloudflare’s service outside the official client. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-07-20 main head, identical to release v4.2.1. The README calls the project early-stage, says its Go API is unstable if used as a library, and states that only the Linux amd64 release binary was tested, although builds are published for Android, Linux, Windows and macOS on several architectures. RESEARCH.md is a narrative research log; the concise protocol document the README plans has not been written. - Requires access to Cloudflare’s WARP service: the register command creates a new WARP account and enrolls a device key, and the generated config holds that registration’s keys and tokens. The tool uses Cloudflare’s service outside the official client; the README says it is not affiliated with, endorsed by or reviewed by Cloudflare, asks users not to abuse the service and notes that the tool is detectable. ZeroTrust login needs SSO the tool cannot perform. - Building needs Go 1.26.3+ with CGO disabled. The project depends on the author’s fork of connect-ip-go because, the README says, Cloudflare’s implementation is not fully RFC 9484-compliant; quic-go carries the connection, and gVisor and wireguard-go netstacks let the proxy modes run in user space without root. Native TUN mode is limited to Linux and Windows, while the README’s Known Issues list still says Linux only. A Dockerfile is provided. - CI verifies modules and runs go build, go vet, go test and golangci-lint, but the reviewed tree contains no Go test files, so correctness evidence is the author’s own use. The README reports one SOCKS5 speed test of about 834/773 Mbps on a 1 Gbps link and lists missing features such as happy eyeballs, WireGuard and DNS-over-HTTPS. These results are author-reported. - MIT (LICENSE.md). Cloudflare’s service terms and trademarks apply separately, and the README describes usque as an independent research project. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Webamp: a browser reimplementation of Winamp 2 > Reimplements Winamp 2's main, equalizer and playlist windows in HTML5 and JavaScript, with Web Audio playback, volume, balance and equalizer, and renders original classic .wsz skins, which its documentation says match Winamp 2.9 pixel for pixel; Milkdrop presets run through the Butterchurn WebGL port. It ships as the webamp npm module for embedding in web pages, and the same monorepo runs webamp.org and the skins.webamp.org skin museum. Its webamp-modern prototype targets Winamp 3/5 modern skins with an interpreter for MAKI skin scripts, whose undocumented bytecode format the author reverse engineered and documents in the repository. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: webamp 2.3.1 on npm, published 2026-06-16; the reviewed master commit (2026-10-17) adds unreleased accessibility and API changes listed in the changelog. The README says it works in modern Edge, Firefox, Safari and Chrome. It reimplements Winamp's behavior and skin rendering rather than recovering Winamp's code, and webamp-modern remains a prototype with an open list of unimplemented MAKI and skin features. - No original Winamp installation is needed: Webamp bundles a default skin and sample track, and users can load their own Winamp 2 .wsz skins, audio files, Milkdrop presets and .eqf equalizer presets. Skins and audio fetched from another domain must be served with CORS permission, because Webamp reads their contents. - Development uses pnpm and Turborepo; .nvmrc names Node.js 22 and CI uses Node.js 20 to build every package, lint, type-check and run the Jest tests. These test Webamp's own parsing and rendering. Compiling webamp-modern's MAKI test scripts calls the bundled Winamp 5.66 mc.exe, directly on Windows or through Wine elsewhere. - The code is MIT-licensed, and the README says the Winamp name, interface and sample audio file are Nullsoft's property. Bundled files that carry no license of their own: the Nullsoft MAKI compiler builds under packages/webamp-modern/resources/maki_compiler (five mc.exe versions from Winamp 3 alpha 8r to Winamp 5.66, nscrt.dll and the MAKI .mi library headers), the skins named after Winamp defaults (base-2.91, Winamp 3 build 499, Winamp Modern 5.66) and the third-party community skins used for demos and tests, the llama sample MP3 and the Winamp Modern Skins tutorial PDF. The bundled Perl MAKI decompiler is GPL-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. #### APK Studio > Qt6 desktop front end that drives Apktool, JADX, uber-apk-signer and ADB from an IDE-style workspace for Android packages. It decodes an APK into smali and resources, optionally adds JADX Java output, then rebuilds, signs (with optional keystore generation and zipalign) and installs the result on a selected device; manufacturer framework files and extra Apktool arguments can be supplied. Decoded projects open in a file tree with syntax-highlighted smali, Java, XML and YAML editing, an image viewer, a hex editor and search across files. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v6.3.0, published 2026-01-05 from the reviewed master commit, with a Linux x86_64 AppImage, a Windows x64 ZIP and a macOS DMG. The 6.x series began with v6.0.0 on 2025-12-03, following 5.2.4 from 2020, and no commits have landed since 2026-01-05. Source builds need CMake 3.16+, Qt 6.10.1+ (Core, Gui, Network, Widgets), a C++17 compiler, Git and the QHexView submodule. - The decoding, decompilation, signing and installation are done by the external tools. On first launch APK Studio can download Microsoft OpenJDK 11.0.29, the latest Apktool, JADX and uber-apk-signer GitHub releases and Google's latest platform-tools, or use installations configured in Settings; only the JDK version is pinned, and on macOS the automatic JDK is the Apple-silicon package. Its console shows the commands actually run, and the README asks users to separate Apktool problems from APK Studio issues. - APKs and any manufacturer framework files are supplied by the user; installation needs a device reachable through ADB. Decoded smali and JADX Java output are reconstructions to be checked, not original source. The README reports CI builds on Windows, Linux and macOS, and its disclaimer says the tool is not intended for piracy or other non-legal uses. - LGPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### APKiD > PEiD-style identifier for Android packages from RedNaga. It scans APK and DEX files, nested ZIP entries and the native ELF libraries, PE DLLs and resources inside them with YARA rules, using the yara-python-dex DEX module, and reports the compilers, packers, protectors, obfuscators and anti-VM or anti-disassembly tricks it recognizes, per file or as JSON. Optional tracker rules attributed to the Exodus API flag embedded tracking SDKs; APKiD only identifies, and does not unpack or deobfuscate anything. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 3.1.0, tagged and uploaded to PyPI on 2026-04-09; the reviewed master commit of 2026-10-07 adds later rules. pip install apkid pulls in yara-python-dex>=1.0.1. setup.py declares no python_requires and its classifiers name Python 3.6 and 3.7, while Travis CI uses 3.9 and the Dockerfile uses Python 3.11; on Windows the README pins Yara 3.11.0 and a separately built yara-python-dex wheel. - Provide APK, DEX or directory inputs you are entitled to examine. By default the CLI picks entries by file magic, searches nested ZIPs two levels deep, scans entries up to 100 MB and stops each YARA scan after 30 seconds; tracker rules are compiled separately and apply only with --scan-trackers. The README's usage block still shows v2.1.2 and omits --scan-trackers and --include-types. - Detection is signature-based, so unrecognized or modified packers and protectors go unreported; the README asks for unknown samples by file hash to write new rules. Tests compile and lint the rules and scan generated ZIP files; the repository has no sample corpus. - Dual-licensed: GPL-3.0, or a perpetual commercial license that allows distributing APKiD binaries and rules in commercial products but no source redistribution, which is why GitHub reports NOASSERTION. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### dex2jar > Java toolkit that converts Android DEX bytecode, including DEX inside APKs, into JVM .class files packed as a jar for Java decompilers and bytecode tools. It also reads and writes DEX through an ASM-like API, disassembles and assembles smali with its own implementation, converts jars back to DEX and ships helpers such as d2j-decrypt-string. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The latest release, v2.4 of 2023-10-03 with the note “bugfix”, is the reviewed 2.x head, and no commits have followed it. Its download is dex-tools-v2.4.zip, while the README build steps still name a 2.1-SNAPSHOT archive. The README lists GitHub as the project's home after earlier Google Code, Bitbucket and SourceForge hosting. - Everything runs on Java: the build targets Java 8 with the Gradle 6.9.1 wrapper, ASM 9.5 and ANTLR 4.9.3, which d2j-smali keeps because newer ANTLR versions need Java 11+. The d2j-* commands are generated as shell and batch launchers. The CI workflow runs gradle check and distZip on JDK 8 for pushes, pull requests and release tags. - Input is a .dex or .odex file, or an APK or zip containing DEX, from the user's own app; the reader accepts DEX versions 035 to 040 and tries others with a warning. Output is a jar of class files rather than Java source, so reading code still needs a separate Java decompiler. Test resources hold small DEX and zip samples, and dex-translator/libs carries an Android dx 30.0.2 jar. - Apache-2.0, with copyright notices in LICENSE.txt and NOTICE.txt. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### apk.sh > Bash script that automates repetitive Android app analysis chores around apktool: pulling an installed package from a device or emulator, decoding resources and disassembling dex code, and rebuilding the decoded directory into an APK. Split APKs from app bundles are combined into a single APK when pulled, and the script can also prepare a copy for Frida instrumentation. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.1.3, published 2026-01-26, which matches the reviewed main commit. It is a single Bash script; the README lists apktool, apksigner, unxz, zipalign, aapt and adb as requirements. - On first use the script creates a hidden apk.sh folder in the home directory and downloads the tools it needs there, including the latest apktool release and Android build tools, so a network connection and a Java runtime are needed. - Input is an APK or an installed package the user is authorized to analyze; pulling requires adb access to the device or emulator. Rebuilt APKs are modified copies, not the original package. - GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. #### NOOP: an offline WHOOP strap client built from Bluetooth protocol research > Replaces the WHOOP companion app with offline macOS, Android and iOS clients that pair with WHOOP 4.0 and 5.0/MG straps over Bluetooth, decode their vendor GATT frames, offload the strap’s history into local SQLite and compute recovery, strain, HRV and sleep on the device. A versioned protocol reference documents framing, checksums, commands and sensor records per strap family, building on the community my-whoop and goose projects. WHOOP 4.0 is the supported path; deeper WHOOP 5.0/MG metrics and Oura ring support remain experimental. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls NOOP an independent, experimental interoperability project; the reviewed main snapshot follows release v12.0.0 (2026-10-04). WHOOP 4.0 is the tested path; on WHOOP 5.0/MG live heart rate is confirmed while recovery, strain and sleep inputs are still being mapped, and README lists SpO₂ and several overnight inputs as unavailable or incomplete. Scores come from published methods and are approximations, not reproductions of WHOOP’s models; the project says it is not a medical device. - Live use needs the user’s own WHOOP strap; a 5.0/MG strap holds one encrypted bond at a time, so pairing can take it from the official app. Without a strap, the app can import a WHOOP CSV export or an Apple Health export.xml. README states that NOOP contains no WHOOP proprietary code, firmware, logos or assets; ATTRIBUTION.md says some protocol facts were re-derived from decompiles or static analysis of the vendor’s apps and ship as unvalidated candidates, while implementation and strings are not copied. - docs/BUILD.md lists macOS 13+, Xcode 26.x (Swift 6.3) and XcodeGen 2.45+ for the macOS reference app; the Swift packages build with swift build alone, and BUILD.md documents Linux test runs for four of them outside CI. The Android app (Jetpack Compose, Android 8+) builds with Gradle and JDK 17 in CI, and iOS builds from source or installs as a sideloaded, unsigned .ipa. The release check is on by default and sends no health data; optional AI Coach and export features send data only when the user configures them. - CI builds and tests each Swift package, including the WhoopProtocol framing and decoder tests, and builds the Android debug APK with its unit tests. Protocol contracts name the firmware they were observed on (WHOOP 4 41.17.6.0, WHOOP 5/MG baseline 50.42.1.0). docs/VALIDATION_PROTOCOL.md sets rules for claiming scoring improvements. - LICENSE applies PolyForm Noncommercial 1.0.0 to NOOP’s own code and documentation, which GitHub reports as NOASSERTION; bundled GRDB.swift and ZIPFoundation are MIT. README names github.com/ryanbr/noop as the canonical home, although GitHub lists it as a fork of muftiarfan/noop. NOOP states it is unaffiliated with WHOOP or Oura; AGENTS.md addresses human and AI-agent contributors and the optional coach uses a user-supplied model. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### NiimBlue: an independent web client for NIIMBOT label printers > Replaces NIIMBOT's own label app with a browser client that designs labels and prints them over Web Bluetooth or Web Serial, with Android (Capacitor) and Windows (Tauri) builds of the same interface. Printer communication comes from the same author's NiimBlueLib, which the README calls the most complete implementation of the NIIMBOT protocol; the protocol is documented on the NIIMBOT Community Wiki, and owners of models that do not print are asked for a packet capture of a print made with the official app. The README says the client runs entirely in the browser and keeps label data there. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit is the v2026.9.0 release of 2026-09-27; newer work lands on the dev branch, which CONTRIBUTING names as the base for pull requests. The README keeps no list of supported models and points to a NiimBlueLib issue that collects tested models; it suggests trying a different print-task version in the preview dialog when printing fails. - Needs the user's own NIIMBOT printer over Bluetooth or USB serial and a browser with the Web Bluetooth or Web Serial API, usually Chrome-based; some systems need Chrome flags enabled, Safari needs a third-party extension, and deployments other than localhost need HTTPS. No vendor app or firmware is needed to print. The optional firmware updater only flashes a .bin file the user selects. - Built with Node.js and npm from Svelte 5, Vite and Fabric.js, with @mmote/niimbluelib pinned at 0.47.0; npm run build writes static files, and the Dockerfile serves them with nginx. Releases attach the static site as niimblue-dist.zip plus an Android APK and a Windows executable, built by the repository's Gitea workflows. - The repository has no automated test suite: the Dockerfile and deployment workflow run svelte-check before building, and the Gitea workflows build and publish the site and apps. The protocol code and its tests live in the separate NiimBlueLib repository. Model support rests on user reports. - MIT (LICENSE, 2024 MultiMote); NiimBlueLib is also MIT, and its README says the work is for informational and educational purposes, is not affiliated with or endorsed by the vendor and is not meant for commercial use without the vendor's consent. CONTRIBUTING says AI-generated code is not appreciated and must be reviewed if used. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### FIRERPA (lamda) > Client/server Android automation and dynamic-analysis platform for devices the analyst is authorized to test. An on-device server exposes UI automation, a browser-based remote desktop, HTTPS traffic capture (MITM), and bundled Frida instrumentation through one service, driven from a Python client library of 160+ APIs. The README reports it works on Android 6.0+ with or without root, maps Frida RPC to Python and JSON-RPC calls, and includes an MCP server and a natural-language agent command. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v10.9, published 2026-09-27 from the default branch 10; the reviewed commit a980a38 is that release's auto-commit. The Python client requires Python 3.6+ (setup.py pins >=3.6,<3.15); the README lists Android 6.0+ targets on arm64-v8a, armeabi-v7a, x86 and x86_64, including emulators and cloud phones. - This repository holds the Python client library, the gRPC/protobuf service definitions and helper scripts; the on-device server and its Debian environment are distributed as prebuilt per-architecture release tarballs and a Magisk module, not committed to the tree. Deployment uses a one-click app (root or Shizuku), a Magisk module, manual extraction or ROM integration. - Operates only on a device the server is installed on, over a single service port with TLS and certificate-based access control; the README positions it for security testing and compliance analysis. The committed tools directory includes the project's own default MITM CA and SSH material, described in the repository as open defaults. - MIT-licensed. A DISCLAIMER.TXT requires use only for lawful study, research or authorized application analysis on a virtual or dedicated device, and states the software itself provides no capability to intrude on other applications. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### open_oura: a cloud-free Oura Ring client built on its reverse-engineered BLE protocol > Reimplements the Bluetooth Low Energy protocol of the Oura Ring Gen 3/4/5 in Rust crates and an oura command-line client that pairs with, authenticates to and syncs a ring directly, with no Oura account or cloud service. The author reports recovering the GATT layout, packet framing and AES app-auth flow from the decompiled Android app, and porting history-event decoders and several on-device metrics, such as HRV, sleep debt and nightly temperature baselines, from Ghidra decompilations of the app's native libraries. Event bodies are stored raw in SQLite so they can be re-decoded as decoders improve. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-10-07 main head; there are no releases or tags, and the workspace version is 0.1.0. The README reports live pairing, authentication and event sync on a Ring 3 Horizon and a Ring 5, and says the client is designed for Ring 3/4/5, which share one GATT layout, packet framing and auth flow. Several event layouts are marked inferred or partly unresolved, and the algorithm status table lists the sleep, readiness and activity scores as only partly recovered. The iOS app and web dashboard built on these crates live in the separate open_health repository. - Requires the user's own ring and a host Bluetooth adapter. Auth-gated reads need the ring's 16-byte app-auth key in a key file: the pair command installs a new key on a factory-reset ring, while an app-onboarded ring's key sits in the official app's local database, and the bundled helper for exporting it needs a rooted Android phone. Sleep staging and some scores depend on Oura's proprietary on-device models, which the README says are not included and must be supplied by the user; factory-reset and other state-changing commands sit behind explicit flags. - Builds with Cargo as a Rust 2021 workspace. The oura-link crate uses btleplug for BLE by default and can be built without it so that an iOS host supplies its own CoreBluetooth transport; on macOS the terminal needs Bluetooth permission. A separate Python research bench in tools/ uses bleak and pycryptodome. - cargo test runs 88 Rust unit tests at review, covering captured-packet decoding, an AES auth known-answer vector, mock-transport authentication and sync and the ported metric functions; no CI workflow is committed. Physiological figures in the documentation, such as overnight heart rate, RMSSD and SpO2 ratios, come from the author's own rings. - MIT (LICENSE and Cargo metadata). Oura's apps, native libraries, models, firmware, decompiled output, captures and keys are kept out of the repository. A CLAUDE.md guide for coding agents is committed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### Binder Trace > Frida-based terminal tool, described by its authors as "Wireshark for Binder", that intercepts the Binder IPC transactions an Android process sends and parses each message and its reply. Bundled structure files for specific Android releases map transaction codes back to AIDL interface and method names and decode parcel arguments into typed fields beside a hex dump. A frequency pane and a JSON filter file narrow the stream by interface, method or type, showing which system services an app calls and with what data. - Type: Tool - Targets: App · Protocol - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - PyPI release at review: binder-trace 1.4.1, published 2024-08-01, requiring Python 3.9+. The reviewed main commit of 2025-09-11 is one README-only commit later, correcting the frida-server steps and the listed Android versions, and is the latest activity. - Needs a rooted Android device or emulator, adb running as root and a frida-server matching the installed Frida Python package, which requirements.txt leaves unpinned. It attaches to a process by PID or name, or spawns it, and should be used on devices and apps the analyst may analyse. Clipboard copy on Linux needs xclip or xsel. - Default structure sets cover Android 9 to 14, with extra sets for 8.1 and some point releases. STRUCTURES.md explains that AIDL method numbering and parcel layouts change between builds, so results on a device whose build differs from the bundled AOSP tags can be wrong and the files may need hand-editing. Only transactions the attached process issues through libbinder's IPCThreadState::transact are captured, together with their replies. - CI runs tox with isort, black, flake8, pydocstyle and pytest across several Python versions; the tests cover argument parsing, parcel parsing and the terminal interface, not live devices. MIT licensed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Quark-Engine > Rule-based engine for analysing suspicious Android apps: it loads an APK's Dalvik bytecode and checks JSON behaviour rules, each naming permissions and a pair of framework API calls, through five confidence stages, from the permission being requested and either API being called up to both calls appearing in order in one method and passing the same register. Weighted rule matches produce a threat score, with summary, detail, JSON, web, call-graph and label reports, and Quark Script exposes the analysis as a Python API that the project presents for finding vulnerabilities. The repository also ships two Claude Code skills, for running an analysis and generating a rule, and an optional LangChain agent that uses the OpenAI API. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v26.10.1, published on GitHub and PyPI on 2026-10-10 and requiring Python 3.10+. The reviewed master commit of 2026-10-17 differs from it only by an added malware-family report in the documentation. - Install from PyPI, or from source with Pipenv, then run freshquark, which git-clones the separate quark-rules repository into a .quark-engine folder in the user's home directory. dextrace is the default core library, with Androguard 4.1.4 pinned, rizin and radare2 backends through optional extras plus the native tools, and a Shuriken backend; call graphs need Graphviz. The Quark Agent needs an OpenAI API key, and the Claude Code skills need Claude Code with Quark installed. - Input is one APK per run; the documentation scans directories with a shell loop or the Python API. Reports are static rule matches whose confidence counts the stages a rule passes, so coverage depends on the rule set; setup.py calls Quark an obfuscation-neglect scoring system. Suspicious samples belong in an isolated analysis environment, and the test suite downloads live malware and deliberately vulnerable APKs from a separate sample repository. - CI builds rizin 0.7.3 and radare2 5.9.0 and runs pytest with coverage on Python 3.10. The malware-family reports in the documentation are project analyses. GPL-3.0 per LICENSE and the setup.py classifier. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### Dexcalibur (Reversense) > Android reverse-engineering platform that combines static analysis with Frida-based dynamic instrumentation; the master branch is Reversense (Dexcalibur 2.0), a rewrite that runs as a Node.js web server for collaborative projects. Its README describes modeling an app's files, Smali and native code into one searchable representation with Radare2 integration, generating hooks for Java methods, Objective-C and native functions, and building dynamic cross-references from traces collected on attached devices. Inspector plugins in the repository observe areas such as permissions, cryptography, file-system, network and UI activity. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The latest GitHub release and npm package are still the original Dexcalibur v0.7.10 (2021-09-27, Apache-2.0 in its package metadata); the reviewed master commit (2026-10-02) declares the unreleased 2.0.0 rewrite. Its README getting-started, prerequisite and installation sections, and the installation page of the linked documentation site, are unfinished placeholders, and TESTED.md lists only a short set of basic engine, web-server, platform, device, project and ADB-bridge checks. - package.json targets Node.js on macOS, Linux and Windows (.nvmrc pins 22.14.0), and the reviewed commit adds Deno as a second runner; the documentation site says Windows is not officially supported. The README asks for a .dexcalibur settings folder in the user's home directory and names Frida 16.1.4, while package.json depends on frida ^17.6.2. MongoDB backs the project database (the Docker Compose file uses MongoDB 6.0.9), OpenID Connect with KeyCloak provides SSO, and the web UIs and device agent are built from separate reversenseorg repositories. - Analysis starts from the user's own app package and, for dynamic work, an Android device or emulator reachable over ADB with Frida. The third-party setup script downloads Android platform-tools, apktool 2.7.0, baksmali 2.5.2 and binwalk from their upstream hosts. The repository's test workspace bundles apktool.jar, OWASP's UnCrackable Level 1 training APK with its apktool-decoded files, and small ELF, Mach-O, plist and nib parser fixtures. - The 2.0 source is AGPL-3.0-only; the third-party notice covers EFF's apkeep (MIT). README features such as automated SAST/DAST scanning, device-farm management and the built-in MCP server are project-reported, and Reversense offers professional support and modules separately. Intended for apps the analyst is authorized to inspect. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### vdexExtractor > Command-line C tool that extracts the Dex bytecode held in the Vdex containers that ART's dex2oat compiler writes beside Oat files since Android 8.0 (API 26), and by default reverts ART's dex-to-dex quickening so the output is ordinary Dex again. It can also dump the verified-dependency records stored in a Vdex file, disassemble the bytecode in a dexdump-like format and report the Android API level of a Vdex version. Android 9 and 10 Vdex files hold CompactDex, which the bundled deodex helper converts back to standard Dex through a separately built compact_dex_converter. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Inactive: the last tag is 0.6.0 (2019-12-30), there are no GitHub releases, and the reviewed master commit (2020-05-13) is seven commits past that tag. Backends exist for Vdex versions 006, 010, 019 and 021, which the README and changelog place between Android 8 (Oreo) and Android 10 (Q); there is no backend for later Vdex versions. - Build with make.sh using gcc (default) or clang on Linux or macOS, or under Cygwin on Windows; zlib development files are required, and the cross-android target uses the Android NDK's ndk-build to produce armeabi-v7a, arm64-v8a, x86 and x86_64 executables. Binaries are written under bin/; the repository commits no prebuilt executables. - Inputs are Vdex files, or directories of them, that the user takes from their own device or system image; scripts/extract-apps-from-device.sh pulls the oat, art and vdex outputs, and optionally the APKs, of installed packages over ADB, and some system app data needs root. tools/deodex/run.sh needs wget, shasum and unzip and downloads the author's prebuilt compact_dex_converter archives from OneDrive with SHA-256 checks; the API 29 converter is Linux-only, and the converter's own source builds only as an AOSP module. - Apache-2.0 (copyright CENSUS S.A.). The README notes that equivalent unquickening was contributed to AOSP's oatdump. Recovered Dex code remains subject to the rights of the app or system-image owner. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Sony Headphones Client: a desktop client for Sony’s headset control protocol > Recreates part of Sony’s mobile-only Headphones app as a Windows, Linux and macOS desktop client that changes noise-cancelling, ambient-sound and virtual-sound settings over a Bluetooth RFCOMM connection to a paired headset. The author reports reverse engineering the phone app to define its control protocol, and the code rebuilds its message framing, with start and end markers, byte escaping, sequence numbers, a sum checksum and acknowledgements, together with the two set-parameter commands the client sends. Full support is reported for few models, mainly the WH-1000XM3, and the project is archived. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit of 2025-07-19 is ten commits after the v1.3.2 release of 2023-04-26, adding build notes, a GCC include fix and the archival notice; CMakeLists.txt still embeds version 1.3.1. The repository is archived: the README says the app keeps working for the devices it supports and points to untested forks for others. Implemented controls are ambient sound with focus on voice, disabling noise cancelling, and the Virtual Sound VPT and sound-position presets; reading battery or current settings from the headset and the equalizer were never done, so the client only sends settings. - No Sony software or files are needed or included; the client connects over RFCOMM to the headset’s control service UUID. The README reports the WH-1000XM3 and MDR-XB950BT as fully working and the WH-1000XM4 as partial, with other models in a user report issue, and the serializer caps ambient-sound levels at the WH-1000XM3’s 19 steps. The README says the app was reverse engineered for interoperability and that only some enums and data are in the code, the rest to be obtained statically or dynamically, linking a comment on sniffing messages; no decompiled app code, captures or method notes are in the repository. - Releases provide prebuilt Windows x64, Linux x64 and macOS builds, and the Windows build needs the Microsoft VC++ Redistributable. Windows and Linux builds use CMake, a C++20 compiler and the Dear ImGui submodule, with Visual Studio 2022 and the Windows SDK on Windows and BlueZ, GLEW, GLFW, D-Bus and OpenGL development packages on Linux; macOS builds use the bundled Xcode project. - CI only builds the Linux and Windows clients with CMake and the macOS app with xcodebuild and uploads them; there are no protocol tests, and headset compatibility is user-reported. - MIT per LICENSE; the bundled Cascadia Code font is under the SIL Open Font License, and Dear ImGui keeps its own license. The README states the program is not affiliated with Sony, which keeps its rights in the app and headsets. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Garlic > Java and Android decompiler written in C that recovers Java source from class, JAR, WAR, DEX and APK files on multiple threads; it also prints javap- or dexdump-style class listings, converts APK and DEX files to smali, searches their strings with regular expressions and generates call graphs for DEX and APK files. Running garlic -m starts a stdio MCP server whose seven tools decompile files, dump class information, build call graphs, load them into DuckDB for SQL queries and read the extracted AndroidManifest.xml. The README reports decompiling an APK of more than 200 MB with about 190,000 classes in 12 seconds. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest garlic release at review: v1.8-release, published 2026-08-17, with standalone binaries for Linux x64, i686 and aarch64, macOS x64 and aarch64, and Windows win32 and win64; the reviewed main commit is 34 commits ahead of it. The later v1.8-release-thyme tag instead carries installers for Thyme, a separate paid reverse-engineering IDE presented on the repository's homepage. - Source builds use CMake 3.26+ on Linux and macOS, Zig 0.16.0+ for host and cross-compiled builds, MinGW-w64 for Windows, or the Android NDK (r21 or later, verified on r28) for an arm64-v8a binary. The MCP server needs the DuckDB CLI on PATH for its analyze, cg_import and cg_query tools. Inputs are the user's own class, JAR, WAR, DEX or APK files. - The -n native-library analysis, which the README lists as control flow, IR, imports, exports, strings and call graphs for AArch64 ELF files, comes from librosemarylib: a closed-source library committed in prebuilt form as librosemarylib.so, .dylib and .dll files under libs/ for each desktop platform and embedded into the garlic binary at build time. Without it, and on Android, -n is disabled. garlic's -l option installs a purchased license key for that library. - The repository's LICENSE is Apache-2.0; no separate terms or source are published for librosemarylib. The README reports no correctness evaluation of decompiled output, and release notes list fixes for decompilation errors and crashes on specific apps. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Android-Disassembler > On-device disassembler and binary viewer for Android, built on Capstone, that opens ELF shared libraries and executables, object files, Windows PE files, .NET assemblies, dex files and APKs chosen from storage or from installed apps. It shows ELF details and symbol tables, PE import and export tables, disassembly with jump following and navigation by symbol or address, a hex view, ASCII string search and byte statistics such as entropy and chi-square tests to help tell whether data is encrypted. Analyses are kept as projects and can be exported as raw, text, JSON or database files. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest formal release at review: v2.1.5, published 2021-08-06 with a debug APK. A rolling Preview latest prerelease, last published 2026-03-20, carries a debug-signed APK built from the newest branch, and CI uploads a debug APK on every run. The README says maintenance has resumed but the project is still in a recovery and modernization phase; the reviewed master commit of 2026-03-22 is part of that work. - The app supports Android 5.0 (API 21) and newer, with target and compile SDK 35. Files open through the Storage Access Framework picker by default; a separate Advanced import path for raw-filesystem, root and installed-app browsing is meant for power users, and system files that need root permission can be read only on rooted phones. - Building needs initialized git submodules and Android Studio or Gradle with an Android SDK and NDK; build.gradle pins NDK 23.1.7779620 and builds the native code with CMake, and CI uses JDK 17 to run unit tests, a debug build and instrumentation UI tests on API 30 and 35 emulators. The app applies Firebase Analytics and Crashlytics, and the README's privacy note says crash reports of types such as FileCorruptedException may attach the file being analyzed to the bug-report email and upload it to the GitHub repository. - MIT license, copyright 2018 Hyeonseo Yang. The repository commits prebuilt Capstone libraries, library JARs including pecoff4j, facile, RootTools and jep, small ls helper executables for ARM and x86 in the app assets, and a Test subject files folder of sample ELF libraries and an arm-linux-androideabi-ar binary; bundled components keep their own licenses. Users supply the files they analyze. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### XAPKDetector > APK and DEX detector from hors, the author of Detect-It-Easy, that reports the build tools, libraries and protections it identifies in Android packages, using scan engines and signature databases from the Detect-It-Easy family. The Qt GUI also shows AndroidManifest.xml, MANIFEST.MF, DEX and ELF contents, strings, hex, entropy, hashes and the APK signature, and can scan whole directories. A console build runs recursive, deep, heuristic or all-types scans and writes XML, JSON, CSV or TSV results. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 0.03, published 2022-03-14, with Windows portable zips (including a Windows XP build), macOS packages including a Qt 6 build, a Linux AppImage and Debian and Ubuntu packages; release_version.txt still reads 0.03. The master branch was still receiving submodule updates at review, such as new Detect-It-Easy signatures on 2026-10-19, so the source is ahead of the released binaries. - Building needs a recursive clone of 55 git submodules from the author's other repositories, including Formats, XDEX, SpecAbstract, the signatures database and Detect-It-Easy, plus Qt. docs/BUILD.md covers Docker, a Debian package build tested on Ubuntu 14.04 to 20.04, autotools and CMake, macOS with Qt 5.15.2, and Windows with Visual Studio 2019 and Qt 5.15.2 or, for Windows XP, Visual Studio 2013 and Qt 5.6.3. - Input is APK, APKS or DEX files the analyst already has; the changelog adds APKS support in 0.03. Detections are signature and heuristic identifications for analyst confirmation. The repository itself contains no tests or CI workflows. - MIT license, copyright 2020-2026 hors; the submodules are separate repositories. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Jsxer > C++ decompiler for JSXBIN, the binary format of Adobe's legacy ExtendScript, the ECMAScript 3 dialect used to script applications such as Photoshop, InDesign and After Effects. It reads a JSXBIN 1.0, 2.0 or 2.1 literal, parses it into a syntax tree and prints JavaScript source with a header naming the format version. An experimental --unblind option renames symbols obfuscated by JsxBlind, and the same decompiler is exposed as a shared library with a ctypes-based Python binding. - Type: Tool - Targets: App - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.7.4, published 2025-03-31 with macOS arm64, macOS x86 and Windows archives. The reviewed master commit, from 2025-04-22, is one commit later and only makes the README's notice more visible: it says the project is being rewritten in Rust on a separate rust-rewrite branch, whose latest commit is from 2025-03-11. - Input is a file holding only the JSXBIN literal, usually beginning with @JSXBIN@; the README warns that other content around it must be removed first. The CLI writes a .jsx file next to the input unless -o names another path; input that fails the JSXBIN signature check yields an error message and no decompiled code. - Source builds need CMake 3.26+ and a C++17 compiler; configuring fetches fmt 9.1.0, plog 1.1.9 and CLI11 2.3.2 from GitHub. The README documents only the macOS build, while CMakeLists.txt also has Windows and Linux branches and builds a static library and a shared library, the latter loaded by bindings/python/decompiler.py from the build directory. - ctest builds four small programs that decompile embedded array, object, member-expression and for-statement samples and print the result; they report the decompiler's status code but do not compare output with the original source, and CI runs them on macOS and Windows for pull requests. TODO.md lists open problems with function argument order, comma-expression declarations, number printing and some XML nodes producing improper code. - AGPL-3.0. The README says Jsxer was made for source code recovery and security research and asks users not to use it to pirate scripts from their authors; it credits Andrin Meier's format research and jsxbin-to-jsx-converter, whose original repository it says was removed after an Adobe DMCA takedown. Decompiled scripts keep their authors' rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### jni_helper > Static helper by evilpan for reverse engineering Android JNI code. Its extract_jni.py script parses an APK's DEX files with Androguard, finds methods declared native, derives each one's mangled Java_ symbol name and C prototype, including overloaded methods, and saves them with the exported Java_ and JNI_OnLoad functions of the APK's arm64-v8a native libraries as a JSON signature file. Scripts for Ghidra, IDA Pro and Binary Ninja load that file and apply the prototypes and JNI types to the matching functions; a radare2 script is a work in progress. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.6, published 2024-10-23, whose only asset is the demo APK built by CI; the reviewed master commit of 2025-02-24 only updates a README link. CI builds the demo app with JDK 17 and runs extract_jni.py on it as its only test, without checking the output or exercising the disassembler scripts. - extract_jni.py needs Python 3 with androguard, rich and pyelftools from requirements.txt and takes an APK the analyst already has; it reads native libraries only from lib/arm64-v8a. Methods bound at run time through RegisterNatives are not covered, which the README lists as an open TODO, and the disassembler scripts find functions only by their mangled Java_ symbol names. - The Ghidra script is installed by a Makefile into the ghidra_scripts folder in the user's home directory, together with the bundled jni.h.gdt data-type archive; the IDA plugin has separate versions for IDA Pro before 7.4 and for 7.4 and later; the Binary Ninja script runs from File > Run Script and parses the bundled headers/jni.h. Supported versions of Ghidra, Binary Ninja and radare2 are not stated. - No license file, and GitHub detects none, so reuse terms for the scripts are unstated. Bundled headers keep their own notices: headers/jni.h is Oracle's GPL-2.0 file with the Classpath exception, while r2/jni.h and headers/art_method.h are Android Open Source Project files under Apache-2.0. The demo_apk folder holds the source of the author's test app. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### ReArk > Desktop reverse-engineering and AI-assisted analysis workbench for HarmonyOS NEXT packages (.hap, .app and .abc), whose binary releases add Android .apk/.aab, iOS .ipa and standalone PE, ELF and Mach-O analysis. The README describes browsing package structure, resources, signatures and metadata, ABC bytecode disassembly and decompilation with strings and cross-references, Java-like Android decompilation, native header, import and mitigation views, and HDC/ADB device workflows for installing apps, reading logs and mirroring screens. Its built-in ReArk Agent answers questions about the open package with OpenAI-compatible or local Ollama models, retrieving package evidence on demand behind approval flows for host and device actions. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.1.1, published 2026-10-15, with a Windows x64 installer and macOS arm64 and x86_64 disk images; the README lists Windows 10+ and macOS 14.0+ and says Linux is coming in the next release. According to the release notes, Android support arrived in v1.0.0, and iOS, PE, ELF and Mach-O analysis with packer detection in v1.1.0. - The published source lags those releases: the v1.0.0, v1.1.0 and v1.1.1 tags point to commits with no source changes after 2026-07-10, VERSION still reads 0.2.0, and the tree holds HarmonyOS and HDC code but no Android, iOS or native-format backends. Building it needs Qt 6, CMake 3.21+ and C++20 plus the author's hyle package, which CMake requires but which is not published; the optional Wuwe agent runtime is a separate Apache-2.0 repository. - Supply the packages or binaries to analyze yourself. For device and signing workflows the repository bundles plugin/hdc/hdc.exe with libusb_shared.dll and the OpenHarmony hap-sign-tool.jar and app_packing_tool.jar. samples/ holds small HarmonyOS packages (Bridge.hap, contacts.hap, EasyHap-default-unsigned.app and fpt-default-signed.app), the shctf.app and shctf.zip CTF sample documented in docs/shctf-analysis-path.md, and 倩倩手机逆向包.rar, an archive of the fpt sample with its app-data files. THIRD_PARTY_NOTICES lists only Font Awesome icons. - ReArk Agent needs a configured model provider: an OpenAI-compatible endpoint, a provider named in the release notes or a local Ollama model. The README asks users not to send secrets, certificates, user data or trade secrets to remote providers, and limits use to legally authorized reverse engineering, interoperability, malware and security research. The app checks GitHub's latest-release API for updates. - The repository is Apache-2.0; the bundled OpenHarmony tools and icons keep their own licenses, and the release installers contain components absent from the published source. Decompiled output and agent answers still need analyst review. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### ARSCLib > Java library, modeled on AOSP's androidfw ResourceTypes.h and meant to replace aapt/aapt2, that reads, writes, modifies and creates Android resource tables (resources.arsc) and binary XML files such as AndroidManifest.xml. It decodes resources to readable JSON, which also handles obfuscated names, or to XML source when names are intact, and builds either form back into binary resources; APK module classes decode, merge and write whole packages. It also has an experimental DEX read/write package, and the APKEditor command-line tool is built on it. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: V1.4.0, published 2026-07-01 with an attached ARSCLib-1.4.0.jar; the same version is on Maven Central as io.github.reandroid:ARSCLib. The reviewed main commit, from 2026-10-19, is 34 commits ahead, already sets version 1.4.1 in build.gradle and is labeled part 1 of an overhaul of the library core, so its APIs may differ from the release. - Pure Java with no runtime dependencies (JUnit 4.12 for tests); the Gradle build targets Java 8, ./gradlew jar builds the JAR, and CI runs the unit tests and JAR build on JDK 8. The README says it works on Java platforms including Android, Linux, macOS and Windows. It is used as a Maven dependency or a JAR, not as a standalone command-line tool; the README points to APKEditor for that. - Works on APKs and resource files the user supplies. The README says decoding to XML needs un-obfuscated, valid resource names, so obfuscated tables are decoded to JSON instead, and that building validates far less than aapt/aapt2, leaving the user to know which values Android accepts. The dex package's README calls it experimental and not fully implemented. - src/main/resources/frameworks bundles Android framework resource tables for API levels 23 to 37, each a small APK holding only resources.arsc and AndroidManifest.xml, used to resolve framework references; the commit adding API 37 names Google's platform-37.2-beta3 SDK package as its source. The tests include one small type_id_offset.apk fixture. - Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Pithus (bazaar) > Self-hostable Django platform behind the Pithus Android analysis service, which its README describes as built for activists, journalists, NGOs and researchers. An uploaded APK is stored under its SHA-256 and queued for static analyses: Androguard attribute and class extraction, APKiD compiler and packer identification, ssdeep and Dexofuzzy similarity, Quark-Engine behavior rules, androcfg call graphs, Exodus tracker signatures, a MobSF static report, APK signing-block metadata and analyst-written YARA rules with retrohunts over stored samples. Results are indexed in Elasticsearch and shown as web reports and through a REST API, optionally enriched with MalwareBazaar, VirusTotal, MISP and Google Play lookups. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.0.1-beta, published 2026-10-12, a bug-fix and dependency update to v1.0.0-beta of 2026-09-21. That release upgraded the 2021 code base, rewrote the API with a separate Python client and is not compatible with earlier Pithus data; its notes say import documentation will follow. The reviewed master commit, from 2026-10-16, is 27 commits later and adds a MISP connector. A hosted beta runs at beta.pithus.org. - The README documents a Linux development stack started with docker-compose -f local.yml and served at localhost:8001, and warns that a missing-index error may appear on first load. The stack runs a Python 3.13 Django 6 app with a django-q worker, PostgreSQL, Redis, Elasticsearch and Kibana 8.19 with a 2 GB Elasticsearch heap, MobSF v4.5.3, RustFS S3-compatible storage and Prometheus; separate compose files cover Apple M1, staging and production. - Input is an APK uploaded through the web interface or API, or fetched from a URL. VirusTotal and MalwareBazaar lookups send the sample's SHA-256 to those services with configured API keys, MISP matching needs a MISP URL and key, Google Play metadata is scraped by package name, tracker signatures are downloaded from Exodus Privacy at analysis time, and an upload_to_mb management command uploads stored samples to MalwareBazaar when an operator runs it. - The analysis tasks are static or lookup-based; no dynamic or sandboxed execution is part of the pipeline, and rule, similarity and reputation results are indicators. The pytest suite mocks Elasticsearch and storage and uses tests/_data/test.apk, a project-built sample app with the package com.pithus.basicapp. The CI pytest job is commented out, so CI lints, runs bandit and builds and pushes Docker images. Quark-Engine is installed from a fork, and quark-rules holds 280 rule files. - AGPL-3.0; the bundled front-end libraries and the analyzers it calls, including MobSF, keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. #### House > NCC Group’s Python and Flask web interface for Frida-based runtime analysis of Android apps, intended to make writing Frida scripts simpler. From a local browser page the analyst can enumerate loaded classes, the classes in a DEX file, class loaders and a class’s methods, then generate and keep tracing scripts for several functions, including ones in dynamically loaded DEX or JAR files. A configurable monitor logs file, HTTP, WebView, SQL, IPC and SharedPreferences calls. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit c3641e3 dates from 2020-12-27; the project has no releases or tags. The README says House was tested with Frida 12.8.6 and needs Frida 12.8.3 or later for DEX/JAR hooking, while requirements.txt and the Pipfile leave frida unpinned, so current Frida releases may not work without changes. - Runs from source with Python 3 and pip or pipenv (Flask, Flask-SocketIO 4.3.2, Flask-Login, Jinja2, IPython and frida), serving the interface on 127.0.0.1, port 8000 by default. The README requires a rooted Android device connected over USB with a frida-server matching the local frida-python version, and recommends attaching only one USB device. The Stetho sideload option expects the analyst to place a stetho.jar on the device; it is not bundled. - The repository bundles the README’s demo app test_apk/overloads.apk (package com.ha0k3.overloads) and a small test_apk/dyhello.dex as test fixtures, plus copies of the Ace editor and Bootstrap for the web interface. The monitor’s hook list in scripts/monitor/monitor_hook.json is described as experimental. Intended for apps the analyst is authorized to test. - MIT (NCC Group). Frida and the bundled web libraries keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### ABCDE > Kotlin toolkit for OpenHarmony reverse engineering that parses Ark bytecode (.abc) files, the format HarmonyOS app packages carry in modules.abc, along with HAP packages and resource index (.index) files. Its Compose desktop viewer browses classes, methods, fields, literal arrays, imports and exports and disassembles methods, showing imported modules and resource references in readable form; an experimental mode translates some methods literally into JavaScript, and a CLI dumps class lists and resource indexes. The parsing core is also published as a JVM library, and the separate abc-decompiler builds on a patched fork of it. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags are published. The README points to GitHub Actions builds, but no workflow artifacts remained available at review, so the jar has to be built locally; the reviewed main commit of 2025-11-28 is also the latest push. Decompilation to JavaScript is labelled experimental: functions containing try/catch and some instructions, such as the async ones, are unsupported, and the output is a literal, unoptimized translation. - Building needs JDK 17+. ./gradlew :abcdecoder:packageReleaseUberJarForCurrentOS produces a desktop uber-jar for the current OS, while CI's -Puniversal build bundles the Compose runtimes for Linux x64/arm64, Windows x64 and macOS x64/arm64; Gradle resolves dependencies through Aliyun Maven mirrors as well as Maven Central and Google. ./gradlew publishToMavenLocal publishes the core modules for use as io.github.yricky.oh:abcde-jvm, and the abclen size-report and findStr string-search examples show library use. - Inputs are .abc, .hap and resources.index files from the user's own OpenHarmony or HarmonyOS app packages; the repository ships no sample apps. The committed isa.json instruction table is generated from OpenHarmony's arkcompiler_runtime_core isa.yaml, which the updateIsaDefine Gradle property fetches again from Gitee. - CI only builds the universal jar. Most JUnit tests read sample .abc, .hap or resources.index files from the author's local paths or an abcPath environment variable, so only a few encoding and checksum tests run from the repository alone, and no disassembly or decompilation accuracy results are reported. - Apache-2.0; the GUI bundles the JetBrains Mono font under the SIL OFL. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### de4js > Browser-based JavaScript deobfuscator and unpacker, built as a Jekyll site that also works offline as a progressive web app. It detects or lets the user pick an encoding and reverses Dean Edwards' Packer, eval- and array-based obfuscators, some Obfuscator.IO output, JSFuck, JJencode, AAencode, URL encoding, My Obfuscate and WiseLoop, then beautifies and highlights the result, with options to unescape strings, merge strings, recover object paths and evaluate constant expressions. An optional userscript sends the code to the JS Nice service to rename unreadable identifiers. - Type: Tool - Targets: Website - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository is archived. The last release, v1.12.0, was published 2021-03-28, and the reviewed master commit from 2021-11-12 adds only dependency updates and a fix to how option values are converted to booleans. The README notes that Obfuscator.IO is always up to date and that automatic tools, this one included, usually do not match its latest version. The homepage, lelinhtinh.github.io/de4js, still served the app through a redirect at review. - No installation is needed for the hosted page. Local copies run with docker-compose, or with Ruby 2.1+, Bundler and the GitHub Pages Jekyll gems, at localhost:4000/de4js/; npm run build also needs workbox-cli to generate the offline service worker. The Wise unpackers load from the NotSoWise git submodule, which must be checked out. - Input is pasted code, an opened file or a script fetched from a URL. The Eval, JSFuck, Array, _Number, Obfuscator.IO and AAencode decoders and the expression-evaluation option run all or part of the input with eval inside a Web Worker, so untrusted code executes in the browser's worker context. The JS Nice userscript sends code to jsnice.org over plain HTTP and does not work offline. - package.json defines no tests and the repository has no automated tests or CI. Whether a decoder succeeds depends on the obfuscator and its version, so output should be checked by reading it. - MIT; the bundled js-beautify, highlight.js, clipboard.js, math.js, Workbox and magic-check code and the AAencode and JJencode decoders keep their own notices. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### DexKit > C++ DEX parsing library with Kotlin and Java APIs that loads an APK, DEX bytes or an app’s class loader and finds classes, methods and fields by their characteristics rather than their obfuscated names. Matchers combine package scope, modifiers and raw access flags, field, parameter and return types, annotations, the strings and numeric constants a method uses and the methods it calls, while batch queries locate many targets from strings at once; results expose opcodes, callers, invoked methods and fields used. Its guides centre on keeping Xposed hook points working across obfuscated app versions, and the same queries serve as a fast, scriptable search over an app’s bytecode. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2.3.0, published 2026-09-22 with no attached files, which added numeric-literal reading and raw DEX access-flag matching and optimized caching and string queries. The reviewed master commit of 2026-10-10 is two core fixes ahead of that tag. Packages are published on Maven Central as org.luckypray:dexkit; the artifact ID changed from DexKit with 2.0. - Android projects need JDK 11+, Kotlin 1.5+, AGP 4.2+ and minSdkVersion 21+, with 23+ recommended because libdexkit.so may not load from compressed APK libraries on older settings. Since 1.1.0 it also runs on Windows, Linux and macOS from a source checkout built with gcc or clang, CMake and Ninja or Make, using MSYS2 on Windows, and CI builds the native libraries on all three. The APK, DEX data or class loader to query comes from the user; the repository’s only app is its own demo. - The guides present DexKit as a tool for Xposed module developers, and the README examples run inside an Xposed hook. Matches depend on the conditions the user writes, so they identify candidate classes and members rather than recover original names. Unit tests with smali fixtures are in the repository, but the reviewed workflows only build the native libraries and packages. - Everything outside Core/ is Apache-2.0, while the native code in Core/ is LGPL-3.0, although the README’s license badge links only to the LGPL. The README credits AOSP’s slicer, ThreadPool and parallel-hashmap as third-party sources. Apps analysed with it keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### bun-demincer > Node.js pipeline that recovers readable JavaScript from Bun-compiled standalone executables. It extracts the embedded module graph and assets, splits the bundle into one file per module, flags npm vendor code with a fingerprint database, and deobfuscates with wakaru, format-preserving renames recovered from export mappings and optional Gemini-suggested names. Dependency-graph clustering, manual or LLM-assisted cluster labels and cross-version artifact transfer then organize and update the output. - Type: Tool - Targets: App · Binary - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit of 2026-03-06 is the repository’s ninth, three days after its initial release commit of 2026-03-03; there are no tags or releases. It needs Node.js 18+ and the npm dependencies in package.json, including node-canvas for cluster PNGs; Bun is needed only to run extracted code. The README says Bun stores the code in a __BUN Mach-O section, appended ELF data or a .bun PE section; extract.mjs parses the Mach-O section header and otherwise searches for Bun's trailer. - Input is a Bun-compiled executable; the repository contains no target binaries or recovered code, and .gitignore excludes pipeline output. data/vendor-fingerprints-1000.json (26 MB) holds property-name and string-literal fingerprints for 23,746 files from 1,668 npm packages and can be rebuilt from a local node_modules. The README says steps 1–4 are automated, while cluster labels need manual input or an LLM. - ai-rename.mjs and ai-rename-scoped.mjs send module source to Google's Gemini API with a GEMINI_API_KEY (default model gemini-3-flash-preview); their names are model suggestions. The README's round-trip reassembly calls a build.mjs it marks as part of the user's project, which this repository does not contain. - The reviewed tree has no tests or CI. The README states MIT, but there is no license file and package.json has no license field. Four of the nine commits carry a Claude Opus 4.6 co-author trailer. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### dex-oracle > Pattern-based Dalvik deobfuscator that takes an APK, a DEX file or a Smali directory, disassembles it with baksmali and runs plugins that look for obfuscation patterns in the Smali code. To learn what a matched call returns, such as a decrypted string, it merges a small driver into the app's DEX, pushes it to a connected Android device or emulator and invokes the static method there through reflection; the result replaces the call as a constant before the APK or DEX is reassembled. Plugins cover simple string encryption, indexed string and class lookups, certain DexGuard patterns and some reflection, and the author describes it as the inspiration for Simplify. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Development is inactive: the latest RubyGems and GitHub release is 1.0.5 of 2016-07-26, while the reviewed master commit of 2018-12-13 already declares an unpublished 1.0.6. It is installed as a Ruby gem or from source with Bundler; the repository pins Ruby 2.5.3 and needs Java, adb, and smali and baksmali on the PATH, with the README's setup snippet using smali 2.2.5. - Input is the user's own APK, DEX or Smali directory, and a running emulator or attached device with Android 5.0 or later is required because matched methods really execute on it. The README prefers an emulator and warns that the executed code may be hostile; its troubleshooting section instead suggests Android 4.4.2 (API level 19, ARM) if the driver crashes. Only static methods can be executed, and plugins can be disabled when a pattern matches code that is not obfuscation. - The res directory ships the prebuilt driver.dex and a copy of the Android SDK's dx.jar, which the tool uses for DEX merging; rebuilding the driver needs Gradle and the SDK's dx tool. The README lists three plugins, while the plugins directory holds six, adding indexed string and class lookups and a bitwise string-decryption pattern. - RSpec tests with tiny hello-world APK and DEX fixtures and Smali pattern samples ran through a Travis CI configuration on Ruby 2.5.3; the repository has no GitHub Actions workflow. - MIT (LICENSE.txt and the gemspec); dx.jar and the smali tools keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### cbyge: reconstructing the C by GE smart-bulb cloud protocol > Reimplements the cloud control path of the C by GE (now Cync) smart-bulb app as a Go library and a small self-hosted web app. The author reports decompiling the Android app with Apktool, finding its JSON HTTP API for login and device lists and a separate raw TCP protocol to the vendor's server, then working out that protocol's type-and-length message framing and packet encodings from proxied traffic and the Smali code. The resulting API lists devices, reads their status and sets power, brightness, color tone and RGB color. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2021-11-09 main commit; there are no releases. The README states that the code was not informed by a protocol specification and may stop working or fail on some networks and devices. Only the author's own lightbulbs were examined, so the outlets, sensors and switches the same app controls were not reverse-engineered. - Requires the user's own C by GE or Cync account with devices already set up in the official app; newer accounts need the email two-factor login, which the web app or the login_2fa command performs. Control goes through the vendor's cloud rather than local Bluetooth or LAN. The Android app, traffic captures and account data are not in the repository; the README quotes only short Smali excerpts and one status packet from the author's devices. - Builds with Go; go.mod declares Go 1.14 and two small dependencies. The server directory serves a browser front end and a JSON API protected by an optional web password, and the repository also keeps the small TCP and HTTP logging proxies used during the investigation. - There are no tests or CI. The README reports that others have used the API successfully in some cases and that the author found it faster and more reliable than the official app. - BSD-2-Clause, copyright 2021 Alexander Nichol. This is an independent client, not recovered vendor source; the vendor's apps, services and trademarks keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### arkdecompiler > Decompiler for HarmonyOS NEXT apps, published under the jd-opensource GitHub organization, that turns Panda binary files (.abc Ark bytecode) back into ArkTS source. Its xabc program parses the bytecode, lifts it into the Ark compiler's Panda IR for analysis, rebuilds an ArkTS syntax tree with loop, class, lexical-environment and module-variable reconstruction, and prints that tree as ArkTS code. A cross-platform GUI, built with either Electron or Tauri, adds a file explorer, function and symbol lists, cross-references, search and a hex view; the README links Black Hat Arsenal presentations from 2025 and 2026. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-07-23 master commit. The README marks all instructions as supported and a basic GUI as done, while covering enough corner cases from the official compiler and test262 is still in progress. Release v0.1.0 (2026-04-23) attaches Electron and Tauri GUI builds for Linux x86, macOS arm64 and Windows x86; decompilation runs only on Linux and disassembly on all three, and the GUI needs the paths of the command-line tools configured first. - Building xabc is tested on Ubuntu 22.04 inside an OpenHarmony arkcompiler standalone build: scripts/prepare.sh installs the repo tool, syncs the ark-standalone-build manifest from Gitee, downloads its prebuilts and checks out OpenHarmony v6.0.0.1-Release, and the files in patches/ must be applied to arkcompiler runtime_core, ets_frontend and third_party/protobuf before gn and ninja build xabc. The Dockerfile instead uses Ubuntu 20.04 and the OpenHarmony 5.1.0 release. - xabc reads one .abc file and writes ArkTS plus an AST dump, defaulting to demo.abc and arkdemo.ts. The documented workflow compiles the user's own demo.ts with OpenHarmony's es2abc and decompiles the result; any other bytecode must come from the user's own app packages, and the repository ships no apps or .abc samples. - tests/ holds 18 TypeScript samples for features such as classes, loops, generators, async functions and modules. autotests/scantstests.py compiles cases from the test262 and OpenHarmony TypeScript submodules and records whether decompilation exits cleanly, fails, crashes or times out, with a blacklist of skipped cases. No pass rates or semantic-equivalence results are reported, and the repository has no CI workflow. - Apache-2.0; the OpenHarmony components it builds against keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### JNIAnalyzer > A Ghidra extension by Terry Chia (Ayrx) with scripts for analyzing the native libraries of Android NDK apps. JNIAnalyzer.java uses the bundled JADX decompiler to extract the signatures of all native methods declared in an APK and applies the return types, parameter names and parameter types to the matching functions in the loaded .so. RegisterNatives.java uses Ghidra's P-Code API to find RegisterNatives calls and lay down the JNINativeMethod structures for dynamically registered methods, and TraceRegisterNatives.java applies the output of the author's trace_registernatives tool. A JNI data-type archive sets up the jni.h types. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at master 7170ce6 (2023-01-02); there are no releases and the default branch has had no commits since that date, so treat it as unmaintained and check compatibility with current Ghidra. Build the extension with Gradle against a Ghidra install (gradle -PGHIDRA_INSTALL_DIR=), then install the produced zip through Ghidra's Install Extensions dialog and restart. - Analysis runs inside Ghidra on an Android native library the analyst has loaded and is authorized to examine. JNIAnalyzer.java reads a supplied APK with JADX to recover native-method signatures; the README warns it overwrites existing function return types and parameter names and types, and that a function annotated JNIAnalyzer:IGNORE is skipped. RegisterNatives.java is marked experimental. - No third-party target files are committed. The repository vendors its Java build dependencies as JARs under JNIAnalyzer/lib/, including JADX, smali/baksmali, dexlib2, dx, apksig, Guava, ANTLR, RxJava, logback and others, each keeping its own open-source license; the committed android-5.1.jar is a 4-entry stub (a single android/R$style class plus JADX resources), not the Android SDK. The Gradle wrapper JAR is also committed, and data/jni_all.gdt is a Ghidra data-type archive of the JNI types. - The repository has no license file, so reuse terms are unstated; the vendored dependency JARs remain under their respective licenses. A Binary Ninja port exists in the author's separate binja-JNIAnalyzer repository. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Android Reverse > Android app, published only as release APKs, that runs an APK reverse-engineering workflow entirely on the phone, from package extraction and Java decompilation to native analysis, editing and rebuilding. It extracts APK, XAPK and split APKS packages from storage or installed apps, decompiles each class with Jadx (with fallback and IR modes), CFR, Procyon, JD-Core, Krakatau or Vineflower, analyzes native libraries through an embedded radare2 with pseudo-C, assembly, hex, control-flow-graph and call-graph views, and since v20 edits resources, binary XML, the manifest and smali before rebuilding and signing the APK. A built-in MCP server lets MCP clients edit those project files while rebuilding stays a manual step; the README also lists Flutter Dart AOT analysis through Unflutter and Unity il2cpp metadata parsing. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v20, published 2026-08-24, with arm64-v8a, armeabi-v7a and universal APKs; the README's badges name those two architectures and mark the project as in active development. The first release, on 2026-06-17, said editing and repacking were not yet available. Neither the README nor the release notes state a minimum Android version. - At the reviewed commit the repository holds only the README and six screenshots: no app source, build files or license file, and GitHub detects no license, so the app's terms are unstated. The README credits radare2, Sora Editor and the CFR, Procyon, JD-Core, Krakatau, Vineflower and Jadx engines without naming their licenses. - According to the README everything runs on the device, with no PC, ADB or desktop tools. Users supply the packages or installed apps they analyze, and its disclaimer limits use to education and to security research on apps whose authors have given explicit permission. - The MCP server is described only in one README paragraph and the release notes, with no transport, port, tool list or setup steps, and open issue #2 reports edits made through MCP that did not appear in the app. The README does not say how its Smali Explainer produces explanations. ##### Primary sources 1. 2. 3. 4. 5. #### jsc-decompile-mozjs-34 > PHP decoder and decompiler for SpiderMonkey 34 JavaScript bytecode, which the README says may handle .jsc files compiled by cocos2d-x. It parses the XDR-serialized scripts with their atoms, constants, objects, regular expressions and try and scope notes, decodes instructions from a SpiderMonkey 34 opcode table and rebuilds approximate JavaScript for each function context, while a second script prints the decoded operations instead. The author describes it as unfinished and as an example of how a JavaScript virtual machine works. - Type: Tool - Targets: App · Game - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases; the last commit, on 2021-07-27, fixed global-variable and object-initialization opcodes, and the README says the project may no longer be updated and is not complete. It targets SpiderMonkey 34 bytecode: the README notes that opcodes differ between SpiderMonkey versions, lists the magic values for bytecode versions 33 to 47, and says the tool does not check the magic, so files from nearby versions may partly decode. - Runs on PHP 7.0 or later (the README says it still works on 7.4) after composer install, which only generates the autoloader. php run.php prints reconstructed code for each script context, and php scan.php prints atoms, decoded operations, constants and regular expressions for files that do not decompile. Input .jsc files come from the user; the repository holds no sample files or tests, and the source has no decryption or decompression step, so it reads only plain XDR bytecode. - The README reports a fatal bug when decompiling deeply nested contexts and says output is not runnable, with generated names for local variables that the compiler discarded, so results should be checked against the scan.php operations. There is no license file, and composer.json declares the package proprietary, so the repository grants no reuse terms; recovered scripts remain subject to the rights of the application's owner. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Andromeda > Interactive command-line tool by Lasha Khasaia for first-pass reverse engineering of Android APKs, written in C/C++ for speed. It unpacks an APK, parses AndroidManifest.xml, the signing certificate and the DEX files at the archive root, then opens a shell with tab completion for listing permissions, activities, services, receivers and likely entry points, listing and searching classes, methods and strings, disassembling a method's Dalvik bytecode and listing, hashing or extracting native libraries. Further commands report whether the app is debuggable, a creation date taken from its certificate, URL and email strings, and a guess at whether it was written in Java, Kotlin or Xamarin .NET. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Inactive early-stage project: the README says the tool is in the early development stage, and its 29 commits run from 2019-09-22 to the reviewed master commit of 2020-03-14, which removes an editor folder. There are no tags or releases, and GitHub does not mark the repository archived. Documenting the tool is still a TODO; the README shows the command list only as a screenshot, and the author notes very limited Android experience. - Built from source with make, which compiles everything with clang++ in C++17 mode (-std=c++1z) and debug flags (-g -O0), linking zlib and OpenSSL's libcrypto; the README's apt commands install clang, libz-dev and libssl-dev. The Makefile adds libstdc++fs on Linux and Homebrew openssl@1.1 paths on macOS; Windows is not covered. - Input is an APK supplied by the user, run as ./bin/andromeda app.apk. The path must end in .apk, and the tool stops if the unpacked archive lacks AndroidManifest.xml or a DEX file at its root, so bare DEX files are not accepted. The repository contains no sample APKs. - Apache-2.0 license. third_party.md lists the bundled libraries with their own licenses: Google's dexter slicer (Apache-2.0), Claud Xiao's AxmlParser, linenoise-cpp, miniz and pugixml; the tree also bundles the digestpp hashing headers. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Dex-Editor-Android > Work-in-progress Android app for editing DEX files on the device, built on a modified in-tree copy of Google's smali, baksmali and dexlib2. It loads one or more DEX files into a class tree and opens classes as smali in a Sora Editor view with method, field and string lists, label jumps, search and replace, method flow diagrams and Jadx decompilation of a class or method to Java, then deletes classes or recompiles the edited DEX files. The README credits MT Manager for the app's logic and interface ideas. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.0-sora-editor, published 2026-06-09 with one app-release.apk, while the README's sample-app link still points to v1.3_final of 2025-04-29; the reviewed main commit of 2026-07-29 adds later fixes and merged contributor pull requests. The README lists DEX format versions 40 and, partially, 41, and its to-do list still has batch class insertion and extraction and a direct class renamer. - Build with Android Studio, JDK 17 or 21, Gradle 9.5.0 and Android Gradle Plugin 9.2.1; app/build.gradle compiles against SDK 37 with minSdk 24 and targetSdk 28, and the README also mentions Sketchware Pro on Java 11. Dependencies include jadx-core 1.4.7, Sora Editor 0.23.6 and bundled antlr and commons-io JARs. CI builds debug and unsigned release APKs, and the only unit and instrumented tests are the Android Studio examples. - The file picker selects DEX files the user supplies. An AI Explanation screen that the README does not mention sends a smali method picked from the method list, with a default register-usage prompt or a user-edited one, to Google's Gemini 2.0 Flash API using an API key entered in settings; method flow diagrams are drawn locally with a bundled Graphviz viz.js build. - LICENSE is Apache-2.0 (copyright 2024-26 Krushna Chandra), but the README adds that the code may not be used in private projects and that contributions are welcome only in this repository, restrictions Apache-2.0 itself does not contain, so reuse terms are unclear; the in-tree smali code keeps Google's BSD-style notices. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### smali/baksmali > Assembler and disassembler for the dex format used by Android's Dalvik VM: baksmali turns dex, APK, odex and oat files into smali text, and smali assembles that text back into a dex file. The README says the syntax, loosely based on Jasmin's and dedexer's, supports the full dex format, including annotations and debug and line information. baksmali can also deodex odex and oat files and list a dex file's classes, methods, fields, strings and references, while the dexlib2 library reads and writes dex files from Java. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - GitHub lists the repository as archived; its last push was on 2024-01-17, and the reviewed master head of 2022-03-08 is ten commits past v2.5.2, the last version, published as org.smali artifacts on Maven Central on 2021-03-03. The README still points downloads to the author's Bitbucket page. Google maintains a fork whose README says it exists because the original is not maintained; it renames the namespace to com.android.tools.smali and publishes 3.x releases (3.0.7 at review) on Google Maven. - Java command-line tools and libraries compiled for Java 8 and built with the bundled Gradle 6.8.2 wrapper; scripts/smali and scripts/baksmali are launcher wrappers for the jars. Users supply their own dex, APK, odex or oat files and can set the API level; analyzing or deodexing optimized files needs a matching boot classpath, which for oat files can be the device's boot.oat. dexlib2's version map at this commit stops at dex 039 (API 28) and maps newer ART versions to API 29. - The repository includes small test-fixture dex files under baksmali/src/test/resources and dexlib2/src/test/resources, hand-written smali examples, and deodexerant, a device-side C helper built in an AOSP tree that dumps Dalvik's inline method table for baksmali's -T option. No other dex, APK or system images are committed. - There is no LICENSE file, so GitHub detects none; NOTICE releases Ben Gruver's code and Google-copyrighted changes under BSD-style three-clause licenses and says portions taken from the Android Open Source Project are used under Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### dalvikus > Desktop Android reverse-engineering and modification workbench built with Kotlin Compose Multiplatform. It opens APK and DEX files, edits the DEX classes inside an APK as smali without manual unpacking, with syntax highlighting and code completion, and shows decompiled Java from JADX, CFR or Vineflower. It also browses resources and XML through apktool, searches the class tree, string constants and method and field references, re-signs modified APKs with apksig and zipalign, and installs and starts them on a connected device over ADB. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.0.13, published 2025-10-16, with a macOS dmg, Windows exe and msi installers and a Linux amd64 deb. The reviewed master commit (2026-02-16) is one commit ahead, with a drag-and-drop change in the file tree; the README notes that its screenshots may change as the project evolves. - The README requires JDK 11 or later on Windows, Linux or macOS; the release workflow packages with Java 17, and source builds run ./gradlew :composeApp:run. ADB deployment and APK signing need an Android SDK with platform-tools and build-tools, located through ANDROID_HOME or ANDROID_SDK_ROOT or set in the app's settings, and signing uses a keystore supplied by the user. - Inputs are APK or DEX files supplied by the user. The pinned libraries include smali/baksmali 3.0.9, JADX 1.5.2, CFR 0.152, Vineflower 1.11.1, dex2jar 2.4.32, apktool 2.12.0, apksig and ddmlib; the tree commits the Gradle wrapper JAR, ANTLR-generated Java lexer and parser sources and the Monaspace Neon Frozen font files, and the UI is translated into English, German, Chinese and Hindi. - GPL-3.0 license; the README says the tool is intended solely for ethical purposes. No test suite was found, and CI only packages releases. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### paranoid-deobfuscator > Python command-line tool that recovers the strings hidden by the Paranoid and LSParanoid Android string-obfuscation plugins, so that smali code becomes readable for static analysis. It scans a smali directory for the obfuscator's string-lookup method and encoded chunk array, decodes the chunks with Python ports of the libraries' DeobfuscatorHelper and RandomHelper classes, and rewrites each lookup call in place as a const-string instruction with a marker comment. Helper commands list the recovered strings, save the chunks to a file and decode a single string from saved chunks. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v3.0.2, published 2025-02-18 and uploaded to PyPI the same day; install it with pip or pipx. pyproject.toml requires Python 3.10+ with click 8 (8.1.7 or later) and NumPy 2 (2.1.3 or later), and CI runs pytest on Python 3.10 to 3.13 on every push. The reviewed main commit of 2025-03-26 adds only tests and a donation link after that release. - It works on a smali directory decoded from an APK or DEX file the user supplies, which the README pairs with Apktool or smali/baksmali for decoding and rebuilding, and it overwrites the smali files in place. The README supports only apps obfuscated with Paranoid v0.3.0 or later, released 25 January 2020; a commented-out README warning about Windows refers to issue #14, which is closed. - The command stops when it finds more than one candidate string-lookup method or obfuscated string array, which the source says is not supported yet, and logs a warning for lookup calls it cannot follow. It restores string constants only, not names or other obfuscation. Tests cover string encoding, smali parsing, Paranoid decoding and the issue #18 regression. - Apache-2.0 (copyright 2024 Giacomo Ferretti); the decoding modules state that they were converted from Paranoid's and LSParanoid's Java helpers. Analyzed apps keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Katalina > Python emulator for Dalvik bytecode that its README likens to Unicorn: it parses a DEX file and executes methods one instruction at a time, substituting Python mocks for common Java and Android APIs such as String, StringBuilder, Base64, ArrayList, AES Cipher and part of reflection. Run over Android entry points, methods matching a name or one method with given arguments, it logs the strings that the code builds or decrypts, optionally as JSON, which helps recover obfuscated strings in apps and malware. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - There are no releases or tags. Development ran from May to December 2023; the reviewed main commit f8e27b9 of 2026-10-01 merges a contributed fix that makes the String.valueOf mock follow the called overload's descriptor. - Requires Python 3.10+ with the pinned requirements.txt packages, including kaitaistruct 0.10 and pycryptodome 3.18.0. main.py takes -xe for Android entry points, -xm for methods matching a name, -x for one fully qualified method with arguments, -dl to skip methods whose names contain listed words and -j for JSON output. Entry-point and name-match runs give each method a SIGALRM time limit, so README says Windows support may be broken and recommends WSL. - Input is one classes.dex from an APK the analyst already has. README lists most instructions, same-class and static calls and String and Base64 APIs as working, iterator and array APIs and cross-class instance calls as partial, and MultiDex and I/O as broken. Framework behaviour without a mock is not reproduced, and the AES mock only tries ECB and then CBC with a zero IV, so recovered strings must be checked against the code. The repository has no tests or CI. - MIT. The first commit included DEX samples, many named after Android malware families, that were removed a month later; the reviewed tree holds only the Python sources. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Doldrums > Python parser for the Dart AOT snapshots inside libapp.so, the compiled Dart code of an Android Flutter app. It finds the VM and isolate snapshot symbols with pyelftools, deserializes the snapshot clusters and writes a text dump of every class in the isolate snapshot, with fields, method signatures and each method's absolute code offset in libapp.so. It recovers declarations and offsets for further disassembly, not decompiled function bodies. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main commit 7430196 (2022-05-01), the last push; there are no releases, and the README calls the tool beta and still missing some deserialization routines and class information. main.py accepts only the snapshot hashes of Dart 2.10 and Dart 2.12, rejects Dart 2.13 as work in progress and any other SDK as unsupported, so apps built with newer Dart releases are out of scope. - Input is the libapp.so ELF of an Android Flutter app, with its _kDartVmSnapshot* and _kDartIsolateSnapshot* symbols. The tests directory commits Dart 2.10 libapp.so builds of a small sample counter app (package sandbox_flutter) for arm64-v8a, armv7 and x64, plus text dumps of the arm64 and x64 builds as reference output; there is no test runner. - Runs as python3 src/main.py [-v] libapp.so output with pyelftools as the only dependency; there is no packaging or declared Python version. The README notes that the verbose option works only for Dart 2.12 snapshots, and that darter is a fully tested parser for the older Dart 2.5. - The author's blog post documents the snapshot format the parser follows. No license file is present and GitHub detects none, so reuse terms are unstated. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Frida UI > Local browser interface for Frida aimed at Android app testing: a FastAPI server lists USB, local and remote frida-server devices with their installed apps and running processes, and lets the analyst attach to a process, spawn an app, spawn it with a script injected at launch, detach or kill it. Scripts are written in a Monaco editor or loaded from files or Frida CodeShare, whose scripts can be queued to run at spawn, and each session's console output is kept and can be exported as text. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release v1.1.0, published 2026-01-18 and also on PyPI; the reviewed main commit 4b25e28 of 2026-03-08 is 16 commits ahead with layout changes, saved remote-device settings, CodeShare caching and keyboard shortcuts. Install with uv tool, pipx or pip on Python 3.7+; it depends on fastapi, uvicorn, pydantic and the frida Python package. - The device must run a frida-server whose version matches the installed frida package, reached over USB through ADB or over the network; README documents Android setup only. The analyst supplies the target app, which must already be installed on that device. - The server binds 127.0.0.1:8000 by default and its REST API has no authentication; README warns that it executes arbitrary JavaScript in target processes and should be exposed only to trusted networks and users. The Monaco editor is loaded from cdnjs, falling back to a plain text area, and CodeShare scripts are fetched from codeshare.frida.re and run unchanged, so review them before use. - MIT. README says it is an independent project, not part of or sponsored by Frida, and credits GitHub Copilot for code suggestions. The repository has no automated tests or CI. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### darter > Python module that parses binary Dart VM snapshots, such as the libapp.so of a release Flutter app, into a navigable graph of VM objects with back-references, including the memory structures the snapshot dumps. It reads old, AppJIT and AppAOT snapshots, usually autodetects flags and settings from the snapshot itself, extracts the snapshot blobs from app.so or .snapshot files, and its darter.asm module disassembles ARM and ARM64 code with Capstone to find references to VM objects. The README's examples include extracting an app's string table, finding where an object is used, generating call and library-dependency graphs, exporting metadata for Radare2 and deobfuscating a snapshot by matching it against a reference one. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README warns that the project is outdated and that snapshots from a reasonably modern Dart or Flutter version probably will not parse correctly. The parser was written against Dart SDK commit 1ef83b86ae, and info/versions.md names snapshot hash c8562f0ee0ebc38ba217c7955956d1cb as the only supported version, which its Flutter table maps to the 2019 releases v1.9.1+hotfix.2 to v1.9.1+hotfix.6. Parser code last changed in 2021; the reviewed master commit of 2026-02-03 only extends that table, now through Flutter 3.38.9, and the repository has no releases or tags. - darter is a library with no stand-alone program or CLI; the README recommends using it from Jupyter, starting with the 1-introduction and 2-playground notebooks. Most of the code has no dependencies, but parse_elf_snapshot needs pyelftools and darter.asm needs Capstone and its Python binding; no Python version or package metadata is given. - The README reports heavy testing only on AppAOT product snapshots for ARM and ARM64 and light testing on x64 AppJIT release snapshots, and the disassembly analysis supports only ARM and ARM64. Kernel AST snapshots, such as .dill files, are not supported. The README recommends practicing on a snapshot one built oneself before analyzing another; users supply the libapp.so or snapshot to study. - samples/ commits arm-app.so and arm64-app.so, which the introduction notebook describes as builds of the default Flutter app; the samples/appjit.snapshot path it shows for AppJIT input is not committed. utils/ adds Radare2-metadata and import generators and a Node script that replays the pub package registry as of a past date through a local HTTPS proxy, using a committed self-signed CA plus a pub.dartlang.org certificate and key; that certificate expired in 2022. - AGPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Appshark > ByteDance's static taint-analysis engine for Android APKs, designed for very large apps, that scans an app against JSON rules naming entry methods, sources, sinks and sanitizers as Jimple signatures, for vulnerability and privacy-compliance review. It works on Soot's Jimple IR and reuses FlowDroid's manifest and resource parsing, but implements its own field-sensitive pointer and taint analysis. Results go to results.json, which records app, component and permission information, deep links and JavaScript bridge interfaces alongside each source-to-sink path, with an HTML page per finding. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires JDK 11; the README says it does not work on JDK 8 or JDK 16 because of dependency compatibility. ./gradlew build -x test produces AppShark-0.1.2-all.jar. Latest release at review: v0.1.2, published 2022-09-22 with prebuilt jars; the reviewed main commit, still versioned 0.1.2, is 123 commits ahead of it, including September 2026 commits that add scan resource budgets, a bounded jadx workspace and validation of untrusted rule graphs. The startup guide still links the v0.1.1 jar. - Input is the APK to analyze, named by apkPath in a JSON5 config passed to the jar, with rules taken from config/rules, which holds seven sample rules such as unZipSlip, PendingIntentMutable and ContentProviderPathTraversal. The repository bundles 18 Android SDK platform stub jars, config/tools/platforms/android-14 through android-33/android.jar (API levels 15 and 21 absent, about 18 to 47 MB each), used as the default SDK path, plus five small compiled test classes; the javaSource option runs jadx from config/tools/jadx/bin, which the repository does not include. - Findings are static source-to-sink paths whose coverage depends on the rules and settings: the argument guide says too short a maxPointerAnalyzeTime can cause false positives and negatives, and the FAQ shows a slice-mode entry missing an aliased path. The README's security notice limits the UI and server to local testing. Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Wallbreaker > Frida-based explorer for the live Java heap of a running Android app, loaded as an objection plugin or used through its small Python package. classsearch and objectsearch find loaded classes by pattern and live instances of a class, returning object handles; classdump prints a class's declared fields, static field values and methods, and objectdump prints an instance's field values, can view it as a superclass and lists every entry of a collection or map. Analysts use it to see the runtime data and concrete implementations that static decompilation leaves open. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Archived by its owner and read-only. Latest release at review: 1.0.3, tagged and uploaded to PyPI on 2022-05-10 with no release assets; the only later commit adds the GPL-3.0 LICENSE file (2023-03-26). - README installs objection with pip and clones the repository into objection's plugin folder, then loads it with explore -P or plugin load and runs the commands as plugin wallbreaker …. The PyPI package depends on frida and click and ships the command agent as a library; its connection helper attaches through Frida to a USB or remote device by process name or PID, and wallbreaker/main.py defines no command-line entry point. setup.py classifiers list Python 3.4–3.8 on macOS, Windows and Linux. - The target is a running Android app reachable by Frida. The bundled agent.js is compiled from the repository's own TypeScript sources with frida-compile 9 and Frida 14-era typings; it calls the global Java bridge and does not bundle frida-java-bridge, which Frida 17 (May 2025) no longer provides to ordinary scripts. - GPL-3.0. Output is a structural view of objects at one moment in one process, not decompiled source. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### axmlprinter > Java library and command-line tool that parses Android binary XML, such as the compiled AndroidManifest.xml inside an APK, and prints it as readable XML. Red Naga's near-complete rewrite of the Android4ME AXMLPrinter tolerates manipulated files seen in the wild, including out-of-order string tables and mangled start tags, and can write the classic AXML format back out. Since v2.0.0 it also reads the protobuf XML used in Android App Bundles and detects which format it was given. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release v2.0.1, published 2026-03-25 with a prebuilt jar, is tagged at the reviewed master commit 5a8d3e5. v2.0.0 of 2026-01-16 added read-only protobuf support through a contributed pull request; converting between AXML and protobuf is not supported. - Build with the Gradle wrapper (./gradlew jar) into a self-contained jar run as java -jar axmlprinter-*.jar with a binary XML file and an optional output path, which applies to AXML only. CI builds and tests on JDK 17, and JitPack builds with OpenJDK 17; it depends on protobuf-java 4.34.1 and includes AOSP's Apache-2.0 aapt2 Resources.proto. Framework resource IDs are resolved only for common Android resources. - Input is a single compiled XML file the analyst has already taken from an APK or app bundle, not the archive itself. The tests include binary manifest fixtures named large_from_malware.xml and qihoo_jiagu_issue8.xml, the latter from an issue about a manifest that failed to parse, plus a smaller test.xml. - Apache-2.0, crediting Android4ME's 2008 code alongside Red Naga's. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### FlowDroid > Static data-flow (taint) analysis for Android apps and Java programs, built on Soot and usable as a command-line tool or as Maven libraries. Given an APK, the Android SDK platforms directory and a definition of sources and sinks, it models component lifecycles and callbacks to build a call graph and reports flows from sensitive sources to sinks; the bundled SourcesAndSinks.txt is a starting point for privacy leaks, and StubDroid summaries model library methods. Options cover inter-component flows from a supplied ICC model file, path reconstruction, implicit flows, reflection and timeouts that trade precision and recall for speed, and the analysis is described in the PLDI 2014 paper “FlowDroid: precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for Android apps”. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.15.1, tagged 2026-02-23 and published to Maven Central under de.fraunhofer.sit.sse.flowdroid, including soot-infoflow-cmd-2.15.1-jar-with-dependencies.jar for the command line. GitHub releases since v2.14 attach no files, the last with JARs being v2.13 of 2024-04-02, and the README's Maven example still names 2.12.0. The reviewed develop commit of 2026-09-28 declares 2.16.0-SNAPSHOT. - The command line needs an APK, the Android SDK platforms directory and a sources-and-sinks file, and users supply the apps they analyze. The README says FlowDroid runs on Windows, macOS and Linux and warns that large apps can take very long; options skip static-field or exceptional flows, and additive timeouts for the data-flow, callback-collection and result stages return partial results. - Building needs Maven, a JDK and the current Soot snapshot; the README asks for JDK 11 or above, but the reviewed pom.xml compiles for Java 17 against Soot 4.8.0-SNAPSHOT. The README says the full test suite takes about 30 minutes and also needs JDK 8 with its rt.jar, the ANDROID_JARS variable and the DroidBench submodule, a separate repository of benchmark apps. - The repository commits 25 APKs as test inputs: test apps named after the cases they exercise, such as SourceToSink1.apk and ThreadRunnable.apk, under soot-infoflow-android/testAPKs and soot-infoflow-integration/testAPKs, the deliberately vulnerable InsecureBank.apk, and one hash-named APK whose manifest identifies another developer's app (com.RZStudio.cube). soot-infoflow-android/lib holds JUnit, Hamcrest and protobuf-java JARs. - LGPL-2.1; the README notes that modified versions must be shared under the LGPL. Results depend on the configuration and on the chosen sources and sinks. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Enjarify > Pure-Python 3 translator from Dalvik bytecode to equivalent Java bytecode, so Java analysis tools and decompilers can be applied to Android apps: given an APK, with every DEX file of a multidex APK combined into one jar, or a single DEX file, it writes a jar of class files. Its README contrasts it with dex2jar and lists edge cases it handles, such as Unicode class names, constants used as several types, implicit casts, exception handlers that jump into normal control flow, very long methods and classes that reference too many constants. By default it also applies readability optimizations such as copy propagation and unused-value removal. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Archived. Latest release at review: 1.0.3, published 2016-12-20 with no assets; the last commit is from 2017-01-30. The README says this repository may be out of date and that future development moved to Storyyeller/enjarify, whose master branch is 15 commits ahead, with its last commit on 2020-03-07. - Runs from a clone with Python 3 and no other dependencies. enjarify.sh prefers PyPy3, which the README calls much faster than CPython, and enjarify.bat always calls python3. Input is the analyst's own APK or DEX file; the output defaults to [inputname]-enjarify.jar, -o sets the name, -f allows overwriting and --fast skips the optimizations. - Optional metadata such as source-file attributes, line numbers and annotations is not translated, and the README notes contrived cases that cannot be translated because of Android or Java limits. The output is bytecode, so reading it as source needs a separate Java decompiler. runtests.py translates the bundled fixtures, small classes.dex files with their smali sources and expected outputs in tests/test1 to tests/test7, adds the small Android API stub classes from tests/stubs and runs the result with java. - Apache-2.0; the README states that it is not an official Google product. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### MagiskFrida > Magisk, KernelSU and APatch module that installs frida-server on a rooted Android device and starts it at boot, so Frida clients can attach for dynamic instrumentation without starting the server by hand. A daily GitHub Actions job checks for a new Frida release, downloads Frida's official frida-server builds for arm64, arm, x86 and x86_64, and publishes a matching module ZIP with an updater.json for updates from the root manager. The server listens on 127.0.0.1:27042 unless another port is written to a file in the module directory, and the module's action button starts or stops it. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-02 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs a rooted Android device with Magisk, KernelSU or APatch on arm64, arm, x86 or x86_64; the README says to install MagiskFrida.zip from the GitHub releases rather than the obsolete Magisk modules repository. The troubleshooting guide asks for a working adb shell, a stable, up-to-date Magisk with MagiskHide disabled and an AOSP-based ROM. Building the ZIP yourself needs uv and Python (CI uses 3.13) and downloads frida-server from Frida's GitHub releases. - **Scope:** Release versions follow the bundled Frida version; at review the latest was 17.25.1-1 (2026-11-01), built the day Frida published 17.25.1. The module only installs and supervises frida-server: instrumentation runs through Frida's own clients and scripts. - **Testing evidence:** The CI workflow builds and publishes the ZIP; the repository has no test suite. - **License:** The repository has no license file and GitHub detects no license, so it states no reuse terms for its scripts. The bundled frida-server binaries are Frida's official builds under the wxWindows Library Licence. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### de4dot > Open-source .NET deobfuscator and unpacker that tries to restore a packed and obfuscated assembly to almost its original form. Depending on the obfuscator, it decrypts strings, constants, methods, resources and embedded assemblies statically or dynamically, removes proxy methods, junk classes and tamper-detection and anti-debug code, devirtualizes virtualized code, deobfuscates control flow and renames symbols to readable names; it can also just detect which obfuscator was used. The README lists 19 supported obfuscators and packers, among them Dotfuscator, .NET Reactor, Eazfuscator.NET and SmartAssembly. - Type: Tool - Targets: App - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The repository was archived on GitHub after its last commit on 2020-08-29 and has no GitHub releases; the README points to CI builds for binaries. Source builds use the .NET Framework or .NET Core solution and need dnlib, which de4dot uses to read and write assemblies. - **Limits:** Original symbol names usually cannot be restored, and XAML is not renamed, so WPF or Silverlight assemblies may need --dont-rename. The README offers no support and says newer obfuscator versions may require updating de4dot yourself. - **Limits:** For some obfuscators, and for dynamic string decryption, it loads the assembly and its dependencies into memory and executes them, so the README advises a safe sandbox for suspected malware. - **License:** GPL-3.0 (COPYING); bundled libraries such as dnlib, SharpZipLib, QuickLZ and LZMA keep their own license files. ##### Primary sources 1. 2. 3. #### ClassyShark > Google's standalone browser for Android executables and libraries that shows class interfaces and members, dex counts and dependencies. It opens .dex, .aar and .so libraries, .apk, .jar and .class executables and Android binary XML files such as AndroidManifest, resources and layouts, and it can export what it shows as text. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Runs as a JAR (java -jar ClassyShark.jar) on a Java runtime; Arch Linux users can install a prebuilt JAR from the AUR. The latest release is 8.2, published 2018-07-25, and the repository was archived on GitHub after its last commit on 2023-05-19. - **Limits:** The README marks its API finder as work in progress; a command-line reference ships as CommandLine.pdf in the repository. - **License:** Apache-2.0 per LICENSE.txt and the README. ##### Primary sources 1. 2. 3. 4. #### JEB Decompiler > PNF Software's commercial reverse-engineering platform for Android apps and native code, combining a Dalvik decompiler and Android debuggers with disassemblers and decompilers for x86, ARM, MIPS and RISC-V machine code. For APKs it decompiles multi-dex Dalvik bytecode to Java, reconstructs resources and obfuscated XML, cleans up obfuscated code with optimizers that decrypt content and undo reflection, and debugs Dalvik and native ARM or Intel code in one session, stepping from Dalvik into JNI methods. Modules in JEB Pro also decompile WebAssembly, Ethereum EVM contracts (to Solidity-like code), Siemens S7-300/400 PLC blocks and Nvidia SASS GPU code and analyze PDF documents, and its loaders read PE, ELF, Mach-O, Intel HEX and raw (headless) firmware images. The JEB API lets Java and Python scripts, back-end plugins and custom headless clients automate analysis, and JEB also exposes an MCP server for AI agents. - Type: Tool - Targets: App · Binary · Firmware - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** Version at review: JEB 5.48, released 2026-10-07. Needs a 64-bit JDK 21+ (JDK 23 at most and Oracle or OpenJDK builds recommended); the GUI client runs on Windows, Linux (GTK) and macOS on x64 or arm64. Packages are per-user zip archives sent by email; license keys derive from machine identifiers. - **License:** Time-based commercial licenses only, none perpetual: JEB Android (per user, non-professional users, Android apps only), JEB Pro (per user, all modules), JEB Pro Floating (per seat) and JEB Pro OEM (per server, back-end or SaaS use). After a non-OEM subscription expires, existing JDB2 projects still open but new ones cannot be created; per the buy page, only Pro licenses work offline. - **License:** JEB Community Edition is free, with most disassemblers and file analyzers and the x86/x86-64 decompilers, but per the features matrix no Dalvik decompiler or debugger, headless launcher or offline use; the EULA sets separate terms for it. JEB Demo has all modules for evaluation but decompiles only part of the code, cannot save or load projects or use the clipboard, and has time-limited sessions that need an Internet connection. - **Limits:** Stated limits: RISC-V support lacks RV128, RVE, vector/SIMD extensions and floating-point decompilation; the S7 decompiler cannot process all MC7 code or S7-1200/1500 blocks; debugging apps that disallow it works on ARMv7 only; command-line Python scripts need a Pro or CE license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Luyten > Graphical Java decompiler front end for the Procyon decompiler, with its editor view powered by RSyntaxTextArea. - Type: Tool - Targets: Binary - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Prebuilt downloads are on the Releases page; building from source uses Maven 3. The newest release was published on 2019-06-06. - Apache-2.0 per license.txt. ##### Primary sources 1. 2. #### jd-cli > Command-line wrapper around a jd-core fork that decompiles Java class and JAR files to the console, a directory or a ZIP file, with options for line numbers, file-matching patterns and parallel processing. It also ships as a Docker image and as a Java library. - Type: Tool - Targets: Binary - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Versions 1.3.0 and later need Java 17+, older ones Java 8+. The newest release is 1.3.0-beta-1 from 2025-10-30. - GPL-3.0 per LICENSE.txt. ##### Primary sources 1. #### Android Unpacker > Code and slides from the Defcon 22 talk "Android Hacker Protection Level 0". It holds a gdb and adb script for Bangcle and SecShell, a native unpacker for APKProtect, Bangcle, LIAPP and Qihoo Packer, tweaks that hide QEMU and debuggers from APKProtect, and a Corellium-based dynamic unpacking approach with automation. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The gdb-scripts unpacker requires gdb and adb; the native unpacker does not depend on gdb. The newest tagged release is v1.2 from 2014-09-11. - Apache-2.0 per LICENSE.txt. ##### Primary sources 1. #### ReverseAPK > Command-line tool that decompiles an APK to Java and Smali, lists the extracted files, and statically checks AndroidManifest.xml and the source for common vulnerabilities and behaviours such as intents, command execution, content providers, crypto references and hardcoded secrets. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed with the bundled install script and run as reverse-apk with an APK name; the README describes version 1.2. - The repository has no license file. ##### Primary sources 1. #### xHook > PLT hook library for Android native ELF executables and shared libraries. It handles ELF HASH and GNU HASH symbols and SLEB128-encoded relocations, selects targets with regular expressions, and needs no root or system permissions. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supports Android 4.0 to 10 on armeabi, armeabi-v7a, arm64-v8a, x86 and x86_64; building takes Android NDK r16b. - MIT for the code per LICENSE, with documentation under a Creative Commons license per LICENSE-docs. ##### Primary sources 1. #### Epic > Continuation of Dexposed on ART: a runtime method-hooking framework that loads into an app and can hook both the app's own code and Android framework code running in its process. Stated uses include instrumentation and security audits. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README states support for ART thumb2 and arm64 on Android 5.0 to 11 and none for arm32, x86, x86_64 or MIPS, which rules out Android emulators on those architectures. Short methods and fully inlined methods cannot be hooked. The newest release is 0.11.2 from 2021-07-31. - Apache-2.0 per LICENSE. ##### Primary sources 1. #### Clickwill: reconstructing iPod library database editing > Clickwill reconstructs direct editing of iPod classic and iPod nano music libraries in a Swift Mac app. It reads and writes iTunesDB and ArtworkDB on the device, preserves unknown record bytes, handles hash58 signatures and publishes a byte map that distinguishes measured fields from uncertain ones. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS 14 or later and an iPod classic or supported iPod nano for normal writing. - **Prerequisites:** Building from source requires Xcode 27 and XcodeGen. - **Limits:** iPod nano third- and fourth-generation editing does not add new artwork until their formats are confirmed; other iPods open read-only by default. - **License:** GPL-3.0 license. ##### Primary sources 1. 2. #### Spark Mail: rehosting the Windows desktop app on Linux with Wine shims > spark-mail-linux rehosts the Windows Spark Mail desktop app on Linux with Wine, two compatibility DLL shims and launcher scripts. The project documents application startup, browser authentication, notifications, clipboard and file-opening behavior, then patches specific DLL imports and bridges those functions to the Linux desktop. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An official Windows Spark.exe installer, Wine, and Arch Linux or an Arch-based system as documented. - **Testing evidence:** The author reports that Spark 3.32.2.141404 starts; mail, calendar, attachment and notification delivery checks remain incomplete for that version. - **License:** MIT licence. ##### Primary sources 1. 2. #### apkscope > apkscope inspects Android application packages through a Rust viewer, CLI, and MCP server. It decompiles DEX classes into Java, searches code and references, reads manifests and resources, scans URLs and secrets including native libraries, and can export or modify packages. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supply an Android application package such as an APK or XAPK. - Apache-2.0 license. ##### Primary sources 1. 2. #### NWBinAnalyzer > NWBinAnalyzer inspects compiled NW.js .bin files by checking their header and walking constant-pool entries. Its Python code extracts UTF-8, null-terminated and length-prefixed strings, then groups findings such as API names, paths, URLs and cryptographic terms. - Type: Tool - Targets: App - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.6+; the author says the tool uses only the standard library. - **Limits:** The author states that it shows constant-pool strings and does not fully decompile V8 bytecode. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### OpenTracks: a UWP port of OpenTracks7 BETA1 > OpenTracks is an early UWP port of the OpenTracks7 BETA1 Windows Phone music app informed by the author's reverse engineering. Its C# and XAML implementation updates page control access and replaces WP7 MediaPlayerLauncher with UWP media playback APIs. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Targets Windows 10 Mobile; the project uses Windows SDK 19041 with minimum SDK 10240. - **Limits:** The author describes the port as pre-beta, with settings storage, playback behavior and background tasks still needing work. - **License:** MIT license. ##### Primary sources 1. #### RTO eChalan: investigating a BankBot Android APK > The RTO eChalan report investigates an Android APK impersonating an Indian government eChallan service through manifest review, JADX decompilation and sandbox analysis. The author reports identifying a BankBot variant, a REQUEST_INSTALL_PACKAGES permission, a BIND_VPN_SERVICE entry and extensive obfuscation that limited decompilation. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The report covers one Android APK named RTO eChalan.apk. - **Limits:** The author reports that approximately 96% of classes failed to load during decompilation. - **License:** CC-BY-4.0 license. ##### Primary sources 1. 2. #### derkt > derkt parses and disassembles Hermes Bytecode files in Racket. It decodes HBC structures and function data, detects the bytecode version and loads a matching generated instruction definition before producing disassembly. The repository includes versioned ISA definitions, parsers and a sample HBC file. - Type: Tool - Targets: Binary - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Racket is required; the CLI accepts an HBC file path. - **License:** MIT. ##### Primary sources 1. #### ODIS file unpacker > ODIS file unpacker extracts protected Java classes from ODIS plugin JARs and files from its DIDB data archives. The author traces AES class decryption and Blowfish ECB data decryption through debugging, a Java agent and decompiled class code; some extracted files also require GZIP decompression. - Type: Tool - Targets: App - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** User-supplied ODIS plugin and DIDB data files. - **Prerequisites:** Python with pycryptodome and blowfish installed. - **License:** No licence file in the repository. ##### Primary sources 1. #### AOL 7.0 Retro Server: reconstructing the P3 server session > AOL 7.0 Retro Server implements local Python servers for the 2001 AOL 7.0 client. It reconstructs the proprietary P3 login and security exchange, the handoff between login and BOS servers, and post-login data used to display the welcome screen and buddy list. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.x and an installed English or German AOL 7.0 client on a VM or older machine are required. - **Limits:** Interactive chat rooms, email simulation and keyword navigation remain on the roadmap. - **License:** No licence file in the repository. ##### Primary sources 1. #### netdumper > netdumper extracts loaded .NET assemblies from Windows processes through the CLR Data Access Component. It enumerates AppDomains and assemblies, recovers JIT method IL, converts memory layouts to PE files, and repairs damaged PE headers or metadata streams for subsequent inspection. - Type: Tool - Targets: Binary - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows, Rust nightly, and the same architecture as the target process are required. - **Limits:** Administrator privileges may be required for some processes. - **License:** MIT License. ##### Primary sources 1. 2. #### SteelSeries Overlay Hook: mapping and hooking the GameOverlay swapchain > SteelSeries Overlay Hook documents IDA analysis of SteelSeriesGameOverlay.dll’s window, object layout and Direct3D 11 swapchain, then uses recovered offsets in a C++ DLL hook. Its injector and hook render Dear ImGui content through the existing GameOverlay window by intercepting Present and ResizeBuffers. - Type: Case study - Targets: App · Binary - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows, Visual Studio 2022 with the v143 C++ toolset, and a Windows 10 SDK are required to build. - **Limits:** The hook relies on fixed internal offsets; compatibility with other SteelSeries versions is not established. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### Sandwitcher > Sandwitcher instruments Java and Kotlin method calls in Android apps by replacing ART method entry points with a trampoline through Pine and LSPlant. Its AAR exposes callbacks before and after the original call to inspect or change arguments and results and inspect thrown exceptions; it also includes a demo application. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Android and the AAR integration are required; building from source needs JDK 17 and Android SDK 35. - **Scope:** The README lists Android 5.0 through 15 compatibility. - **License:** Apache License 2.0. ##### Primary sources 1. #### Zygisk - Frida Gadget > Zygisk - Frida Gadget loads Frida Gadget into selected Android app processes for runtime instrumentation. A configuration file selects packages, process names, ABIs, and profiles; deployment scripts place Gadget and its configuration in the app's native library directory before the Zygisk loader starts it. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Magisk 27001 or Kitsune Magisk with Zygisk enabled is required. - **Prerequisites:** The documented ABIs are arm64-v8a and armeabi-v7a; Gadget files must match the target ABI, and non-default profiles need matching configuration files. - **License:** No licence file is present in the repository. ##### Primary sources 1. #### WeChat: recovering SQLCipher keys through CommonCrypto hooks > An investigation of WeChat 4.1.10 for macOS reports recovering per-database SQLCipher keys by breaking on CommonCrypto encryption calls in LLDB. It compares that approach with memory scanning and sqlite3_key breakpoints, and describes an offline check against a decrypted SQLite page. - Type: Case study - Targets: App · Binary - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** WeChat 4.1.10 on Apple Silicon macOS, with LLDB and access to the user's own app data. - **Testing evidence:** The author reports testing on one machine running macOS 26.5.1. - **License:** No licence file in the repository. ##### Primary sources 1. #### Siriously: recovering macOS Writing Tools entry points > Siriously investigates how macOS 27 changed access to Writing Tools and restores its popover through a Services client. The author used Objective-C runtime introspection and behavioral tracing to identify private WritingToolsUI classes, then passes selected text to the popover and writes accepted results back through Accessibility APIs. The findings concern one macOS build. - Type: Case study - Targets: App · Binary - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Mac with Apple Intelligence and the new Siri enabled is required. - **Prerequisites:** Accessibility permission is required to read selections and write results back. - **Scope:** The author reports operation on macOS 27.0 build 26A5368g on arm64. - **Limits:** Private framework behavior can change with OS updates. - **License:** MIT license. ##### Primary sources 1. 2. #### tuya-mobile: a Python reconstruction of Tuya app signing and API calls > tuya-mobile reconstructs Tuya mobile-app request signing, encrypted API calls and MQTT signaling credential derivation in Python. It replaces the app's native libthing_security.so signing step with HMAC-SHA256, SHA256 and MD5 calculations and includes versioned Smart Life and Tuya Smart profiles. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.9 or newer with aiohttp and cryptography is required. - **Prerequisites:** Authenticated calls require application signing constants and account authentication; password login uses a selected application profile and account credentials. - **Limits:** Interactive captcha, MFA, QR and social logins raise typed exceptions instead of completing login. - **License:** MIT license. ##### Primary sources 1. 2. #### ddg-tenor-bridge: replacing Gboard's Tenor search endpoint > ddg-tenor-bridge redirects Gboard's Tenor GIF searches to a service that returns DuckDuckGo animated-image results in Tenor v2 response form. Its documented workflow changes Gboard's persisted search URL flag while leaving other Tenor features on their original endpoint. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A rooted Android device and an HTTPS endpoint with a publicly trusted certificate are required. - **Limits:** The author calls this a proof of concept; DuckDuckGo's endpoint and Gboard's version-specific flags may change. - **License:** GPL-3.0 license. ##### Primary sources 1. #### MSP CSV Export Format: reconstructing My Stocks Portfolio exports > MSP CSV Export Format reconstructs the undocumented CSV export of the My Stocks Portfolio & Market app. The author compared eleven iOS exports, app displays and public translation strings to describe columns, blocks and transaction replay. A dependency-free Python parser and synthetic export exercise the documented rules and flag malformed input. - Type: Case study - Targets: App - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An MSP CSV export is required for parsing personal data; Python 3.9+ is the documented runtime. - **Limits:** The evidence base is eleven exports from one portfolio; some locale and transaction-order behavior remains unconfirmed. - **License:** Apache-2.0 License. ##### Primary sources 1. #### Benro Polaris Firmware Patcher: rebuilding camera control and mapping the app protocol > Benro Polaris Firmware Patcher investigates the Polaris camera controller and repacks a user-supplied firmware image with a newer libgphoto2 stack and targeted pgphoto changes. Its documentation maps Benro Connect app behavior and the TCP messages used to control the device. The author reports end-to-end testing with a Canon EOS R5 Mark II. - Type: Case study - Targets: App · Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A user-supplied stock FwPkt is required; the author tested firmware 4.0.0.32 with a Canon EOS R5 Mark II. - **Limits:** Optional astronomy features are experimental and have not been tested under real stars. - **License:** MIT license. ##### Primary sources 1. 2. 3. #### Malware Analysis: a trojanized FL Studio installer and Go stealer > This malware-analysis report investigates a trojanized FL Studio installer that bundles an Electron/NSIS wrapper and a Go information stealer. The author traces the wrapper statically and studies the payload in an isolated Windows environment with process, registry and network observations, recovering its reported command-and-control mechanism. - Type: Case study - Targets: App · Binary - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The author used an isolated KVM/QEMU Windows guest and a simulated network for dynamic observations. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### grsimwrite-mac: reconstructing GRSIMWrite for macOS > grsimwrite-mac reconstructs the Windows GRSIMWrite 4.4.10 SIM-writing workflow in Python for macOS. Its research records card-family profiles and APDU write behavior, while the implementation identifies cards, reads elementary files, writes selected fields, and builds formatting sequences. - Type: Case study - Targets: App · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS, a PC/SC card reader, and the pyscard and pydes dependencies are required for card operation. - **Testing evidence:** The author reports 41 offline unit tests using mocks, without hardware. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### dnlib > dnlib is a .NET library for reading and writing modules and assemblies. It provides access to metadata, method bodies, resources, and PDB files. - Type: Tool - Targets: Binary - Category: .NET tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - For .NET Core assemblies, disable GAC loading and add .NET Core reference assembly search paths. - Writing Windows PDB files requires Windows. - Licensed under MIT. ##### Primary sources 1. #### View8 > View8 is a static analysis tool that decompiles serialized V8 bytecode (JSC) files into readable JavaScript-like text. It can also export opcodes, parsed objects, and function trees organized by declarations, calls, or references. - Type: Tool - Targets: Binary - Category: JavaScript and Electron tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python 3.x is required. - Raw JSC input requires a compatible patched V8 disassembler binary; the listed versions are 9.4.146.24, 10.2.154.26, and 11.3.244.8. - Serialized input uses Python pickle and must come from a trusted source. - The repository has no license file. ##### Primary sources 1. #### Soot > Soot is a Java optimization framework for analyzing and transforming Java bytecode. It provides four intermediate representations, including forms suited to optimization, decompilation, and code inspection. - Type: Tool - Targets: App · Binary - Category: JVM bytecode tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a Java runtime and Java classes or bytecode to analyze. - Available as a dependency through Maven, Gradle, or SBT, or as a JAR. - The repository declares the LGPL-2.1 license. ##### Primary sources 1. #### DroidLysis > DroidLysis is a pre-analysis tool for Android apps that disassembles samples, organizes their contents, and flags code patterns for further inspection. It accepts APK, DEX, ODEX, ARM executable, ZIP, RAR, and directory inputs. - Type: Tool - Targets: App · Binary - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python 3 and the listed system packages, including a Java runtime. - Requires Apktool and Baksmali, with their locations set in the configuration file; Dex2jar is optional. - Known third-party SDKs are excluded from analysis by default unless the relevant option is enabled. - The repository declares the MIT license. ##### Primary sources 1. #### VirtualXposed > VirtualXposed is an Android app that runs Xposed modules alongside apps in a virtual environment without root access, an unlocked bootloader, or a custom system image. It is based on VirtualApp and epic. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires an Android 5.0–10.0 device and installation of the VirtualXposed APK. - Apps and Xposed modules must both be installed inside VirtualXposed for modules to take effect. - Modules that modify the system and resource hooks are unsupported; the README prohibits commercial use. - The repository declares the GPL-3.0 license. ##### Primary sources 1. #### EdXposed Framework > EdXposed is a Riru module that provides an Xposed-compatible ART hooking framework for Android 8.0 through 11. It lets Xposed modules change system and app behavior without modifying APKs. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Android 8.0 through 11. - Magisk v21+ and Riru v23+. - EdXposed Manager for the documented installation process. - License: GPL-3.0. ##### Primary sources 1. #### Vector Framework > Vector Framework is a Zygisk module that provides ART hooking for Android apps. It supports Xposed APIs and lets modules change app and system behavior in memory without modifying APK files. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Android 8.1 through Android 17 Beta. - Requires a recent Magisk or KernelSU installation with Zygisk enabled. - Licensed under GPL-3.0. ##### Primary sources 1. #### JustTrustMe > JustTrustMe is an Xposed module that disables SSL certificate checks in Android apps. It can help expose network traffic from apps that use certificate pinning. - Type: Tool - Targets: App - Category: Android tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a rooted Android device. - Requires the Xposed framework to be installed. - Apache-2.0 per License.md. ##### Primary sources 1. ### Native binaries (269) #### DownUnderCTF: masked-squares flag checker > An official educational challenge investigation connects binary checks to equations and records an original-program validation. - Type: Case study - Targets: Binary - Category: Official REA: case studies - Relationship: Official REA case study - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Upstream case: public DownUnderCTF 2023 challenge, REA 4.1.0 and Ghidra 12.1.4 on Linux x64. - **Testing evidence:** Target hash and source revision are documented; author-reported execution. ##### Primary sources 1. #### Show Your Work: a measured dissection of REA's evidence architecture > An unofficial field study that reads REA's source and then drives the running server through 1,012 recorded calls across 27 artifact classes, measuring its content-addressed Evidence records, revision-chained unknown ledger, typed refusals, cold starts and response limits. The author maps those mechanisms onto vulnerability-research agents as an argument for not overclaiming. It evaluates REA's tool surface; it is not a reconstruction or a vulnerability finding. - Type: Case study - Targets: Binary - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-20 - Original resource: - Catalog page: ##### Requirements & limits - Published 2026-10-18 on the author's HackThe4O4 blog under the byline Noflag, who calls it unofficial, not peer-reviewed and unaffiliated with REA's maintainers, and says the official source wins where they disagree. The main study used the published rea-agents 6.5.0 package for 993 of the 1,012 calls; 19 calls comparing two deep providers ran a build of commit fe2a398dd, 286 commits later. - All runs used one Debian-derived Linux VM (4 vCPU, 7.9 GB RAM) with operator-supplied engines, including a headless Ghidra 12.x decompiler, GDB, Rizin, a packet dissector, firmware tools, headless Chromium and Electron; the Android device was a container sharing the host kernel. The decompiler startup deadline was raised to 1,200 s, and macOS-only tools, a GUI-attached disassembler's cursor tools and an unlicensed commercial Java decompiler could not be exercised. - The author reports calling all 207 advertised tools, 178 with at least one success, and 454 Evidence-bearing replies. Oversized replies were refused with a retained-Evidence pointer, but a 10.1 MiB request dropped the connection without a reply. Decompiler cold starts ranged from 14 s to 827 s, and two schema switches cut the default 3.09 MB tool catalog to 215 KB. - Timings come from one lightly loaded VM and are offered as orders of magnitude. The calls came from the author's scripted campaign driver acting as an informed caller, and the article names no analyzed targets. The security-agent mapping is presented as argument, not a built system. Per-call records, campaign files and scripts are described as accompanying the research but are not linked from the page. - This evaluates REA's evidence model and tool surface; no reconstruction, exploit or vulnerability is reported. The page states no license; REA, the third-party engines and the analyzed artifacts keep their own terms. ##### Primary sources 1. 2. 3. #### Windows loader: static malware analysis with REA and Codex > Fedele Mantuano reports using Codex with REA in an offline Docker lab to statically analyze a public Windows malware sample without executing it. The article separates behavior supported by the extracted JavaScript bundle from claims that would depend on remote components that were never obtained, and reclassifies a suspected infostealer as a loader. It is a defensive analysis case built on an author-reviewed agent report, not a reconstruction or a dynamic detonation. - Type: Case study - Targets: Binary - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-27 - Original resource: - Catalog page: ##### Requirements & limits - The Code Geeks article by Fedele Mantuano is dated 2026-10-18, with an Italian version, and reports an analysis performed on 2026-10-17. Codex was asked to use REA on one Windows x64 executable obtained from MalwareBazaar and to write a Markdown report on files, processes, persistence, network destinations, updates, defensive indicators and limits. The agent’s technical report, artifacts and code references are not published; the author offers further details privately. - Analysis ran in a Linux/amd64 Docker Desktop container with REA 6.5.0 and Node 24.22.0, no network, a read-only root filesystem and sample mount, an unprivileged user and dropped capabilities. Neither the sample nor extracted code was executed, and Wine was not used; the author notes that Codex still communicated with its model service while the container was offline. The appendix separately documents a macOS Apple Silicon setup of REA 6.5.0, Ghidra 12.1.4, Temurin JDK 25.0.4.1 and Node.js 24.21.0 connected to Codex over MCP with the REA skill; it was not repeated on a clean Mac or tested on other hosts. - After initial PE inspection, work focused on a JavaScript bundle extracted from the executable’s embedded Bun runtime; the roughly 98 MB native executable was not fully decompiled. The author reports analyst-written decoders for the bundle’s layered string obfuscation, run without evaluating the sample’s code, and spot checks of hashes, the extraction range and decoded tables, partly against an independent Python implementation. These checks support specific findings. - The author reclassifies the suspected infostealer as a loader: its code supports host and screenshot collection, encrypted reporting, download and in-memory loading of further components, and server changes through fixed fallbacks and a remote lookup, with no DGA found in the bundle. Those further components were not obtained, so mining, credential theft, persistence and execution on a victim system remain unestablished, and one reported initialization inconsistency is left for dynamic verification. The article’s threat-intelligence pipeline is a proposed use, not an implemented or measured one. - Handling live malware needs an isolated lab and the analyst’s own authorization. The article credits REA, Ghidra and Codex together and relies on an agent-written report reviewed by the author. The pinned blog repository has no license file; REA, Ghidra, Codex and the model service keep their own terms. ##### Primary sources 1. 2. 3. 4. #### OpenBSD netcat: static REA and Ghidra investigation > A REA/Ghidra report studies the Ubuntu netcat-openbsd 1.234-1 ELF binary and publishes evidence envelopes, decompiled functions and a function inventory. Its output is a static investigation, rather than a rebuilt netcat application. - Type: Case study - Targets: Binary - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Reproducing the documented analysis needs the target package binary, REA, Ghidra 12.1.x and JDK 21; the README records additional pwntools tooling. - **Limits:** The author explicitly reports no target execution or dynamic analysis. Function roles remain inferred, and compiler inlining or hot/cold splitting obscures boundaries. - **Scope:** Upstream netcat.c was consulted for function naming; recovered pseudocode is not an independently reconstructed or behaviorally validated program. - **License:** Analysis and documentation use MIT; upstream BSD attribution is retained in NOTICE. ##### Primary sources 1. #### Ghidra > Open-source analysis suite for disassembly, decompilation, graphs and Java/Python automation across executable formats. - Type: Tool - Targets: Binary · Firmware · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - An official Ghidra release and its required JDK; extension and script compatibility must match the installed release. ##### Primary sources 1. #### radare2 > Scriptable command-line framework for inspecting, disassembling, debugging and modifying binaries across many architectures. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use the release/build for your host; decompilers and other optional functionality may require separate plugins. ##### Primary sources 1. #### Cutter > Rizin-powered graphical reverse-engineering workspace with extensible views and Ghidra decompiler integration. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Desktop builds are available for Linux, macOS and Windows; use plugins compatible with the selected Cutter release. ##### Primary sources 1. #### Qiling > Python emulation framework that adds OS, filesystem and API behavior around CPU emulation for instrumented binary analysis. - Type: Tool - Targets: Binary · Firmware - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A supported Python environment and the target's required root filesystem/libraries; emulation coverage varies by platform. ##### Primary sources 1. #### Unicorn Engine > Multi-architecture CPU emulator for executing selected instruction ranges with register, memory and hook control. - Type: Tool - Targets: Binary · Firmware · Game - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use a supported binding and explicitly supply the CPU state and memory model; it is a CPU emulator rather than a complete OS environment. ##### Primary sources 1. #### angr > Python binary-analysis framework combining control-flow recovery, symbolic execution, data-flow analysis and decompilation. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A compatible Python 3 environment; useful results require an appropriate model of program inputs, state and external functions. ##### Primary sources 1. #### LIEF > Library for structured parsing and modification of executable formats including ELF, PE and Mach-O. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - C++, Python or Rust integration; check the distinction between core and extended features for the selected distribution. ##### Primary sources 1. #### Capstone > Disassembly library with architecture-neutral APIs and instruction details for custom binary-analysis pipelines. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Select a library/binding release supporting the target ISA and mode; the next branch can differ from stable releases. ##### Primary sources 1. #### ImHex > Hex editor with a binary-pattern language, structured data inspection and visual tools for understanding file formats. - Type: Tool - Targets: Binary · Firmware · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Desktop build or web edition; some data sources and features depend on the platform and selected build. ##### Primary sources 1. #### x64dbg > Windows binary debugger with disassembly, memory views and plugins for analyzing programs without source code. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows; choose x32dbg or x64dbg according to the executable's architecture. ##### Primary sources 1. #### GDB > Native and remote debugger for controlling execution and inspecting live or crashed program state. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A GDB build supporting the target architecture and a permitted local process, core dump, simulator or remote debug endpoint. ##### Primary sources 1. #### rr > Records process execution and replays it under GDB, enabling repeatable inspection and reverse execution. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Linux with supported CPU performance counters; VM use depends on counter virtualization and the project's hardware requirements. ##### Primary sources 1. #### Diaphora > IDA-based binary diffing that matches functions and transfers names, comments and types between analyzed versions. - Type: Tool - Targets: Binary · Game - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - IDA with Python 3 support; richer pseudocode and microcode comparisons depend on the corresponding decompiler capabilities. ##### Primary sources 1. #### BinDiff > Compares disassembled binaries to find matching functions and changed code across versions. - Type: Tool - Targets: Binary · Game - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a separate supported disassembler/export pipeline; upstream documents IDA Pro, Binary Ninja and Ghidra configurations. ##### Primary sources 1. #### Detect It Easy > Format-aware file identification and static inspection using parsers, signatures and programmable heuristics. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use the project-linked DIE-engine releases for the host platform; identification results require analyst interpretation. ##### Primary sources 1. #### r2frida > Use radare2 commands and Frida instrumentation together to inspect local or remote process memory, symbols, classes, and runtime calls on desktop and mobile targets. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Install with r2pm or use a plugin build matching the radare2 major/minor ABI; the reviewed README reports CI against radare2 6.2.2 and git master. - Mobile or remote operation needs a reachable Frida target, such as frida-server over USB or TCP. The plugin bundles the host Frida library; separate host frida-tools are not required. ##### Primary sources 1. #### Kaitai Struct > Turn documented binary layouts into reusable parsers for files and network packets. A .ksy specification can be inspected with visualizers and compiled to multiple languages, helping preserve reverse-engineered format knowledge in interoperable implementations. - Type: Tool - Targets: Binary · Firmware · Protocol - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Provide a .ksy specification or adapt an existing format description; Kaitai generates parsers from that description rather than discovering unknown protocol semantics automatically. - The stable 0.11 universal compiler runs on Linux, macOS and Windows with Java 8+; Java 21 LTS is recommended. Generated parsers also need the selected language's Kaitai runtime. - Compiler and visualizer are GPL-3.0-or-later; runtimes have separate licenses, including MIT and Apache-2.0. Compiler licensing does not impose its license on input specifications or generated output. ##### Primary sources 1. 2. 3. 4. #### GoReSym > Recover Go build metadata, function names and address ranges, source file and line tables, embedded types and strings from Go binaries, including stripped and some malformed unpacked samples. JSON output can be imported into IDA Pro with the included IDAPython script. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed release: v3.4.1, published 2026-09-14 and tagged at the reviewed commit, with prebuilt Linux, macOS and Windows archives; source builds need a recent Go toolchain. - Documented support covers ARM64 and Intel x86/x64 Mach-O, ELF and PE binaries in either endianness; pclntab parsing and moduledata location need Go 1.2+, and type parsing Go 1.5+. Some stripped binaries need a manual version override, and type parsing fails if that version is wrong. - MIT. Output is runtime and symbol metadata, not original source or decompiled code. The README's write-up link now redirects to a generic Mandiant page; the article is on the Google Cloud blog. ##### Primary sources 1. 2. 3. 4. 5. #### rev.ng > Open-source decompilation pipeline that lifts x86-64, AArch64, i386, ARM and MIPS code with QEMU, runs LLVM-based analyses and emits C designed to be valid and recompilable. Data layout analysis infers structures from pointer use; an editable YAML model and Python or TypeScript wrappers support automation. Its VSCode-based UI is a separate closed-beta product, with commercial plans announced. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs only on Linux x86-64; the docs suggest WSL on Windows and Docker on macOS, using linux/amd64 on Apple Silicon. The user installer downloads the current master distributable and the repository has no tagged releases, so this entry pins the reviewed develop-branch commit. - Developer setups use the orchestra package manager with binary archives or source builds. Scripting connects to a GraphQL API, locally or over the network; QEMU serves only as a lifter and code is not emulated. - GPL-2.0 as a whole because it depends on GPLv2 components such as QEMU; individual files are MIT-licensed. The rev.ng site describes the decompilation pipeline as Free Software. The UI is in closed beta, with free cloud use planned for public projects and commercial plans for private projects and a fully offline version. - Valid, recompilable C is a stated design goal; inferred types and names need analyst review. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Rizin > Command-line reverse-engineering framework that began as a fork of radare2. The rizin shell analyzes and disassembles binaries, debugs programs and works as a scriptable hex editor, while rz-* tools cover binary-format information, assembly, diffing, hashing, pattern search and FLIRT signatures. The README lists dozens of architectures, bytecode formats and file formats from ELF, PE and Mach-O to dyld caches and BIOS/UEFI images; rzpipe scripts it from Python, Rust, Go and other languages. Cutter is the separate GUI built on it. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.9.1, published 2026-06-29, with a static Linux x86_64 build, a macOS package, Windows installers and static/shared archives, Android arm, aarch64 and x86_64 archives and a source tarball. The reviewed dev branch already declares the unreleased v0.10.0. - Source builds use meson and ninja; meson.build requires meson 0.58.0+, although the README mentions 0.55.0. The README lists Windows 7+, macOS/iOS/iPadOS, GNU/Linux, the BSDs, Android, QNX, Solaris/Illumos, Haiku and GNU/Hurd hosts. rzpipe lives in a separate repository. - meson.build declares LGPL-3.0-only, with COPYING and COPYING.LESSER; the LICENSES directory holds further licenses used by individual files. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Decompiler Explorer > Web service at dogbolt.org that runs one small uploaded executable through many decompilers and shows their C-like output side by side, described as Compiler Explorer in reverse. The pinned source has runners for angr, Binary Ninja, Boomerang, dewolf, Ghidra, Hex-Rays, Kuna, REC Studio, Reko, Relyze, RetDec, rev.ng and Snowman, which helps compare how different decompilers render the same code. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The public service saves every submitted binary and makes it available to the authors of the included decompilers, so do not upload confidential, proprietary or other binaries you may not share. There is intentionally no public automation API; automating comparisons requires terms from the respective license holders. - Self-hosting needs Python 3.8+, pipenv, Docker and docker-compose; scripts/dce.py builds the decompiler images and starts the service. Binary Ninja and Hex-Rays images need the operator's own binaries and license files. The FAQ forbids public instances that include the commercial tools and says private instances depend on each vendor's license terms. - MIT license (Vector 35 Inc.); no tagged releases, so this entry pins the reviewed master commit. As the FAQ notes, decompiler results vary with compiler, settings, language, architecture and complexity. ##### Primary sources 1. 2. 3. 4. 5. 6. #### pwndbg > Python plug-in that loads into GDB, or runs as a REPL around LLDB, to make live program state easier to inspect. Each stop prints a context of registers, stack, call frames and annotated disassembly with recursively dereferenced pointers; commands cover memory maps, search, telescoping, heap allocators and Go values, with Capstone/Unicorn emulation and decompiler integration for IDA, Binary Ninja, Ghidra and angr-management. The README lists Linux ELF, macOS Mach-O, QEMU user/system and embedded Cortex-M or RISC-V/32 debugging. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Compatibility table: pwndbg-gdb needs Python 3.10+ and GDB 12.1+ (tested on Ubuntu 22.04/24.04); pwndbg-lldb needs Python 3.12+ and LLDB 19+, and its support is marked experimental/early-stage; qemu-user needs QEMU 8.1+ (its vFile API is needed for vmmap) and qemu-system QEMU 6.2+. Mach-O debugging on macOS uses LLDB, and qemu-user debugging is GDB only. - Release at review: 2026.09.15, published 2026-09-20, with portable archives, deb/rpm/apk/Arch packages, including macOS portable builds; the setup guide covers Linux and macOS through an install script, Homebrew, Nix, distro packages and source installs. The reviewed dev commit declares the same version. - MIT license. Decompiler integration needs the separately installed decompiler. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### DynamoRIO > Runtime code manipulation system for building dynamic tools that observe or transform any part of an unmodified program while it runs. Its API and IA-32/AMD64/ARM/AArch64 instruction manipulation library allow arbitrary changes to application instructions, not only inserted callouts. The release package bundles tools including drcov for code coverage, drltrace for library-call tracing, drstrace for Windows system calls, drmemtrace instruction and memory traces and the drdisas disassembler. It is a framework for building instrumentation tools, distinct from Frida's scripting of live processes. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README lists Windows, Linux and Android on IA-32, AMD64, ARM and AArch64 hardware; macOS support is in progress. Latest stable release at review: release_11.3.0-1, published 2025-01-11, with Windows, Linux, AArch64 Linux, ARM Linux EABIHF and ARM Android packages. Weekly cronbuild packages follow master (cronbuild-11.91.20741, published 2026-10-17, with no Android package); this entry pins the reviewed master commit. - Custom tools are written against the API, whose documentation ships in the release package and online; API samples cover memory-address, instruction and basic-block tracing and instruction counting. The README names WinAFL, the Arm Instruction Emulator, DrCCTProf, VClinic and GWPSan as external tools built on it and bundles Dr. Memory. - Primarily BSD. The drsyscall, drwrap and drutil extensions and the Dr. Memory Framework libraries are LGPL 2.1, and the drsyms extension links elfutils libraries under LGPL 3. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Decompyle++ (pycdc) > C++ disassembler and decompiler for compiled Python bytecode that aims to support bytecode from any Python version. pycdas prints the disassembly of a .pyc file, and pycdc prints reconstructed Python source to stdout with errors on stderr; both also accept raw marshalled code objects when the Python version is given on the command line. The source carries opcode tables for Python 1.0 through 3.13. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The project publishes no releases or tags, so it is built from source; the reviewed master commit dates from 2026-04-07. The README makes no per-version completeness claim. The .pyc loader recognizes bytecode up to Python 3.13 but not 3.14, and the regression suite’s compiled samples stop at 3.12: 20 of its 191 samples are for 3.10–3.12, and 39 more are kept as expected failures. - CMakeLists.txt requires CMake 3.12+ and a C++11 compiler, and GCC and Clang builds treat warnings as errors. make check runs the tests on Unix-like systems or MSYS; CI builds and tests on Ubuntu and as 32-bit Visual Studio 2022 builds on Windows, where the executables are kept only as workflow artifacts. - Input .pyc files or marshalled code objects come from the user; recovering them from packaged applications is outside the tool. The README describes no verification of decompiled output, so uncertain regions should be compared with the pycdas disassembly. - GPL-3.0. Recovered source remains subject to the rights of the original program’s owner. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### cwe_checker > Static analyzer from Fraunhofer FKIE that searches binary executables, mainly Linux and Unix ELF files, for code paths matching Common Weakness Enumeration bug classes such as buffer overflows, use-after-free and double free, NULL pointer dereferences, format strings and integer overflows. Ghidra disassembles the binary into a common intermediate representation on which its checks run, from simple heuristics to abstract-interpretation data-flow analysis, so it covers the CPU architectures Ghidra supports, including x86, ARM, MIPS and PowerPC. Warnings are printed as text or JSON, and a bundled Ghidra script annotates them in the disassembly for manual review. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest stable release at review: v0.9, published 2024-08-20 as a source release. Prebuilt Docker images on the GitHub container registry are tagged latest (master), stable and v0.9 and are x86 only, although the image can be built natively on ARM. The reviewed master commit is 97 commits after v0.9; CHANGES.md labels it 0.10-dev, with a rewritten P-Code extractor and support for more architectures through a Ghidra update, while the crate manifests still say 0.9.0 and the online documentation covers the stable version. - Local builds need Rust 1.82+ and a Ghidra 10.2+ installation, which make all locates when GHIDRA_PATH is omitted; the Docker image builds on a Ghidra 11.2.1 headless base, and a Nix flake is also provided. Checks are tuned through src/config.json. Analysis of Linux loadable kernel modules, which runs a subset of the checks with its own configuration, and of bare-metal binaries, which needs a per-device configuration such as the bundled STM32F407VG example, is experimental. - Each run takes one binary supplied by the user. The README warns that both false positives and false negatives are to be expected and keeps the CWE-78 OS command injection check disabled on standard runs, so warnings mark code paths for manual review rather than confirmed vulnerabilities. It is also integrated as a plugin in FACT. - LGPL-3.0; the README notice allows version 3 or later. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### FLARE-VM > Mandiant FLARE installer that sets up and maintains a Windows virtual machine for reverse engineering and malware analysis. Its PowerShell script uses Boxstarter and Chocolatey to install packages from the separate VM-Packages feed and the Chocolatey community feed, chosen in a GUI or a custom config.xml that also sets environment paths, the taskbar layout and post-install registry, service and path settings. The reviewed default configuration lists 137 packages, among them Ghidra, IDA Free, x64dbg, dnSpyEx, capa, FLOSS, PE-sieve, FakeNet-NG and Wireshark; scripts in its virtualbox folder build, snapshot and export FLARE-VM and REMnux VMs in VirtualBox. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs a Windows 10 or later virtual machine with PowerShell 5+, at least 60 GB of disk and 2 GB of memory, a username without spaces or special characters and internet access. The README says FLARE-VM should only be installed on a VM and that Windows Updates, Tamper Protection and anti-malware must be disabled on it first; it recommends a snapshot before installation and host-only networking afterward. The installer checks that it is running in a VM and warns on Windows builds other than the tested 19045, 20348 and 26100. - FLARE-VM itself has no releases because its packages download tools from external URLs outside the project's control; the only release, vbox-1.0.0 (2025-08-13), holds Linux executables for some VirtualBox helper scripts, which were tested on Debian 12 with GNOME. Package updates are best effort and untested, failures of individual packages are reported to VM-Packages, and the README suggests a fresh install when updates break. The idapro.vm package needs the user's own IDA Pro installer, and optionally a license file, on the Desktop. - The scripts are Apache-2.0. Per the README's legal notice, every downloaded or installed package keeps its own license terms, which the user must review and accept; installing accepts those terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### B2R2 > Binary analysis framework written in F# for .NET by KAIST's SoftSec Lab. It parses ELF, PE, Mach-O and WebAssembly files, parses, disassembles and lifts instructions into its own IR, recovers control-flow graphs and assembles code; the README's feature table covers x86/x86-64, ARMv7/AArch64, MIPS, PowerPC, RISC-V, SPARC, S390 and other ISAs as well as CIL, EVM, eBPF, WebAssembly and Python bytecode. Its b2r2 launcher starts a readelf-like format scanner, a linear-sweep disassembler, a recursive-descent explorer with a web GUI, an IR and assembly REPL and an assembler. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.10.1, published 2026-06-17, with BinExplore archives for Linux, macOS and Windows on x64 and arm64; libraries such as B2R2.FrontEnd.API and the B2R2.RearEnd.Launcher .NET tool are on NuGet at 0.10.1. The reviewed main commit (2026-10-17) is 1,231 commits ahead of that tag and still declares 0.10.1. - Building needs the .NET 10 SDK or later, and the projects target net10.0. The README states that the core library has no external dependencies, while System.IO.Hashing, FSharp.Compiler.Service, FParsec, BenchmarkDotNet and Avalonia.FuncUI serve specific components; it presents the APIs as usable from F# and, in principle, other CLI languages, on Linux, macOS, Windows and other .NET platforms. - Input is a user-supplied ELF, PE, Mach-O or WebAssembly file, or a raw byte image loaded with an explicit ISA. The README's feature table gives CFG recovery a full mark only for x86, x86-64 and EVM and a half mark for the other ISAs, lists no lifting, CFG recovery or assembly for TMS320C6000, and notes that some areas are still in progress. - MIT license. The README cites the 2019 NDSS Binary Analysis Research workshop paper describing B2R2 and lists research papers that use or build on it. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### rz-ghidra > Rizin plugin that embeds Ghidra's C++ decompiler and Sleigh disassembler, so no Java Ghidra installation is needed. Its pdg commands decompile the current function, optionally side by side with offsets or as XML or JSON, can return the output to Rizin as comments, and list the loaded Sleigh languages; config variables control formatting and can override the auto-detected Sleigh language. The decompiler draws on Rizin's loaded binary, types and comments, and an optional plugin brings it into the Cutter GUI. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.9.0, published 2026-06-21 as a source tarball, which its notes declare compatible with the Rizin v0.9.x series and which updates the Ghidra code it uses to 12.1. The reviewed dev commit, from 2026-10-12, tracks Rizin's dev branch and is 3 commits ahead of and 5 behind that release tag. The README says version numbers do not guarantee Rizin compatibility and points distributors to rz-* tags instead. - Builds with CMake against an installed Rizin after fetching the rizinorg/ghidra and pugixml submodules. The install step is required because it installs the Sleigh files; the rz-pm package sets them up automatically. The Cutter plugin needs Cutter installed from source and -DBUILD_CUTTER_PLUGIN=ON. CI builds on Debian Bullseye, Arch Linux and Windows. - Decompilation works on binaries loaded and analyzed in Rizin, for architectures whose Sleigh specifications are installed; output is Ghidra decompiler output and needs analyst review. - LGPL-3.0-or-later, which the README notes is stricter than Ghidra's own license; the decompiler sources come from the separate rizinorg/ghidra fork. Its test binaries are built from C sources in the repository. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### dewolf > Research decompiler from Fraunhofer FKIE, developed with Singapore's DSO National Laboratories between 2019 and 2021, that runs as a Binary Ninja plugin and starts from Binary Ninja's Medium Level IL. A pipeline of preprocessing, SSA, data-flow and control-flow stages restructures code following the DREAM/DREAM++ approach and emits C-like output. Results appear in a Binary Ninja dock widget, or decompile.py prints or writes them for a whole binary or one named function in batch use. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v2026.7.11, published 2026-07-11 by the project's automatic release workflow; the reviewed main commit is that release, and plugin.json declares the same version and lists Windows, Linux and macOS. - Needs Python 3.10+, a separately licensed Binary Ninja (the README asks for the latest stable release, at least 3.4; plugin.json sets minimum build 4271) with its Python API installed in the same environment, and astyle for indentation; libgraph-easy-perl is needed only for ASCII graph output. The plugin is installed by cloning it into Binary Ninja's plugin folder and installing requirements.txt, which pulls the project's dewolf-logic and dewolf-idioms packages from Git. - Settings made in the Binary Ninja GUI do not apply to decompile.py, which reads a config.json in the plugin folder instead; decompiler/util/default.json lists every option. - The README calls dewolf a research prototype that is not optimized for production use and warns of bugs or decompilation failures on real-world binaries. Its tests compile C sample sources and keep GNU coreutils executables under tests/coreutils/binaries as fixtures; CI builds a Docker image around a Binary Ninja archive and license supplied from repository secrets. - LGPL-2.1 (the plugin.json notice allows any later version). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### decomp2dbg > Decompiler-to-debugger bridge that serves function names, global variables, stack and register variable names and decompiled code from IDA Pro, Binary Ninja, Ghidra or angr-management to GDB over an XML-RPC connection. Synced functions and globals become ordinary GDB symbols for breakpoints and memory examination, local variables appear as convenience variables, and each breakpoint stop prints the decompiled line for the current address. It works with vanilla GDB, GEF and pwndbg, and can map a shared library's symbols once its load range is supplied. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v4.0.3, published 2026-07-14 on GitHub and PyPI; the reviewed main commit is that version bump. Package metadata requires Python 3.10+, and the README says decomp2dbg must be installed in the same Python environment as the decompiler and the debugger. The bundled installer places the decompiler plugin and sources the GDB client from the user's .gdbinit, after GEF or pwndbg are loaded; a Windows decompiler outside WSL needs the README's manual steps. - The README lists IDA Pro 9.0+, Binary Ninja 2.4+, Ghidra 12+ (started in PyGhidra mode with the plugin enabled) and angr-management 9.0+, each installed separately; decompiler access goes through the declib library. Only GDB-based debuggers are supported: LLDB and WinDbg support, struct syncing, function-type syncing and online DWARF creation are listed as unfinished. - The decompiler side starts an XML-RPC server on localhost:3662 by default; debugging from another machine or VM needs the host and port at connect time and the port reachable. One decompiler can be connected at a time, and a shared library's symbols need its base and end addresses supplied manually. - tests.py holds integration tests that drive headless Ghidra, or IDA through idalib, with GDB; CI runs only the Ghidra suites against Ghidra 12.0. The testing/binaries directory keeps sample executables, including an Ubuntu objdump build, as test fixtures. BSD-2-Clause license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### E9Patch > Static binary rewriter for x86-64 Linux ELF executables and shared objects that inserts instrumentation without control-flow recovery and writes a drop-in replacement binary, following the PLDI 2020 paper Binary Rewriting without Control Flow Recovery. The e9tool front end selects instructions with a matching language over disassembly attributes and patches them with built-in trampolines, calls into C or C++ functions compiled with e9compile.sh, or hand-written plugin trampolines; the e9patch back end accepts JSON-RPC commands so other tools can drive it. Optional modes add heuristic control-flow recovery for faster rewritten binaries or SIGILL-based fallbacks for full patch coverage. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.0.1, published 2026-06-22, with an amd64 Debian package; earlier 1.0.0 release candidates ran through rc10 (2025-04-16) before v1.0.0 on 2026-03-01. The reviewed master commit (2026-06-28) is one commit ahead of v1.0.1, fixing undefined behavior on empty trampoline template entries, and its VERSION file reads 1.0.1. - build.sh builds e9patch and e9tool after checking for gcc, g++, make, binutils, xxd, markdown and zlib headers, and suggests Debian/Ubuntu package names; Zydis and libdw are vendored under contrib. Patch functions are compiled with e9compile.sh using gcc and freestanding flags. The README targets x86_64 Linux; the source also contains PE handling and a Windows example that calls itself a proof of concept, which the guides do not document. - Input is the user's own ELF executable or shared object, and output is written to a.out or a.so by default. The guide notes that the built-in linear disassembler can mishandle binaries that mix code and data and accepts --use-disasm and --use-targets CSV files from other analyzers. The CFR mode is heuristic and less robust, and in the -100 mode a rewritten program's own attempts to install a SIGILL handler fail with ENOSYS. - GPL-3.0, with specific files such as examples/stdlib.c under MIT as stated in their preambles. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Rellic > Trail of Bits implementation of the pattern-independent structuring algorithm from the No More Gotos paper, turning LLVM bitcode into goto-free C as a small, hackable decompiler back end that interoperates with LLVM and Remill. rellic-decomp translates a bitcode module to C in batch, rellic-xref serves a web interface for choosing refinement passes and linking C AST nodes to the bitcode that produced them, and rellic-headergen emits C layouts of data structures from a module's DWARF metadata. Machine code must first be lifted to bitcode by another tool; a bundled IDA script uses Anvill for that step. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.2.3, published 2023-04-04, with LLVM 15 builds: deb and tgz packages for Ubuntu 20.04 and a tgz package for macOS 11. The reviewed master commit (2025-11-03) is 13 commits ahead and comments out the AnghaBench CI cron jobs; the code commits before it date from April 2024. - The README supports Linux, tested on Ubuntu 22.04, and also documents a macOS build. Building needs CMake 3.21+, LLVM and Clang 16, Z3 4.7.1+, gflags and glog, most of which come from Trail of Bits' prebuilt cxx-common packages; scripts/build.sh downloads the rest and produces a deb package. Docker images on Docker Hub and the GitHub Package Registry are parameterized by Ubuntu and LLVM version. - Input is an LLVM bitcode module built with the same LLVM version as the decompiler. C sources can be compiled with clang -emit-llvm, but executables need a separate lifter such as Remill or Anvill. The README's examples show output whose control flow and variable types differ from the original source, and its AnghaBench 1,000-program test only checks that bitcode translates to C, not the readability or behavior of the result. - Apache-2.0 license. The roundtrip tests compile C to IR and back and check that the result builds and behaves roughly like the original. By default rellic-xref listens on all addresses, on port 80. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### ghidra-delinker-extension > Ghidra extension that delinks a selected part of a program back into a relocatable object file. Its relocation table synthesizer analyzer reconstructs, from the Ghidra database, the relocations a linker normally discards, and its exporters write COFF (x86, x86-64), ELF (x86, x86-64, MIPS) or OMF (x86) objects with symbols and relocation tables that a toolchain can link again. The README lists binary patching through the linker, software ports, format conversion, library extraction and decompilation projects that reimplement a program one object file at a time among its uses. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.9.2, published 2026-09-26 at the reviewed commit, with separate extension archives for Ghidra 12.0.4, 12.1, 12.1.2, 12.1.3 and 12.1.4; use the archive built for the installed Ghidra release. CI builds with JDK 21. - Source builds need GHIDRA_INSTALL_DIR and Gradle. Dependencies come from GitHub's Maven registry, which requires a token with read:packages, or from vendored submodules through gradle installStandaloneDeps. After installation, RelocationTableSynthesizedPlugin is enabled from Ghidra's Experimental plugin list; a bundled DelinkProgram script covers headless use. - Input is a program already loaded and analyzed in Ghidra. The README warns that synthesized relocations depend on the accuracy of the Ghidra database, so incorrect or missing information can break or miss relocations, and advises rerunning the analyzer right before each export. Only the listed format and architecture combinations are supported. - Apache-2.0. The test references are built from C sources in the repository. The README's examples link the author's blog series, including one on decompiling the PlayStation game Tenchu: Stealth Assassins. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### BinExport > The exporter component of BinDiff: plugins for IDA Pro and Binary Ninja and an extension for Ghidra that write an analyzed disassembly to the Protocol Buffer format BinDiff requires. The BinExport2 schema covers instructions with their operands and expressions, basic blocks, flow graphs, the call graph, sections, strings, comments and data references; the exporter can also write a statistics text file or a text dump for debugging. Exports can be scripted through IDC or IDAPython in IDA and through a BinExport.java script that also runs in Ghidra's headless analyzer. - Type: Tool - Targets: Binary - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v12-20240417-ghidra_11.0.3, published 2024-04-17, with Linux, macOS and Windows plugin archives and a Ghidra 11.0.3 extension; the release notes say its artifacts are not code-signed. The reviewed main commit is 111 commits ahead of that release, and its README requires IDA Pro 9.4 or later and drops the 8.x series, so the current README describes plugins that no release yet provides. - Requires a separately licensed IDA Pro or Binary Ninja installation, or Ghidra; Binary Ninja integration is minimal and the Ghidra extension is described as experimental. Users supply their own binaries and analysis databases, and BinDiff itself is a separate tool. - Native builds need CMake 3.20+, Boost 1.83+ (a partial copy is bundled), GCC 15 or recent Clang on Linux and macOS or Visual Studio 2022 with the Windows 11 SDK, and download Abseil, GoogleTest, Protocol Buffers and the IDA and Binary Ninja SDKs; Debian 11 is the preferred Linux build environment. The Ghidra extension builds with OpenJDK 21+, Gradle 8.7+ and Ghidra 11.0.3. - Apache-2.0. The README states that it is not an official Google product. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Karta > Source-code-assisted IDA Python plugin from Check Point Research that finds and matches open-source libraries compiled into large binaries and firmware. Its identifier script reports which supported libraries, such as OpenSSL, zlib, libpng and net-snmp, are present and fingerprints their versions; the matcher then uses a JSON configuration built from that library version to locate its compiled files by their original function order, match their functions and the external libc functions they call, and export selected matches as IDA names. The bundled Thumbs Up scripts improve IDA's function analysis beforehand, including ARM/Thumb separation in firmware. - Type: Tool - Targets: Binary · Firmware - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.1.0, published 2021-05-18; the reviewed master commit, from 2022-03-15, adds only README and CI workflow changes. The README says the original author can no longer maintain the repository after leaving Check Point Research, citing the IDA Pro versions and regression-test requirements involved. - Requires IDA Pro 7.4 or newer with Python 3; v1.2.0 is the last release for Python 2 and older IDA versions. setup.py installs dependencies including elementals, sark, click and scikit-learn, while requirements.txt still names the old sklearn package. The scripts are loaded through IDA's script-file menu rather than installed as plugins. IDA is the only implemented disassembler backend, although the docs describe an interface for adding others. - Run the scripts on a binary that IDA has already analyzed well, and select the Windows option for Windows-compiled binaries. Matching needs a configuration for the exact library version: the repository ships configurations for OpenSSL 1.0.1j, libpng 1.2.29, libtiff 4.0.8 and zlib 1.2.3 and 1.2.11, and others are generated with karta_analyze_src.py, which also drives IDA, from the static library and object files of a library you compile yourself, following the notes in compilations/. Upstream advises backing up the binary before Thumbs Up, which makes major changes to its analysis. - MIT license. The identifier covers 15 library modules, including the closed-source Treck library, which is detected only. Matches are heuristic proposals whose matching rules differ in accuracy and are shown in different colors, so they need analyst review. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### VTIL-Core > C++20 core of the VTIL (Virtual-machine Translation Intermediate Language) project, an intermediate language and optimizing compiler that the README describes as built for binary de-obfuscation and de-virtualization. Unlike LLVM IR, VTIL keeps the native stack, physical registers and non-SSA form, so code from register or stack machines can be lifted into it, native instructions can stay inline, and code can be emitted back at any virtual address. The library provides the IL with routines, basic blocks and serialization, a symbolic expression engine and simplifier, optimizer passes such as dead-code elimination, propagation and stack pinning, and Capstone/Keystone-based AMD64 and ARM64 disassembly and assembly helpers. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags; the README says the repository is incomplete because the initial release is not done, and further documentation is still to come. The reviewed master commit (2026-07-27) only edits the README; the preceding code commits date from 2026-04-04 and 2026-04-05. - Build with CMake 3.16+ and a C++20 compiler: generate a Visual Studio solution on Windows, or use Ninja on Linux and macOS, where Apple Silicon builds need -DCMAKE_OSX_ARCHITECTURES=x86_64. CMake fetches Capstone and Keystone at pinned commits, and CI builds on Windows Server 2022, Ubuntu 24.04 and macOS 14. - This is a library for analyzing virtualized or obfuscated code: the user supplies a lifter that translates the code under analysis into VTIL routines, which can then be optimized, inspected or re-emitted. The reviewed tree contains no lifter for a particular virtual machine or protector. Its Sample Routines folder holds 2020 .vtil test routines next to the small C test functions they correspond to, which commit messages describe as VMProtect tests. - BSD-3-Clause license. The fetched dependencies keep their own licenses: Capstone's BSD-style license, and Keystone's GPL-2.0 with a FOSS license exception, which matters when distributing builds. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Frida Workbench for VSCode > Unofficial Visual Studio Code extension for Frida work. A sidebar lists apps and processes on local, Apple Simulator, USB and remote devices to attach, spawn or kill, and runtime panels browse an attached process's native modules and exports and its Java and Objective-C classes, methods and protocols; selected items generate Interceptor, Objective-C or Java hook scaffolds, optionally with GitHub Copilot-inferred native signatures, and Objective-C headers or Java class stubs can be dumped. A language server completes class, selector and module names from a live target, and the extension also scaffolds Frida agent and C-module projects, script-debugging configurations, syslog streaming and Android frida-server setup. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.12.11, published 2026-09-29 as a .vsix package, whose tag is the reviewed main commit; package.json requires VS Code 1.94+. The extension is also listed on the Visual Studio Marketplace under the CodeColorist publisher. CHANGELOG.md's newest entry is v0.12.8, so later releases are not described there. - Needs Python 3.7+ with the frida-tools package; because of PEP 668 the README recommends the workspace's active virtual environment, or pipx or uv. Targets need a working Frida setup: on Android the extension can download and start frida-server, iOS USB access from Windows needs iTunes kept open, libimobiledevice is optional for SSH shells, and iOS shells require a jailbroken device. - The language server attaches to the live target named in .vscode/frida.json, which needs a device and exactly one of app, pid or process. Copilot-assisted hook generation depends on GitHub Copilot, and Objection is an optional external tool. Users supply their own devices, apps and processes. - A community project, not affiliated with the Frida team; MIT-licensed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### ghidriff > Command-line binary diffing engine that drives Ghidra headlessly through pyghidra: it imports and analyzes an old and a new binary, then reports added, deleted and modified functions, with patch diffing as its main use. The default VersionTrackingDiff engine combines several Ghidra Version Tracking correlators with BSim matching, alongside simpler symbol-name and structural-graph engines and a GhidraDiffEngine base class for custom differs. Results are written as JSON and Markdown with Mermaid charts and meta diffs of strings, called and calling functions and binary metadata, plus optional side-by-side HTML. - Type: Tool - Targets: Binary · Firmware - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.0.0, published 2025-07-04 on GitHub and PyPI, which requires Python 3.9+ and pyghidra 2.0+. The reviewed main commit, merged 2026-05-11, is six commits ahead and still reports version 1.0.0: it requires Python 3.10+ and pyghidra 3.x, targets Ghidra 12.0.4 and logs a warning when another Ghidra or pyghidra version is running. setup.cfg classifies the package as Alpha. - Install Ghidra with a JDK supported by that release, set GHIDRA_INSTALL_DIR and install the package with pip or uvx; the README covers Windows, Linux and macOS, and its x64/arm64 Docker image ships the PyPI release so Ghidra and Java need not be installed on the host. Large binaries may need a larger JVM memory share. - Supply two or more versions of the same binary, ordered oldest to newest, with an optional summary across several new versions; anything Ghidra can import and analyze can be compared, with a custom base address for firmware or bootloader images, analyzer options and GDT type archives. The supported-platforms page says native code works best, managed .NET results are mixed and native libraries must be taken out of an APK first. A preflight check stops the diff when the two programs' processor languages differ or their symbol counts differ by 4,000 or more, unless --force-diff is given. By default Ghidra's well-known PDB symbol servers are configured with a local symbol store unless --no-symbols is set. - GPL-3.0. Matching quality depends on Ghidra's analysis and decompilation. The README's use cases and the documentation site's sample diffs cover Windows and macOS system binaries obtained separately; the repository ships no target binaries. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Ddisasm > GrammaTech's Datalog disassembler, which turns ELF and PE binaries for x86-32, x86-64, ARM32, ARM64 and MIPS32 into the GTIRB intermediate representation. It decodes a superset of possible instructions, then applies Soufflé Datalog rules and weighted heuristics to infer code locations, symbolization and function boundaries; gtirb-pprinter turns the result into reassemblable assembly or a rebuilt binary, and the GTIRB APIs or gtirb-rewriting can modify it in between. User hint files add Datalog facts or change heuristic weights where inference goes wrong. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest GitHub release at review: v1.8.0, published 2023-12-14 without attached files. Later versions are distributed elsewhere: PyPI lists ddisasm 1.9.5, uploaded 2026-07-06 as a single manylinux x86_64 wheel. The reviewed main commit, from 2026-10-13, declares version 1.9.6, which its changelog marks unreleased. - Prebuilt options are the grammatech/ddisasm Docker image (stable or unstable tags), Ubuntu 20 (focal) apt packages and Windows .zip builds on GrammaTech's servers; the docs warn against mixing stable and unstable tools. Source builds need a C++17 compiler, GTIRB 1.12.1+, gtirb-pprinter 2.0.0+, Capstone 5.0.1+ (GrammaTech tests with its fork), Soufflé 2.4 built with 64-bit numbers, libehp 1.0.0+ and LIEF 0.13.2+. - Input is an ELF or PE binary; rebuilding through gtirb-pprinter invokes a compiler or assembler such as gcc. Code inference and symbolization are heuristic: --self-diagnose checks symbolization only for binaries linked with complete relocation information, and the docs call the option that replaces CFI directives with .eh_frame symbolic expressions experimental and unreliable. - AGPL-3.0; contributions require GrammaTech's contributor license agreement. GTIRB, gtirb-pprinter and gtirb-rewriting are separate projects. The README cites a USENIX Security 2020 paper and an IEEE S&P 2025 paper on the approach. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### PINCE > Linux front end for the GNU Debugger (GDB), focused on games but usable for other reverse engineering; the name stands for “PINCE is not Cheat Engine”. It scans process memory and pointers through libmemscan into a typed address table, and its memory view adds disassembly, an on-the-fly assembler, code dissection for referenced calls, jumps and strings, function, region and instruction searches, and structure overlays, including structures generated from Mono/IL2CPP class dissection of native Linux or Wine/Proton processes. Debugging covers chained breakpoints and watchpoints, tracking of the instructions that access an address, tracing and stack traces, alongside a GDB console and the reusable libpince Python library. - Type: Tool - Targets: Binary · Game - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Linux only. Latest release at review: v0.10.2, published 2026-09-18, whose tag is the reviewed master commit; it ships an x86_64 AppImage that the README supports on distributions as new as Ubuntu 22.04 or newer. - Local development installs run install.sh with APT, Pacman or DNF and need Python 3.11+, PyQt 6.11+ and GDB; Kubuntu 22.04+ and Arch Linux are officially supported, while Debian 12+, Fedora 35+ and openSUSE are only partially supported and not actively tested. The PINCE.sh launcher runs PINCE as root, elevating through pkexec or sudo. - Users select a running process of their own to inspect. The README states that users are responsible for their actions and asks that only this GitHub repository be trusted as a source of PINCE code or packages. - GPL-3.0-or-later (COPYING); AUTHORS lists the bundled Silk icons in media/icons under CC BY 3.0 (COPYING.CC-BY). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### uncompyle6 > Cross-version decompiler that translates Python bytecode back into equivalent Python source, accepting bytecode from Python 1.0 through 3.8 as well as some PyPy bytecode and Dropbox's Python 2.5. It disassembles code objects with the companion xdis library and parses the instruction stream into a grammar-based tree from which source is printed; it can also deparse just the fragment around a given bytecode offset, which the author's trepan debuggers use for exact location reporting. It succeeds the older decompyle, uncompyle and uncompyle2 forks. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 3.9.3, published 2025-09-29 on GitHub and PyPI; the reviewed master commit is 34 commits later and reports 3.9.4.dev0. Installing from PyPI, like the master branch, is meant for running on Python 3.11+; older interpreters back to Python 2.4 use the version-specific tarballs, eggs or wheels on GitHub Releases, built from separate git branches. It depends on xdis 6.3+, spark-parser and click. - The README reports testing on bytecode from Python 1.4, 2.1–2.7 and 3.0–3.8 and later PyPy versions. Python 3 support is strongest around 3.3–3.4 and weakens further away, control flow is the biggest known problem, and the author does not intend serious work on 3.8 or 3.9, pointing to the separate decompyle3 for 3.7 and 3.8. Bytecode newer than 3.8 is not decompiled, and candidate-release magic numbers, some Python 3.6 magic variants, encrypted or custom-interpreter bytecode other than Dropbox's old 2.5, obfuscated code, Cython and MicroPython are not handled. - Input .pyc or .pyo files come from the user; it cannot decompile Py2EXE executables directly, and bytecode bundled by such packagers has to be extracted first. The --syntax-verify option checks only that the output is valid Python syntax, so the README suggests cross-checking with other uncompyle6 versions or other decompilers such as pycdc. Recovered source remains subject to the rights of the original program’s owner. - GPL-3.0-or-later per pyproject.toml, with the GPL-3.0 text in COPYING. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### ret-sync > Reverse-Engineering Tools SYNChronization: plugins that keep IDA, Ghidra or Binary Ninja graph and decompiler views following a live WinDbg, GDB, LLDB, OllyDbg 1.10/2 or x64dbg session, rebasing addresses on the fly so ASLR does not break the mapping. Debugger commands push comments, labels, rebased addresses and command output into the disassembler database and resolve symbols from it, while disassembler hotkeys set breakpoints and step the debugger; several databases can be synced at once and the two sides may run on different hosts. A standalone Python library offers the same position syncing to custom tracing tools. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No release tracks the reviewed master commit (2026-02-15): the only GitHub release is a 2022 Binary Ninja community build, prebuilt WinDbg, OllyDbg, OllyDbg2 and x64dbg plugins come from an Azure DevOps pipeline, and ext_ghidra/dist holds per-version Ghidra extension archives, the newest for Ghidra 11.4.2. Each Ghidra archive supports only the Ghidra version in its file name; other versions are built with Gradle against a local installation. - The IDA plugin requires IDA 9.2+, with older IDA versions served by history before the ida9.2 tag; the Binary Ninja plugin needs Binary Ninja 2.2+ with Python 3 and is marked experimental; the WinDbg extension is built from a Visual Studio solution, reported working with Visual Studio 2017 and 2026; the IDA and GDB plugins need Python 2.7+ or Python 3. IDA, Binary Ninja and WinDbg are obtained separately, and users supply their own binaries and debugging targets. - The README states there is no authentication or encryption between debugger and disassembler and that self-modifying code is out of scope; its tested-versions list is older (Python 2.7/3.7, IDA 7.7, Ghidra 10.1.1, Binary Ninja 3.0, GDB 8.1, LLDB 310.2.37), and it notes GDB signal issues with multi-threaded debugging and a possible WinDbg race condition. Remote and renamed-module setups are configured through an optional .sync INI file. - GPL-3.0-or-later; the Binary Ninja plugin is MIT-licensed. ret-sync is a fork of Quarkslab's qb-sync. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### PyInstaller Extractor (pyinstxtractor) > Single-file Python script that extracts the contents of executables built with PyInstaller, including Linux ELF builds without other tools. It locates the PyInstaller archive in the executable, reports the PyInstaller and Python versions and likely entry-point scripts, and writes out the bundled CArchive files and the modules in the PYZ archive. It fixes the headers of the extracted .pyc files so that Python bytecode decompilers such as uncompyle6 and Decompyle++ (pycdc) recognize them. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs under Python 2.x or 3.x and needs no PyInstaller installation. Latest release at review: 2026.07, published 2026-07-22 without attached files; it tags the reviewed master commit, whose script header still calls itself version 2.0. The README lists PyInstaller 2.0 through 6.19.0 as tested against a separate test-binary repository and supported. - Modules in the PYZ archive are extracted only when the script runs under the same Python major and minor version that built the executable; otherwise it warns and skips them, and an archive whose table of contents fails to unmarshal is skipped too. Entries that cannot be decompressed, such as those of encrypted PYZ archives, are saved unchanged with an .encrypted suffix rather than decoded. - The PyInstaller executable comes from the user, and turning the recovered bytecode into source needs a separate decompiler. Recovered code remains subject to the rights of the original program’s owner. - GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. #### Binary Analysis Platform (BAP) > OCaml binary analysis platform from Carnegie Mellon University. Its bap command loads a program, disassembles it, lifts instructions into an architecture-neutral intermediate representation, builds the control-flow graph and runs analysis passes, while objdump, raw-loader and mc modes handle linear disassembly, raw code blobs and single encodings. The README lists x86, x86-64, ARM, MIPS and PowerPC support, an interpreter, a microexecution interpreter, a symbolic executor and the Primus Lisp language for analyses, function stubs and SMT-solver queries; analyses are written as OCaml plugins or by embedding BAP as a library, with C bindings and minimal Python support in separate repositories. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest stable release at review: v2.5.0, published 2022-07-11, with x86_64 Debian and RPM packages, tgz archives and sigs.zip/sigs.tar.gz signature archives; a v2.6.0-alpha development build dates from 2023-01-07. The reviewed master commit (2026-05-07) is 60 commits ahead of v2.5.0 and its opam packages carry version dev; the commit before it dates from April 2025. - The binary packages omit the OCaml development environment, so writing analyses needs a source install. The README recommends opam with OCaml 4.14.1 (opam install bap), offers a rolling testing opam repository that follows master, and also documents dune builds from a clone; the opam dependencies keep core_kernel and base below v0.16. The LLVM backend needs llvm-config (conf-bap-llvm 1.8+). The Ghidra and radare2 integrations, which the README calls experimental, and the Z3-based symbolic executor come with the bap-extra meta-package; IDA Pro integration is a separate package. - Input is a user-supplied executable, or a raw code blob opened with --loader=raw and a base address. The tree also has RISC-V, SystemZ and Thumb packages beyond the README's architecture list. Lifted output depends on per-architecture semantics coverage; the 2.5.0 changelog adds a --print-missing option to list unlifted instructions. - MIT license; contributions to the repository are accepted under MIT, while separately hosted plugins may use any license, including a proprietary one. The README names ForAllSecure Mayhem, Draper's CBAT tools and Fraunhofer FKIE's CWE Checker as projects built on BAP. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Reko > General-purpose decompiler that loads executables or raw images, scans their machine code into a machine-independent register transfer language, groups it into procedures and decompiles them into high-level C code. The reviewed source has 64 architecture directories, from 6502, Z80 and PDP-11 to ARM, MIPS, PowerPC, RISC-V and x86, and loaders for formats including ELF, PE/MZ, Mach-O, COFF, Amiga Hunk, VMS, WebAssembly, Xbox XBE and Xbox 360 XEX. It runs as a Windows Forms GUI, a command-line client or a .NET library, and project files and scripts let users add names, types and comments. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 0.12.5, published 2026-09-29, with x86 and x64 Windows MSI installers and command-line and GUI zip builds; the Reko.Decompiler.Runtime NuGet package is also at 0.12.5. The reviewed master commit, from 2026-10-14, is ten commits ahead of that release. - Requires .NET 9.0. Source builds use the .NET 9.0 SDK, or Visual Studio 2026 for IDE users, plus CMake for the NativeProxy project; the WiX toolset is needed only for MSI installers. CI builds on Ubuntu, Windows and macOS. The cross-platform Avalonia GUI is still under development, and the user guide's non-Windows instructions still mention AppVeyor builds and Mono. - Input is a binary the user has the right to decompile; the README warns that many software licenses prohibit decompilation. Raw images need the loader, architecture, base and entry addresses given explicitly. The user guide says useful decompilation usually needs the user to supply types, names and comments, and that a heuristic scan may be needed when indirect jumps or calls hide code. - GPL-2.0 (COPYING). The complete architecture and format list is on the project wiki. The repository's subjects directory holds regression samples collected from other sources together with Reko's output for them; it is test data, not part of the tool. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Dyninst > Binary instrumentation, analysis and modification libraries from the Paradyn project. DyninstAPI inserts and changes instrumentation in a running program, or rewrites an executable or library on disk and writes the patched copy back, through one machine-independent interface that also supports static and dynamic analysis. Separately documented components handle symbol tables, line numbers and types (SymtabAPI), instruction decoding and disassembly (InstructionAPI), parsing into blocks, functions and loops (ParseAPI), dataflow analyses such as slicing (DataFlowAPI), process control, stack walking and patching. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The CMake platform check accepts Linux, FreeBSD and Windows hosts on x86-64, 32-bit x86, AArch64, ppc64le and riscv64, plus AMD GPU code-generation targets; InstructionAPI documents x86, x86-64, ARMv8-64 and 32/64-bit PowerPC decoding. The README calls AArch64 dynamic instrumentation experimental and incomplete, and its known issues include no Windows 64-bit or Windows rewriter mode, uncaught exceptions in relocated code, a fragile Windows stack walker and a crash when parsing a binary with no functions. - Latest release at review: v13.0.0, published 2024-03-21. The reviewed master commit still declares version 13.0.0 and is 590 commits ahead of that tag; the README says the bundled v13.0.0 PDF manuals are a snapshot, so current behavior needs manuals built from source with pdflatex. - Install with Spack or build from source with CMake 3.14+ (3.19.0 is rejected), a C11/C++11 toolchain (GCC 6+), Boost 1.71+, TBB 2019.9+ and, on Unix, elfutils 0.186+; Docker containers for development are described in the docker directory. Users supply their own executables, libraries or running processes to analyze or instrument. - LGPL-2.1 (LICENSE.md). COPYRIGHT credits Barton P. Miller with contributions from LLNS, Red Hat and Bull SAS, and DataFlowAPI incorporates Rose Compiler Project code under its own copyright notice. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### goblin > Rust crate for zero-copy, endian-aware parsing of ELF32/64, 32/64-bit Mach-O and multi-architecture fat containers, PE32/PE32+, COFF objects, Terse Executable (TE) images and Unix/BSD archives; Object::parse picks the format from its magic bytes. Parsed structures cover ELF headers, sections, symbols, dynamic entries, relocations and notes, Mach-O load commands, imports and exports, and PE imports, exports, relocations, TLS, resources, exception and unwind data, Authenticode certificates and the .NET CLR header. Feature flags can reduce it to std-free #[repr(C)] struct definitions for kernels and other no_std code. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest tag at review: 0.10.6 (also tagged v0.10.6) on the 2026-05-25 version-bump commit; the project publishes no GitHub releases. crates.io also lists 0.10.7, published 2026-05-28, which has no matching tag or changelog entry. The reviewed master commit (2026-08-30) still declares 0.10.6. - Used as a Cargo dependency; it needs rustc 1.85.0+ (Rust 2024 edition) and depends on plain, scroll and an optional log. Default features enable every format with std; elf32/elf64, mach32/mach64, pe32/pe64, te and archive select backends, endian_fd parses by the binary's own byte order, and Mach-O, PE and TE parsing requires alloc and endian_fd. - Input is a byte slice holding an executable, object file or archive the user supplies. goblin parses format metadata only and includes no disassembler, so code needs a separate instruction decoder. PE parse options can skip RVA resolution, attribute certificates, TLS data, resources or imports, and the changelog describes an ELF and PE permissive mode for packed, broken or malware samples. - MIT license. The README quotes a report of 100 million fuzzing runs, and the repository holds cargo-fuzz and AFL harnesses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### FLOSS (FLARE Obfuscated String Solver) > Mandiant FLARE string extractor for malware analysis that is used like strings.exe but also recovers obfuscated strings. Besides static ASCII and UTF-16LE strings it extracts stack strings, tight strings and strings decoded by functions: it heuristically identifies decoding routines, recovers their arguments through control-flow analysis, emulates them and diffs memory before and after emulation. It also extracts Go and Rust strings and accepts PE, ELF and raw 32- or 64-bit shellcode; JSON results can be turned into import scripts for IDA Pro, Ghidra, Binary Ninja, radare2 and x64dbg. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v3.2.0, published 2026-10-16 as standalone Linux, macOS and Windows executables and on PyPI for Python 3.10+; it adds basic ELF support and moves the Ghidra import script to PyGhidra. The reviewed master commit has 857 commits that are not in v3.2.0, which in turn has 8 not on master: it merges the QUANTUMSTRAND preview, so the layout-aware static strings with file-structure context and tags, the HTML report and the hosted viewer described in its README have so far shipped only in quantumstrand pre-releases (latest quantumstrand-beta3, 2026-04-22). Master requires Python 3.12+ and still reports version 3.1.1. - Decoding uses static emulation with embedded FLIRT signatures to identify library functions; files above 64 MB abort deobfuscation unless --large-file is given. Shellcode is recognized by .sc32/.raw32/.sc64/.raw64 extensions or selected with -f. Source clones need Git LFS for the tag databases and signature files, and the installation guide calls the Python API unstable between releases, leaving the CLI as the stable interface. - Samples come from the analyst. v3.2.0 fixed an issue in which crafted .viv vivisect workspace files, either the sample itself or one beside it, could execute code during analysis in v3.1.1 and earlier and in the QUANTUMSTRAND pre-releases; saved workspaces now load only with FLOSS_LOAD_VIV_WORKSPACE=1. Decoded strings come only from routines that FLOSS identifies as decoders and emulates. - Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Zydis > Lightweight C11 x86/x86-64 disassembler and code-generation library. Its decoder reports each instruction's operands, accessed CPU and FPU flags, ISA set and extension and branch type; the formatter prints Intel, MASM or AT&T syntax, and the encoder assembles instructions from encoder requests, which can also be derived from decoded instructions. ZydisDisasm and ZydisInfo command-line tools are included, and the official Rust and Python 3 bindings live in separate repositories. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v4.1.1, published 2025-02-16 with no attached files; v4.1.0 (2024-02-04) carries the zydis-amalgamated single-header and single-source archives the README describes. The README says master holds the next, unreleased version without API stability guarantees; the reviewed master commit (2026-07-27) declares 5.0.0 and is 121 commits ahead of and 59 behind the v4.1.1 tag. - Build with CMake 3.10+ (the README lists Windows, macOS, Linux and the BSDs), the Meson 1.3+ build file, the maintained Visual Studio 2022 project, or the amalgamated files with any C11 compiler. A recursive clone fetches the Zycore support library from its zycore-c submodule unless a system copy is forced. The README lists Arch, Debian, Ubuntu, Homebrew, NixOS and vcpkg packages, and CMake options can disable the decoder, encoder, formatter, AVX-512 or KNC support or force minimal decoding mode. - The caller supplies code bytes and selects a 16-, 32- or 64-bit machine mode; ZydisDisasm reads a raw byte file. No executable-format loader is documented, so locating code in PE, ELF or firmware images needs another tool. - MIT license; Zycore is a separate MIT-licensed zyantific repository. The README's statements about performance, dependency-free and allocation-free operation, thread safety, testing on Windows, macOS, FreeBSD, Linux and UEFI, and use in x64dbg, Firefox and WebKit. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### QBDI > Quarkslab's modular dynamic binary instrumentation (DBI) framework, which JIT-recompiles a program's basic blocks inside its own process so that an instrumentation tool can register callbacks before or after instructions, on memory reads and writes, and on VM events. The engine is a library that can start an instrumented execution anywhere in a process, scripted from C, C++, Python (PyQBDI) or Frida JavaScript. It has no preferred injection method: it bundles the LD_PRELOAD-based QBDIPreload for Linux and macOS dynamic executables and is integrated with Frida. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README status table supports execution and memory-access information for x86-64 and x86 on Android, Linux, macOS and Windows, ARM on Android and Linux, and AArch64 on Android, Linux, macOS and iOS; iOS support is described as unstable and needs a jailbroken device. Latest release at review: v0.12.1, published 2026-01-07, with Android, iOS, macOS and Windows packages; Linux packages last appear in v0.12.0 (2025-10-14). PyQBDI 0.12.1 on PyPI requires Python 3.8+. - The reviewed dev-next commit is 12 commits ahead of v0.12.1; the README says all new work merges there and there is no scheduled release plan. Source builds need CMake 3.12+, Ninja or Make and a C++17 toolchain, and build a bundled LLVM statically because QBDI uses private LLVM APIs of one specific version; per-platform configuration scripts cover Linux, macOS, Windows (with a native Python 3 and Visual Studio) and Android NDK cross-compilation. - The README states that QBDI does not handle signals, new-thread creation or C++ exceptions. Its documentation adds that the instrumentation tool shares the target's heap and libraries, so non-reentrant code such as the heap allocator should be left to the execution broker outside the instrumentation range, and the OS loader itself cannot be instrumented. Users supply their own target programs and an injection route. - LICENSE.txt places QBDI under Apache-2.0 and lists statically linked components: LLVM (Apache-2.0 with LLVM exceptions), spdlog, fmtlib, Catch2, pybind11 and a GPLv3/Apache-2.0 SHA-256 implementation; GitHub could not classify the combined file. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### binsider > Terminal user interface for inspecting ELF binaries. It shows file information and linked shared libraries in the manner of stat and ldd, browses ELF headers, notes, sections, segments, symbols, dynamic symbols and relocations much like readelf, extracts strings with an adjustable minimum length, and offers a searchable hexdump view. Optional dynamic analysis runs the binary and traces its system calls like strace, with a summary of time and call counts per system call; the interface can also be embedded as a Rust library in Ratatui applications. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.3.2, published 2026-02-01, on crates.io and as prebuilt archives for Linux (x86_64, i686, AArch64, ARM and powerpc64le, with glibc and musl variants), macOS on Intel and Apple silicon, and Windows x86_64. The release workflow enables dynamic analysis only in the x86_64 Linux builds and the AArch64 glibc build. The reviewed main commit is six commits later and adds the --syscall-number, --string-limit and --no-abbrev trace options, which the website documents but no release includes yet. - Cargo.toml requires Rust 1.88+, although the website's installation pages still give an MSRV of 1.74.1. The dynamic-analysis feature is enabled by default and can be left out with --no-default-features. The website also documents Docker, Nix, Arch Linux and Alpine Linux installation. - Input is an ELF file chosen by the user. Dynamic analysis executes that binary on the host under ptrace-based tracing, so untrusted samples should only be traced in an isolated environment; the other views read the file without running it. - Dual-licensed MIT OR Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### iced > x86 instruction library for 16-, 32- and 64-bit code that decodes, formats, assembles and encodes instructions, with masm, nasm, GNU AT&T and Intel XED output syntaxes. Its instruction-info API reports the registers, memory operands and RFLAGS bits an instruction reads or writes, its CPUID feature flags and control-flow type, and the encoder can re-encode decoded instructions at any address. Rust, C# (.NET) and Java implementations live in one repository, with Python, JavaScript (WebAssembly) and Lua bindings built on the Rust crate. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.21.0, published 2024-01-20, distributed as iced-x86 on crates.io, PyPI, npm and Maven Central (group io.github.icedland.iced) and as iced on NuGet. The reviewed master commit (2026-07-14) is 340 commits ahead of that tag, with no newer release, and still declares version 1.21.0. - The Rust crate needs rustc 1.64.0+, supports no_std and WebAssembly, and uses Cargo features to select the decoder, encoder, block encoder, instruction info, each formatter and the optional code assembler. The .NET library targets .NET Standard 2.0/2.1 and .NET Framework 4.5, and the Java library needs Java 8+. PyPI ships Windows, macOS and Linux wheels, and source builds need Rust and Python 3.8+; the JavaScript package is built with wasm-pack, and the Lua binding is built from source with Rust, luarocks and Lua 5.1+. - The caller supplies raw code bytes, the bitness and the instruction pointer. The reviewed documentation describes no executable-format parsing or function discovery, so a loader or format library has to locate code first. Knights Corner MVEX instructions need the mvex feature and the KNC decoder option. - MIT license. The README reports that all instructions are tested, that iced was tested against xed, gas, objdump, masm, dumpbin, nasm and ndisasm and fuzzed, and Rust throughput above 250 MB/s for decoding and 130 MB/s for decoding plus formatting in its disas-bench results. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### hrtng > IDA plugin published by Kaspersky that extends the Hex-Rays decompiler with tools its author collected for reverse-engineering work, including malware analysis. It decrypts strings, data and constants with built-in ciphers or in bulk through IDA's Appcall debugger feature, resolves API-name hashes, unflattens control flow and forces decompilation of obfuscated code, and recognizes library code through microcode signatures, inlined-function detection and PAT files built from an IDA database. Pseudocode helpers cover automatic renaming, retyping and enum substitution, structure creation, virtual and indirect call navigation, and patching. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires IDA with the Hex-Rays decompiler. The README supports only the latest IDA version; the plugin can still be compiled against IDA SDK 7.3 or later, but new features are usually not well tested on older versions. Latest release at review: v3.9.114, published 2026-09-02, with prebuilt archives for IDA 9.2, 9.3 and 9.4 plus a separate 7z archive; the reviewed master commit is one changelog fix ahead and declares 3.9.115 in ida-plugin.json. - The CI workflow builds Linux x64, macOS (Apple silicon and Intel) and Windows x64 binaries, and Linux ARM for IDA 9.3 and 9.4. Source builds use CMake with the Crypto++ CMake submodule and an IDA SDK whose path and version are set in src/CMakeLists.txt; the README gives manual SDK fixes for 8.5 and 9.1. The apilist.txt and literal.txt files from bin/plugins must sit beside the plugin for API-hash scanning and enum substitution. - Samples and IDA databases come from the analyst. The Appcall engine for mass decryption runs the analyzed program's own decryption routine under the selected IDA debugger, and its documentation reports testing only with the imul emulator and IDA's Remote Windows debugger. Obfuscated-code decompilation and inline detection are described as experimental. - GPL-3.0. NOTICE.txt lists bundled third-party code and its licenses, including Crypto++ 8.9.0 under the Boost Software License 1.0, used for ciphers such as RC4, AES and ChaCha20, and MIT-licensed GraphSlick and microavx code. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### BinCAT > Static binary code analysis toolkit designed for reverse engineers. Starting from a chosen address and initial state, it computes register and memory values, taint and reconstructed types, with forward and backward analysis and heap use-after-free and double-free detection; bits it cannot determine are shown as unknown. It is driven from an IDA plugin, where analysts can override values or taint, skip functions or replace instructions with NOPs before re-running, or from Python and an .ini configuration for automation. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.5, published 2025-02-25; its tag is the reviewed master commit, and the repository has had no commits since. The Linux and Windows release archives bundle the analyzer and the IDA plugin, which is installed by running install_plugin.py from IDA. The plugin requires IDA 7.4 or later with Python 3; the changelog adds IDA 8.3 support in v1.3 and IDA 9.0 support in v1.4. - The README lists x86-32, x86-64, ARMv7, ARMv8 and PowerPC as analysis targets; the changelog also records initial RISC-V and initial, incomplete ARMv7 Thumb support. The analyzer runs locally on Linux or Windows (macOS only “maybe”, per the README) or as a Flask web service in the airbusseclab/bincat Docker image that the plugin reaches through its remote URL option. Source builds need OCaml with dune, menhir, ocamlgraph, ppxlib and zarith plus Python 3; Windows builds use Cygwin and an opam mingw64 OCaml switch. - Each analysis is described by a versioned .ini file covering the program, its sections and imports, the initial register and memory state and overrides; the IDA plugin generates it from the open database, ELF core dumps can supply the initial state, and the format documentation is partial, with the parser source as its reference. Binaries to analyze come from the user; the tutorial uses the project’s own keygen-me sample. - AGPL-3.0 per the README and doc/COPYING; GitHub detects no license because there is no root license file. The OCaml code includes LGPLv2 OCaml runtime code, the plugin includes Apache-2.0 code from python-pyqt5-hexview, and a modified copy of c2newspeak is bundled. Results depend on the configured initial state, skipped functions and overrides. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### GEF (GDB Enhanced Features) > Single-file Python extension, gef.py, that adds dynamic-analysis commands to GDB. Each stop shows a context view of registers, stack, code, threads and call trace, and commands cover memory maps, pointer dereferencing, searching process memory for patterns, ELF and security-property information, process status and glibc heap inspection. An architecture abstraction layer covers x86-32/64, ARMv5–v7, AArch64, SPARC, MIPS and PowerPC, and gef-remote enriches remote sessions through gdbserver or the GDB stubs of qemu-user and qemu-system. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs GDB 10.0+ built with Python 3.10+, the baseline since GEF 2025.01 in the compatibility table, plus file, readelf, nm, ps and python3 on the host; Python 2 users are pointed to the separate gef-legacy. The README installs it by downloading gef.py, through an install script or manually, and sourcing it from the user's .gdbinit file. - Release at review: 2026.01, published 2026-02-02 without binary assets; the reviewed main commit is 12 commits ahead, adding glibc 2.42/2.43 heap support and removing unmaintained commands. More commands live in the separate GEF-Extras repository. - GEF relies on the GDB API and Linux-specific sources such as /proc/, so some features may not work on custom or hardened systems, and heap commands support only the glibc allocator. qemu mode needs a local copy of the debugged binary because QEMU's GDB stub cannot transfer files. The README aims it at exploit developers and reverse engineers. - MIT license. Tests run with pytest under the Python version GDB was built against. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Triton > C++ library with Python bindings for dynamic binary analysis of x86, x86-64, ARM32, AArch64 and RISC-V 32/64 code. Callers process instructions one at a time, optionally with concrete register and memory values; Triton builds symbolic expressions from each instruction's semantics, tracks taint and solves path constraints through Z3 or Bitwuzla. It also synthesizes and simplifies expressions and lifts them to LLVM IR or Z3 and back, for building analysis tools, automating reverse engineering, software verification or emulating code. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README calls Triton a part-time project that may not be fully reliable. The newest GitHub release is v0.9 from 2022-02-09, with Windows builds only; PyPI's triton-library 1.0.0rc4, first uploaded 2024-05-22 with wheels added through 2026-02-23, provides CPython 3.8–3.14 wheels for x86_64 Linux (manylinux 2.31/2.34), macOS 12 and Windows. The reviewed master commit declares version 1.0, and the dev-v1.0 branch was 22 commits ahead. - Source builds use CMake 3.20+ and need Capstone 5+. Z3 4.6+ is the default solver; Bitwuzla 0.4+, LLVM 12+ for lifting, Boost 1.68+ and libpython 3.6+ for the Python bindings are optional, and LLVM and Bitwuzla are off by default. The README also covers Windows builds and a vcpkg port maintained outside the project. - The README example processes raw instruction bytes against caller-set registers; some bundled examples load executables with LIEF and hook libc functions themselves, and the examples include CTF write-ups with their challenge binaries. CTest runs Python unit tests and per-architecture scripts that compare Triton's semantics with the Unicorn emulator; the x86 script notes that Unicorn 2.1.1 lacks some tested instructions. - Apache-2.0; Capstone, Z3, Bitwuzla, LLVM and Boost keep their own licenses. Symbolic results describe only the executed instructions and modeled state. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### PyLingual > Research decompiler for CPython bytecode from Python 3.6 onward that pairs per-version transformer models with control-flow reconstruction. A segmentation model splits bytecode into statements, a statement model translates each into source, and templates rebuild loops, conditionals, exception handlers, with blocks and match statements. The result is recompiled with the target Python version and its control flow compared with the original bytecode, and failing segments are retried with alternative segmentations; the design is described in the IEEE S&P 2025 paper “PyLingual: Toward Perfect Decompilation of Evolving High-Level Languages”. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - First release at review: v0.0.1, published 2026-09-21, whose notes report decompilation rates of about 82–87% for Python 3.6–3.12 and about 71% for 3.13–3.15 on the separate pylingual_eval_dataset; these are project-reported figures. The reviewed main commit is 67 commits later and declares version 0.1.0. The README warns that this readability-focused codebase may initially regress in control-flow accuracy compared with the hosted service. - Installed from a clone with uv tool install; pyproject.toml requires Python 3.12+ and pulls in PyTorch, Transformers, Hugging Face Hub and xdis. Per-version segmentation and statement models are downloaded from the syssec-utd Hugging Face organization at their unpinned main revision and run on CUDA when available, otherwise on CPU. Model cards differ in declared licenses: the 3.12 statement model states Apache-2.0, while its segmenter states none. - Checking a reconstruction compiles it in the target version: uv-managed interpreters cover 3.8–3.15, while 3.6 and 3.7 need pyenv or pyenv-win, which --init-pyenv can install. An optional Redis instance caches model predictions, keyed by version and normalized bytecode but not by model revision. The pylingual.io web service is a hosted alternative, so confidential .pyc files should stay with the local CLI. - GPL-3.0-only. Passing the control-flow check does not prove that the recovered source is identical to the original, and recovered code keeps the original owner’s rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Miasm > Python reverse-engineering framework for analyzing, modifying and generating binary programs. It reads, modifies and generates 32- and 64-bit PE and ELF files, assembles and disassembles x86, ARM, AArch64, MIPS, PowerPC, SH4, MSP430 and MeP code, and lifts it into its own intermediate language for symbolic execution, SSA and data-flow analysis, dependency graphs and expression simplification aimed at deobfuscation. Its JIT emulator runs shellcode or parts of binaries through LLVM, GCC, Clang or pure-Python backends, with Python callbacks that stand in for library functions, sandboxes with selected Windows API and Linux emulation, and dynamic symbolic execution through Z3. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - PyPI’s latest release and the newest tag are 0.1.5 from 2023-04-18; GitHub releases stop at v0.1.3 from 2019. The reviewed master commit still declares 0.1.5 but is 100 commits ahead of that tag, so current code is installed from a clone with pip or taken from the project’s Docker images. CI runs the regression suite on Ubuntu with Python 3.10 and 3.13. - pyproject.toml requires Python 3.10+ with future and pyparsing, pinned to 3.3.2. Native jitter extensions are built only when a C compiler is available; otherwise installation continues without the jitter features unless MIASM_REQUIRE_JIT=1 is set. Optional extras add pycparser C-type parsing, Z3 for solver-backed dependency graphs and dynamic symbolic execution, llvmlite 0.44.0 for the LLVM backend, graphviz export and pycryptodome for Windows crypto API emulation. The README marks the LLVM backend untested on Windows. - Binaries, shellcode and memory dumps come from the analyst. The bundled Windows API emulation targets 32-bit x86, and other library effects are modeled with Python callbacks. The IDA plugins use a subset of Miasm without the jitter. - GPL-2.0-only. Lifted IR, simplified expressions and emulation results are analysis aids. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### HyperDbg > Hypervisor-assisted Windows debugger that virtualizes the running system with Intel VT-x and Extended Page Tables to debug kernel and user mode, either locally as a tracing and introspection tool or from a host attached over a serial connection to a guest virtual machine. Its events include EPT-based hidden breakpoints and hooks, memory read, write and execute monitoring without the limits of hardware debug registers, monitoring of system calls, CPUID, MSRs, I/O ports, MMIO, exceptions and interrupts, and Intel PT and LBR branch tracing. A kernel-side script engine, PDB symbol support and an SDK automate analysis. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.24, published 2026-09-22 as a single compiled ZIP; the reviewed master commit is that release. The README and FAQ name Windows as the only supported OS. The v0.24 changelog reports that the kernel modules now compile on Linux, but Linux support is still under development. - Requires an Intel x64 processor with VT-x and EPT; AMD and ARM processors are not supported, and the FAQ says most features need a 4th-generation or later Intel processor. The driver is not digitally signed, so the documented setup enables VT-x in firmware and turns off driver signature enforcement and virtualization-based security on the debugged machine. The documentation recommends a guest VM under VMware Workstation, ESXi or KVM in Debugger Mode, because local VMI Mode cannot pause or step. - Building from source needs a recursive clone, Visual Studio 2026 and current Windows SDK and WDK releases; CI builds with Visual Studio 2022 and 2026. The user supplies the drivers, programs or systems to debug, and the README recommends OpenSecurityTraining2’s Reversing with HyperDbg (Dbg3301) course for getting started. - GPL-3.0 for HyperDbg and its submodules unless a file states otherwise; dependencies keep their own licenses. The README also describes transparency features aimed at debugger detection. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Kuna > Agent-first decompiler written in Rust that began as a port of Ghidra’s C++ decompiler and SLEIGH compiler, and has since diverged with option-gated features, some ported from angr. A single self-contained kuna binary decompiles one function or exports a whole binary to C, header and assembly files, and the same engine runs in the browser through WebAssembly or as the decompiler backend inside Ghidra. The project calls itself an experiment in having LLM agents refine the decompiler; most code is agent-written and steered by regression and benchmark results. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README calls Kuna an experiment. A scheduled workflow publishes releases daily; the latest at review, v1.906 of 2026-10-18, has kuna archives for Linux x86_64 (glibc and musl) and arm64, macOS arm64 and x86_64 and Windows x86_64, a specs archive and a Ghidra 12.1.2 extension zip. The reviewed main commit is 40 commits ahead of it, and the README’s Ghidra install step still links the older v1.157 zip. - Release binaries embed the compiled SLEIGH specs. Source builds need only a Rust toolchain, with the workspace declaring Rust 1.90+; make specs compiles the vendored Ghidra processor specs before a release-style kuna build. Users supply the binaries to analyze; the README says the browser version decompiles on the user’s machine, so the file stays local. - The Ghidra extension is version-locked to the Ghidra release in its file name and bundles Linux, macOS and Windows backends; other 12.x releases are marked unverified, and the README says not all native Ghidra features are supported yet. Headless Ghidra never loads the plugin, so the README swaps the stock decompile binary or uses a PyGhidra toggle, and reports testing that swap with Ghidra 12.1.2 and REA 3.1.0. - CI runs the 675-assertion XML regression corpus vendored from Ghidra against a checked-in baseline, Kuna’s own stage testcases, the cargo workspace suite, a spec-documentation check, CLI tests and the browser page’s modules. docs/history.md reports that the Rust port matched all 675 assertions against the untouched C++ decompiler before the C++ tree was removed. The README’s top DecBench standing and speed figures are project-reported. - Apache-2.0. NOTICE says the engine, SLEIGH compiler, processor specs and regression corpus derive from Ghidra, also Apache-2.0, and that some structuring and region-recovery code is ported from angr under BSD-2-Clause. Output can differ from stock Ghidra by design and is a reading aid. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Binary Ninja API > Vector 35’s public C++, Python and Rust APIs for Binary Ninja, with their documentation, examples and the open-source plugins built on them. Binary Ninja itself is a closed-source commercial application, and this repository does not contain its analysis core. The open plugins cover the x86/x86_64, ARM64, ARMv7, PowerPC, MIPS, RISC-V and MSP430 architectures, ELF, PE/COFF, Mach-O and Apple shared-cache and kernel-cache loaders, DWARF, PDB and IDB import, and Objective-C, RTTI and SVD analysis, while the examples walk the low- and medium-level intermediate languages and extend the analysis pipeline through workflows. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The dev branch tracks Binary Ninja development builds. The newest release in this repository at review is stable/6.0.10601, published 2026-09-03, whose assets are Binary Ninja Free installers; the reviewed dev commit is 165 commits ahead of it, and dev-only material such as the guide to plugin-registered MCP tools is not in that release. The README says master tracks the stable build, but master was last updated in August 2024. - The API does not run on its own: plugins and scripts load the closed-source core from an installed copy of Binary Ninja. C++ plugins must be built from the API revision named in the installation’s api_REVISION.txt, and the install_api.py script shipped with the installation adds the Python module to another interpreter. The standalone examples and other headless scripts need a license with headless API access; the plugin guide says non-commercial licenses lack headless automation and names the Commercial and Ultimate editions for it. - CMakeLists.txt requires CMake 3.28+, a 64-bit C++20 toolchain and a Python 3.12+ interpreter. UI plugins need Qt 6.8.2, which the README recommends taking from the official installer or Vector 35’s Qt build rather than Homebrew, and -DHEADLESS=ON skips them. The Rust crate declares rust-version 1.98.1. - Most of the API and documentation is MIT-licensed and the Rust API is Apache-2.0; some components carry their own license files, and contributions go through Vector 35’s CLA. These licenses cover the API layer only and do not make Binary Ninja open source. The repository’s issue tracker also serves the wider product. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### capa > Mandiant FLARE tool that reports what an executable can do by matching a YAML rule set against features extracted from PE, ELF and .NET files or 32/64-bit shellcode, such as API calls, imports, strings and constants. Matches are grouped into capability namespaces with ATT&CK and MBC tags, and verbose output shows the function or basic-block addresses and features behind each match, pointing analysts to code worth studying. It also reads CAPE, DRAKVUF and VMRay sandbox reports for dynamic features and can use vivisect, IDA Pro, Ghidra or Binary Ninja for analysis, with explorer plugins for IDA and Ghidra and a browser viewer for its JSON results. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v10.0.0, published 2026-10-16, with standalone PyInstaller builds for Linux (x86_64, arm64 and a Python 3.13 variant), macOS (x86_64 and arm64) and Windows that run without installation; the reviewed master commit only syncs the rules submodule after that tag. The installation guide says the Linux build needs GLIBC 2.26+ and that macOS Gatekeeper must approve the binary on first run. The flare-capa PyPI package (10.0.0, Python 3.10+) does not include the default rules or library-identification signatures, which are passed with -r and -s. - Inputs are user-supplied PE, ELF or .NET modules, raw shellcode, CAPE, DRAKVUF or VMRay reports, BinExport2 files or saved capa feature files. The IDA Pro explorer needs IDA 7.4+ with Python 3.10+ (tested through IDA 9.0); the Ghidra backend and explorer script need Ghidra 12.0+ started through PyGhidra; the Binary Ninja backend uses a separately installed Binary Ninja. - The limitations guide states that packed or obfuscated programs, installers and packaged programs such as AutoIt give misleading or incomplete results, and that capabilities split across wrapper or child functions are not matched; capa warns when its rules detect packing or installers. Matches are rule-based indications of capability, not confirmed behavior. - Apache-2.0, as is the separate capa-rules repository. v10.0.0 fixes code execution through crafted vivisect .viv workspace files, which affected v9.4.0 and earlier; existing workspaces now load only with CAPA_LOAD_VIV_WORKSPACE=1. A recursive source clone also fetches the test-file submodule, which the installation guide warns contains many malware samples. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### RetDec > Avast's retargetable machine-code decompiler built on LLVM. It takes ELF, PE, Mach-O, COFF, AR, Intel HEX or raw code for 32-bit x86, ARM, MIPS, PIC32 and PowerPC or 64-bit x86-64 and ARM64, recovers functions, types and C++ class hierarchies, and emits C or a Python-like language with call and control-flow graphs. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README warns that RetDec is in limited maintenance mode: pull requests are reviewed with priority, issues get delayed reactions and are not actively solved unless they concern basic maintenance, and only very limited development continues. The latest release is v5.0 (2022-12-08); the reviewed master commit of 2026-05-26 is 81 commits ahead of it and still declares version 5.0. - Release packages cover Linux, macOS and Windows; README lists Windows 7+, Linux, macOS and experimental FreeBSD, with about 5–6 GB per installation. Source builds need a C++17 compiler (GCC 7+, Visual Studio 2017 15.7+ or full Xcode on macOS 10.15+), OpenSSL 1.1.1+, Python 3.4+ and, outside Windows, autotools; CMakeLists.txt requires CMake 3.13, not README's 3.6. The build downloads pinned Capstone, Keystone, YARA and yaramod, an Avast LLVM fork and a 2019 support package. - Input is the user's own executable, object file, archive or raw machine code. Since v5.0 the decompiler is also a set of CMake libraries for other projects, and separate retdec-idaplugin and retdec-r2plugin repositories embed it in IDA and radare2. - GitHub Actions builds Release and Debug builds on Ubuntu 22.04, Windows (MSYS2) and macOS, then runs the separate retdec-regression-tests suite. README calls nightly builds unguaranteed, with possible regressions, and Docker support community-maintained. - MIT (Avast Software). The modified PeLib keeps its zlib/libpng license, and LICENSE-THIRD-PARTY lists the other components, including Keystone used under its FOSS exception to GPLv2. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### REDasm > Cross-platform interactive disassembler whose version 4 is a plain-C rewrite: a C17 engine library, the Qt6 GUI kept in this repository, and loader, processor and analyzer plugins loaded as shared libraries. The listing supports renaming, comments and typed data, with a synchronized control-flow graph, cross-references, string detection, a hex view, patching and saved projects. Besides PE and ELF, loaders cover retro and console formats such as DOS MZ, Win16 NE, OS/2 LE/LX, PlayStation 1, original Xbox and ZX Spectrum, with x86/x86-64, MIPS32, ARM/Thumb, ARM64, Z80 and 6502 processors. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v4.0.0-beta3, published 2026-09-02, with a Linux x86_64 AppImage and a portable Windows x86_64 ZIP plus GPG-signed checksums; the reviewed master commit is 43 commits ahead of that tag. Nightly builds from master, which the README warns may be unstable, also include macOS DMGs. Version 4 is a complete rewrite still in beta; the README says version 3 was retired, and its last release, 3.0 beta 5, dates from 2021. - The README rates Windows 10+ with Visual Studio 2022 and Linux with GCC 12+ (Ubuntu 24.04/Debian 13 reference) as actively tested platforms with official binaries; FreeBSD and macOS only pass CI builds and tests, and Haiku only compiles. Source builds go through the separate workspace repository, which fetches the core, GUI, plugin and knowledge-base repositories and needs CMake 3.20, C17/C++17 compilers and Qt 6.8 LTS. - Executables and console program files are supplied by the user. The README's maturity tables rate PE, ELF and x86/x86-64 support production ready and Visual Basic 5/6 event recovery highly stable, but the DOS MZ, PS1 BIOS, Xbox, ZX Spectrum and NES (NROM only) loaders and the Z80 and 6502 processors only functional, and MSVC RTTI and exception-handling recovery work in progress. There is no decompiler yet, and extensions are written in C; a Python plugin API is on the roadmap. - GPL-3.0 for the GUI, the core and every bundled plugin; the separate knowledge-base repository of TOML signatures and type definitions is CC0-1.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Lighthouse > Code-coverage explorer plugin for IDA Pro and Binary Ninja that loads execution traces of native programs and paints the executed code across the disassembler's views, without needing symbols or source. Its coverage overview lists per-function coverage, and a composing shell combines loaded coverage sets with logical operators to diff runs, filter functions and jump to addresses, while coverage cross-references show which of many batch-loaded sets executed a block. It reads DynamoRIO drcov logs, module+offset, absolute-address and Tenet traces, writes basic HTML coverage reports, and ships a prototype Intel Pin tool and a Frida script that produce drcov-compatible logs. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v0.9.3, published 2024-02-05 as a servicing release that adds full drcov v3 support and Binary Ninja/PySide6 fixes; the reviewed master commit is that tag. The develop branch is nine commits ahead with IDA 9.x, 9.2 and 9.3 compatibility fixes from 2025-2026 and a 0.9.4 development version, none of them released. - Requires IDA Pro 7 or newer (the IDA layer stops on IDA 6) or Binary Ninja, where the README says plugin-manager installation supports v3.5 and newer; for IDA the README copies the plugins folder into the user plugin directory. The README describes a cross-platform Windows, macOS and Linux Python 2/3 plugin with no third-party dependencies. In Binary Ninja, coverage is painted in linear, graph and IL views but not decompiler output. - Coverage is collected separately against the user's own target: the coverage README shows DynamoRIO drcov, the bundled CodeCoverage pintool (a prototype; the release attaches Windows builds for Pin 3.30, and macOS and Linux users build it against their own Intel Pin download) and the experimental frida-drcov.py, which its README recommends mainly for mobile applications. Absolute-address traces must match the database's address space; unmapped addresses are discarded, and other modules' hits in module+offset traces are not loaded. - MIT for Lighthouse and for the contributed pintool. Opening the coverage overview checks the GitHub releases API for a newer version. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### BinAbsInspector > Static vulnerability scanner from Tencent Keen Lab that runs as a Ghidra extension or headless script and applies abstract interpretation to Ghidra's P-code rather than to assembly, covering x86, x64, ARMv7 and AArch64 binaries. Its flow- and context-sensitive interprocedural analysis, with configurable value-set size and call-string depth, optional Z3 constraint solving and models of external functions, feeds checkers for 13 CWE classes, including command injection, buffer overflows and out-of-bounds access, format strings, integer overflow, double free, use-after-free and NULL dereference. Warnings list the instruction address and its call context, in the Ghidra console or as JSON. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The only release, v0.1 from 2022-04-20, is an extension ZIP built for Ghidra 10.1.2. The reviewed main commit is 20 commits ahead; its Dockerfile and CI workflows use Ghidra 10.4 with JDK 17, and the last commit dates from 2024-05-14, so compatibility with current Ghidra releases is not documented. Source builds use Gradle 7.x (tested with 7.4) against a local Ghidra installation. - Z3 is required (tested version 4.8.15): the README suggests replacing the Java bindings bundled in lib/ with a matching package and installing the native library separately, not from Linux distribution packages. Runs use Ghidra's headless analyzer, the Script Manager after default auto-analysis in the GUI, or the provided Dockerfile, which builds Z3 from source and defaults to an Ubuntu mirror in China that the UBUNTU_MIRROR argument overrides. - Binaries are supplied by the user. Warnings are leads for manual review, not confirmed vulnerabilities; Keen Lab's release article reports its own Juliet test-suite comparison with cwe_checker on x86, x64 and ARMv7 for four CWE classes, scored by true and false positives and negatives. - GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### VulHunt Community Edition > Open-source Community Edition of Binarly REsearch's VulHunt engine for hunting vulnerabilities in POSIX binaries and UEFI firmware on x86 and ARM. Lua rules run on the Rust BIAS framework, which lifts code to Ghidra's P-code and bundles Ghidra's C++ decompiler, and combine taint and dataflow tracking, Weggli-based queries over decompiled code, byte patterns, FLIRT signatures and type libraries; findings are written as JSON with annotated decompiled code. The CLI scans single binaries, Binarly BA2 archives or Binary Ninja databases, and can also run as an MCP server that lets AI assistants open a project, query it with Lua, rename functions and keep notes. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v1.0.0, published 2026-03-07, with Linux x86_64/aarch64, macOS arm64 and Windows x86_64 ZIPs; the reviewed dev commit is 7 commits ahead and its CLI crate declares 1.0.1. The documentation recommends its install scripts or a Docker image built from the repository; source builds need Rust, cargo-make, a recent CMake, Clang 20+ and a patched static LuaJIT 2.1, which cargo-make builds. - Scans need auxiliary data from the separate vulhunt-re/data repository (processor specifications and type libraries, fetched with git-lfs and, for source installs, built with bias-lutil and bias-tutil) and a rules directory, such as the community rules repository with POSIX and UEFI rules; the rules, data and agent-skills repositories had no license file at review. The Binary Ninja loader needs a build with the bndb feature, which links against the Binary Ninja 5.2 stable API, and the btp commands need a Binarly Transparency Platform account. - Binaries and BA2 archives are supplied by the user. The component loader takes one binary at a time; this repository has no loader for whole UEFI firmware images, since the UEFITool-based loader is published separately and is not part of the reviewed workspace. Binarly describes a commercial Enterprise Edition with further features. Rule findings are analysis aids for manual review, and the reviewed sources report no accuracy evaluation. - GPL-3.0 for VulHunt; the BIAS framework crates are dual-licensed MIT OR Apache-2.0 according to README.BIAS.md. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### BinSync > Decompiler plugin for collaborative reverse engineering that records each analyst's work in a shared Git repository, one branch per user, so teammates can pull, push or auto-push changes across IDA Pro, Binary Ninja, Ghidra and angr-management. Synced artifacts are function headers (names, arguments and types), stack and global variables, structs, enums and comments, including user-defined types. It is built by mahaloz, the angr team and the SEFCOM research lab and is used by the Shellphish hacking team; scripting goes through the separate DecLib library. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 5.15.4, published 2026-08-21 on PyPI and GitHub (with an IDA plugin ZIP); the reviewed main commit is one commit ahead, adding Ghidra comment sync and auto-push without a version bump. Install with pip and then binsync --install, which places the plugin in each decompiler; Binary Ninja also offers it in its plugin manager. Every setup needs Python 3.10+ and Git. - Supported hosts per the README: IDA Pro 8.4+ (older IDA versions need BinSync 4.10.1), Binary Ninja 2.4+, angr-management 9.0+ and Ghidra 12.0+ launched in PyGhidra mode. Support differs by decompiler: angr-management does not sync global variables, structs or enums, and although the Ghidra table marks every artifact as supported, the README text still calls Ghidra support early-stage and says to expect only minimal features such as name and comment syncing. - Collaborators share a Git repository and analyze the same binary, which each of them supplies. The optional extras add an auxiliary server and an AI user that applies DAILA prompt results to a project and requires an OpenAI API key; its changes are model output to be reviewed. - BSD-2-Clause. The README's term REAs means reverse-engineering artifacts. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### class-dump > Command-line utility that reads the Objective-C runtime metadata in Mach-O executables, frameworks and bundles and prints it as ordinary Objective-C declarations for the classes, categories and protocols it finds, the same information otool -ov shows in a more compact form. It can write one header file per class, recurse into the frameworks a binary uses, choose one architecture from a universal binary, filter or sort the output, and annotate it with instance-variable offsets and implementation addresses. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Dormant: the newest tag, 3.5, is dated 2013-11-16, GitHub release entries stop at 3.4, and the README points to the author's website for the latest version. The reviewed master commit, from 2019-03-15, is 75 commits past 3.5 and carries unreleased changes such as building with the macOS 10.14 SDK. - Builds use Xcode on macOS with the bundled class-dump.xcodeproj, whose targets set macOS 10.8 and 10.9 deployment targets. The README's usage text lists ppc, ppc64, i386 and x86_64, and the 3.5 changelog adds arm64; support for later Apple architectures or metadata formats is not documented. - Input is a Mach-O file, framework or bundle the user already has, and only Objective-C metadata is decoded; files with an encryption load command are flagged in the output header. The unreleased changelog says Swift types have a blank encoding and are now written as MISSING_TYPE, so Swift types are not recovered. Output is declarations without method bodies. - Tests/doTests.py is a Python 2 script that diffs an older and a newer build's output over the installed system frameworks; the repository has no CI. The README notice applies GPL-2.0-or-later, copyright 1997-2019 Steve Nygard, and there is no separate license file; ThirdParty/blowfish.c is LGPL-2.1-or-later. Headers generated from closed-source binaries remain subject to their owners' rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Lucid > IDA Pro plugin by Markus Gaasedelen for studying how the Hex-Rays decompiler transforms its microcode intermediate language. Opened from a Pseudocode window with View microcode, its explorer stays synchronized with the pseudocode and lets the user scroll a selected microinstruction through each microcode maturity level, tracing sub-operands back to their origins and changing the cursor color when the traced code has been optimized away. Nested sub-instructions can be shown as tree graphs; the author labels it a developer-oriented prototype and code resource, not a general-purpose reverse-engineering tool. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Unmaintained since its initial release: v0.1.1, tagged 2020-09-15, is the last release and the reviewed master commit, with no commits since, and a community pull request adding further features has been open and unmerged since 2024. The README's list of known bugs from that release, including a possible IDA crash when double-clicking some address comments and little testing on macOS and Linux, has not been revised. - Needs IDA Pro 7.5 or newer with a Hex-Rays decompiler for the analyzed architecture. It is a Python 2/3 plugin without third-party dependencies, installed by copying the plugins folder into IDA's user plugin directory; its UI imports IDA's bundled PyQt5, and compatibility with current IDA releases is not documented. - Works on binaries the user has opened and decompiled in IDA. It is a viewer for decompiler internals; the README lists microcode-optimizer workflows only as possible future work. - MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### r2dec > Decompiler plugin for radare2 that turns the disassembly of an analyzed function into pseudo-C through the pdd command. Its decompiler is written in JavaScript, with one module per architecture, compiled to QuickJS bytecode and embedded in a native radare2 core plugin; output can sit beside the assembly or offsets, show only scope blocks, casts or cross-references, render as HTML, or be written back into radare2 as comments. The README lists x86/x64, 16/32/64-bit ARM, MIPS, PowerPC (including VLE), SPARC, AVR, V850 and Dalvik, plus experimental 6502, 8051, BPF, m68k, SuperH, WebAssembly and RISC-V support. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 6.2.0, published 2026-08-16 from the reviewed master commit, with a Linux amd64 plugin, Windows 32- and 64-bit builds and a source archive that includes dependencies. Release numbers follow radare2's: CI builds against radare2 6.2.0 on Linux and Windows, and the macOS job is commented out. Install through r2pm, or build with meson 0.55.0+ and ninja against the radare2 development files; QuickJS is fetched as a meson subproject. - Binaries are supplied by the user and the target function must first be analyzed in radare2 (af). Output is readable pseudo-C rather than recovered source; as the README example shows, it can keep register assignments such as eax and generic local names. Regression tests live in the separate r2dec-regression repository, and issue reports use the JSON produced by pddi. - This repository builds only a radare2 plugin; Rizin's jsdec decompiler is a separate project. Source files carry SPDX headers: BSD-3-Clause for most of the code and MIT for the bundled base64 helper, so GitHub detects no single license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Runtime Mobile Security (RMS) > Frida-based web interface for observing Android and iOS apps at run time on a test device. It lists the classes and methods loaded in memory, traces method arguments and return values, generates hook templates for a selected class, finds class instances on the heap, and on Android monitors categorized framework APIs and a few libc file functions; a beta file browser covers the app's private folders. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.5.25, published 2026-07-01, matching the reviewed master commit; it installs from npm as rms-runtime-mobile-security and its package.json depends on Frida 17 node bindings. The README says it was tested on macOS with Android emulators, an Amazon Fire Stick 4K, an iPhone 7 and Chrome, and may need minor adjustments on Windows and Linux. - Requires Node.js, Frida's CLI tools and a frida-server already running on a single connected test device; RMS cannot handle several devices at once. It also attaches to a default system process to list preloaded classes. Use it only on apps and devices the user is authorized to analyze. - The web interface defaults to port 5491; rms.js passes only a port to server.listen, so Node's default all-interface binding applies, and the reviewed code adds no login. The README notes that complex methods sometimes fail to load and that Safari is unsupported. - GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Pharos > Carnegie Mellon SEI's framework of automated static analysis tools for binary programs, built on LLNL's ROSE compiler infrastructure for disassembly, control-flow analysis and instruction semantics. Its best-known tool, OOAnalyzer, recovers C++ classes, methods and other object-oriented constructs from 32-bit x86 executables built with Microsoft Visual C++ by applying Prolog rules to facts about how object pointers move between functions, as described in a CCS 2018 paper, and exports JSON for an included IDA plugin or the separate Kaiju Ghidra plugin. Other tools find API call sequences (ApiAnalyzer), report static API-call parameters (CallAnalyzer), produce function hashes and YARA signatures for similarity analysis (FN2Hash, FN2Yara) and work out the conditions for reaching one address from another (PathAnalyzer). - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - There are no tagged releases; the reviewed master commit is from 2026-08-03. The README calls Pharos a research project under active development whose documentation is incomplete and whose portability has not been actively tested, and it says DumpMASM is no longer maintained, recommending ROSE's own tools instead. - The easiest route is the prebuilt ghcr.io/cmu-sei/pharos Docker image, which the GitHub workflow builds for amd64 and arm64 on each push and weekly. Building from source is heavy: C++14 with CMake, Boost, yaml-cpp, SQLite, Z3, SWI-Prolog and ROSE, with the build script pinning ROSE v2.6.0, Z3 4.8.7 and SWI-Prolog 8.5.12. INSTALL.md suggests about 4 GiB of RAM per build CPU for small CPU counts, supports its build script only on the latest Ubuntu, and lists older manually tested configurations on RHEL 7, Ubuntu 19.04 and openSUSE 15.1. - Provide the executables to analyze yourself. OOAnalyzer is limited to 32-bit MSVC binaries and has been tested little on 64-bit executables or other compilers; its JSON output feeds the IDA plugin in the repository or the separate Kaiju Ghidra plugin, and very large executables need the extra steps in the oorules notes. - The Dockerfile has a test stage that runs ctest against test executables compiled from the sources in tests/, but the GitHub workflow builds only the release image. - LICENSE.md is an SEI BSD-style license (Copyright 2021 Carnegie Mellon University) that also restricts use of the CMU and SEI names, which is why GitHub reports NOASSERTION. ROSE, SWI-Prolog, Z3, Boost, yaml-cpp and SQLite keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### heimdall-rs > Rust toolkit by Jonathan Becker for analyzing EVM smart-contract bytecode, particularly of contracts without verified source. Its CLI disassembles bytecode, builds control-flow graphs, decompiles it through per-function symbolic execution and heuristic post-processing passes into an ABI plus beta Solidity or Yul source, decodes raw calldata, dumps the storage slots a contract accesses over a block range, and inspects transactions by decoding their calldata, traces and logs. Targets can be raw bytecode, files, contract addresses or ENS names; function selectors are resolved against the OpenChain signature database unless that step is skipped. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 0.9.3, published 2026-04-30, with Linux and macOS binaries for amd64 and arm64 and no Windows build; the reviewed main commit is 38 commits ahead, and both that tag and main still declare workspace version 0.9.2. Install through the bifrost installer, which builds from source with Cargo or, with -B, fetches a precompiled binary; the repository pins Rust 1.91.0. - Contract addresses, ENS names, storage dumps and transaction inspection need an Ethereum JSON-RPC endpoint, given as a URL or a MESC reference; an optional Etherscan API key lets decompilation recover creation bytecode of self-destructed contracts. Optional LLM post-processing sends the decompiled Solidity to OpenRouter (default model openai/gpt-4o-mini) and needs an OpenRouter API key. - Decompiled Solidity and Yul output is marked beta and is a heuristic reconstruction to be checked, not original source. The README lists more than 20 papers and theses that cite Heimdall. - MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### PE-bear > Qt GUI to view and edit Windows Portable Executable files, meant as a fast first look for malware analysts and robust against malformed PE32 and PE64 files. It shows headers and section layout, follows raw, RVA and VA addresses, disassembles from any offset with Capstone, matches packer signatures, compares two files and unmaps dumped images. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release: v0.7.2 (2026-06-05), with Windows Qt6 and Qt5 builds, a legacy Qt4 x86 build for old Windows such as XP, Linux tar.xz and AppImage builds and a macOS Qt6 app; Chocolatey, Scoop and WinGet also package it. The reviewed main commit of 2026-10-14 is 16 commits ahead, with a Capstone update and an unreleased update check that, per its README, queries GitHub's releases API at most once a day and sends only a PE-bear User-Agent. - Linux builds need a matching Qt installation, and Windows builds made with Visual Studio 2017 or later need the Visual C++ 2015–2022 redistributable. Source builds need Git, CMake 3.12+, Qt6 (or Qt5/Qt4) and the bearparser, Capstone and sig_finder submodules, with build scripts for Linux and macOS. AppVeyor builds test packages from each main commit, which README warns may be unstable. - Input is a PE file chosen by the analyst, including images dumped from a process, which PE-bear offers to unmap. Wiki pages cover adding imports, removing overlays, filling content and searching strings or masked byte signatures. Packer detection uses SIG.txt, converted from PEiD's UserDB by a third-party script and last updated on 2022-10-17. - GPL-2.0; the author's page says PE-bear has been open source since 2022-09-18, after development was discontinued in 2014 and later reopened. The bearparser and sig_finder submodules are BSD-2-Clause, and Capstone keeps its own license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### PE-sieve > Windows process scanner by hasherezade that finds and dumps implants in one running process: replaced or injected PE modules, shellcode, inline and IAT hooks and other in-memory patches, with the README naming Process Hollowing, Process Doppelgänging and reflective DLL injection among the techniques it detects. Options add shellcode detection by patterns or statistics, scans of thread call stacks, non-executable pages and encrypted or obfuscated content, a choice of dump mode with import-table recovery for dumped PEs, minidumps and JSON reports. It builds as an EXE, as a DLL with a small API that Python, Go and Rust bindings use, or as a static library, and is the engine behind HollowsHunter and MalUnpack. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.4.1.1, published 2025-09-13, with 32- and 64-bit EXEs and DLLs; the README also lists Chocolatey and Scoop packages. The reviewed master commit (2026-06-06) reports version 0.4.1.5, so the pinned sources may describe unreleased changes. PE-sieve runs on Windows and scans one process per run, selected by PID; the separate HollowsHunter scans many processes or the whole system. - Source builds use CMake 3.12+ (or the MinGW build script) and a recursive clone for the libpeconv, paramkit and sig_finder submodules, with an option to build an EXE, a DLL or a static library. The Python bindings in the repository and the separate Go and Rust bindings load pe-sieve32.dll or pe-sieve64.dll from PESIEVE_DIR or the current directory. Optional symbol download fetches symbols for the scanned modules. - Inputs are running processes on a machine the analyst controls, and the README describes the results as potentially malicious material collected for further analysis, so detections and dumps need review. AppVeyor builds x86 and x64 Release and Debug configurations, and its only CTest check runs pe-sieve -? and expects a version string; the GitHub workflow publishes Doxygen documentation. - BSD-2-Clause (LICENSE, 2017-2026 @hasherezade); the submodules keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### oletools > Python package by Philippe Lagadec for analyzing Microsoft OLE2 (Compound File Binary) files such as Office 97–2003 documents, MSI files and Outlook messages, as well as RTF and OpenXML documents, mainly for malware analysis, forensics and debugging. Its command-line tools detect and extract VBA and Excel 4 (XLM) macros, embedded OLE and Flash objects and DDE links (olevba, MacroRaptor, oleobj, rtfobj, pyxswf, msodde), flag characteristics common in malicious files with oleid and ftguess, and show directory entries, metadata, timestamps and sector maps with oledir, olemeta, oletimes and olemap. It is built on the same author's olefile parser. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.60.2, published 2024-07-02 on GitHub and PyPI. The reviewed master commit (2026-01-26) already sets version 0.60.3, and its README news lists 0.60.3 under 2025-05-22 with an olevba fix for a security issue with ANSI escape codes in CLI output, but no 0.60.3 tag or PyPI upload existed at review. SECURITY.md lists 0.60.x and later as supported. - Install with pip as oletools, or oletools[full] to add the optional XLMMacroDeobfuscator. Dependencies are pyparsing, olefile, easygui, colorclass and pcodedmp, plus msoffcrypto-tool for encrypted documents except on PyPy under Windows, macOS or Python 2. setup.py classifiers list Python 2.7 and 3.4 to 3.12; the GitHub workflow runs pylint -E and the unit tests on Linux, Windows and macOS with current CPython 3 and PyPy 3.9, while the older Travis configuration targets Python 2.7 to 3.8 and PyPy. - Inputs are user-supplied documents, which in malware analysis may be malicious; the unit tests use sample documents committed under tests/test-data. The README describes oleid as detecting characteristics usually found in malicious files and MacroRaptor as detecting malicious VBA macros, so results are indicators that need analyst review. - LICENSE.md applies a two-clause BSD license (copyright 2012–2025 Philippe Lagadec) to the package; olevba contains MIT-licensed code from officeparser, and the thirdparty folder keeps its own terms, including GPL-3.0 for xxxswf and public-domain oledump plugin code. The README notes that python-oletools is unrelated to BeCubed Software's OLETools. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### MonkeyDev > Based on iOSOpenDev, MonkeyDev adds a MonkeyApp project template to Xcode for instrumenting iOS apps the developer is authorized to analyze. From Xcode it injects a developer-written dylib into a supplied decrypted app, builds Objective-C or Logos (CaptainHook) hooks, and re-signs, installs and debugs the result with source-level breakpoints; optional build settings restore Objective-C symbols, export the target's Objective-C headers and enable Reveal view inspection. The current version also builds jailbreak Logos/CaptainHook tweaks and command-line tools for rootless, rootful or roothide environments. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit f906af1 (last pushed 2026-10-20) documents version 4.10; the repository has no tagged release. The README reports the non-jailbreak flow verified on Apple Silicon Macs with Xcode 27.0 and an iPhone 14 Pro on iOS 18.6.2, covering build, repeat install, hooking, symbol breakpoints, header export and Reveal, and separately reports rootless tweak and command-line builds verified on device with rootful only build- and package-checked. - Installation needs a full Xcode, a native arm64 shell and Theos installed separately under the current user's home directory; it installs to /opt/MonkeyDev and registers the templates in the user's Xcode template directory without modifying Xcode.app. The repository commits prebuilt native helper binaries (its own monkeyparser and a build of class-dump) and the libsubstitute.dylib library, plus a demo app under Resource/TargetApp.app used as the built-in validation input. - Each MonkeyApp needs one target input the developer supplies: a decrypted .app or already-dumped IPA placed in the project's TargetApp folder, or the built-in demo when none is provided. The README states MonkeyDev does not decrypt apps on non-jailbroken devices. Signing requires a certificate available to the current team, a matching provisioning profile and device authorization, and the keep-bundle-ID toggle does not bypass signing entitlements. - GPL-3.0 licensed; the bundled roothide SDK under Librarys/roothide is MIT. The repository ships the Xcode templates, install/packaging scripts, the helper binaries and the demo app, and contains no third-party target application. ##### Primary sources 1. 2. 3. 4. #### Hollows Hunter > Windows command-line memory scanner by hasherezade that runs the PE-sieve engine across many processes, or the whole system, instead of a single PID. It recognizes and dumps replaced or implanted PE modules, shellcode, hooks and other in-memory patches for further analysis, selecting processes by PID list, name list or creation time relative to the scan. Scans can repeat in a loop or, in the 64-bit build, run as an ETW listener whose INI profile chooses the triggering events. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.4.1.1, published 2025-09-13, with 32- and 64-bit executables, ZIP archives and DLL-build archives; the README also points to a Chocolatey package, and the wiki to unstable AppVeyor test builds. The reviewed master commit identifies itself as the unreleased 0.4.1.3, 37 commits later and mostly PE-sieve submodule updates. - Windows only. Source builds need a recursive clone with the pinned PE-sieve, paramkit and Microsoft krabsetw submodules, plus CMake 3.12+; AppVeyor builds x86 and x64 with Visual Studio 2019, and mingw_build.sh shows a MinGW-w64 cross-build. ETW mode works only in the 64-bit build, must run as Administrator and writes HH_ETWProfile.ini to the current directory. - It scans processes running on the analyst's own system or VM, and the repository holds no samples. Hook and patch scanning is off by default and enabled with /hooks, dumps go to the current directory unless /dir is given, and the wiki calls looped full-system scans processor-intensive. The wiki warns that detected processes are not necessarily malicious and links PE-sieve's false-positive FAQ, so reports and dumps need review; the optional /suspend and /kill responses act on live processes. - AppVeyor runs ctest after each build: the tests check that the executable starts and that scans of the clean build machine report zero suspicious processes, then run IAT, hook, thread and shellcode-pattern scans that only check the report format. The only GitHub workflow publishes Doxygen code documentation. - BSD-2-Clause, like PE-sieve; krabsetw is MIT, and the pinned paramkit commit has no license file. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### restore-symbol > macOS command-line tool that writes a stripped iOS app's Mach-O executable back out with a rebuilt symbol table, so a debugger such as lldb can break on and display Objective-C method names. It recovers method names and addresses from the binary's Objective-C metadata through class-dump, and can merge extra name and address pairs from a JSON file, such as the block symbols found by the bundled IDA script. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - There are no releases or tags; the reviewed master commit of 2019-04-27 is the latest, and the repository has no tests or CI. The README covers Objective-C methods and blocks only and does not mention Swift symbols. - Builds on macOS with Xcode: make initializes the pinned class-dump submodule (0xced's fork) and runs xcodebuild on a project targeting macOS 10.11. The block-symbol script search_oc_block/ida_search_block.py runs inside IDA, uses Python 2 print statements and the legacy idaapi.get_inf_structure call, and writes block_symbol.json. - Input is a thin armv7 or arm64 Mach-O executable from an app the user is authorized to analyze; the tool rejects fat files with a request to thin them using lipo, and writes a new output file instead of changing the input. The README then re-signs the bundle with the user's own developer certificate and debugs it on a device with lldb. The repository contains source and a README screenshot, no app binaries. - There is no license file and GitHub detects none, so reuse terms for restore-symbol's own code are not stated; the build links the MachObjC library from the class-dump submodule, which is GPL-2.0-or-later. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### FakeNet-NG > Mandiant FLARE's dynamic network analysis tool for malware analysts, a successor to the original Fakenet. Its Diverter redirects traffic from local processes on Windows, or from other hosts in Linux MultiHost mode, to configurable listeners that simulate DNS, HTTP and HTTPS, SMTP, FTP, TFTP, IRC, POP and raw TCP or UDP services, with process and host filters, custom responses and an option to launch a command such as a debugger on a connection. Sessions can be saved as PCAP and end with an interactive HTML report of network-based indicators grouped by process and protocol. - Type: Tool - Targets: Binary · Protocol - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v3.5, published 2025-04-09, as fakenet3.5.zip with a PyInstaller fakenet.exe for Windows. The reviewed master commit, 11 commits later and still versioned 3.5, adds a Windows release-build workflow, CRL generation for TLS revocation checks and SingleHost as the default NetworkMode, although the README still recommends Auto. - Module installs use Python 3.10.11 and administrator rights; Windows needs the Visual C++ build tools, and Linux needs build tools, Python and libnetfilter-queue development packages and port 53 freed from systemd-resolved, with the README's Linux steps tested on Ubuntu 24.04.2. SingleHost mode needs Windows Vista or later and is experimental on Linux, without process and host filtering; MultiHost is Linux-only, only TCP, UDP and ICMP are intercepted, and the Linux Diverter mishandles packets over 4,016 bytes. - The README recommends a controlled, isolated VM, because the tool changes the system's network settings, and says antivirus and EDR products may flag it. The repository bundles runtime helpers: WinDivert 32- and 64-bit DLLs and drivers, a small FakeNetMini.exe and other placeholder files served from defaultFiles, and TLS listener keys plus a static CA certificate and private key. The repository states no separate license for the WinDivert files, and the README notes that some dynamically loaded libraries may be LGPL; since the CA private key is public, trust that CA only inside the analysis VM. - docs/testing.md describes an interactive test/test.py suite and manual tests on Windows and Linux VMs on a host-only network; the GitHub workflow only builds the Windows PyInstaller release. FakeNet-NG itself is Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Joern > Static code analysis platform that parses source code, JVM bytecode and executables into code property graphs held in a graph database and queried with a Scala-based language from an interactive shell or server mode. Frontends cover C/C++, Java, JavaScript, Python, Kotlin, PHP, Go, Ruby, Swift, C#, Rust and ABAP source, JVM bytecode and APK/DEX files through Soot, and binaries loaded through an embedded Ghidra, which the documentation lists as x86/x64 support. It adds a static taint-tracking engine, the joern-scan query database of vulnerability patterns, and export of AST, CFG, PDG or whole-graph views to DOT, GraphML, GraphSON or Neo4j CSV. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v4.0.660, published 2026-10-19; the README says releases are created automatically once a day, and the reviewed master commit is three commits ahead of that tag. Each release ships joern-cli zips for Linux, macOS and Windows on x86_64 and arm64 plus joern-install.sh, and the README also documents ghcr.io/joernio/joern Docker images, with an AlmaLinux 8 variant for CPUs without SSE4.2. - The README requires JDK 21 and says other versions have not been properly tested; gcc and g++ are optional, for discovering C/C++ system headers. Source builds use sbt, with an experimental partial Bazel setup. Inputs are the user's own source trees, class, JAR, APK or DEX files, or executables. - Binary support is the ghidra2cpg frontend, built on a bundled Ghidra 12.2 package. It has specific passes for MIPS and ARM/AArch64 and routes every other processor through its x86 pass; its README notes that varargs are not handled properly. The documentation's maturity table rates C/C++ and Java very high, JavaScript, Python and x86/x64 via Ghidra high, JVM bytecode, Kotlin, PHP, Go and Swift medium, and Ruby and C# medium-low; the Rust and ABAP frontends in the reviewed tree are not rated there. - Apache-2.0; CITATION.cff still names version 2.0, released 2024-01-18. The project describes itself as a tool for vulnerability discovery and static program analysis research; query and taint results describe the generated graph, not observed runtime behavior. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Speakeasy > Mandiant's Windows malware emulation framework, which runs PE executables, DLLs, kernel drivers and raw x86/amd64 shellcode on the Unicorn CPU emulator inside a modeled Windows runtime instead of a full VM. Hand-written handlers and a signature database built from win32metadata and phnt emulate Windows API calls, process and thread behavior, the filesystem, registry and network, and each run is recorded as a structured JSON report of API events with named arguments, dropped files and optional memory snapshots. It runs from the speakeasy CLI or as a Python library, and a built-in GDB stub lets an analyst step through an emulated sample. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.0.0b9, a GitHub pre-release published 2026-10-11 that tags the reviewed master commit and moves the report format to version 5.0.0. The newest stable speakeasy-emulator on PyPI is still 1.5.11 from 2022, and pip skips pre-releases by default, so the README's plain pip install resolves to 1.5.11 unless a 2.0 beta is requested. - Requires Python 3.10+; dependencies include Unicorn 2.1.4+, pefile, Capstone and pycryptodome, and the package is marked OS independent. Source installs need a recursive clone for the win32json and phnt submodules plus two scripts that generate the API signature databases; the Dockerfile builds a Python 3.13 image that mounts samples at /sandbox. GDB sessions connect gdb-multiarch or another GDB to the stub, which the documentation warns has no authentication. - Samples come from the user. The tests use small test executables, DLLs, WDM drivers and a shellcode blob under tests/bins, and the capa-testfiles submodule of Mandiant's capa test data, which supplies Practical Malware Analysis lab samples; handle both as malware-analysis material. - The limitations page says only a curated subset of APIs has handlers: APIs emulated from signatures alone return success values without real side effects, unknown imports stop a run, and a missing file, registry key or network response can look like anti-analysis behavior, so reports need analyst interpretation. MIT licensed; the win32json, phnt and capa-testfiles submodules keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### LazyIDA > Single-file IDA plugin of convenience actions first written for CTF work. In the disassembly and hex views it dumps a selection as a string, hex string, C/C++ array or Python list of bytes, words, dwords or qwords and copies the result to the clipboard, shows a selection XORed with one byte, fills it with NOPs, and copies or jumps to addresses and file offsets by hotkey. With Hex-Rays it toggles a function’s return type to void, copies item names and jumps to the member function behind an obj->func call on double-click, while a heuristic scan lists printf-family calls whose format argument is not a read-only constant. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit is three commits after the v1.1.0 release of 2026-01-25; LazyIDA.py now declares 1.1.1 while ida-plugin.json still says 1.1.0. The plugin is the single LazyIDA.py file, installed with Hex-Rays’ hcli plugin command or copied into the IDA plugins directory. ida-plugin.json asks for IDA 7.4 or later on Windows x86-64, Linux x86-64 and macOS x86-64 or arm64; the changelog adds IDA 9.0 and 9.2 support, and clipboard access uses PySide6 on IDA 9.2+ and PyQt5 on earlier GUI builds. - It works on whatever database the user opens in IDA and bundles no sample binaries. The Hex-Rays actions load only when a Hex-Rays decompiler initialises. The format-string scan is offered in the disassembly view only for 32- and 64-bit x86 and 32-bit ARM databases; it walks back from each call to printf-family functions in .text, .plt, .idata or .plt.got using fixed register and stack-slot conventions, so its hits are leads to check by hand, not confirmed vulnerabilities. - The README says the project was written casually about ten years ago and that several features are now outdated: return-type removal is built into IDA 7.5+, IDA’s Shift-E export can replace the dump actions, and the format-string scan should be reimplemented with the Hex-Rays API; it points users to HappyIDA instead. Multi-byte dumps decode little-endian values, and Fill with NOPs writes x86 0x90 bytes into the database whatever the architecture. - The repository has no tests or CI. MIT per LICENSE and ida-plugin.json; IDA Pro and the Hex-Rays decompiler keep their own licences. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Tiny Tracer > Intel Pin tool by hasherezade that traces a 32- or 64-bit program while it runs on Windows or Linux, logging API calls (with arguments and return values for watched functions), chosen local and statically linked functions, inline system calls, RDTSC, CPUID and INT instructions, and transitions between sections of the traced module, which helps find the original entry point of a packed module. It can follow code the module unpacks into new memory, disassemble selected ranges and, on Windows, flag the anti-debug and anti-VM checks a sample performs. Each run writes a .tag file of RVA;event lines that PE-bear reads natively and that the wiki shows loading into IDA Pro, Binary Ninja, x64dbg, Ghidra and Cutter to annotate code. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 4.0, published 2026-05-28 and refactored for Intel Pin 4.x; the reviewed master commit is two commits ahead of it. Releases contain source only, because, as the release notes and installation guide explain, Pin's license does not allow distributing compiled Pin tools. Users download Pin themselves and build the tool inside Pin's source/tools tree; the README names Pin 4.2 as the version tested, Pin before 4.0 needs a pre-4.0 release with the legacy build, and Windows versions older than 8 also need the legacy build. - Windows builds use MSYS2 make with clang-cl, with Visual Studio 2019 or later optional as an editor; Linux builds use g++ and make. Both scripts produce 32- and 64-bit builds in install32_64, which holds run_me.bat with context-menu .reg files, pin_attach.bat for attaching to a running process, tiny_runner.sh for Linux, and the TinyTracer.ini, params.txt and excluded.txt settings. The README says kernel debugging must be disabled for Pin to work. - install32_64 also commits the author's prebuilt Windows helpers dll_load32.exe, dll_load64.exe, kdb_check.exe, pe_check.exe and syscall_extract.exe, whose sources are in the separate hasherezade/pe_utils repository; the README notes that Windows Defender sometimes flags kdb_check.exe, a known false positive. The anti-debug and anti-VM modes are Windows-only, and the deep anti-debug mode is documented as prone to false positives. The analyst supplies the program to trace, which executes natively under Pin. - GPL-2.0 in LICENSE.txt; Intel Pin keeps its own license. Traces cover only code that executes during the run. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Ponce > IDA Pro plugin, described by its repository as the winner of the 2016 IDA plugin contest, that brings the Triton framework's taint analysis and symbolic execution into IDA's debugger for x86 and x64 programs. After the analyst taints or symbolizes registers, memory or inputs such as argv or a buffer read with fread, Ponce single-steps the debugged program, analyzes each instruction with Triton and renames the functions that the input influences. Its symbolic engine can solve a branch condition, or negate it and inject a satisfying input into memory, while execution snapshots restore earlier state to try that input; builds with Hex-Rays support also show the results in decompiler pseudocode. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.3.7, published 2023-06-01, with prebuilt Windows, Linux and macOS zips; the Windows zip holds Ponce.dll and Ponce64.dll builds for IDA 7.0 through 8.1, with none for later IDA releases. The README says Ponce works with any IDA version from 7.0 and that the binary built for the installed IDA version must be used. The reviewed master commit of 2025-06-06 adds only a work-in-progress CI fix after that release. - Installation copies the matching build into IDA's plugins folder; the README lists native Windows, Linux and OS X support. Source builds use CMake 3.15+, the IDA SDK for the target version (IDASDK_ROOT_DIR) and Triton, which the CI installs through vcpkg; pseudocode feedback also needs hexrays.hpp from an IDA installation that includes the Hex-Rays decompiler, otherwise -DBUILD_HEXRAYS_SUPPORT=OFF. The repository contains no SDK files, and its CI clones the SDK archives from a separate repository that is not public, so source builds rely on the user's own SDK. - Ponce analyzes a program the analyst runs under IDA's debugger, stepping one instruction at a time; the README cites about 3,000 instructions per second in the authors' tests, and common library functions such as printf are blacklisted from analysis by default. The limitations page says symbolic memory indexes can lose track of the input, Triton handles floating-point instructions poorly, and concolic execution only analyzes instructions that actually execute. - Ponce's own terms are a BSD-style license, and LICENSE also reproduces Triton's BSD and Z3's MIT licenses; GitHub does not classify the file. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### DRAKVUF Sandbox > CERT Polska’s automated black-box malware analysis system built on the DRAKVUF engine, which observes a Windows guest from the Xen hypervisor through virtual machine introspection rather than an agent installed in the guest. Samples submitted through the web interface or the CLI run in a restored snapshot, and the report covers the process tree, WinAPI, file and network activity, a PCAP, intercepted TLS keys, memory dumps, screenshots and capa-based TTP indicators. A drakrun installer builds the Windows guest, its snapshot and the VMI profile. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit is the v0.21.0 release of 2026-08-19, which GitHub ships as a Python wheel; the drakvuf-sandbox package provides the drakrun CLI, web application and workers, needs Python 3.9+ and pins its dependencies, including flare-capa 7.4.0. The host needs an Intel CPU with VT-x and EPT and Debian 12 or Ubuntu 22.04 booted through GRUB into Xen 4.17+ (4.19 recommended); the getting-started guide asks for at least two cores and 8 GB of RAM, while the README says 5 GB. Xen, LibVMI and the DRAKVUF engine come from prebuilt .deb packages or source builds, Redis, dnsmasq, tcpdump and other host packages are added, and the documented installation runs as root. - Guests are Windows 10 x64 (build 2004 or later, 22H2 recommended) or Windows 7 x64, installed by drakrun install from a Windows installation ISO the user supplies and completed over VNC, then snapshotted and profiled by drakrun postinstall. The guide suggests turning off UAC and Windows Defender in the reference snapshot and adding Visual C++ and .NET runtimes, and each analysis can cut the guest’s internet access. Nested virtualization works under Xen, under KVM as experimental, and under VMware Workstation with virtualized EPT; cloud hosts, Hyper-V and VMware Fusion are unsupported. - Observations come from DRAKVUF plugins: apimon, filetracer, memdump, procmon, socketmon and tlsmon by default, with regmon, syscalls, exmon and others optional and Intel Processor Trace plugins documented as experimental. The docs warn that many plugins slow execution, that monitoring begins only after the sample process starts, and that summary observations derive from DRAKVUF output, so exact network data should be checked in the PCAP. S3 storage, a ZFS storage backend and Karton integration are optional. - Profiling injects a small drakshell shellcode agent into explorer.exe for preparation commands. The repository carries source for drakshell and other guest helpers, a 15 KB test/test.exe sample used by its sanity test, and pinned DRAKVUF and Mandiant capa-rules submodules. That test suite installs the sandbox on a VM-runner service needing project credentials, while the public workflow only builds the docs, tools, web bundle and wheel and lints the Python code. The README warns that maintaining a sandbox is difficult and bugs may reproduce only on one configuration. - LICENSE applies GPL-2.0 with the authors’ added clarifications and exceptions, including a broad reading of derivative works and a bar on combining it with plain-GPL software, so GitHub reports no standard license; DRAKVUF and the capa rules keep their own licenses, and Windows guests remain under Microsoft’s terms. It is a defensive platform for running untrusted samples in isolated guests. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### HexRaysPyTools > IDAPython plugin for IDA Pro's Hex-Rays decompiler that helps rebuild structures and classes from pseudocode. Its structure builder collects the fields a variable accesses within one function or, with deep scan, across the functions it is passed to, marks virtual tables, resolves conflicting fields and finalizes a C declaration applied to every scanned variable; a Classes view edits classes and their virtual functions, and a graph shows how local types relate. Pseudocode helpers recast and rename across assignments and calls, propagate names, rewrite out-of-bounds pointers as CONTAINING_RECORD for a containing structure, edit function signatures, rename functions from assert strings and untangle if statements. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No commits since 2020-02-15 and no releases; the tags ida_6_8 and ida_7_2 mark older code. The README states support for IDA Pro 7.x with Python 2 or 3 and says nothing about later IDA releases; it notes that IDA 7.4 added an official implementation of its structure cross-references (Shift+X), describes Guessing Allocation as a very raw feature and marks its API as under construction. - Needs IDA Pro with the Hex-Rays decompiler. Installation copies HexRaysPyTools.py and the HexRaysPyTools directory into IDA's plugins folder; settings live in IDADIR\cfg\HexRaysPyTools.cfg, and by default the cross-references collected during decompilation are stored in the database (store_xrefs). It works on the analyst's own IDA databases and type libraries. - The repository has no license file and GitHub detects no license, so it grants no explicit reuse terms. ##### Primary sources 1. 2. 3. 4. #### CAPE Sandbox (CAPEv2) > Malware sandbox derived from Cuckoo v1 that runs samples in isolated Windows guests and records API-hook behavior, created and modified files, network traffic as PCAP, screenshots and memory dumps. Its capemon monitor adds automated unpacking, capturing injected, extracted or decompressed payloads and dumping process images, plus a debugger that YARA signatures or submission options can program with breakpoints and short instruction traces. Results are classified with YARA, Suricata and behavioral signatures, and malware configurations are extracted by parsers maintained in the separate CAPE-parsers package. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - There are no releases or tags: the reviewed master commit of 2026-10-18 is a rolling snapshot, with changes recorded in changelog.md, and pyproject.toml carries the placeholder version 0.1.0. The README recommends an Ubuntu 24.04 LTS host with KVM and Python 3.10 or 3.12, and Windows 10 or Windows 11 23H2 guests running agent.py under 32-bit Python 3.7.2 or 3.8. The kvm-qemu.sh and cape2.sh installers must be edited before use, only the rooter component runs as root, and the README asks users to read every file in conf/. - Users supply the samples and their own Windows guest VMs; the repository ships no guest operating system. The Windows analyzer bundles helper binaries: the capemon.dll and capemon_x64.dll monitors and the loader.exe and loader_x64.exe loaders, built from the separate GPL-3.0 capemon repository; PPLinject and version.dll helpers whose source the reviewed files do not identify; and third-party tools under their publishers' own terms, namely Sysinternals PsExec, signtool.exe from the Windows SDK and the AutoIt3 interpreter. - CI runs ruff, the pytest suites for the core, web interface and Linux analyzer, and mypy on Ubuntu 22.04 with Python 3.10 after a recursive checkout, plus pytest for the Windows analyzer on Windows. These check the framework's code, not detection or unpacking quality, and the README warns that configuration parsers can break as malware families change. A recursive clone also fetches the CAPE-TestFiles unit-test submodule, which includes a malware folder. - LICENSE applies GPL-3.0 under a Cuckoo Foundation notice, which GitHub reports as NOASSERTION; the bundled Microsoft and AutoIt executables are not covered by it. Analysis executes malicious files, which the README places in an isolated environment. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### LuaDec > Lua bytecode decompiler that turns compiled chunks back into Lua source, with a disassembly mode, selection of single nested functions by number and a guesser for local variable declarations that can be overridden by hand. Its -fc option recompiles each decompiled function and compares it instruction by instruction with the original. It targets Lua 5.1, marks Lua 5.2 and 5.3 support as experimental, and continues Hisham Muhammad’s LuaDec for Lua 5.0 and Zsolt Sztupak’s LuaDec51. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit, the latest on the default branch, dates from 2017-01-06, and the repository has no releases or tags. A build initialises one Lua submodule from the author’s lua5 fork (branch 5.1, 5.2 or 5.3), builds that Lua, then runs make LUAVER=5.x in luadec/, which also builds the luareplace and luaopswap helpers; Visual C++ 2008 project files are included, which the README says were tested with VC 2008 and 2013. A Travis CI configuration builds each Lua version with gcc and clang but runs no tests. - Input is a chunk compiled by the matching standard Lua version, or a Lua source file compiled on the fly for testing. For bytecode from a virtual machine with a reordered opcode table, luaopswap compares that VM’s compilation of a bundled script using every opcode with a standard compilation, derives an opcode map and rewrites files to standard opcodes; luareplace swaps a nested function between two files. The -fc check reports per function whether the decompiled code recompiles to the same instructions, and the README’s own example shows failures, so output must be checked function by function. - test/ holds small Lua source cases for control-flow constructs, and test-compiled/lua-5.1 bundles compiled Lua 5.1 chunks as decompiler inputs, including files named for the Xunlei downloader, JX3 add-ons and the Defense Witches game; the repository does not state their origin or rights. ChunkSpy listers for each Lua version and Ruby comparison scripts are also included. - The README says LuaDec is free software under the same license as the original LuaDec but does not name it, the repository has no license file and GitHub detects none, so reuse terms are unclear; the Lua, LuaAssemblyTools, ilua and memwatch submodules and the bundled ChunkSpy scripts keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### xpcspy > Frida-powered command-line tool that observes XPC messages exchanged between processes on iOS and macOS in both directions, for understanding how Apple-platform apps and services talk over XPC. It can spawn or attach to a target over a USB or remote Frida connection, filter the trace by direction (incoming or outgoing) and by service name with wildcards, and optionally parse the binary-plist payloads carried in XPC dictionaries, with bplist00 and bplist16 described as officially supported and bplist15 and bplist17 as experimental. A Python CLI drives a TypeScript Frida agent that is compiled to JavaScript. - Type: Tool - Targets: App · Protocol - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at tag v0.9.0 (the reviewed commit, last pushed 2026-05-11); the matching xpcspy 0.9.0 release was uploaded to PyPI the same day. requirements.txt pins frida ~=17.9.7 and frida-tools ~=14.8.2, so a compatible Frida must be present, and interception works only where that Frida can instrument the target: a local macOS process, or an iOS device reachable by a frida-server over USB (-U) or remotely (-R/-H). - Install with pip3 install xpcspy for the CLI. Building from source uses the Makefile: the Frida agent under agent/ is a TypeScript project compiled with frida-compile (needs Node.js and npm), then python3 setup.py sdist packages the Python tool. The package metadata credits author hot3eed and points its homepage at github.com/hot3eed/xpcspy. - The analyst chooses the process to inspect by name, PID, frontmost application or a spawned file; no sample files ship with the tool. It reads the XPC traffic of a running target for analysis and does not modify or inject messages. bplist parsing is partly experimental, and the README's TODO list notes recursive bplist deserialization and other unfinished work. - Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### de4py > Python deobfuscation and analysis toolkit with a PySide6 GUI and a CLI mode, aimed at analysts examining obfuscated or packed Python programs. It bundles deobfuscators for named Python obfuscators such as Jawbreaker, BlankOBF, PlusOBF, Wodx, Hyperion and pyobfuscate, and an AI-assisted "Onyx" engine that pairs a local Ollama LLM (default qwen2.5-coder:1.5b) with AST cleaning and pattern matching. A file analyzer detects packers such as PyInstaller, computes hashes, looks up suspicious strings and extracts metadata, while a behavior monitor and a Python-code execution shell support dynamic inspection of a target process. It has a plugin API and can be used as a library. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit (2026-08-17) is 18 commits past the v3.3.2-stable release (2026-08-12) and carries the same 3.3.2 version. The README asks for Python 3.10+ and recommends Windows for full feature support, while pyproject.toml declares requires-python >=3.8. There is no PyPI package: install from source with git clone then pip install . (entry point de4py, or python -m de4py / python main.py). - Dependencies include PySide6 for the GUI, xdis, pefile and pyinstaller for the analyzers, plus requests, psutil, pycryptodome, colorama, pypresence and sentry-sdk; the project also ships a remote API client and Sentry telemetry. The optional Onyx AI engine needs a separately installed Ollama with the configured model pulled; the model and thresholds are set in the UI. - Inputs are the user's own obfuscated Python scripts or packed executables. The repository's samples directory bundles the project's own test fixtures: obfuscated Python files for each supported obfuscator and small packer-built sample executables (PyInstaller, Nuitka and py2exe outputs). No third-party application files are required. - Licensed CC BY-NC 4.0 (non-commercial); the README states the tool is free and open source and that any paid copies are misrepresentations, and GitHub does not classify this license. The disclaimer says the tool is for educational purposes and that software should not be deobfuscated without permission. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Dwarf > PyQt5 debugger built on Frida that attaches to or spawns processes on Android and iOS devices, the local machine or a remote Frida server. A session offers breakpoints, watchpoints, register context, backtraces and threads, a Capstone disassembly view for x86, x64, ARM and ARM64, a hex editor and panels for modules, memory ranges and memory search, while Java explorer, inspector and trace panels and an Objective-C inspector cover mobile app runtimes. User Frida scripts and Python plugins extend a session, and companion commands trace Java methods or native addresses (dwarf-trace), log syscalls from one module on arm64 (dwarf-strace) and scaffold scripting projects with Dwarf API typings (dwarf-creator). - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: dwarf-debugger 1.1.3 on PyPI, uploaded 2022-04-09; the repository has no GitHub releases or tags. The reviewed master commit, from 2024-05-16 and the most recent at review, merges a small type fix after that release. The README still says a Dwarf 2.0 release is being worked on, and none has been published. - Installed with pip from PyPI or a master archive. setup.py accepts any Python 3 and declares Linux, Windows and macOS, depending on frida 12.8+, PyQt5 5.11.3+ (requirements.txt pins 5.13.*), Capstone 4.0.1+, requests and pyperclip. The bundled core.js agent is built from the core1 branch of the separate DwarfCore repository; the reviewed sources do not state which current Frida releases it works with. - The user supplies the apps, processes and devices to debug; the repository holds only Dwarf's own code, agent, icons and examples. Android sessions use adb and a device running frida-server: the device bar can download the latest frida-server from Frida's GitHub releases and install it with su on a rooted device, and flags devices where it finds no root access. iOS sessions use a USB-connected Frida device, local sessions spawn a given path or attach to a PID, and remote sessions use Frida's remote device. - GPL-3.0 (setup.py: GPLv3+). The README lists two known JavaTraceView display problems, and dwarf-strace handles only arm64 processes. The README pitches the tool to reverse engineers, crackers and security analysts. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### bddisasm > Bitdefender’s dependency-free C decoder for x86/x64 instructions, reporting explicit and implicit operands with their access modes, CPUID feature flags, flag accesses and valid modes, and printing Intel/MASM-style text. A minimal API with a 64-byte instruction structure trades detail for speed, and the companion bdshemu library emulates basic x86/x64 code in a raw buffer to flag shellcode-like behaviour such as NOP sleds, reading the instruction pointer, self-modification, TEB/PEB access and system calls. The disasmtool command-line example decodes or emulates files and hex strings. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit is the v3.1.0 release of 2026-10-14, which attaches a Linux .deb package and x86 and x64 Windows zip bundles; the README says releases newer than 2.1.4 can be checked with GitHub artifact attestations. v3.1.0 removed the Python and Rust bindings, whose directories now hold only notices that they are unsupported and must not be used in production, and the README warns that the vcpkg package may lag behind. - Builds use CMake 3.16+ with optional Ninja, tested with GCC and Clang on Linux and MSVC on Windows; a Makefile builds only the static libraries, and the Visual Studio 2019 solution with Windows SDK 10.0.18362.0 adds Windows kernel configurations that need WDK 1903. Python 3 is needed only to regenerate the instruction tables with isagenerator, and Make or MSBuild builds leave nd_vsnprintf_s and nd_memset for the integrator to supply. - The caller supplies code bytes and a 16-, 32- or 64-bit mode, optionally with vendor and feature preferences, and only Intel/MASM-style syntax is printed. No executable-format loader is documented, so code in PE, ELF or firmware images must be located with another tool. The README says bdshemu handles only basic instructions, emulates no API calls and supports memory accesses only inside the shellcode and its emulated stack, so its flags describe shellcode-like behaviour rather than a full program run. - CI builds on Linux, Windows and macOS, runs cppcheck and runs the repository’s decoder and emulator regression suites, which compare disasmtool output for bundled test byte files, many with their .asm sources, against expected results. The README also reports internal fuzzing, testing with mishegos and per-instruction speed figures. - Apache-2.0 license. The documentation says Bitdefender uses the library in Windows and Linux user mode, Windows kernel mode and its Napoca hypervisor. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### decompyle3 > Reworking of uncompyle6 by the same author that translates Python 3.7 and 3.8 bytecode, including some PyPy 3.7 and 3.8 bytecode, back into equivalent Python source; older bytecode stays with uncompyle6. It disassembles code objects with the companion xdis library, then tokenizes and parses the instruction stream with a refactored grammar into a tree from which source is printed, and it can decompile between given start and stop offsets or, through decompyle3-code, only a file's lambdas, generators and comprehensions. The README says the grammar rewrite does not by itself fix uncompyle6's control-flow problem, which the author is addressing with dominator-based analysis in a separate, non-public project. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 3.9.3, published 2025-10-01 on GitHub and PyPI; the reviewed master commit, from 2026-07-21, is 18 commits later and reports 3.9.4.dev0. The README says the code runs on Python 3.7 or 3.8, whereas pyproject.toml requires Python 3.7+ with classifiers through 3.13, master CI tests under Python 3.13, and a separate python-3.7-to-3.10 branch is tested under 3.8; the 3.9.3 release also ships wheels and eggs for 3.7, 3.8 and 3.9. It depends on xdis newer than 6.2, spark-parser 1.8.9 up to but not including 1.9.2, and click; master CI installs xdis from its git repository until the next xdis release. - The README reports testing on bytecode from Python 3.7 and 3.8, and the regression suite keeps compiled 3.7 and 3.8 samples plus a few PyPy ones; the release notes state that bytecode newer than 3.8 is not decompiled. The author warns of numerous decompilation bugs and does not intend serious work on 3.8 or 3.9 until the project is better funded. Candidate-release magic numbers, PJOrion or otherwise obfuscated code, Cython and MicroPython are not handled, and pathologically long expression or statement lists are slow. - Input .pyc or .pyo files come from the user; it cannot decompile Py2EXE executables directly, and bytecode bundled by such packagers has to be extracted first. The README's --syntax-verify option appears in the reviewed CLI as --verify syntax, next to --verify run; a syntax check is meaningful only when the checking interpreter matches the bytecode version, so the README suggests cross-checking with another decompiler such as unpyc37 and with programs that test themselves, including Python's standard-library tests. Recovered source remains subject to the rights of the original program’s owner. - GPL-3.0-or-later per pyproject.toml, with the GPL-3.0 text in COPYING. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### DRAKVUF > Tamas K Lengyel's virtualization-based, agentless black-box binary analysis system: running on the Xen hypervisor through LibVMI, it traces execution in Windows and Linux guests, from kernel functions to user-mode code, without installing software inside the analyzed virtual machine. Plugins log system calls, API calls and file, registry, process, socket and memory activity, extract files from memory before they are deleted and dump process memory, while an injector starts programs in the guest without an in-guest helper. CERT Polska's separate DRAKVUF Sandbox builds an automated sandbox with a GUI on top of it. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest tagged release: 1.0, published 2022-12-29 with Debian and Ubuntu packages. meson.build at the reviewed main commit of 2026-09-30 declares version 1.1, and the separate drakvuf-builds repository publishes per-commit drakvuf-bundle 1.1 packages for Debian bookworm and Ubuntu 22.04 and 24.04 with matching Xen 4.20.1 hypervisor packages, including a build of the reviewed commit. - Needs an Intel CPU with VT-x and Extended Page Tables; the README says DRAKVUF will not work on AMD or on Intel CPUs without them. DRAKVUF runs in Xen's dom0. The project website's installation guide, last updated 2022-12-29 for Xen 4.17 and mainly tested on Ubuntu 22.04, builds Xen from the bundled submodule, sets Xen boot options, asks for a dom0 kernel of 5.11 or newer and stores guest disks on LVM; DRAKVUF itself builds with meson and ninja. - The README lists Windows 7 and 8 (32- and 64-bit), Windows 10 64-bit and Linux 2.6.x to 6.x guests; the older website guide says Linux up to 5.x. The analyst installs the guest from their own operating-system media and generates a JSON kernel profile for LibVMI, from the Windows kernel's PDB with the bundled Volatility 3 pdbconv script or from Linux kernel debug symbols with dwarf2json; extra per-module profiles, such as one for tcpip.sys, enable plugins like socketmon. - Custom license: GPL version 2 only with the author's clarifications and exceptions, which read derivative works broadly, bar combining DRAKVUF with plain-GPL software and offer alternative licenses for proprietary use; GitHub does not classify it. Xen, LibVMI, Volatility 3 and dwarf2json are git submodules under their own licenses. The README presents it mainly for malware analysis. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### ViperMonkey > VBA parser and emulation engine, created by Philippe Lagadec and developed since 2017 mainly by Kirk Sayre and other contributors, for analyzing and deobfuscating malicious macros in Microsoft Office files such as Word, Excel, PowerPoint and Publisher documents, as well as VBScript files and HTA files carrying VBScript. The vmonkey command reads the macros through oletools' olevba, emulates them from their auto-run entry points or from functions the analyst names, and reports the recorded actions, such as process creation, along with optional intermediate IOCs and the files the code would write; vbashell is an interactive VBA shell. A Python API evaluates VBA snippets, walks and emulates individual code blocks, replaces functions and deobfuscates code. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Version 1.0.3, set in setup.py and vmonkey.py in 2021; there are no GitHub releases, tags or PyPI package, so it is installed from a master archive. The reviewed master commit, from 2024-04-25 and the latest at review, caps oletools at 0.60.1. The README says most development since November 2017 happens in Kirk Sayre's fork and is synchronised here regularly; at review that fork's master branch was 162 commits ahead of and 8 behind this one, with its latest commit from 2021-08-04. - Runs on Python 2.7: the README installs it under PyPy 2.7, recommended as about five times faster, or CPython 2.7, and the API tutorial uses Python 2 print statements. Dependencies are pinned for that interpreter, including pyparsing 2.2.0 because newer versions mis-parse or run out of memory on some samples, unidecode 1.2.0 and oletools 0.56.1–0.60.1, plus olefile, xlrd, xlrd2, prettytable, colorlog and colorama. Alternatively, docker/dockermonkey.sh pulls the third-party haroldogden/vipermonkey image, updates the checkouts inside it with git pull, starts headless LibreOffice, disconnects the container from the network and runs vmonkey with -s, --iocs and --jit. - The user supplies the suspicious documents or VBScript files; the repository includes no samples, and its tests are four Python modules. The README calls ViperMonkey experimental, working on some but not all maldocs, and extremely slow, recommending -s to strip useless statements. --jit converts VB loops to Python and runs them with eval, which the README flags as a security risk and suggests the Docker sandbox for; dropped files, including PE files found embedded in Office files, are written to a _artifacts directory with their SHA-256 hashes reported. Results depend on how far the engine emulates VBA, Office objects and called DLLs or ActiveX objects, which the README describes as hard and incomplete. - BSD two-clause terms stated in the README and source headers, copyright 2015–2020 Philippe Lagadec; there is no license file, so GitHub detects none, and the README's exception for a thirdparty folder refers to a folder absent from the reviewed commit. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### BREAD > Injectable real-mode x86 debugger for legacy BIOS code, boot code and DOS programs on real hardware or in a virtual machine. A small 16-bit assembly stub placed in the target code installs interrupt handlers, single-steps the processor and talks over a serial line to a Linux bridge, which translates its simple packets into the GDB remote protocol so GDB can read and write memory and registers, step, continue and set one hardware breakpoint and one watchpoint at a time. A companion script turns an address–label list into a minimal ELF symbol file for GDB. - Type: Tool - Targets: Binary · Firmware - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases are published. The reviewed master commit of 2025-10-21 fixes EIP handling in the interrupt-based mode; the previous code change, adding the symbolify tool, dates from 2023-10-19. Building needs a Linux host with GNU Make, a C compiler such as GCC, Clang or TCC, and NASM. The default build polls the UART at full CPU load, while UART_POLLING=no selects the interrupt-based mode, which is not the default because interrupts are not always enabled. - dbg.asm must be edited for each target, changing its ORG and return path and restoring any instructions replaced by the call into it, and the assembled dbg.bin then goes into the user’s own BIOS ROM image or runs as a DOS .COM program from a minimal FreeDOS or DOS boot floppy. Real hardware needs a serial connection to the Linux host. The repository ships no ROM; symbols/ami_ipm41d3.txt holds the author’s symbol names for one PCWare IPM41-D3 AMI legacy BIOS, which its header calls the author’s interpretation, not official or leaked symbols. - The README lists limits: the debugged code is unaware of the debugger, so a switch to protected mode, a changed IDT or a missing stack stops it from working, and BIOS code cannot be followed from the boot block because RAM must already be set up; a warm reboot can replay initialisation but may take a different path from a cold boot. Virtual machines need debug-register support, from a Bochs build with its x86 debugger enabled or QEMU with KVM, which the bundled qemu target uses with a floppy built from the included boot sector and debugger. - The repository has no tests or CI; the README links a demonstration video that changes the CPU name string. MIT license by Davidson Francis; firmware and programs being debugged keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Mergen > Function-level lifter that symbolically lifts one x86-64 function from a Windows PE binary into LLVM IR, then iterates LLVM and custom passes to a fixpoint so obfuscated or virtualized code reduces to simpler control flow and semantics for analysis. Its scope document lists 119 instruction handlers, two-way branches and tested jump-table shapes; README examples lift small test functions the authors protected with VMProtect and Themida, and the IR can be compiled for viewing in a decompiler. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.7, published 2026-03-29, with Windows lifter and microtest executables for the iced and Zydis decoder backends. The reviewed main commit, dated 2026-05-08, is 150 commits past the later v0.8 tag, which has no release. docs/SCOPE.md limits support to x86-64 PE files and one function per run: 32-bit x86, other formats and architectures, self-modifying code, floating-point or AVX code beyond the listed SSE2 integer instructions and whole-binary lifting are unsupported, and general-purpose decompilation is a non-goal. - The lifter takes a PE file and the target function's address, with optional --outline addresses; analysts supply their own binaries. The VMProtect check runs against local protected samples that are not committed, and the reviewed tree holds source, assembly and C test sources and documentation rather than prebuilt executables. Output is LLVM IR text plus output_diagnostics.json, which records unresolved indirect jumps and returns. - Developed and CI-tested mainly on Windows with CMake, Ninja, clang-cl using MSVC headers and libraries, LLVM 18 and Rust/Cargo for the default iced backend; the Zydis-only lane builds from a vendored Zydis 4.1.0 amalgamation, and linux-pe is a git submodule. A secondary Ubuntu 22.04 Dockerfile builds and exports a Linux lifter. - docs/SCOPE.md reports 115 of 119 handlers covered by a Unicorn-generated oracle suite, 33 semantic samples with 177 runtime cases checked under lli, golden IR hashes and Windows build lanes in CI, and says reliability on protected code varies by protection level. The README's branch example still says jumps with more than two targets are unsupported, while the newer scope document lists tested jump-table shapes. These gates cover the project's own compiled samples, not arbitrary protected software. - LICENSE is GPL-3.0; the vendored Zydis source and the submodule keep their own licenses. Lifted IR still needs analyst validation. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### readpe (formerly pev) > Command-line toolkit, formerly named pev, for analyzing 32- and 64-bit Windows PE files. readpe prints the DOS, COFF and optional headers, sections, data directories, imports and exports, while companion tools disassemble code (pedis), hash the file, headers or sections with ssdeep and imphash among others (pehash), list and extract resources (peres), match packer signatures (pepack), flag traits such as TLS callbacks, high entropy or an unusual entry point (pescan), report ASLR, DEP/NX, SEH and stack-cookie flags and dump certificates (pesec), find strings and convert between file offsets and RVAs. Output plugins write text, CSV, XML, HTML or JSON, and the bundled libpe C library provides the parser. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.85.1, published 2025-08-29 to correct the version string reported by v0.85 (2025-08-08); only the older v0.81 and v0.82 releases attach Windows ZIP builds. The reviewed master commit, from 2026-07-08, is five commits ahead, fixing peres version output and ordinal-only imports and moving the macOS CI build to a newer OpenSSL. The README explains the rename from pev and that libpe was merged into this repository. - Built from source with make and a C compiler and needs OpenSSL development headers. On Linux, make install puts files under /usr/local, and /usr/local/lib must be registered with ldconfig so libpe.so is found; macOS builds pass Homebrew OpenSSL paths in CFLAGS and LDFLAGS, and Windows builds use Cygwin with gcc-core, binutils, make, zip and libssl-devel, where make zip also builds cpload and bundles the needed Cygwin DLLs. CI only compiles on Linux, macOS and Cygwin. - Input is a PE file the user supplies. The other tools parse it, but the Windows-only cpload loads a Control Panel (.cpl) item and sends it CPL messages for debugging, so it runs that item's code. pepack depends on the bundled userdb.txt list of PEiD-style signatures, whose header counts 3,520 entries without naming their source, and pescan and pesec report heuristic indicators and header flags rather than verdicts. - tests/run.sh runs each tool in every output format and diffs the results against an expected_outputs directory that is not in the repository; valgrind scripts and a helloworld.exe sample built from tests/samples_src with MinGW are also included. CI does not run these tests. - The tools are GPL-2.0-or-later with an OpenSSL linking exception, lib/libpe is LGPL-3.0, and the bundled udis86 disassembler keeps its BSD notice. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### malware-jail > Node.js sandbox for semi-automatic analysis of JavaScript malware: it runs a sample in Node's vm module against emulated Windows Script Host and ActiveX objects such as WScript.Shell, MSXML2.XMLHTTP, ADODB.Stream, Scripting.FileSystemObject and WMI, plus a partial browser context with selectable browser profiles. It logs the objects created and methods called, keeps every eval() argument to help deobfuscation, records requested URLs and WMI queries, and saves the files a dropper tries to write so payloads can be examined. When the run ends, the whole sandbox context is dumped to JSON for review. - Type: Tool - Targets: Binary · Website - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - There are no releases or tags, and the README says an npm package is not yet available. The reviewed master commit, from 2023-06-16, only edits the README; the last code change, adding newly analyzed malware and ADODB methods, dates from 2019-08-08. Version labels disagree: package.json says 0.18.0, the README 0.19 and jailme.js 0.20. - Requires Node.js and npm: package.json declares Node 6 or later, and the README says the tool was developed and tested on Linux with Node.js v6.6.0. npm install fetches minimist, iconv-lite, entities and sync-request, npm test runs a small tap suite for the WScript emulation, and native_test holds scripts meant to run under Windows cscript for comparison. Emulation covers the WScript and ActiveX features the author saw malware use and only part of the browser context, so a sample may stop early or diverge from real Windows behavior; the logs and dumps are traces for an analyst, not a verdict. - Node's vm module is not a security boundary: the README warns that sandbox-aware malware may try to escape and recommends an unprivileged Linux account or a virtualized Windows machine. By default HTTP requests are not sent and receive dummy responses; --down lets the sample contact remote servers and download payloads, while --h404 and --t404 answer every request with HTTP 404 so all remote URLs can be listed. Execution stops after 60 seconds unless -t sets another limit. - The malware folder holds real-world samples, most of them downloaded from malwr.com according to the README, with their logs and dumps. Besides scripts and HTML pages it includes two extracted Windows payload files, a .exe under malware/20171004 and a .tmp under malware/20190808, and the README states that the Angler files are not disarmed, so a clone contains live malware. - MIT, per the LICENSE file and README. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### gxpc > macOS command-line XPC sniffer, inspired by xpcspy, that injects a Frida agent into an attached or newly spawned process and logs the XPC messages it sends and receives, labelled with the libxpc function, connection name, peer PID and process name. The agent recursively converts xpc_object_t dictionaries, arrays and scalar values into readable output and decodes binary-plist payloads, while a Go host built on frida-go selects a local, USB or remote Frida device, filters connections by name or PID and can save the trace to a file. It observes how Apple-platform apps and services communicate over XPC and does not alter or inject messages. - Type: Tool - Targets: App · Protocol - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.2.1, published 2025-08-12, with macOS x86_64 and arm64 archives that GoReleaser links against the Frida 17.2.16 core devkit; the reviewed main commit adds only a cobra dependency bump (2025-09-02). Installing with go install instead needs Go, cgo and the Frida devkit set up as frida-go documents; go.mod declares Go 1.20 and frida-go 1.0.0. - On first run the binary writes its embedded TypeScript agent and package files to a gxpc folder in the system temp directory, runs npm install for frida-objc-bridge and compiles the agent with Frida’s compiler, so Node.js, npm and network access are needed at least once; the compiled agent is then reused. The analyst picks the target by PID, process name or a file to spawn, on a local device (-i local), a USB device (the default) or a remote Frida server; the README documents no device setup or tested OS versions. - Outgoing messages come from hooks on the public libxpc send, reply and notification functions, and new connections from xpc_connection_create_mach_service and xpc_connection_set_event_handler. Incoming messages rely on the private _xpc_connection_call_event_handler and __CFBinaryPlistCreate15, which the agent resolves from debug symbols and caches as offsets per machine and OS build in gxpc.conf in the user’s home directory (or a file given with -c). bplist16 payloads are decoded through an external jlutil executable when one is installed on the host, otherwise by the agent’s own parser or as base64. In the reviewed main.go the --whitelistp option reads the --whitelist value, so PID allow-listing may not work as documented. - MIT. frida-go, the Frida devkit and frida-objc-bridge keep their own licenses, and jlutil is a separate third-party tool not shipped with gxpc. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Manticore > Trail of Bits' now-archived symbolic execution tool for Linux ELF binaries on x86, x86-64, AArch64 and ARMv7, Ethereum smart contracts as EVM bytecode, and WebAssembly modules. It runs a program on symbolic inputs to explore the states it can reach, generates concrete inputs that lead to a chosen state and detects crashes and other failures, solving constraints with an external Yices, Z3 or CVC4 solver. The manticore CLI writes generated test cases to an mcore_ workspace, while the Python API adds instruction hooks, event callbacks and custom initial states; manticore-verifier checks contract properties written in the contract's own language. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Archived and unmaintained: the README states that the project is no longer internally developed and maintained, and GitHub marks the repository archived. The reviewed master commit, from 2026-06-24, only changes that status; the last change under manticore/ dates from 2022-08-07. The latest release is 0.3.7 on GitHub and PyPI (2022-02-17), and PyPI's nightly 0.3.8.dev builds end on 2024-02-27. - Requires Python 3.7 or later. pip install manticore covers EVM and WASM, manticore[native] adds the pinned capstone 5.0.0rc2 and unicorn 2.x needed for native binaries, and a trailofbits/manticore Docker image is offered. The README names the latest Ubuntu LTS on GitHub Actions as the supported platform, gives macOS experimental EVM and WASM support but no native-binary support, and recommends a larger stack limit; CI at the reviewed commit still runs Python 3.7 on ubuntu-20.04. - Inputs are the user's own ELF binaries, Solidity or Vyper sources or EVM bytecode, or WASM modules. Contract analysis needs solc on PATH and compiles through crytic-compile; the README says EVM Istanbul semantics are not fully implemented, so some opcodes may be unsupported. Whole-program CLI runs are prone to state explosion, which the README suggests limiting by tailoring the initial state through the API. - CI runs ethereum, native, WASM, examples and other test suites after downloading Yices 2.6.2 and solc 0.4.24. tests/native/binaries and examples/linux/binaries hold small prebuilt Linux test programs for amd64 and ARMv7, some with their C sources; larger examples, including CTF problems, live in the separate manticore-examples repository, and server/ holds an unpublished gRPC wrapper for the Manticore UI. - AGPL-3.0; the README says Trail of Bits can be contacted for an exception to its terms. The ASE 2019 paper (arXiv 1907.03890) describes the tool. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Ghidra Ninja ghidra_scripts > Thomas Roth's (Ghidra Ninja) collection of Ghidra Python scripts, which appear under a Ghidra Ninja category in the Script Manager. binwalk.py and yara.py run binwalk or bundled YARA crypto-constant rules over the loaded program and bookmark the findings, YaraSearch.py does the same with a rule file the user chooses, swift_demangler.py demangles Swift function names, golang_renamer.py restores function names in stripped Go binaries from the .gopclntab table, and export_gameboy_rom.py writes a working ROM back out of a Game Boy program imported with GhidraBoy. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags; the last commit is a merge from 2020-10-07. Open issues filed between 2020 and 2025 report problems including golang_renamer data-type errors, a binwalk.py temporary-file error and an out-of-memory failure, with no later commits. - Installed by adding the checked-out repository as a script directory in Ghidra's Script Manager. The scripts are Python 2 code for Ghidra's Jython interpreter, and the README names no supported Ghidra version. binwalk.py, yara.py and YaraSearch.py need binwalk or yara on PATH, swift_demangler.py needs the swift toolchain, and export_gameboy_rom.py needs the GhidraBoy extension. - Input is a program the analyst has loaded into Ghidra; export_gameboy_rom.py works on a Game Boy ROM the user imported, and an open issue says it fails for single-page ROMs. golang_renamer.py only searches for the .gopclntab header used before Go 1.16, and an open issue asks for Go 1.16 support. YARA and binwalk hits are signature matches. - GPL-3.0 (LICENSE). The README says the bundled yara-crypto.yar rules are licensed under GPLv2, with an added SHA256 rule credited to @phoul, and credits golang_renamer.py as a port of George Zaytsev's go_renamer.py. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### FindCrypt - Ghidra Edition > Ghidra script that ports Ilfak Guilfanov's FindCrypt plugin for IDA, searching a program's memory or the current selection for constants of cryptographic and compression algorithms. Its serialized signature database keeps the original plugin's 79 algorithm constant sets and, by the README's count, holds 122 detectable constants for hash functions, block and stream ciphers, Curve25519 code, Keccak and zlib; when a whole constant is absent, the script also looks for its individual elements and reports partial matches above a detection threshold. Hits become Ghidra bookmarks and a results table from which matching data can be defined. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README says the project is discontinued because its author cannot keep it maintained, and points to forks such as TorgoTorgo/ghidra-findcrypt. The reviewed master commit dates from 2021-03-18; the last release, 1.5 of 2020-04-17, attaches FindCrypt.java and database.d3v, and the script and database both report version 7. No supported Ghidra versions are stated; the installation example path names Ghidra 9.0. - Installation is manual: copy FindCrypt.java into Ghidra's Features/BytePatterns/ghidra_scripts directory and the findcrypt_ghidra database folder into the user's home directory, then run the script from the Script Manager on a program already loaded in Ghidra. Headless runs print the results instead of opening the table. - By default each run contacts raw.githubusercontent.com to compare script and database versions with this repository and downloads a newer database.d3v into the home-directory folder; the README describes the __FORCE_NO_DBUPDATE and __FORCE_NO_SCRIPTUPDATE flags in the script that turn this off. - Detection is a byte search for known constants, so hits mark candidate locations, and code that carries no table constants is not found. New signatures are built with the FCExporter Visual Studio project in Utils, which needs Crypto++ for compression. - GPL-3.0, with the Crypto++ license notice included for the exporter. The README credits Ilfak Guilfanov's original plugin, and the database changelog credits contributor Pawlos with its current format. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Binary Refinery > Large collection of composable Python command-line units for transforming binary data: encodings, compression, encryption, archive and executable-format extraction, carving and pattern search. Each unit reads stdin and writes stdout, so units chain into shell pipelines, while framing, multibin arguments and meta variables let one pipeline process many chunks, and the binref command searches unit help. The author describes it as a command-line take on CyberChef focused on malware triage; the README also points to a separate binref/agent repository of instructions for language-model agents that use refinery. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 0.11.2, uploaded to PyPI on 2026-07-14 and requiring Python 3.10+. The reviewed master commit of 2026-10-11 is 1,138 commits past that tag and still reports version 0.11.2, while its changelog already lists breaking 0.11.3 changes, including Python 3.11+ and renamed meta variables. The README says refinery is still in alpha and that units and parameters can be renamed or removed. - Installed with pip as binary-refinery, preferably into its own virtual environment. The default, extended and all extras add progressively more optional dependencies, and units name a missing dependency when run. Installation creates one shell command per unit, optionally with a prefix to avoid name clashes. The README rates Bash and CMD support as good, PowerShell 7.4+ as reasonable, and Zsh and Fish as having minor issues. Several decompression and cipher routines have Cython extensions next to pure-Python versions. - Inputs are the analyst's own files or data piped on stdin. CI runs pytest on Windows, macOS and Ubuntu with Python 3.11 and 3.13. Tests that need real-world inputs fetch encrypted files from the separate binref/refinery-test-data repository. Unit output depends on the parameters chosen and needs analyst validation. - LICENSE.md is the 3-Clause BSD License, which GitHub does not classify. refinery/lib/thirdparty keeps third-party modules under their own licenses, and refinery/lib/seven ports compression code from 7-Zip. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### AngryGhidra > Ghidra extension that runs angr symbolic execution from a CodeBrowser panel. The analyst marks a destination address, an optional start address and addresses to avoid with hotkeys, and can make program arguments, memory ranges or registers symbolic, write concrete values into memory and registers, hook instructions or apply bytes patched in Ghidra to the angr project. A bundled Python script runs angr's explorer on the program's original file, the listing highlights the instructions along the path it finds, and the panel shows the argument, memory and stdin values that reach the destination. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.1, published 2024-02-13, with prebuilt extension archives for Ghidra 11.0 and 11.0.1; the older 0.1 release carries builds for Ghidra 9.1.2 through 10.3. The reviewed master commit of 2024-07-29 is two commits later, changing the plugin type and the README. Compatibility with newer Ghidra releases is not stated. - Install angr with pip for Python 3 and put python3 on the PATH; the plugin starts the bundled angryghidra.py as an external process and passes the analyst's settings through a temporary angr_options.json file. No angr version is pinned. Building from source uses Gradle with GHIDRA_INSTALL_DIR, followed by File → Install Extensions in Ghidra; if no new-plugin prompt appears, enable AngryGhidraPlugin under File → Configure → Miscellaneous. - angr loads the binary from the path Ghidra recorded at import, so the original file must still be there; raw binaries are loaded as blobs with the architecture of the Ghidra language. The analyst supplies the binary and chooses the find, avoid, hook and symbolic-input settings. Path explosion, unmodeled environment behavior and solver limits remain angr's, and a found path gives one satisfying input. - The README demonstrates it on the SecurityFest 2016 fairlight CTF challenge from angr's examples; no other results or tests are published. MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### fpicker > Frida-based fuzzing suite for closed-source programs, listed here for its in-process instrumentation and coverage layer. A JavaScript harness injected with Frida starts Stalker at an analyst-chosen function and records the basic blocks executed in the target module on each call, feeding either AFL++'s coverage bitmap or fpicker's own standalone mode. Its passive mode works as a tracer: it attaches to a running process without sending inputs and stores each input that reaches the function together with new coverage, on the local host or on USB and network devices running frida-server. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - There are no releases or tags. The reviewed main commit, from 2025-07-24, moves the harness to the Frida 17 APIs, and the Makefile pins frida-core 17.2.14. The README points to a 2021 blog post for background and says fpicker builds on ToothPicker, developed during the author's master's thesis, and was mostly written at ERNW. - make fpicker-macos, fpicker-linux or fpicker-ios builds the C host program; the Makefile downloads the matching frida-core devkit from Frida's GitHub releases, although the README still describes placing the devkit files by hand. iOS builds use Xcode's iPhoneOS SDK on macOS, harness scripts are bundled with frida-compile, and AFL++ is needed only for AFL++ mode, built with USEMMAP on macOS and iOS. - Each target needs a hand-written harness that names the function where instrumentation starts and, for in-process input, how to call it, so that function and its arguments must first be identified in the target. The README warns that coverage becomes unreliable if the function runs more than once per iteration. Shared-memory communication is unavailable for USB-attached devices, and attach mode does not respawn a target that crashes. - Coverage covers basic blocks in the target module during the instrumented call, not a whole-program trace. The examples are small project-written C programs with seed inputs and slides from a WiSec 2021 tutorial; the repository has no automated tests or CI. - MIT; Frida and AFL++ are separate projects with their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### RetroWrite > HexHive's static binary rewriter for x64 and aarch64 Linux ELF binaries, which turns a binary into symbolized, reassemblable assembly so instrumentation can be inserted without source code and without heuristics. Bundled passes add a binary-only AddressSanitizer and AFL coverage instrumentation, plus a coarse-grained control-flow-integrity pass on aarch64, and the symbolized assembly can also be edited by hand or by other tools before reassembly. The KRetrowrite variant of the x64 rewriter instruments Linux kernel modules with BASan or kcov for kernel fuzzing. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - There are no releases or tags, and setup.py says 1.0.0. The reviewed master commit, from 2025-04-26, adjusts an x64 pass added four days earlier that randomizes instruction order within functions; before that, the latest commits, from 2023 and 2024, fixed capstone options and executable stacks on older kernels. - Written in Python 3 (the README names 3.6) with pyelftools, capstone 4.0.2 or later, intervaltree and archinfo pinned to 9.1.11752, which the README says to install with pip rather than from distribution packages. x64 output is reassembled with an ordinary compiler such as gcc, linking -lasan for BASan, or with afl-gcc or afl-clang for AFL coverage; on aarch64, retrowrite -a assembles and links. The README's KRetrowrite setup calls a setup.sh that sits in the demo folders rather than at the repository root. - Inputs are the user's own binaries or kernel modules. Per the README feature table, the x64 rewriter needs position-independent, unstripped binaries from standard compilers and has no C++ support, while the aarch64 rewriter also takes stripped and non-PIE binaries but not kernel modules or C++; --ignore-no-pie and --ignore-stripped skip the checks, to be used with caution. The two architectures use different rewriting algorithms: the IEEE S&P 2020 paper describes the x64 version and a separate HexHive thesis the aarch64 version. - CI runs a SPEC CPU benchmark script on a self-hosted runner, and test scripts clone and rewrite coreutils, SQLite and Debian packages. Demos cover userspace, kernel-module and fuzzing setups; the Docker fuzzing demo bundles fuzz seeds and a patched AFL 2.52b archive but also needs a self-built clang 8, a git bundle of the repository and the separately downloaded LAVA-M corpus, and kernel fuzzing setup downloads about 10 GB of syzkaller VM files. - MIT according to the LICENSE file and README, although GitHub does not recognize the license; capstone is included as a submodule under its own license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Interruptor > Frida library, taken from the Dexcalibur project, that uses Frida’s Stalker to trace a process’s system calls and print strace-like lines with the calling thread, module and offset, decoded flag values and file paths resolved from descriptors. A trace can be limited to chosen modules and syscalls by name or pattern, started when a given library loads, extended with Interceptor-style per-syscall callbacks, and used to write drcov basic-block coverage files. The README documents Linux and Android on AArch64 and x64; the source also contains AArch32 Linux and macOS arm64 and x64 entry points. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest npm release at review: @reversense/interruptor 1.0.12, published 2023-04-02; the newest GitHub release is v1.0.9 (2023-03-29). The reviewed main commit of 2026-09-23 adds unreleased changes, including refactored arm64 register handling and a preadv2/pwritev2 argument fix, without a version bump, and the README still calls the project a work in progress. - It is used inside the analyst’s own Frida agent: install the npm package, build from source with npm and TypeScript, or load a webpack-bundled per-architecture script. The README says passing a TypeScript agent directly to frida needs Frida 16 or later, and package.json depends on @types/frida-gum ^17.3.0. Android examples attach to a USB device with frida -U; the README warns that the CodeShare quick-start cannot be configured and may fail on obfuscated or multi-threaded apps. - The README’s support list names the Linux syscall API on AArch64 (SVC, with HVC marked work in progress) and x64 (SYSCALL); the AArch32 Linux and macOS factories in the source have no documented status. The agent tracer cannot follow child or multiple processes, and a standalone host-side tracer is marked TODO. Coverage needs an output path the target process can write. CI runs Mocha tests of the Linux AArch32 and arm64 factories on Node 16; no device test results are published. Intended for software the analyst is authorized to inspect. - package.json and the npm metadata declare GPL-3.0-only, but the LICENSE file is x64dbg’s modified GPL-3.0 text, whose added exception concerns x64dbg plugins rather than this project, so GitHub cannot classify it. The README also promotes the separate commercial Dexcalibur Pro. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### dyld_cache_extract > macOS application and command-line tool that reads a dyld_shared_cache file from macOS or iOS, shows its header, mappings and image list, and copies one library or every library out to a directory. The CLI offers --info, --extract and --extract-all; the GUI presents the same header details and lets users select images to extract. The README marks the project obsolete and points to the author's dyld-cache-dump. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README marks the project obsolete and refers users to dyld-cache-dump. The last commits, on 2023-06-12, fix the build for the then-current Xcode and update CI and the README. Releases 0.1.0 (2017-03-06) and 0.1.1 (2017-06-18) each attach a zipped Dyld Cache Extractor app; there is no newer release. - Builds on macOS with Xcode from dyld_cache_extract.xcodeproj, whose schemes cover the CLI tool, the GUI app and the DCE static library; the PIMPL, GitHubUpdates and xcconfig submodules must be initialized. CI builds and analyzes Debug and Release configurations of the CLI and GUI on macos-latest, with tests disabled. - Needs a dyld_shared_cache file from the user's own macOS or iOS system; the repository contains no caches or extracted libraries. The parser reads only the original header fields (magic, mapping and image tables, dyld base address) of a single cache file and copies each image's bytes plus the __LINKEDIT region; the reviewed code has no split sub-cache handling, and support for current macOS or iOS caches is not documented. - MIT license (2016, Jean-David Gadina, XS-Labs). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### FLARE IDA Pro utilities > Archived collection of IDAPython plugins and scripts from Mandiant's FLARE team for malware and native-code analysis in IDA Pro. It searches code for precomputed API-name hashes used by shellcode, recovers strings built on the stack (statically, or by emulation with flare-emu in ironstrings), applies function types to structure fields and indirect calls, annotates imports with MSDN function, argument and constant information, and uses idb2pat to generate pattern files from an IDB's functions for building FLIRT signatures. Other scripts track static arguments to functions such as string decoders, link Objective-C selector references to their implementations in Mach-O files, and graft stub implementations of common Windows API imports so that decoding or unpacking code can run under IDA's Bochs emulation. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository is archived and read-only, with no releases or tags; the reviewed master commit of 2024-10-29 is its last. Nothing is packaged: the README says to copy plugins/ into IDA's plugins folder and python/ into IDA's python folder or onto PYTHONPATH, and scripts such as annotate_IDB_MSDN.py, ironstrings.py and code_grafter.py are run through File → Script file. - Needs IDA Pro with IDAPython; the README gives Windows %PROGRAMFILES% paths and names no supported IDA version. The code spans several IDA generations: apply_callee_type was fixed for IDA 7.6 SP1 and idb2pat was ported to Python 3, while stackstrings, argtracker and the decompiler_scripts still use Python 2 syntax, and the StackStrings plugin warns that it only works under Python 2 because of its vivisect dependency. Dialog-based tools import PyQt5; ironstrings, objc2_analyzer and revil_string_decrypt need flare-emu and Unicorn, the decompiler_scripts need the Hex-Rays decompiler, and code_grafter targets IDA's Bochs IDB emulation mode. - Samples and IDBs come from the analyst. The repository bundles sc_hashes.db, a SQLite database of about 50 MB holding precomputed hashes of export names from Microsoft DLLs, with make_sc_hash_db.py to rebuild it from a DLL directory the user chooses. The MSDN annotator expects an MSDN_data directory that is not shipped; the MSDN_crawler script builds it with Python 2.7 from an extracted copy of the MSDN documentation and IDA's tilib. - There are no tests or CI. Behaviour is documented through the README, per-tool READMEs and linked FireEye and Mandiant blog posts. - Apache-2.0 for the repository, while msdn_crawler.py is a GPL-2.0-or-later derivative of the zynamics msdn-crawler. IDA Pro, the Hex-Rays decompiler and Microsoft DLLs and documentation keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Binlex > Binary trait-lexer framework that extracts instructions, basic blocks and functions from executables and emits searchable JSON traits for similarity, hunting and signature work. It models code with a genomics-inspired hierarchy and computes features such as MinHash, TLSH, SHA256, entropy and wildcard byte patterns, so samples can be compared, clustered and turned into signatures at scale. It ships a CLI suite, a Rust API, Python bindings and an IDA plugin, can generate YARA rules from its patterns, and runs processors locally or over IPC and HTTP. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit declares a Rust 2024-edition workspace at version 2.0.0. The latest stable GitHub release is v1.1.1 (2023-03-04); the v2.0.0 line is still at release candidates, the most recent being v2.0.0-rc2 (2025-01-14), whose prebuilt zips cover Linux (Debian and Arch), macOS (amd64 and aarch64) and Windows, plus an IDA plugin archive and a server archive. The reviewed master is ahead of those tags. - The README lists Linux, macOS and Windows; input formats PE, ELF and Mach-O; and AMD64, I386 and CIL architectures, with disassembly through Capstone 0.12. Build and install with cargo build --release --workspace, build the Python bindings with maturin, package with make zst/deb/wheel, install the IDA plugin with pip and python -m binlex_ida install, and the repository also provides Docker Compose files for its server, web, MCP and Python images. - Supply the binaries to analyze yourself; the repository commits no sample binaries, and its tests are Rust source. Binlex extracts static traits and hashes and generates patterns and YARA rules; it does not run the target, and derived signatures and similarity scores still need analyst validation. - MIT license; contributions require signing the repository's CLA. ##### Primary sources 1. 2. 3. 4. 5. #### Driver Buddy Reloaded > IDA Pro Python plugin for triaging Windows kernel drivers, building on NCC Group's original DriverBuddy. Its auto-analysis identifies the driver model (WDM, KMDF, UMDF, WDF, Mini-Filter, Stream Minidriver, AVStream or PortCls), locates the device-control dispatch routines, labels IRP, IO_STACK_LOCATION and WDF structures and calls, and discovers and decodes IOCTL codes through Hex-Rays ctree, switch-table and immediate-operand scans. It also reports device names, symbolic links and device ACLs, pool tags, flagged APIs and opcodes, name-based call chains and heuristic vulnerability leads with per-IOCTL risk scores, in an IDA findings window, a JSON file and an HTML report. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2.5.1, published 2026-07-08 as a zip; the reviewed main commit of 2026-10-19 is four commits later, adding an IOCTL-recovery fix for issue #41 with a new regression fixture, DriverEntry typing for the MajorFunction annotator and the licence change noted below. The README says it runs on IDA 7.6+, 8.x and 9.0+ with Python 3, with API differences handled by ida_compat.py, and ida-plugin.json lists Windows, Linux and macOS hosts. IDA 9.0+ installs it with hcli plugin install; 7.6 and 8.x need the script and its package folder copied to the top level of the plugins directory. - Analysts load their own Windows kernel driver (.sys) in IDA. The Hex-Rays decompiler is optional but drives the strongest IOCTL scan, with switch-table and immediate-operand scans as fallbacks, and the experimental DispatchDeviceControl search works only for x64 drivers. Each run writes findings.json, report.html, pooltags.txt and an analysis log next to the IDB, and optional stages are toggled in config.py. - tests/test_dbr.py is a pure-Python regression suite that needs no IDA; run_cross_version.ps1 runs the pipeline under IDA 7.6 SP1, 8.4 and Free 9.3, and run_golden.ps1 compares findings on reference drivers with committed golden JSON captured with the IDA 8.4 decompiler. The README reports that decompiler-based scanning raised IOCTL recovery from 7/28 to 28/28 on HEVD and from 4/17 to 17/17 on ALSysIO64 with no false positives. There is no CI, and these results are project-reported. - tests/drivers bundles IDA databases (.i64) and golden findings for eight reference drivers as regression fixtures: ALSysIO64, HEVD, IObitUnlocker, MODAPI, WinRing0x64, amp, beep and zam64 .sys. Those drivers keep their own vendors' terms. - LICENSE was replaced on 2026-07-10 with the PolyForm Noncommercial License 1.0.0, which permits only noncommercial purposes, while release 2.5.1 and earlier carry GPL-3.0 and ida-plugin.json still declares GPL-3.0. IDA Pro and Hex-Rays keep their own terms. The README calls its findings heuristic lead generators for manual review rather than confirmed vulnerabilities. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### FA (Firmware Analysis) > Python framework, mainly used as an IDA plugin, that turns the manual steps of locating symbols, such as finding a string, following its cross-reference and taking the function start, into reusable signatures. Hjson SIG files, grouped into per-platform projects, chain commands that search bytes, strings, immediates or Keystone-assembled opcodes, filter by operands and cross-references, and then set names, types, constants, enums and struct members; Python scripts can drive the same interpreter. In IDA it adds an FA menu and toolbar to find all of a project's symbols, draft a temporary signature from the current function and export symbols plus a C header, and a separate loader runs signatures over a raw ELF file without IDA. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.0.11, published 2026-03-25 without attached files; it tags the reviewed master commit, and the same version is on PyPI as fa 1.0.11. The README installs it by cloning the repository and running pip install -e, says the code base is very IDA-oriented and only considers Ghidra, radare2 or other disassemblers for the future. - The README supports IDA 8.0+, and a March 2026 commit added IDA 9.0 support to make-offset. The package requires Python 3.8+; its dependencies, including keystone-engine, capstone, hjson and rpyc, are installed into IDA's Python. IDA can also run the plugin in script mode to write a symbols file, while the ELF loader script imports pyelftools, which is listed only in the testing requirements. - The binaries, IDA databases and signatures come from the analyst: the repository ships only two small test projects under fa/signatures and no signature sets for real firmware. The README groups signatures into projects partly to lower false positives, and the ELF loader reports symbols with several matches instead of choosing one. - CI lints with flake8 and runs pytest on Python 3.8 to 3.12; the tests check find-bytes on mocked memory segments and ELF symbol search on a small ARM ELF built at test time with Keystone and simpleelf, and neither runs IDA. GPL-3.0 license text; pyproject.toml classifies it as GPLv3 or later. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### pyinstxtractor-ng (PyInstaller Extractor Next Generation) > Fork of PyInstaller Extractor (pyinstxtractor) by the same author that extracts the bundled CArchive files and PYZ modules from Linux ELF and Windows PE executables built with PyInstaller, writing .pyc files with repaired headers for a separate bytecode decompiler. Unlike the original script, it unmarshals the PYZ archive with the xdis library, so it does not have to run under the Python version that built the executable, and it automatically decrypts PYZ entries that PyInstaller's optional AES encryption protected, using the key module bundled in the same executable. A one-directory mode extracts the PYZ next to the other files so the result can be run directly, and --info prints archive metadata such as versions, entry points and encryption without writing files. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2026.07.03, published 2026-07-03, with a Linux binary and a Windows .exe built by PyInstaller, so those builds need no Python installation; the same version is on PyPI as pyinstxtractor-ng 2026.7.3. The reviewed main commit is two commits ahead of that tag and only relaxes the pycryptodome requirement from exactly 3.17 to 3.19.1 or later below 4. - Running the script needs Python 3.8+, xdis pinned to 6.3.0 and pycryptodome; a leftover Poetry section in pyproject.toml still caps Python below 3.13. Release binaries come from a manually triggered workflow that builds with Python 3.8 and PyInstaller 5.10.1, and the repository has no tests or test executables. - The script header lists PyInstaller 2.0 through 5.10.1 as supported, and the README states no version range. Entries that can be neither decompressed nor decrypted are saved unchanged with an .encrypted suffix. - The PyInstaller executable comes from the user, and turning the recovered bytecode into source needs a separate decompiler. Recovered code remains subject to the rights of the original program’s owner. - GPL-3.0-only. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### CoBRA (Coefficient-Based Reconstruction of Arithmetic) > Trail of Bits' C++23 simplifier for Mixed Boolean-Arithmetic (MBA) expressions, an obfuscation technique that rewrites simple computations as interleaved arithmetic, bitwise and shift operations. Given an expression and a bit width from 1 to 64, cobra-cli returns a simpler equivalent: a worklist scheduler combines signature-vector and change-of-basis techniques, semilinear handling of constant masks, polynomial recovery, decomposition of mixed products and subexpression lifting, and each result is checked on random inputs or, optionally, with a Z3 equivalence proof. The same engine is available as a library and as an optional LLVM pass plugin that simplifies MBA expressions it detects in LLVM IR. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.3.0, published 2026-06-30 without prebuilt binaries. The reviewed master commit is eight commits ahead: README edits, a CI dependency bump, a fix that requires LLVM only when the pass is built, and a fix that lets cobra-core build under MSVC. - Builds from source with CMake 3.20+ and a C++23 compiler (GCC 13+, Clang 17+ or Apple Clang 16+); a dependency superbuild builds Abseil and Highway, and GoogleTest when tests are enabled. The LLVM pass plugin needs LLVM 19 to 22, runs through opt as cobra-simplify, replaces an expression only when the simplified form is cheaper and drops nuw/nsw flags. Z3 checking is compiled in only when CMake finds Z3; otherwise cobra-cli warns that --verify is ignored. CI builds with Clang 22 and LLVM 22 on Ubuntu 24.04 on every run, and with GCC 14 and on macOS 15 only for version tags; Windows is not in CI. - cobra-cli takes the obfuscated expression as text, with at most 16 variables by default, so expressions in a binary must first be recovered with other tools or reach the pass as LLVM IR. The README's known limitations are deeply interleaved mixed-polynomial MBAs that exhaust the worklist budget, a few candidates that are correct only on Boolean inputs and are reported as verify-failed, and no general logic minimization. - The README reports 1,195 tests, and DATASETS.md reports 75,023 of 75,126 parsed expressions from 35 dataset files and seven sources simplified and spot-checked (99.86%). The OSES subsets are disabled for running out of memory or taking minutes per expression, so their figures come from an earlier run; DATASETS.md says the numbers are checked on every CI run, but the reviewed CI workflow excludes the dataset benchmark tests. - Apache-2.0 for CoBRA. The test/datasets files are redistributed from third-party research projects: THIRD_PARTY_LICENSES lists most as effectively GPL-3.0-only, Loki's as AGPL-3.0-only, and the OSES and ObfuscatorX sets with unspecified or unknown licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### ollvm-unflattener > Python command-line deobfuscator for the control-flow flattening applied by Obfuscator-LLVM (OLLVM). Given a flattened function's address, it uses Miasm's symbolic execution to track the dispatcher's state variable, records which blocks each state value selects and which state follows it, and writes a copy of the binary in which the function is reassembled with Keystone in its recovered order; an optional mode also follows the function's calls. The README covers 32- and 64-bit x86 Windows and Linux binaries and contrasts this approach with MODeflattener's static one. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.0, published 2025-04-16 without attached binaries; its notes call it most likely the final release, and the reviewed master commit is that tag and the repository's last push. The tool runs from a clone as python unflattener -i -o -t , with -a to follow calls; there are no tests or CI. - The README requires Python 3.10+ and Git; requirements.txt lists miasm, graphviz and keystone-engine without version pins. The code handles PE and ELF files for x86_32 and x86_64 and raises an error for other formats or architectures. - The analyst supplies the obfuscated binary and the target function's address. Functions scoring below 0.9 on a dominator-based flattening heuristic are left unchanged, the dispatcher and state variable are located by structural assumptions about OLLVM's layout, and -a only follows calls into the .text section. Output is a patched copy in which the original function bytes are overwritten with int3 padding and the reassembled function is written at its start. - The samples folder bundles small obfuscated test programs for 32- and 64-bit Linux and Windows (CFF.bin, CFF_full.bin, CFF_full_linux64.bin, CFF_win.exe, CFF_win_full.exe, CFF_win64.exe and CFF_win64_full.exe), their deob_* outputs and C/C++ sources for most of them; a comment in CFF_full.c says Claude generated that test program. The README's only reported result is a before/after control-flow graph of target_function in CFF_full.bin, with no check that deobfuscated binaries behave like the originals. - Apache-2.0; the dependencies keep their own licenses, including GPL-2.0-only for Miasm and GPL-2.0 with a FOSS exception for Keystone. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### GolangAnalyzerExtension > Ghidra extension whose Golang Analyzer reads the runtime header and module data in Go binaries built with go1.6 through go1.27 to identify the Go version, rename functions, correct their arguments, comment source files and line numbers, add Go types to the Data Type Manager and label Go strings. A plugin window lists the recovered functions, types, source files and strings with links to Go source, and WebAssembly builds are handled when a separate Wasm loader such as ghidra-wasm-plugin is installed. A bundled script also renames functions that decode gobfuscate-style obfuscated strings and comments the decoded text. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.4.0, published 2026-07-21 from the reviewed master commit, with notes stating support for go1.6 through go1.27. It provides prebuilt zips for Ghidra 12.0 through 12.0.4 and for 12.1, 12.1.2, 12.1.3 and 12.1.4, the last two built on 2026-10-14; install the zip matching the Ghidra release through File > Install Extensions and restart Ghidra. Source builds use Gradle with GHIDRA_INSTALL_DIR set to a Ghidra installation. - Analysis runs on Go executables the user supplies, and the analyzer is enabled by default. Source has function handlers for x86, ARM, PowerPC and RISC-V; WebAssembly needs a separate Wasm loader. Function disassembly is off by default, and optional PcHeader-address and Go-version settings override detection. Function-name guessing by pattern matching and BSim exists in source, but its option is not registered and stays off. - The repository commits generated name-guessing data: a 4.3 MB list of calling-function names under test resources and a 53 KB H2 BSim database under scripts, with scripts that produce them by compiling a small sample Go program with each listed Go toolchain and running Ghidra headless. The copy under src/main/resources is empty at this commit, and no target binaries are committed. JUnit tests cover version, header, string and name-data parsing; there is no CI workflow. - The MIT license sits in GolangAnalyzerExtension/LICENSE (2021, mooncat-greenpy); it is not at the repository root, so GitHub detects no license. Output annotates the Ghidra program and needs analyst checking; it does not produce Go source. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### IDA iOS Helper > IDA Pro plugin that cleans up Hex-Rays pseudocode and adds navigation helpers for iOS user-mode binaries and the kernelcache, enabling its components according to the loaded file. For Objective-C and Swift code it hides reference-counting calls, selectors and static class arguments, collapses os_log sequences, turns property helpers into plain assignments or field reads, lists cross-references to a method's selector, and adds Swift type declarations and readable stack strings. For kernelcaches it types the results of safeMetaCast and typed operator new, names and types kalloc_type_view globals, fixes this arguments and lists the possible implementations of a virtual call, while shared helpers remove __break calls, rewrite ranged conditions, collapse block initializers and mark outlined functions. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires IDA Pro 9.0+, and most listed features rewrite Hex-Rays pseudocode, so they assume IDA's decompiler is available. Installation uses IDA's own pip to install the ida-ios-helper package, which needs Python 3.10+ and pins the author's idahelper library at 1.0.18, and then copies ida-plugin.json and ida_plugin_stub.py into IDA's plugins folder. - Latest release at review: 1.0.23, published 2026-06-25 with the wheel and source archive that are also on PyPI. The reviewed master commit is six commits ahead, adding an Objective-C fast-enumeration component and Swift type fixes that are not yet released, and its ida-plugin.json still declares version 1.0.19 and pins ida-ios-helper==1.0.19. - The iOS binaries or kernelcaches come from the analyst. Virtual-call navigation needs vtable symbols in the database, and typing typed operator new results first needs the Locate all kalloc_type_view action. A Swift importer added in June 2026 and not described in the README runs the separate ipsw tool's swift-dump command on the input file to name and type Swift class methods. - CI only checks Python 3.10 compatibility with vermin and runs ruff lint and format checks; there are no automated tests. The repository also holds headless idat probing scripts and a Claude Code skill used while developing the plugin. GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### MAMBO > Dynamic binary modification framework from the University of Manchester that runs unmodified Linux user-space programs on 32-bit Arm (A32/T32), AArch64 and RV64GC RISC-V, translating their code into a code cache as it executes. An event-driven C plugin API registers callbacks on code-scanning and execution events and emits instrumentation; sample plugins count instruction mixes, branches and blocks, trace memory accesses and system calls, find hotspots, simulate caches, check memory errors and detect data races. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit of 2025-01-21 updates the HiPEAC 2025 tutorial. There are no versioned releases; GitHub releases 1 and 2 only host talk slides. The README says application compatibility is improved as needed, lists SPEC CPU2006, PARSEC 3.0, GCC, LibreOffice and GIMP among programs that work on Arm, and notes that most development happens in a private tree. - Builds and runs on an Armv7, Armv8 or RV64GC Linux system, physical or virtual, with GCC, libelf development files and Ruby 1.9.1+; the build generates instruction encoders and decoders from the bundled PIE specifications and links dbm statically. The authors use armhf/arm64 Debian, Ubuntu and Arch Linux ARM and Ubuntu 22.04 on RISC-V; for other hosts, a Dockerfile downloads Ubuntu 24.04 preinstalled server images for Arm64 and RISC-V and runs them under QEMU. Plugins are compiled in through the makefile's PLUGINS list. - Known issues listed in the README: SA_SIGINFO handlers receive incorrect siginfo_t data, synchronous-signal handlers cannot sigreturn, code-cache invalidation after munmap or cache flushes only happens in the calling thread, and RISC-V signal handling is incomplete. MAMBO is not designed to protect itself from the program it translates, so the README says it cannot serve as a secure sandbox without hardening. - CI builds MAMBO in Ubuntu 20.04 chroots under QEMU user emulation for arm64, armhf and riscv64 and only runs /bin/ls under it; the instruction, signal and self-modifying-code programs in test/ are not run by CI. The authors ask users to cite their 2016 ACM TACO paper and list later ICPE 2018, CC 2020, VEE 2020 and ISPASS 2023 papers. - Apache-2.0, with the same license in pie/. Programs to instrument are supplied by the user. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Class Informer > IDA Pro plugin that scans Microsoft Visual C++ binaries for virtual function tables (vftables) through their C++ run-time type information (RTTI), names, labels and comments the vftables it finds, defines the RTTI data structures and identifies single, multiple and virtual inheritance in each class hierarchy. It also processes static initializer and terminator tables, and opens a list window of the vftables with their method counts and class hierarchies, where each line jumps to its vftable. Its author notes that IDA 9's built-in RTTI plugin now finds nearly all of this data, so the current version only sets types that IDA missed and serves mainly as a gathering and browsing view. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v6.0.3, published 2026-08-04, which tags the reviewed master commit and attaches a zip holding a single Windows plugin DLL; its notes describe it as a fix for IDA 9.4, and a September 2025 commit had updated the plugin for IDA 9.2 and Qt 6. The plugin loads only for x86/x64 (metapc) databases. - The README's IDA 9.4 note says the plugin flags had to change before IDA would recognize the plugin, which broke loading it through plugins.cfg, so the Alt-2 hotkey is now built in and the plugin also runs from Edit > Plugins. The installation steps still name an older Class_Informer.plw file, and the plugins.cfg arguments the README gives for turning off the demoscene-style intro and its music predate that note. - Source builds need Windows and Visual Studio 2022 (v143 toolset) with Qt 6 for MSVC 2022 x64 and the Qt Visual Studio tools, the IDA SDK inside the IDA directory, and the author's separate IDA_Support repository and libxmp, neither of which is in this repository. There is no CI and there are no tests. The analyst supplies the IDA database; the README says the plugin is tailored to MSVC-compiled binaries and results with other compilers may be unpredictable. - The README states the MIT License, but the repository has no separate license file; according to the README, the tracker module in res is used with the permission of its composer, Drax. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Kam1n0 > Server platform from McGill University's Data Mining and Security Lab that indexes collections of disassembled binaries into shared repositories and searches them for cloned assembly functions. Its applications cover subgraph clone search within one instruction-set family (Asm-Clone), cross-architecture semantic search over VEX IR using symbolic and concrete execution (Sym1n0), Asm2Vec representation learning aimed at compiler optimization and obfuscation, and executable classification built on Asm2Vec. An IDA Pro plug-in sends functions to the server and shows flow-graph, text-diff and clone-group views; the README's accuracy and query-time figures come from the authors' own papers. - Type: Tool - Targets: Binary - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest stable release at review: 2.2.0, published 2020-11-15, with Windows installers and Linux tarballs for the server and the IDA Pro plug-in; a nightly-action pre-release from 2023-02-27 attaches Windows builds only. The reviewed master2.x commit of the same date is the default branch's latest, and README says repositories and configuration files from versions before 2.0.0 are no longer supported. - The server needs a 64-bit Java 11 runtime (README asks for Oracle's) and, to disassemble uploaded binaries, an IDA Pro installation with IDAPython set in kam1n0.properties; the shipped configuration requests a 12 GB maximum JVM heap and serves the web interface on port 8571. The plug-in needs IDA Pro newer than 6.7 with IDAPython and the CEF Python wheels its installer bundles. Source also contains an undocumented Ghidra disassembly backend. - Users supply the binaries to index and query. The repository commits test and example binaries built from open-source code: zlib and libpng builds for several architectures and optimization levels, a Chromium DLL, and IDA databases for PuTTY and zlib. Windows installer sources commit the Microsoft .NET Framework 4.0 and Visual C++ x64 redistributable installers and CEF Python wheels, and the server resources commit JavaFX SDK 11.0.2 DLLs, a prebuilt LibVEX library (VEXIRBB.dll) and a local Maven repository holding a z3 jar. - Maven builds the Java 11 modules against those pre-compiled LibVEX and z3 binaries; README says LibVEX comes from angr's fork, and z3 is a submodule. The Maven tests drive Chrome through chromedriver and, per the README, take about three hours; CI only builds the Windows distribution and WiX installers. Accuracy and timing figures are taken from the README and the authors' KDD 2016 and IEEE S&P 2019 papers. - Apache-2.0 (LICENSE.txt), copyright McGill University and the researchers. Bundled runtimes, redistributable installers, wheels and test binaries keep their own licenses, and IDA Pro is separately licensed commercial software. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### iblessing > Toolkit for analyzing iOS apps and arm64 Mach-O binaries, built on Capstone, Unicorn and Keystone. Its scanners extract app-bundle metadata such as URL schemes and transport-security settings, locate Objective-C class references and NSPredicate uses, detect symbol wrappers, and partially emulate arm64 code with Unicorn to recover objc_msgSend cross-references, including those passed through blocks. Generators turn the reports into IDA Pro scripts that add cross-references and rename wrappers, or into a local query server, and a shared core library with a plug-in interface supports custom tools. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.0.4-beta, published 2021-11-26 and tagged at the reviewed master commit; every release is marked as a pre-release. Each recent release attaches macOS and Linux command-line and all-in-one binaries, framework archives with the shared core library and headers, and a JSON table of Foundation and UIKit method signatures. The README's feature list leaves Swift class parsing, following branches and calls, and Android scanners unfinished. - Users supply an iOS .app bundle for app-info or an arm64 Mach-O binary for the other scanners; README examples analyze commercial third-party apps after restoring symbols with a separate tool, but no app binaries are committed. The class and objc_msgSend cross-reference scanners accept arm64 binaries only, and app-info is unavailable on Linux because it still depends on Cocoa. The README warns that binary scanners reserve 12 GB of virtual memory per Mach-O file, so physical memory or swap must cover that. - Builds on macOS or Linux with CMake 3.5+ and a C++17 compiler after a recursive clone; compile-cmake.sh first builds the pinned Capstone, Unicorn (arm, aarch64 and x86) and Keystone submodules as static libraries. An Xcode project is also included. IDA Pro is needed only to apply the generated scripts. - GitHub Actions builds on Ubuntu and macOS and, on macOS only, scans the bundled sample-app benchmark and runs the built-in objc_msgSend cross-reference test; Travis CI builds and publishes tagged releases. The README notes that objc-msg-xref follows no calls to save time, so its results are partly missing. - GPL-3.0 (LICENSE). The project calls itself an iOS security exploiting toolkit. Analyzed apps and Apple frameworks keep their own terms, and the Capstone, Unicorn and Keystone submodules carry their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### SiMBA > Research tool from Denuvo that simplifies linear mixed Boolean-arithmetic (MBA) expressions, which combine bitwise and integer operations and are used in code obfuscation. Like MBA-Blast and MBA-Solver it works algebraically, using the fact that a linear MBA is fully determined by its values on inputs of zeros and ones: it evaluates the expression on every such combination and rewrites it as a linear combination of basic bitwise expressions, without first translating it to 1-bit space. Python scripts simplify single expressions or whole datasets, can check that an input is linear and can prove the result equivalent with Z3. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Accompanies Benjamin Reichenwallner and Peter Meerwald-Stadler's paper at the CheckMATE 2022 workshop, co-located with ACM CCS 2022 (DOI 10.1145/3560831.3564256, arXiv 2209.06335); the repository also holds the paper PDF, slides and a talk video. The reviewed main commit dates from 2022-12-12, and there are no releases or packages: the scripts run directly from src/. - Needs Python 3; Z3's Python bindings are required by simplify_dataset.py and by the -z verification option of simplify.py. Input is expression text, or a file with one complex expression and its simpler equivalent per line, built from variables, constants and the operators ~, unary minus, *, +, -, &, ^ and |; the tool has no disassembler or decompiler integration. Output constants depend on the bit width, 64 by default and set with -b. - Only linear MBAs are handled: the optional -l check rejects nonlinear input such as products of variables, and the README warns that operator precedence follows Python, so parentheses are needed. Result refinement through lookup tables of bitwise expressions covers up to three variables; expressions with more variables keep the generic linear-combination form. - For reproducing part of the paper's experiments, data/ holds generated sets of 1,000 equivalent linear MBAs per target function with 2 to 4 variables, plus 5- and 6-variable sets for x+y; the README also mentions 7 variables, which are not in the tree. The datasets assume 64 bits, and simplify_dataset.py reports how many results Z3 verified or matched exactly and the average runtime. There is no test suite or CI. - GPL-3.0, copyright 2022 Denuvo GmbH. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### GTIRB > GrammaTech's intermediate representation for passing disassembly, analysis and rewriting results between binary tools, modeled on the role LLVM-IR plays for compilers. An IR holds modules for executables or libraries with their sections, byte intervals, code and data blocks, symbols and symbolic operands, plus an inter-procedural CFG and AuxData tables for analysis results, all referenced by UUID; instruction semantics are deliberately left out, so machine code stays as raw bytes for Capstone/Keystone or any other IL. It serializes as protobuf, with C++, Python and Common Lisp APIs and a partial Java API; the separately listed ddisasm produces it. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - PyPI's newest gtirb is 2.3.2, uploaded 2026-06-16 as a pure-Python wheel for Python 3.8+; the changelog says the PyPI package needs protobuf 4.21.1 or newer. The reviewed master commit of the same day bumps version.txt to 2.3.3, which CHANGELOG marks unreleased. GitHub releases stop at v2.0.0 (2023-12-14, no files), and later versions are git tags. The README says ABI compatibility is not yet provided across any version change, and that stable or unstable packages must match the installed ddisasm and gtirb-pprinter. - Prebuilt options are Windows .zip builds and Ubuntu 20.04 (focal) apt packages from GrammaTech's download server, and the grammatech/ddisasm Docker image with GTIRB, ddisasm and gtirb-pprinter; the README warns that apt metapackages for stable gtirb 2.0.0 and older conflict on upgrade. Source builds need a 64-bit C++17 compiler (GCC, Clang or Visual Studio), CMake 3.10+, Protobuf 3.0.0+ and Boost 1.68+; the Common Lisp API needs further manual setup, and the Java API is marked incomplete. - GTIRB is a data structure, not an analyzer: IR comes from a producer such as ddisasm. The schema names file formats including ELF, PE, COFF, XCOFF, Mach-O and raw images, and ISAs from IA-32 and x64 to ARM, MIPS, PowerPC and, from 2.3.2, RISC-V; what a given producer actually supports is up to that tool. Programs in doc/examples walk the C++ API and compute CFG paths, data symbols and functions in several languages. - The GitLab CI configuration builds and tests on Ubuntu 20.04, 22.04 and 24.04 with GCC and Clang, plus static, Java, Common Lisp, Python and coverage jobs; the GitHub Actions workflow only builds and publishes documentation. - LICENSE.txt places GTIRB under MIT (2018, GrammaTech) and appends Apache-2.0 with LLVM Exceptions for included third-party code, which GitHub leaves unclassified; contributors must sign GrammaTech's CLA. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### Quokka > Quarkslab’s binary exporter, inspired by BinExport, saves a disassembler’s analysis to a protobuf .quokka file so functions, basic blocks, data, cross-references, segments and optionally decompiled code can be used later without the disassembler. Its Python bindings load an export together with the original binary, decode instructions at runtime with Capstone, or optionally lift them to P-code with pypcode, and expose programs, functions and control-flow graphs through one API. The main branch adds Ghidra and Binary Ninja exporters beside the IDA Pro plugin, a parallel quokka-cli batch exporter and name and type edits that can be written back to an IDA database. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.6.2, published 2025-12-08 together with quokka-project 0.6.2 on PyPI; its README supports IDA 7.3+, and it ships prebuilt IDA plugins for IDA 7.4 through 9.2 on Windows, Linux and macOS. The reviewed main commit (2026-10-14) is 261 commits later and declares version 1.0.0; the Ghidra and Binary Ninja exporters, quokka-cli and the IDA 9.1+ requirement described here exist only on main, not in a released package. - Exporting needs one disassembler. The main-branch C++ plugin targets IDA Pro 9.1+, installs through hcli on 9.2+ or builds with CMake, which fetches the open-source IDA SDK for 9.2+ and needs a separately obtained SDK for older versions; the Java extension needs Ghidra 12.0.3+ and JDK 21+; the Binary Ninja plugin declares version 4.0 build 4911 as its minimum, and headless use there needs a commercial license. The Python bindings need Python 3.10+ on main, or 3.8+ for 0.6.2, with capstone, networkx, protobuf and python-magic. - Only the LIGHT export mode works: exports hold block-level data, so loading them needs the original binary for Capstone to decode instructions, and the self-contained FULL mode is planned but not implemented. quokka-cli offers decompiled-code export for IDA only. The README warns that Capstone’s disassembly can differ from the disassembler’s. - Test fixtures in tests/dataset are stored with Git LFS: programs built from the included many_types and sig_test sources, a Linux kernel module (nf_nat_pt.ko), a UEFI PEI module (StatusCodeHandlerPei.efi), a puraUpdate executable and their exports; docs/samples adds a qb-crackme sample and its export. Workflows build the IDA plugin, build and test the Ghidra extension, test the Binary Ninja plugin and run the Python tests on Python 3.10–3.13. - Apache-2.0 license; IDA Pro, Ghidra and Binary Ninja keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### knife > Static reverse-engineering toolkit in Rust, installed as the knife command, that parses PE, ELF, Mach-O and WebAssembly files without running them. It triages hashes, sections, mitigations, imports, strings, indicators and crypto constants; recovers functions, call graphs and CFGs through recursive-descent disassembly for x86/x64 and AArch64; and lifts functions to experimental pseudocode. Analysts' names, notes, types and staged patches persist in a per-binary database shared by the CLI, a terminal UI and an MCP server, and further passes rank risky API call sites by argument provenance and summarize Windows driver dispatch and IOCTL surfaces. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository was created on 2026-08-08. Release v1.8.3 (2026-10-11) ships Linux x86_64, macOS arm64/x86_64 and Windows x86_64 archives, while the reknife crate on crates.io stops at 1.8.0 (2026-09-15); the reviewed main commit is 48 commits past v1.8.3, with unreleased changes listed in CHANGELOG. Source builds need Rust 1.88+, and the README says no system libraries are needed beyond the platform default; knife update needs curl. - Input is a binary the analyst supplies, which knife only reads. Disassembly covers x86/x64 and AArch64, the audit data-flow checks are x86/x64 only, and the README says empty reachability results do not prove unreachability because indirect dispatch is outside the direct call graph. WebAssembly gets section, import/export and WAT views without code analysis. The repository contains no target binaries: tests build synthetic PE and ELF fixtures in code, and data/loldrivers.json is a snapshot of the public LOLDrivers list used for SHA-256 matching. - knife mcp speaks MCP over stdio; docs/MCP.md lists 58 tools, four of which write names, notes, prototypes or staged patches to the project database rather than the binary. The optional investigation desk sends prompts and tool results to the model provider the user configures (local Ollama, OpenRouter, OpenAI or another OpenAI-compatible endpoint) and keeps hosted API keys in the OS credential vault. Optional adapters call a separately installed Rizin, and the provider docs also describe Ghidra headless and capa adapters; YARA-X 1.12 is linked in for rule scans, and a GDB runtime exporter is documented but not yet exposed. - CI runs cargo build and test on Ubuntu, Windows and macOS, plus cargo fmt and clippy. The README presents audit hits as call sites whose argument provenance matches a bug pattern, and its 7z.dll, kernel32.dll and CVE-2017-11882 figures are the author's results. - MIT (2026, 0xblack). The LOLDrivers snapshot comes from that project's public API, and Rizin, Ghidra, capa and YARA-X keep their own licenses. The repository's AGENTS.md is contributor guidance for coding agents. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### BARF > Python binary analysis framework that loads ELF and PE programs, disassembles 32- and 64-bit x86 and 32-bit ARM code with Capstone and translates it into the REIL intermediate language, so its analyses do not depend on the source architecture. Modules recover control-flow and call graphs, emulate REIL and turn code fragments into Z3 or CVC4 formulas for checking constraints on registers and memory; release 0.6.0 added basic symbolic execution. Bundled command-line tools recover CFGs and call graphs, replay x86 execution traces and search, classify and verify ROP gadgets. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Inactive since 2019: the reviewed master commit, dated 2019-11-24, is tagged v0.6.0 and is the last commit; 0.6.0 is also the newest PyPI release of barf. GitHub does not mark the repository archived, and it has tags but no GitHub release entries, although the README links a v0.6.0 release page. setup.py classifies it as alpha, and the README still calls it under development. - setup.py and the Travis CI configuration target Python 2.7 and 3.6, with Python 3 support added in 0.6.0. The README says all packages were tested on Ubuntu 16.04 x86_64, and the Dockerfile installs it on Ubuntu 18.04 through Python 2 pip. Dependencies include Capstone 3.0.5rc2+, pefile, pyelftools, networkx, pydot and pyparsing, plus at least one of the Z3 or CVC4 solvers; Graphviz is needed for graph output and PyAsmJIT for some tests. - Binaries come from the analyst. The repository bundles small sample binaries built from included C sources under examples/misc/samples and tests, and two challenge binaries for its worked examples: Flare-On 2015 challenge #2 (examples/flareon-2015/2/bin/very_success) and kao's toy project (examples/kaos-toy-project/bin/toyproject.exe). The Sphinx manual is in Spanish and refers to an install.sh script that is not present at the reviewed commit. - BSD 2-Clause license, copyright 2014 Fundación Dr. Manuel Sadosky. The README describes checking instruction translations by running code natively through PyAsmJIT and in the REIL emulator and comparing the final contexts. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### rabbitizer > MIPS instruction decoder written in C that never allocates on the heap, with Python, C++ and Rust bindings in the same repository and the stated aim of producing matching assembly. It decodes one instruction word at a time, focusing on MIPS I to III with partial MIPS IV support, and also handles the N64 RSP, the PlayStation's R3000 GTE, the PSP's R4000 Allegrex and the PS2's R5900; it offers validation checks, instruction-grouping queries, configurable pseudo-instructions and register names, and small helpers for building pointer and symbol detection. Matching-decompilation tooling builds on it: splat and spimdisasm both list it as a Python dependency. - Type: Tool - Targets: Binary · Game - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest stable release at review: 1.16.2, published 2026-05-29 on GitHub, PyPI and crates.io, which matches the reviewed 1.x commit. A 2.0.0 alpha series (2.0.0-alpha.9, 2026-05-20) is published from a separate Rust branch; splat and spimdisasm both pin versions below 2.0.0. - Install with pip install rabbitizer or cargo add rabbitizer. The README gives Python 3.9 as the minimum, although pyproject.toml still declares >=3.4, and building the Python bindings from source needs the Python development headers. The C and C++ libraries build with make and clang (C11 and C++17), and the Rust crate declares Rust 1.66.0. Instruction tables for every binding are generated from templates in tables/, and CI checks that the generated files are current. - Input is raw 32-bit instruction words, so callers must take code from their own binaries, choose the CPU variant and handle addresses and symbols themselves. Pseudo-instructions that expand to more than one instruction are deliberately unsupported; the README says output should match, reports that RSP output reassembles to matching code with armips, and calls MIPS IV support partial. - GitHub Actions build the C code with warnings as errors on Ubuntu 22.04 and run build-info, logic and instruction checks, and Python unit tests run on Linux, macOS and Windows; tests/asm holds assembly samples for the GTE, Allegrex and R5900. The README's reference list points to third-party CPU manuals and documentation hosted elsewhere. - MIT. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### ghidrecomp > Python command-line decompiler that drives Ghidra through pyghidra to decompile every function of a binary into separate C files, or into one C file and header with Ghidra's C++ exporter, keeping the Ghidra project so later runs can reuse the analysis. Options filter functions by regex, apply PDB symbols from a local file or from Microsoft, Chromium, Mozilla, Intel, NVIDIA and AMD symbol servers, apply extra GDT data-type archives, write Mermaid call-graph Markdown, generate BSim function signatures, and scan the decompiled code with Semgrep rules into SARIF reports. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.5.9, published to PyPI and GitHub on 2026-01-06; the reviewed main commit is that tag. setup.cfg requires Python 3.10+ and pyghidra 2.2.1+ and marks the project as alpha; the CodeQL option is a placeholder that only prints a coming-soon message. - Needs a separate Ghidra installation and the Java runtime it requires, found through GHIDRA_INSTALL_DIR. The Dockerfile and devcontainer build on the author's ghidra-python image and pin pyghidra 2.2.1 for Ghidra 11; CI runs pytest in that image for the latest Ghidra and for 11.3, 11.3.2 and 11.4.2. SAST scanning needs Semgrep, installed with the sast extra. - Binaries to decompile are the analyst's own; symbol lookups contact the listed public symbol servers unless --skip-symbols is set. The tests bundle tests/data/afd.sys.10.0.22621.1415, a Microsoft Windows driver build also used in the README examples, an AArch64 ls binary and an ntddk_64.gdt data-type archive; these files keep their publishers' terms. - The README presents the output as decompilations for research and analysis and makes no recompilation claim; the tests check function counts, call graphs, one signature after GDT application, BSim and SAST output. GPL-3.0 (LICENSE); Ghidra and Semgrep keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Vivisect > Pure-Python reverse-engineering framework that combines the vivisect static analyzer, the vtrace debugging library and the vdb debugger. Vivisect loads PE, ELF, Mach-O, Intel HEX, S-record and raw blob files into workspaces, disassembles and emulates code through envi architecture modules for x86, AMD64, ARM, Thumb, AArch64, MSP430, H8 and Z80, and adds symbolic execution, a Qt GUI and a remote workspace server. vtrace drives processes on Windows, Linux, FreeBSD, macOS and Solaris and has GDB-stub and VMware backends. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.3.2, uploaded to PyPI on 2026-03-31 from tag v1.3.2 (the project publishes no GitHub release pages); it requires Python 3.8+ and pins PyQt5 5.15.7 for the GUI, and AArch64 support arrived in 1.3.0. The reviewed master commit (2026-09-03) is ten commits later and, still labelled 1.3.2, requires Python 3.11+ and PyQt6 6.5+. Install with pip install "vivisect[gui]"; releases before 1.0.0 are Python 2 only, and Python 2 workspaces are typically not loadable in Python 3. - Bundled helper libraries: vtrace/platforms/windll holds Microsoft’s dbghelp.dll and symsrv.dll for amd64 and i386, committed since 2014 and loaded by the Windows vtrace backend for symbol handling, and pyproject.toml packages them into the PyPI distribution. They are Microsoft binaries under Microsoft’s terms, not the project’s Apache-2.0 license, and no Microsoft license or notice accompanies them. The macOS backend ships a prebuilt machhelper.dylib next to its C source and Makefile. - Input is binaries or firmware images the user supplies. CircleCI runs the unittest suite on Python 3.11 against sample binaries from a separately cloned vivtestfiles repository, and a GitHub Actions workflow checks formatting; documentation is on Read the Docs. - Apache-2.0 license (COPYRIGHT names invisigoth, 2014); the Microsoft DLLs keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### r2pipe > radare2's official scripting interface, with implementations for more than two dozen languages in one repository. Every binding sends radare2 command strings and returns their text output, the design behind r_core_cmd_str(), and the README recommends asking for JSON output and decoding it into native objects instead of using the C API. Bindings connect through the R2PIPE_IN/R2PIPE_OUT pipes of a script run from inside r2, a spawned r2 -q0 process, TCP, HTTP or radare2's RAP protocol, many offer asynchronous calls, and r2pipe scripts can also implement radare2 plugins such as disassemblers, IO backends or ESIL syscall handlers. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The newest GitHub release at review is 6.1.2, published 2026-04-20 as source only, and the reviewed master commit is 54 commits ahead of it; each language is also packaged separately. The Python package r2pipe 2.1.0 (Python 3.6+) was uploaded to PyPI on 2026-10-19, matching python/pyproject.toml, while npm's r2pipe was at 2.8.6 from 2024-01-16 and r2pipe-ts at 0.4.0. The Rust crate lives in the separate r2pipe.rs repository, and the README's capability table marks which backends each language supports. - Apart from the WebAssembly variant, every binding talks to a radare2 process, either spawned locally or reached as a TCP, HTTP or RAP server, and command strings and output formats follow the radare2 version in use. CI installs the radare2 6.1.4 Debian packages on Ubuntu 24.04 and tests the Perl, Python, TypeScript, Ruby, Tcl, Vala, Swift and .NET bindings. - python-wasm is a separate r2pipe_wasm package that runs radare2's wasi-api WebAssembly build inside Python through Wasmer's Python SDK 1.1.0, downloading the newest stable release with that asset by default. Its README verifies only CPython 3.9 on Linux x86_64, pins its examples to 6.1.4 and reports that the published 6.2.2 API module traps during startup. - GitHub detects no repository-wide license. The Python, Python WASM, Go, .NET, Haskell and Erlang directories carry MIT license files and the npm packages declare MIT. Binaries to analyze come from the user, and the TypeScript tests bundle one fixture, typescript/tests/fixtures/wasm-api.wasm. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### GREASE > Galois's command-line tool, Ghidra plug-in and Haskell library for checking properties of binaries with under-constrained symbolic execution. It lifts AArch32, PowerPC or x86_64 ELF executables and shared objects, or LLVM bitcode, into a control-flow graph, simulates each function from fully symbolic registers and grows the inferred memory layout after out-of-bounds accesses, then reports likely undefined behavior such as division by zero or invalid memory access together with concretized arguments. Built-in overrides, or user overrides written in Crucible's S-expression language, model external library functions, and the plug-in presents results in Ghidra. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No tagged releases at review: the installation guide offers a nightly Docker image built from main (ghcr.io/galoisinc/grease:nightly) or a source build, and the same documentation is published at galoisinc.github.io/grease. The reviewed main commit is dated 2026-09-24; Galois introduced the tool in a blog post dated 2025-03-19. - Source builds need GHC 9.6, 9.8 or 9.10, cabal-install 3.6+ and the repository's git submodules, including Galois's macaw, crucible, what4 and elf-edit. A standalone binary also needs one of the SMT solvers bitwuzla, cvc4, cvc5, yices or z3; it defaults to yices, which CI tests at 2.6.5, and the Docker image includes the solvers. The Ghidra plug-in needs Ghidra 11.0+ and a local grease binary. - Supply the ELF binary or LLVM bitcode yourself. By default every known function is analyzed; entry points can instead be chosen by symbol, address or core dump. The limitations page lists single-threaded analysis only, k-bounded data structures, loops and recursion, skipped calls through symbolic function pointers, no stack-buffer-overflow detection or heap-exhaustion modeling, limited string operations and no support for code that runs before main. - The repository commits small test fixtures built from adjacent C or assembly sources: about 200 AArch32, PowerPC and x86_64 ELF executables and shared objects under grease-exe/tests, plus test ELFs under grease-x86/test-data, ghidra-ecfs/src/test/resources/ecfs and the bundled screach reachability tool's test-data directories. - BSD-3-Clause (LICENSE). The README credits DARPA funding and carries Distribution Statement A, approved for public release. Reports depend on the inferred preconditions, bounds and overrides. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### PLASMA > Interactive terminal disassembler, formerly named Reverse, for x86 and x86-64 with partial ARM and MIPS/MIPS64 support, reading ELF, PE and raw binaries. Its visual mode shows functions as indented, colored pseudo-code and lets the analyst reshape the flow by inverting conditional jumps, while a Python API runs scripts for strings, cross-reference call graphs, crypto-constant detection and Keystone assembly. Development stopped in 2019, and the repository has no releases. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Inactive: the last commit on master, ec7df9b, is dated 2019-03-04, and there are no releases or tags; GitHub does not mark the repository archived. The README still describes the project as in heavy development and warns that the database format may break until structures and type definitions are implemented. - Requires Python 3.4+, Capstone (install.sh builds 4.0-alpha5 from source), pyelftools, pefile with python3-future, msgpack-python 0.4.6+, c++filt from binutils and a UTF-8, 256-colour terminal; python-qt4 for the memory map and Keystone for asm.py are optional. The Dockerfile builds on Ubuntu 16.04. - make runs the regression suite, comparing output for the bundled test binaries with expected .rev listings; tests/ holds 96 small compiled test binaries, most next to their C sources. Analysis inputs are the user's own binaries. - GPL-3.0; the relocation definitions taken from angr's cle keep their BSD-style license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### mobdevim > Derek Selander's macOS command-line utility for inspecting and controlling iOS devices connected over USB or Wi-Fi through Apple's private MobileDevice framework. It lists devices and installed apps with their Info.plist keys and entitlements, streams the device console, fetches crash logs, shows provisioning profiles and developer certificates, copies an app's data container off the device and back where the sandbox allows, and installs, uninstalls and launches apps with arguments and environment variables. With a Developer Disk Image mounted it also lists and kills processes and simulates location, and output can be printed as plist for scripts. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags; the reviewed main commit of 2024-02-01, which says it fixed log grabbing, is the latest push. The README's usage text shows a build compiled on 2023-11-07 and still marks log retrieval as broken on iOS 16.5 and device backup as a to-do. The repository also commits a prebuilt compiled/mobdevim binary, last changed on 2023-11-07. - Build the Xcode project on macOS; it links /System/Library/PrivateFrameworks/MobileDevice.framework, sets macOS deployment targets of 10.12 and 10.13, and a build phase copies mobdevim to /usr/local/bin, which must be writable or the build fails. The README states no supported iOS or Xcode versions. - Needs an iOS device connected over USB or paired for Wi-Fi. Process listing and killing, app launching and location simulation need a mounted Developer Disk Image, which the -I option mounts from a signature and .dmg pair the user supplies, for example from Xcode. Copying app data goes through the house_arrest service, so it works only for apps the sandbox exposes. - GitHub detects no license and the repository root has no license file, so the tool's terms are unstated; the process directory carries a 2018 Hex-Rays MIT license for its Instruments client code, and misc/InstrumentsPlugin.h credits codecolorist's FreeTheSandbox. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### XPEViewer > Qt-based PE file viewer and editor for Windows, Linux and macOS by horsicq, the author of the catalog's Detect It Easy. Its PE view parses the DOS, NT and optional headers, sections, normal, delay-load and bound imports, exports, resources including manifests, version data and string tables, relocations, TLS callbacks, exception, debug and load-configuration data, certificates, the Rich header and .NET metadata tables. Hex, disassembly, strings, entropy, hash, memory-map and extractor views sit beside Detect It Easy, Nauz File Detector and YARA scans and an optional VirusTotal lookup. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest full release at review: 0.05, published 2024-07-02, with a Linux AppImage, Debian 10–12 and Ubuntu 14.04–24.04 .deb packages, macOS x86_64 and Qt 6 arm64 packages, Windows x86, x64 and XP portable zips and a source tarball. Release 0.06 (2025-12-22) is marked as a prerelease with no attached files; the rolling Beta prerelease carries 0.06 Ubuntu 22.04/24.04 packages and Windows portable zips, and release_version.txt on the reviewed master commit reads 0.06. - Source builds need a recursive clone of 56 horsicq submodules, including Detect-It-Easy, signatures and XYara. docs/BUILD.md covers Docker, a Debian package script, autotools, qmake6 with Qt 6, CMake, macOS with Qt 5.15.2, Windows 7–10 with Visual Studio 2019 and Qt 5.15.2, and Windows XP with Visual Studio 2013 and Qt 5.6.3. - Supply the PE file yourself. The main window opens files for writing when it can and falls back to read-only, so editing changes the opened file; work on a copy. The VirusTotal view uses that online service. - MIT (LICENSE). The README itself is brief: download, run and build links, a changelog and screenshots; the parsed structures come from the PE widget source in the pinned FormatWidgets submodule. The main repository commits no sample binaries. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Fermion > Ruben Boonen's Electron desktop application that wraps frida-node and the Monaco editor into one window for writing, injecting and refining Frida scripts. The editor brings linting, IntelliSense and Frida API type definitions, a device menu reaches local, USB and remote Frida servers to attach to or spawn processes, scripts reload in the target with a keyboard shortcut and their output appears beside the code. A prototype CALL tracer follows every call a thread makes from a chosen pointer or module symbol until it returns and renders the result as a Graphviz SVG graph, and Frida's JavaScript API documentation is built in. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.9.3, published 2023-04-20 by the repository's CI with zipped Windows, Linux and macOS builds, pinning Electron 21.0.0, Frida 16.0.17 and frida-gum types 18.3.1. Every later commit, up to the reviewed master commit of 2025-03-20, is an automated keepalive commit, and the release workflow builds only when the package version changes, so the app has not followed the Frida 17 series (17.24.3 at review). - Running from source needs Node.js and npm: in the Fermion folder, set npm_config_runtime=electron and npm_config_target=21.0.0, then run npm install and npm start; release packages are built with electron-packager, and the CI uses Node 16. Remote and mobile targets need a reachable Frida server, which the README says is often detected automatically over USB or in emulators such as Genymotion, or can be given as an IP address and port. - On Windows, attaching to SYSTEM processes needs Fermion running as Administrator with SeDebugPrivilege, because the README says running it as SYSTEM has frozen it since Electron 8; on Linux, attaching may need root or a relaxed kernel.yama.ptrace_scope. The README calls the tracer a prototype whose window can lag on large graphs and which can make the traced process unstable. - The repository commits 22 example Frida scripts, most of them hooks on Windows APIs, a Graphviz library compiled to WebAssembly (Fermion/pages/graphvizlib.wasm) for rendering traces, and bundled jQuery, Semantic UI (with Lato fonts), Split.js and Tailwind CSS assets. Users supply their own devices, processes and apps. - BSD-3-Clause (Copyright 2019 Ruben Boonen); bundled frameworks and fonts keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Ghidrathon > Mandiant FLARE's Ghidra extension that embeds the user's local CPython 3 interpreter in Ghidra through Jep, as an alternative to Ghidra's Jython-based Python 2.7 scripting. It adds an interactive Python 3 interpreter window, Python 3 scripts in the Script Manager and Python 3 post-scripts in headless analyzeHeadless runs, with GhidraScript state such as currentProgram() and FlatProgramAPI methods available as Python builtins. Because the configured interpreter or virtual environment is used as is, scripts can import installed packages; the README names capa, Unicorn and angr as motivating examples and shows Unicorn emulating ARM code inside Ghidra. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository is archived on GitHub and read-only. Its last commit on main dates from 2024-05-08, and the latest release, v4.0.0 of 2024-02-13, attaches one extension zip that the release workflow builds against Ghidra 11.0 and bundles with the configure script. The archive states no reason; Ghidra's own change history records that 11.3 (February 2025) integrated PyGhidra, a native CPython 3 interface whose module provides a CPython interpreter plugin and a script provider for CPython 3 GhidraScripts. - The README requires Python 3.8+, exactly Jep 4.2.0, Ghidra 10.3.2+ and Java 17+. Setup installs Jep from util/requirements.txt into the chosen interpreter or virtual environment and runs util/ghidrathon_configure.py against the Ghidra install directory, which writes a ghidrathon.save file there or under GHIDRATHON_SAVE_PATH; the zip is then installed through Ghidra's extension manager, whose version-mismatch prompt the README says may be overridden. Source builds need Gradle 7.3+ and the Jep 4.2.0 JAR downloaded into lib/. - CI built and tested only Ghidra 10.3.2 and 11.0 with Python 3.8 and 3.12 on Ubuntu, Windows and macOS, running the repository's Python tests as headless post-scripts. Jep embeds Python in the JVM through JNI, which the README notes Ghidra's developers advise against, and unlike Ghidra's Java and Jython APIs, scripts read GhidraScript state through calls such as currentProgram(). - Apache-2.0 (LICENSE.txt). The repository commits Java and Python sources, an example script, Python tests and three README screenshots, and no binaries; the CI tests analyze a demangler executable taken from the downloaded Ghidra distribution. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### diStorm3 > Lightweight x86/AMD64 disassembler library in C that the README describes as a decomposer: besides formatted text, distorm_decompose returns a binary structure per instruction with its opcode, operands, prefixes, flow-control class and optionally affected CPU flags. It decodes 16-, 32- and 64-bit code, can stop at calls, returns, branches, interrupts or privileged instructions, and its generated instruction tables cover integer, x87, MMX, 3DNow!, SSE through SSE4.2 and SSE4a, AVX, FMA, AES, CLMUL, VMX and SVM sets. The repository includes the distorm3 Python module, plus example Java and .NET wrappers and sample programs for Linux, Win32 and a Windows kernel driver. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No commits on master since 2021-12-18, the reviewed commit. The latest PyPI release is distorm3 3.5.2, uploaded 2021-03-19 as a source tarball and a Windows 32-bit Python 3.7 wheel; the GitHub release list ends with 3.5.2b (2021-04-03), and setup.py on master already says 3.5.3, which is not on PyPI. - Install the Python module with pip install distorm3, which compiles the C sources, or build the C library with the Makefiles for Linux, macOS and TinyCC or the Visual Studio solution for Windows. setup.py lists Windows, macOS and Linux, and its newest Python classifier is 3.5; CI last targeted Ubuntu 18.04, Windows and macOS with Python 3.x. The README points to the GitHub wiki for API documentation. - Input is raw machine code bytes plus a code offset and decoding mode supplied by the caller; it decodes instructions only and does not parse executable formats, build control-flow graphs or lift code. The disOps scripts generate its instruction tables from the x86sets.py database. - The repository bundles a test helper executable, test-deps/yasm-1.3.0-win64.exe, which the CI workflow copies into place so the Python tests can assemble their instruction samples with yasm on Windows; no other sample binaries are committed. - BSD three-clause license (COPYING; GitHub reports it as unclassified). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### ProbeDroid > Dynamic Java-method instrumentation kit for Android 5.0 that lets analysts write their own tracing and profiling tools for apps whose source code they do not have. A launcher uses ptrace to inject the native engine library and a user-built instrumentation APK into a newly started target app, and the tool subclasses the Instrument API to hook framework or app-defined Java methods and inspect or change their arguments and return values. The README's demos use sample tools that log strings built through StringBuilder and StringBuffer and the activities and services an app starts. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags; the reviewed master commit of 2018-12-16 only updates the project introduction, and the last code change dates from January 2017. The README calls the kit still under construction, supports only Android 5.0 on x86 and ARM armeabi-v7a devices, and says native methods cannot be instrumented yet. - The wiki pages of July 2016 list JDK and JRE 7+, Python 2.6+ for the auto.py build and deploy script, the Android SDK, the NDK for the launcher and libProbeDroid.so, and Apache Ant for the ProbeDroid.jar API; tools are written as Android Studio projects with minimum API 21 that import that jar, and no Android source tree is needed. Sample tools are under tools/ and in the separate ProbeDroidTool repository. - Running it needs a rooted Android 5.0 device or an API 21 emulator image, and the wiki has the analyst set SELinux to permissive on that test device before starting the launcher with the target package, engine library, tool APK and main class; results go to logcat. Users supply the apps they analyze. - MIT (copyright 2016 ZongXian Shen), except the AOSP-derived ART runtime and common sources under Apache-2.0 and the bundled libffi under its MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Fridump > Small Python command-line tool that attaches to a running process through Frida and writes its accessible memory ranges to files, run from a Windows, Linux or macOS host against iOS, Android or Windows applications. By default it saves ranges that are readable and writable, -r also takes read-only ones, ranges above a size limit (20 MiB unless set with --max-size) are split into chunks, and -s runs a basic strings pass that collects printable text from every dump into strings.txt. Its README presents it for penetration testers and developers. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README calls this version 0.1 and warns that bugs are expected. The newest commit on master dates from 2019-04-25, and the repository has no tags or releases. The README reports testing only from Windows 7 and Mac OS X hosts, against an iPad Air 2 on iOS 8.2, a Galaxy Tab running CyanogenMod 4.4.4 and a Windows 7 laptop. - Run fridump.py from a clone with Python and the frida package from pip; there is no requirements file and no Frida version is pinned. Its embedded agent calls Process.enumerateRangesSync and Memory.readByteArray, legacy APIs that Frida's 17.0.0 release notes (May 2025) say are now gone, so the unmodified script appears to need an earlier Frida release. - Mobile targets need a frida-server matching the host's Frida on the device, which the README says must run as root on Android; -U selects a USB-connected device and frida-ps lists process names. Output is one raw file per memory range, named by its base address, with no structure or symbol recovery; ranges that cannot be read are skipped with a warning. - Dumps can hold credentials and personal data from the target process, so use it only on apps and devices you own or are authorized to test. The repository has no license file and GitHub detects no license, so it grants no explicit reuse terms; it contains only three Python files and the README. ##### Primary sources 1. 2. 3. 4. 5. #### Redress > Command-line tool, built on the GoRE library, that recovers metadata from stripped binaries produced by the Go compiler. It reports the compiler version, build ID, GOROOT, main-package path and Go module information; lists project, standard-library and vendored packages; prints interfaces, structs and their methods as Go type declarations; and projects the source tree as packages, files and functions with estimated line ranges. Run inside radare2 through r2pipe, it adds function and type flags and analyzes main.init and main.main. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit fe38d96 (2024-10-12) on develop, the default branch. The stable master branch is 96 commits ahead, all automated "Update Gore version" commits: a daily workflow bumps the GoRE dependency whenever GoRE publishes a new release, then tags and builds a release. Latest release at review: v1.2.98 (2026-10-20), built against GoRE v0.14.7, while develop's go.mod still pins v0.11.5; the README is identical on both branches. - Release archives are amd64-only builds for Linux, macOS and Windows. Source builds need Go 1.21+ according to go.mod, with Make targets for each platform; the r2 subcommand is meant to run from radare2 as #!pipe redress r2. - Input is an executable built with the Go compiler. The README's examples use a macOS cryptominer sample first reported by Malwarebytes, which the repository does not include; it commits no test binaries. GoRE recovers functions from the pclntab and types from the typelink list, fully supporting Go 1.7 and later and only partially 1.5 and 1.6, and its compiler-version detection is a string search that the GoRE README says is not perfect. - Redress is AGPL-3.0 (LICENSE). GoRE is mostly BSD-licensed, but its AGPL features such as GOROOT extraction make any build without the gore_bsd tag AGPL. Output reconstructs symbols, types and a source layout, not Go source code, and the README notes that some packages cannot be classified. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### ghidra-nanomips > Ghidra processor module that adds nanoMIPS disassembly and decompilation through a SLEIGH specification of the little-endian 32-bit nanoMIPS instruction set, including its multithreading instructions. NCC Group's announcement says it was written while reverse engineering MediaTek 5G baseband firmware, implements the instructions met in that firmware and leaves some complex P-Code emulation unimplemented, yet decompiles most of the baseband code the team analyzed. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.3.3, published 2025-11-06 from the reviewed main commit, with an extension zip built for Ghidra 11.4.2; v0.3.1 and v0.3.2 also target 11.4.2, while the README's build example uses Ghidra 11.0.3. For another Ghidra release, build from source with Gradle and GHIDRA_INSTALL_DIR, then add the zip through File > Install Extensions. - The module defines the single language nanomips:LE:32:default, and its importer opinion file is a commented-out template, so the language is chosen manually when importing, for example for a raw binary. The README lists the nanoMIPS32 ISA, privileged-architecture, multithreading, ELF ABI and I7200 core manuals it was written from; those documents are not included. - Release notes record p-code fixes for LWM/RESTORE, BITREVH and memory references, a compiler-spec fix for a decompiler varnode error and PC-relative address display for ADDIUPC. The repository has no tests or CI, and the specification still carries TODO notes on effective-address handling. - GPL-3.0; build.gradle keeps the Apache-2.0 header of Ghidra's extension skeleton. extension.properties names James Chambers and Robert Herrera as authors. Users supply the firmware to analyze; the announcement's MediaTek walkthrough is an illustration, not a bundled sample. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### SMDA > Python recursive disassembler library built on Capstone that recovers control-flow graphs from PE, ELF and Mach-O files, .NET assemblies, raw DEX files and memory dumps with a known base address, through x86/x64, AArch64, 32-bit ARM/Thumb, CIL and Dalvik backends. Its JSON reports list functions, basic blocks, instructions and the edges between them, enriched with symbols from imports, exports, PDB, Go, Rust and Delphi metadata, referenced strings, Windows API references inferred with the ApiScout method and position-independent code hashes. Function discovery deliberately favours completeness over precision; the README names SMDA as capa's disassembler backend and MCRIT's code-analysis layer, and IDA Pro or Binary Ninja analyses can be exported into the same report format. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the v5.0.1 release commit of 2026-10-20, which is also the latest GitHub release and PyPI version; v5.0.0 of 2026-10-16 added the 32-bit ARM backend. The CHANGELOG states that version numbers are a release counter, not semantic versioning, and pyproject.toml classifies the package as Beta. - pip install smda needs Python 3.11+ and pulls in capstone 5.0.2 or later below 6, demangle 0.6.0, dncil, dnfile, LIEF 0.16+ and purepdb. CI runs the tests on Python 3.11 to 3.14 on Ubuntu and on 3.11 on Windows and macOS. The analyze.py, batch_analyze.py and export scripts are not installed by pip and need a clone; the IDA frontend needs IDA Pro 8.4+, headless IDA export needs IDA 9.1+ with the optional ida-domain package, and Binary Ninja export needs a licensed Binary Ninja whose Python API is importable. - The README rates the intel backend as production quality and benchmarked against other disassemblers, AArch64 as matching IDA closely on its test corpora, and the ARM, CIL and Dalvik backends as recent; the managed backends are not benchmarked on obfuscated code and report file offsets rather than virtual addresses. Dalvik accepts raw single-DEX files only, not APKs, multi-dex, ODEX or CDEX, and recognized machine types such as big-endian ARM32, MIPS, PowerPC, SPARC and RISC-V have no backend. Binaries, memory dumps and IDA or Binary Ninja databases come from the analyst; for a headerless dump pass the architecture and base address, and ApiScout resolution needs WinAPI profiles matching the dumped system, of which data/ bundles Windows 7 SP1 and Windows XP SP3 profiles. The default analysis budget is 300 seconds, enforced cooperatively, a timed-out report is a lower bound, and synthesizing binaries from reports is experimental. - The tests use XOR-encoded binaries that are decoded in memory: programs built for the project, a DEX file whose classes are Apache HttpClient code (blockblast_classes_xored), and malware samples including Mirai builds for 12 architectures, Asprox, Cutwail, Bashlite, Komplex and njRAT, plus AArch64 Mach-O malware from Objective-See and Malpedia under tests/aarch64_macho_corpus, whose README forbids executing them. The CI benchmark additionally uses .github/workflows/data/malpedia.zip, a 74 MB password-protected Malpedia corpus whose password is a repository secret, so AGENTS.md says the benchmark cannot be reproduced locally. - BSD-2-Clause (LICENSE); NOTICE lists third-party parts, including rust_demangler-derived code under MIT and MSVC symbol names from LLVM's demangler tests under Apache-2.0 with the LLVM exception. AGENTS.md gives guidance to AI coding agents working on the code. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### frida-trace (NowSecure library) > JavaScript library for Frida agents that traces native functions from a declarative description: each function is listed with its return type and input and output arguments, including pointers, UTF-8 and UTF-16 strings and byte arrays whose length is bound to another argument or the return value, with conditions such as reading an output pointer only when the call succeeds. It resolves the functions from a module's exports or a vtable, attaches Frida's Interceptor and hands one event per call to callbacks. Helper scripts in the same repository generate trace boilerplate from C headers through libclang. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Not Frida's own frida-trace command-line tool, which shares the name. The latest npm release, 4.0.1 of 2025-06-16, matches the reviewed main commit 9b92c17 and ports the library to Frida 17; 4.0.0 of January 2024 moved it to ES modules. - It runs inside an agent script that the user writes, compiles (for example with frida-compile) and loads into a process Frida can attach to; it has no command-line interface of its own. Types cover bool, byte, short, int, pointer, byte arrays, UTF-8, UTF-16 and C strings, and the captured values are only as accurate as the signatures the user declares. - The header tools live in frida-trace-tools, version 3.3.0 in the repository and not published on npm; they need Node.js and frida-libclang, and the README still runs them from an older ./bin path. The bundled example host application and agent still depend on frida 16 and frida-trace ^3.0.0. The repository has no tests or CI. - MIT. Instrumentation needs a target process the user is entitled to inspect. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### BTD (Bin To DNN) > Research artifact for the USENIX Security 2023 paper “Decompiling x86 Deep Neural Network Executables”. BTD decompiles x86 executables emitted by the DNN compilers TVM, Glow and NNFusion into model specifications: operator types, network topology, dimensions and parameters such as weights and biases. It splits IDA disassembly into functions, infers each operator's type with a trained classifier over assembly tokens, records Intel Pin traces filtered by taint analysis, recovers dimensions and parameters with a trace-based symbolic execution engine, then rebuilds the model in PyTorch and compares its output with the original executable. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Research artifact with no tagged releases; the reviewed master commit (2026-03-13) fixes README typos. The paper appears in the USENIX Security 2023 proceedings, arXiv 2210.01075 is the authors' 25-page extended version, and the README reports Available, Functional and Reproduced artifact-evaluation badges. - README prerequisites: Ubuntu 18.04, gcc/g++ 7.5, Python 3.6.9+ with numpy 1.19.5, torch 1.9+, torchvision 0.11.2, fastBPE and tqdm, Intel Pin 3.14, and IDA Pro 7.5 for disassembly. IDA is commercial and not included, so precomputed disassembly is supplied; the authors recommend their Docker image. Their server had 256 GB RAM, and logging and filtering traces for every executable took over a week and nearly 1 TB, so filtered traces are shipped and the rest of the evaluation takes about a day and under 120 GB. - Evaluation inputs are downloaded separately from Dropbox or the Zenodo dataset (DOI 10.5281/zenodo.7219867): 63 executables built from 7 ONNX models with Glow 2020–2022 and TVM v0.7–v0.9.dev at O0 and O3, their disassembly and filtered traces, operator-inference training data and checkpoints, and the Docker image. The repository itself commits scripts, Pin tool sources, per-executable JSON metadata and a cat test image stored as input tensors in cat.bin and cat_transpose.bin. - Scope is x86 CPU executables from the evaluated compiler versions; the main evaluation covers TVM and Glow, with NNFusion handled by separate scripts. Per-model decompilation scripts under evaluation/ serve as the interface rather than a general command-line tool. - HKUST Academic Software License (LICENSE, COPYING): academic or nonprofit researchers may use, copy and modify it for educational or academic research only, and publications must include the stated acknowledgment; GitHub reports no SPDX license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Boomerang Decompiler > Fork of the SourceForge Boomerang project, a general machine-code decompiler that translates executables into C. The README lists x86 (IA-32 only), PowerPC and ST20 code in ELF, PE, DOS MZ, DOS/4GW LE and Mach-O files; instruction semantics are defined in SSL specification files, and library signature files plus printf- and scanf-style format strings help recover types. It provides a boomerang-cli command-line tool and a Qt boomerang-gui application, with unit, regression and recompilation test suites. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Inactive legacy project: the reviewed develop commit of 2020-12-28 is the repository's last push, and the Changelog still marks v0.6.0 as in development. The last release, v0.5.2 (2020-01-11), provides Linux x86_64 and Windows x64 builds, while the README recommends building develop from source. - Building needs a 64-bit OS, a C++17 compiler (GCC 7+, Clang 6+ or MSVC 2017+), CMake 3.13+, Qt5 (5.12+ known to work), Capstone 4.0.1+, GNU bison 3.3+ and flex 2.6+; Python 3 runs the regression tests, which are not supported on Windows. The README documents Linux, macOS 10.13+ with Xcode 10 and Homebrew, and Windows with Visual Studio 2017. - Supply the executable to decompile. x86 support covers 32-bit code only, the v0.6.0 development line removed SPARC support, and the generated C needs analyst review. - data/samples commits about 240 small test binaries for macOS, DOS, ELF, PowerPC, Windows and x86, most named after the test programs in tests/recompilation-tests and tests/sources, plus three Linux distribution builds of the true utility; tests/regression-tests stores the expected decompiler output for them. data/signatures holds hand-written library prototype files, not vendor headers. - BSD-style terms in LICENSE.TERMS, carried over from the University of Queensland, Sun Microsystems and the original authors; GitHub reports no SPDX match. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### ktool > Pure-Python toolkit for static Mach-O and Objective-C analysis, used as the ktool command line, a terminal browser (ktool open) or a library, with no compiled dependencies. Its commands print load commands, linked libraries, symbol tables, imports and exports, Objective-C classes and protocols, Swift types, function starts and code-signing entitlements, and dump reconstructed Objective-C headers or .tbd stubs. It can also list and extract kexts from kernel caches, split and combine fat binaries, change install names and insert load commands. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest PyPI release at review: k2l 2.0.0, uploaded 2024-01-10 and also tagged on GitHub. The reviewed master head of 2026-03-07 declares version 2.1.2 in pyproject.toml, which has not been published. The README marks the terminal GUI as still in active development and lists file and img4 utilities that the reviewed command parser does not define. - Install with pip install k2l: the package requires Python 3.6.2 or later, depends on Pygments and adds windows-curses on Windows. The README reports running it on Windows, macOS, Linux (including ARM64), iOS through iSH, Android through Termux, WebAssembly and Brython. Unless KTOOL_NO_UPDATE_CHECK is set, each run asks PyPI for a newer k2l in a background thread. - Inputs are Mach-O files, fat binaries or kernel caches the user supplies; the repository commits no Mach-O binaries. tests/src holds two small Objective-C test sources, an entitlements plist and libSystem.tbd, a text-based stub of the watchOS libSystem export list of the kind found in Apple's SDKs, used to link the arm64_32 test build; tests/build.ninja compiles the test binaries locally with Xcode's clang, lipo and codesign. - The macOS GitHub Actions workflow builds those test binaries, runs tests/unit.py and exercises the insert, edit, lipo, dump and symbols commands; its run on the reviewed commit failed. - MIT (LICENSE, copyright 2021 _kritanta). EXTERNAL_LICENSES notes that the chained-fixup code is based on the author's code for Binary Ninja's Mach-O view plugin and includes an Apache-2.0 license for it. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Brida > Burp Suite extension by Federico Dotta and Piergiovanni Cipolloni that bridges Burp and Frida, so an analyst can run an app's own functions on the HTTP messages it exchanges with its backend instead of reimplementing its encryption, encoding or signing. A graphical plugin engine connects Frida-exported functions to Burp: they can process requests and responses in every Burp tool, or run from custom message-editor tabs, context-menu entries and buttons, and a Generate Stubs tool emits Java or Python code for external Burp extensions. An analysis tab shows the app's Java and Objective-C classes, methods, imports and exports as a tree, from which hooks that log arguments and return values, or replace return values, can be added; an editor holds the analyst's own Frida exports. - Type: Tool - Targets: App · Protocol - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.6, published 2025-10-23 as a single Brida_0.6.jar; the reviewed master commit is two commits ahead, adding and then removing a BApp Store description. Version 0.6 was refactored for Frida 17's JavaScript API and needs Frida 17 or later; v0.6pre, used with frida-compile 10.2.5, remains the release for older Frida versions. The README also points to Burp's BApp Store and notes that the copy there can lag behind GitHub. - Needs Burp Suite Community or Pro, Node.js and npm on the system path (the README warns that this can be hard on macOS), and the frida, frida-tools and pyro4 Python packages; a bundled Pyro4 service script connects the extension to Frida. The README says Brida supports every platform Frida does (Windows, macOS, Linux, iOS, Android and QNX). Mobile targets need a jailbroken iOS or rooted Android device running frida-server, or an app patched with the Frida gadget. - Builds use Gradle's jar task, or Maven once the bundled modified RSyntaxTextArea jar (libs/rsyntaxtextarea-2.6.1.edited.jar) is installed locally; the extension uses the legacy Burp Extender API. Demo/ holds the authors' own conference demo apps and backend (HIP2021_demo.apk, DemoHIP.ipa, DemoHITB.ipa and BridaTestAppBackend-0.0.1-SNAPSHOT.jar), demo TLS certificates and keys, and exported demo plugins. The iOS demo README asks that its backend, which logs in to MySQL as root with an empty password, run only on a firewalled system or VM. - MIT license. Brida for apps and backends the analyst owns or is authorized to test. The default Android and iOS hook collections under res/, which the README credits to various Frida CodeShare and GitHub authors. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Qu1cksc0pe > All-in-one malware triage tool that statically analyses Windows PE, Linux ELF (including Go binaries), macOS Mach-O and Android APK, JAR and DEX files as well as Office and PDF documents, scripts, shortcuts, archives, e-mails and PCAPs, reporting imports and API categories, sections, strings and IOCs, packers, embedded executables, Android permission risk, YARA matches and, for Windows and Linux, MITRE ATT&CK mappings. VBA/VBScript, JavaScript and PowerShell are run through bounded in-memory emulators instead of being executed, and --watch modes monitor live Windows, Linux and Android processes. A CLI, a Flask web UI and an MCP server expose the analyses, with optional LLM summaries of the JSON reports. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Actively developed from the master branch with no tags or GitHub releases; the reviewed commit of 2026-09-18 adds live-memory YARA/IOC scanning, Windows injection and hollowing checks and expanded Android dynamic analysis. README recommends Parrot OS, Kali Linux or Windows 10/11; Mach-O and Go binaries are analysed statically only. - README has users clone the repository into a Python virtual environment and run setup.sh (apt-get or pacman hosts) or setup.ps1 on Windows. Setup installs requirements.txt, which pins androguard 3.4.0a1, yara-python 4.5.0 and unicorn 2.1.4 and adds lief, pefile, oletools, frida-tools, docker, flask and mcp>=2.0.0, plus adb, binutils strings, unzip, 7-Zip, JADX 1.5.3 in a sc0pe_Base folder in the home directory and Ollama with its configured model. A Dockerfile based on Ubuntu 22.04 runs the CLI against a mounted file. Hash scans download the HashDB SQLite database from the separate CYB3RMX/MalwareHashDB repository, and VirusTotal lookups need the user's own API key. - Inputs are the analyst's own suspicious files. The repository ships detection data, about 300 YARA rule files, Android Frida scripts and API and ATT&CK mapping tables, plus a bundled dnlib 3.6.0 .NET library (Systems/Windows/dnlib.dll, from the open-source de4dot project) that the reviewed scripts do not reference by name; it contains no malware samples. Static analysis and the script emulators do not run samples, but Linux binary emulation runs them under qemu-user in a network-disabled Docker container, falling back to host qemu when Docker is unavailable, and the --watch modes attach to live processes on the host or a connected Android device. Handle samples only on an isolated analysis machine. - --ai sends a report to Ollama by default; the shipped multiple.conf names the cloud-tagged kimi-k2.5:cloud model, for which setup.ps1 suggests ollama signin, and Claude, OpenAI, DeepSeek, Kimi and GLM backends are opt-in through --ai_provider, in which case report data leaves the machine. The MCP server (--mcp) exposes 14 tools over streamable HTTP on 127.0.0.1:8765 by default, or over stdio, and a bundled .mcp.json registers it for Claude Code. Family candidates, emulation traces and AI summaries are heuristic findings for analyst review. - GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### AppMon > Frida-based framework by Nishant Das Patnaik, shown at Black Hat Arsenal 2016, for watching the system API calls that native macOS, iOS and Android apps make. Its Sniffer attaches to or spawns an app, loads hook scripts from a bundled library covering areas such as crypto, keychain, files, SQLite, HTTP, IPC and WebView, and records each intercepted call in a per-app SQLite database that a local Flask web interface displays. Further components trace Java classes, methods and argument types in Android apps and repackage IPAs or APKs with Frida Gadget so they can be inspected on non-jailbroken or non-rooted devices. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository is archived on GitHub and read-only. Its last commit on master, from 2022-11-08, changed the Frida release URL in apk_builder/getlibs.sh, and there are no releases. The usage documentation lives in the project wiki, last edited in 2019; the GitHub Pages site only links to it. - requirements.txt pins frida 12.2.6 (September 2018), Flask 1.0.2, Werkzeug 0.15.3 and other packages of that period. The hook scripts rely on Frida's Java and ObjC bridges and on legacy calls such as Module.findExportByName and Memory.readUtf8String, which Frida 17.0.0's release notes (May 2025) say are no longer bundled or have been removed, so current Frida releases are unlikely to work without changes. - The wiki's host setup covers macOS and Ubuntu or Kali Linux, with Android command-line tools on Linux. Jailbroken iOS and rooted Android devices run frida-server. For other devices the IPA Installer injects the committed ipa_installer/release/FridaGadget.dylib (about 14 MB) and re-signs the app with the user's iOS developer provisioning profile, while the APK Builder adds Frida Gadget libraries that getlibs.sh downloads and re-signs the APK with apk_builder/appmon.keystore, a shared key committed with a fixed password. Use these only on apps and devices you are permitted to test. - The README also lists an Intruder component that changes API-call data to alter an app's behavior. Apache-2.0 (LICENSE). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Yagi > Airbus CERT plugin that embeds Ghidra's native decompiler in IDA Pro and IDA Free: pressing F3 on a function shows Ghidra's C output inside IDA, and edits made there, covering global symbols such as function prototypes and the names and types of stack and register variables, are saved to the IDA database. The README lists x86, x86-64, ARM, AArch64, PowerPC, MIPS, SPARC, AVR8, 6502, Z80 and eBPF as supported, while other Ghidra processors such as Dalvik, JVM, RISC-V and 68000 are not yet enabled. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Inactive since its latest release, v1.5.0 (2022-08-04), which adds eBPF and IDA 7.7 support and ships Windows MSI installers for IDA 7.6, IDA 7.7 and IDA Freeware; the last Linux installers (.sh and .tar.gz for IDA 7.5, 7.6 and Freeware) are in v1.4.0 (2021-12-20). No builds for IDA 8 or later are published. The default branch is main; an older master branch stops in 2021. - Source builds need a recursive clone, whose submodules are Airbus CERT's Ghidra fork on its fix-memory-access-violation branch (pinned at the Ghidra 10.1 release commit), eBPF-for-Ghidra and cylance/eBPF_processor. They also need CMake 3.11+, a C++ compiler (Visual Studio on Windows), flex and bison for the SLEIGH grammar, WiX for the Windows installer, and the Hex-Rays IDA SDK matching the user's IDA version, which the repository does not include. - The workflows build on a self-hosted Windows runner against a locally installed IDA 7.6 SDK. Their googletest unit tests decompile machine-code byte arrays written into the test sources for x86 (16-, 32- and 64-bit), ARM, MIPS, PowerPC, SPARC, 6502 and Z80, using mocked IDA loader, symbol and type interfaces. README TODOs include enum types, AArch64 function-end rules and changing constant types. - Apache-2.0; Ghidra's decompiler keeps its own Apache-2.0 terms, and IDA and its SDK are Hex-Rays products under their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### frida-scripts (0xdea) > Marco Ivaldi's (raptor) collection of Frida JavaScript instrumentation scripts for reverse engineering mobile apps and Linux programs. The main Android and iOS tracers hook Java or Objective-C classes and methods selected by name, wildcard or regular expression, plus native functions matched by Frida ApiResolver patterns such as exports:*!open*, and log each call's arguments and return value; they can also print backtraces. Companion scripts enumerate loaded classes and methods, and a Linux pair traces and enumerates functions in an ELF binary and its shared libraries. - Type: Tool - Targets: App · Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-02 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Load a script with Frida's CLI from frida-tools, for example frida -U -f -l raptor_frida_android_trace.js for an app on a USB-connected device, after uncommenting or editing the usage examples at the end of the script. Mobile use needs a device that Frida can instrument; the iOS tracer's header records a jailbroken iPhone 8 on iOS 16.5. - **Limits:** Version 0.2 (2025-10-02) ported the main tracers to Frida 17. Script headers record Frida 17.3.2 on Android 11 and iOS 16.5 and Frida 17.2.1 on Ubuntu, while the android-snippets and ios-snippets directories were tested only with Frida before 17.0.0. The README warns that the iOS and Android scripts may need tweaking and points to Brida as a maintained project that includes some of them. - **Testing evidence:** The repository has no automated tests or CI, and its TODO lists extensive testing with real-world apps. - **License:** MIT per LICENSE. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### System Informer > Windows process viewer and system inspector, formerly Process Hacker, for examining running programs and the system around them. It gives a highlighted overview of system activity, searches the handles and loaded DLLs of processes to find which one is using a file, shows active network connections and real-time disk access, displays stack traces with kernel-mode, WOW64 and .NET support, and creates, edits and controls services. Version 4.0 adds a Process Monitor that logs process, thread, image, registry, file, handle and silo events from its kernel driver, and plugins add .NET assembly and performance tabs, a window explorer and Hybrid Analysis lookups. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows 10 or later, 32-bit or 64-bit, per the README. Release at review: v4.0.26241.138, published 2026-08-29 as the first 4.0 release; the reviewed master commit is 874 commits ahead of it. Building from source needs Visual Studio 2022 or later and the build_init.cmd and build_release.cmd scripts in build/. - **Limits:** The KSystemInformer kernel driver gives its broader inspection only to verified callers: binaries loaded into System Informer need a .sig from the build's key pair or a Microsoft or anti-malware vendor signature, and loading an unsigned third-party plugin restricts driver access. Builds signed with a developer's own key need debug and test-signing mode, with Secure Boot disabled where applicable. - **Scope:** The Agent Tools plugin is on the master branch only, not in the 4.0 release; its source describes it as exposing System Informer's process data and actions to AI agents over the Model Context Protocol. It is off by default, asks to confirm connections by default and offers stdio setup commands for clients such as Claude Code and Codex CLI. The OnlineChecks plugin's Hybrid Analysis lookups are opt-in with per-service API keys and can optionally submit unknown files. - **License:** MIT per LICENSE.txt and the README. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### CyberChef > GCHQ's browser-based workbench for decoding, decrypting, decompressing, parsing and carving data by chaining operations into a recipe, with all processing done client-side. The pinned operation catalogue lists 506 operations, among them XOR brute force, AES, DES and Blowfish decryption, x86 and ARM disassembly, ELF info, file-type detection, file extraction, entropy and strings, YARA rules, Protobuf decoding and Ethernet, IPv4, TCP and UDP header parsing. The Magic operation tries to detect nested encodings automatically, and breakpoints step through a recipe one operation at a time to show the data at each stage. - Type: Tool - Targets: Binary · Protocol - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Use the hosted app at gchq.github.io/CyberChef, a full copy downloaded from the app, the ghcr.io/gchq/cyberchef Docker image or a Node.js v24 build (npm install, then npm start or npm run build); the README lists Chrome 50+ and Firefox 38+ as supported browsers. Release at review: v11.5.0, published 2026-09-18; the reviewed master commit is newer. - **Limits:** Inputs and recipes stay in the browser and are not sent to the web server. Files of up to about 2 GB load, depending on the browser, and some operations can take a very long time on that much data; Auto Bake can be turned off for large inputs. - **License:** Apache-2.0, under Crown Copyright; contributions require signing the GCHQ Contributor Licence Agreement. ##### Primary sources 1. 2. 3. 4. 5. #### YARA > VirusTotal's pattern-matching tool for identifying and classifying files such as malware samples with rules that combine text, hex and regular-expression strings with a Boolean condition. It scans a file, a folder or a running process from the command line, through the libyara C API or from Python with yara-python. Modules expose parsed structure to rules: pe and elf expose most fields of PE and ELF headers, dotnet adds .NET metadata, math adds calculations such as entropy, and the optional magic and cuckoo modules add libmagic file types and Cuckoo sandbox behavior reports. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Runs on Windows, Linux and macOS; release at review: v4.6.0, published 2026-10-27. Source builds need automake, libtool, make, gcc and pkg-config. Features that depend on OpenSSL are enabled only when OpenSSL is installed, and the cuckoo (Jansson) and magic (libmagic) modules are compiled only with --enable-cuckoo or --enable-magic; vcpkg also packages YARA. - **Limits:** The README marks YARA as in maintenance mode; the YARA-X README says YARA still receives bug fixes and minor features, while new modules and large features go only into YARA-X. The command-line documentation warns that compiled rules from untrusted sources can lead to the execution of malicious code; since YARA 3.9 they load only with -C. - **License:** BSD-3-Clause per COPYING. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Cheat Engine > Memory scanner, debugger, disassembler and assembler for inspecting and changing running games and other applications; its README calls it a development environment focused on modding games and applications for personal use. The project site lists a memory scanner for finding the variables a game uses, a debugger, disassembler, assembler, speedhack, trainer maker, Direct3D manipulation and system inspection tools, and the README's build notes add Mono, .NET and Java runtime inspection, a VEH debugger interface, Lua and C code in scripts and an optional kernel-mode driver. - Type: Tool - Targets: Binary · Game - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The site's news of 2026-05-29 says Cheat Engine 7.7 was released for Windows, Mac and Linux to Patreon supporters first, followed by a public Windows installer. The newest GitHub release is 7.5 (2023-02-23), which attaches no binaries, and the reviewed master commit dates from 2025-04-19. - **Prerequisites:** Building needs Lazarus 2.2.2 for 64-bit Windows with its i386 cross-compiler for the main project and Visual Studio (usually 2017) for the .sln helper projects, such as the Mono, .NET and Java data collectors. Kernel-mode functions need the DBK driver built without a signature, then booting with unsigned-driver support or signing the driver yourself. - **Scope:** The site describes it as made for modifying single-player games without an internet connection, says it will most likely not work on online games, requires users to be 18 or older, calls it for private and educational purposes and asks users not to violate a game's or application's EULA or terms of service. - **License:** The repository has no top-level license file and GitHub detects no license; the site says the source code is visible so that anyone can compile their own version. Bundled components such as tcclib carry their own license files. ##### Primary sources 1. 2. 3. 4. 5. #### Noriben > Python script that drives Sysinternals Process Monitor to record what a program does while it runs, filters out routine system activity and writes a text report of the processes it created and its file, registry and network activity. It works as a lightweight malware sandbox and can also log events while the analyst runs a sample by hand, with command-line options, user interaction or under a debugger; created files can be scanned with YARA rules and their hashes looked up on VirusTotal. Version 2.1.0 adds DLL-load monitoring, an ASCII process tree and JSON output, and NoribenSandbox.py automates runs inside a guest VM. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3 and Sysinternals procmon.exe or procmon64.exe on the Windows analysis machine; yara-python is optional for --yara scans and requests for VirusTotal lookups. Release at review: 2.1.0, published 2026-11-03, whose tag is the reviewed main commit. - **Scope:** The README's sandbox workflow runs a sample in a VM, copies the results off and reverts before the next sample. NoribenSandbox.py starts a predefined VM snapshot, copies in the sample, runs Noriben and retrieves a ZIP report and a screenshot; the README says this front end currently runs on macOS hosts. - **Limits:** With a VirusTotal API key it looks up file hashes; uploading every created file to VirusTotal happens only when virustotal_upload is set to True in Noriben.config, which defaults to False. - **Testing evidence:** The 2.1.0 notes add large-scale unit testing, developed with AI assistance; the README runs tests/unit_tester.ps1 through Noriben in a Windows VM with Procmon module loads enabled. - **License:** Apache-2.0 per the README and LICENSE. ##### Primary sources 1. 2. 3. 4. 5. #### QEMU > Machine and user-space emulator that runs code built for one CPU architecture on another through its TCG dynamic translator. System emulation boots a complete emulated machine, such as an ARMv7 board on an x86_64 PC, and user-mode emulation runs Linux or BSD binaries built for another ABI by translating their system calls. For analysis, its gdbstub lets GDB stop the guest, examine registers and memory and set breakpoints and watchpoints, TCG plugins passively instrument execution down to single instructions and memory accesses (bundled examples count instructions, trace system calls and log execution), and system emulation supports deterministic record/replay debugging. - Type: Tool - Targets: Binary · Firmware - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Builds on modern Linux, macOS, Windows through the Mingw64 toolchain and other Unix hosts (mkdir build, ../configure, make). The upstream repository is gitlab.com/qemu-project/qemu; GitHub carries a read-only mirror that asks users to take release tarballs from the QEMU website. The newest tag at review was v11.1.3, on a commit dated 2026-10-28. - **Limits:** User-mode emulation covers only the Linux and BSD system-call interfaces and emulates no hardware, and each guest architecture supports system emulation, user mode or both. TCG plugins observe guest state without changing it, and the bundled syscall plugin works only in user mode. With KVM or Xen, the hypervisor runs the CPU while QEMU provides emulated hardware. - **License:** QEMU as a whole is released under GPL-2.0; the LICENSE file gives component details. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Hex Fiend > Open-source macOS hex editor that inspects and edits binary files of any size without loading them into memory. It supports insertions and deletions, fast search and a data inspector that reads integers and floating-point values as signed or unsigned and big- or little-endian. File > Compare shows the differences between two files while accounting for inserted or deleted bytes, and Tcl binary templates display a file's structure next to its bytes; bundled templates cover COFF, ELF, Mach-O and MS-DOS EXE headers, 6502 disassembly and Commodore 64 PRG files, plus archives, file systems, partition tables and media formats. Its hex and data views are also available as an embeddable framework. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS 10.14.6 or later, required since v2.17. Release at review: v2.18.1, published 2025-03-16; the reviewed master commit is dated 2025-06-29. Custom templates are .tcl files in the app's Templates folder under Application Support. - **Limits:** Binary templates arrived in v2.9 and are written in Tcl, which ships with macOS. Since v2.17 templates can declare file types for automatic selection, but the release notes say most built-in templates do not yet set this information. - **License:** BSD-2-Clause per License.txt. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### ScyllaHide > User-mode (ring 3) anti-anti-debug library for 32- and 64-bit Windows programs that hooks system functions so the program being debugged cannot detect the debugger. Its documentation covers options for PEB debug flags such as BeingDebugged, NtGlobalFlag and heap flags, threads hidden with ThreadHideFromDebugger, debugger windows and processes found through window and process-list queries, invalid-handle NtClose checks, input blocking, timing checks, hardware-breakpoint detection and exception-based checks; extra options inject DLLs, prevent thread creation and dump processes started RunPE-style. Plugins integrate it with x64dbg, OllyDbg v1 and v2, IDA and TitanEngine, and the standalone InjectorCLI injects its hook library into a process under any debugger. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows; release at review: v1.4, published 2023-03-24, with the reviewed master commit dated 2023-07-29. Plugins cover x64dbg, OllyDbg v1 and v2, TitanEngine v2 and IDA; the README lists the IDA v6 plugin as not supported and says PE x64 debugging is fully supported with the x64dbg and IDA plugins. - **Limits:** It works only in user mode, and the README points to TitanHide for kernel-mode (ring 0) anti-anti-debug. Each option targets specific anti-debug checks: the documentation advises enabling the timing, hardware-breakpoint, thread-prevention and NtYieldExecution options only when needed, and using the RunPE unpacker, which terminates and dumps newly created processes, only inside a virtual machine. - **License:** GPL-3.0. The project is a fork of the original ScyllaHide repository on Bitbucket; the full manual is a PDF attached to the docs-2019-05-17 release, and its LaTeX source is in Documentation/. ##### Primary sources 1. 2. 3. 4. 5. #### YARA-X > VirusTotal's Rust rewrite of YARA for identifying and classifying files with pattern-matching rules. It is meant to replace YARA, with more detailed error reports, faster regular-expression and hex-pattern matching and a more capable command line. Rules keep YARA's syntax of text, hex and regular-expression patterns joined by a Boolean condition, and modules parse PE, ELF, Mach-O, .NET, Android DEX, Chrome CRX and Windows LNK files; the CLI can also print a module's parsed output as JSON or YAML without any rule, which makes it usable as a file-dissection tool. Rust, C, Go and Python APIs, a rule formatter and a language server with a Visual Studio Code extension are included. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Pre-built binaries for Linux, macOS and Windows come with each release; macOS users can install it with Homebrew and Python users with pip install yara-x. Building needs a recent Rust toolchain (cargo install --path cli), and the Go library builds on the C API. Release at review: v1.23.0, published 2026-11-05. - **Limits:** Its comparison page says the C/C++, Python and Go APIs are not compatible with YARA's and that process scanning is not implemented yet; a separate page lists rule-level differences. The README calls YARA-X mature and stable and says VirusTotal runs it in production. - **License:** BSD-3-Clause per LICENSE; contributions need Google's Contributor License Agreement. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### ReClass.NET > Memory structure editor for reconstructing the classes and data structures of a running x86 or x64 process, a .NET port of ReClass with many additions. Users lay out memory as typed nodes, such as integers, floats, vectors and matrices, text, pointers, arrays, unions, virtual tables and function pointers, with automatic node dissection, highlighting of changed memory, types from PDB debug symbols and RTTI class names, then generate C++ or C# code from the result. It also offers a memory viewer and scanner, a module and section dumper, a debugger that finds what writes to or accesses an address, and plugins that can supply other memory-access methods or game-specific class information, such as for Frostbite games. - Type: Tool - Targets: Binary · Game - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Releases ship x86 and x64 builds with a launcher that picks between them, and the README lists Linux support tested on Ubuntu 18.04. Release at review: v1.2, published 2019-04-15; the reviewed master commit dates from 2023-07-03. Compiling needs Visual Studio 2019, and the Linux native core library needs WSL, plus g++-multilib for cross-platform builds. - **Scope:** It imports ReClass 2007–2016, ReClass QT, Cheat Engine and CrySearch files. Plugins are installed by copying them into the Plugins folder; the README says the Unreal plugin is no longer available. - **License:** MIT per LICENSE. ##### Primary sources 1. 2. 3. #### Keypatch > IDA Pro plugin built on the Keystone assembler engine that patches a binary from typed assembly, fills an address range with instructions or raw bytes and searches the loaded binary for assembly instructions. It assembles Arm, Arm64, Hexagon, MIPS, PowerPC, SPARC, SystemZ and 16-, 32- and 64-bit x86 code, shows the encoding while you type, can pad with NOPs up to the next instruction boundary, keeps the original instruction in an IDA comment and can undo the last patch. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs IDA Pro on Windows, macOS or Linux with the Keystone engine and its Python binding plus the six module; keypatch.py is copied into IDA's plugins folder. The README confirms IDA Pro 6.4 to 7.5, and the reviewed master commit (2024-09-06) adds IDA 9.0 API changes. The latest tagged release is 2.1 (2017-01-17), while the code reports version 2.2. - **Limits:** Patches change only the IDA database until Edit | Patch program | Apply patches to input file writes them to the original binary. - **License:** GPL-2.0 per COPYING. ##### Primary sources 1. 2. 3. 4. 5. #### edb-debugger > Qt-based graphical debugger for AArch32, x86 and x86-64 programs, inspired by OllyDbg, with Linux as its only officially supported platform. Its interface docks disassembly, register, stack and data views, adds a memory-regions window, process attaching, symbols, an expression syntax and an analysis bar similar to IDA Pro's, and its default plugins include Analyzer, Assembler, BinarySearcher, BreakpointManager, FunctionFinder, HardwareBreakpoints, HeapAnalyzer, OpcodeSearcher, ROPTool and SymbolViewer. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux is the only officially supported platform; FreeBSD, OpenBSD, macOS and Windows ports are underway with varying functionality. Building needs a C++17 GCC or Clang, Qt 5.15+ or 6.8+, Capstone 3.0+ and optionally Graphviz 2.38+, using CMake on a recursive clone so that the submodules are fetched. - **Scope:** Release at review: 1.5.0, published 2024-03-22 and the last version to support Linux kernels older than 3.0; new development targets kernel 3.0 and newer and will be released as 2.0.0. The reviewed master commit is dated 2026-10-27. - **License:** GPL-2.0 per COPYING. ##### Primary sources 1. 2. 3. 4. 5. #### BinNavi > Google's open-sourced binary analysis IDE for inspecting, navigating, editing and annotating the control-flow graphs and call graphs of disassembled code. It also collects and combines execution traces and keeps track of analysis results among a group of analysts. Disassemblies come from IDA Pro through a bundled export plugin that writes the PostgreSQL database BinNavi uses for disassemblies, comments and traces; the README notes that no exporter exists yet for other disassemblers. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs Java 11 or later, a reachable PostgreSQL database and IDA Pro to import disassemblies. It builds from source with Maven and Ant (mvn dependency:copy-dependencies, then ant build-binnavi-fat-jar); the Gradle build is experimental. GitHub releases include BinNavi 6.1 (2016-03-17) and a historical 1.2 version published in 2017. - **Limits:** The README says the project is no longer under active development, and the repository was archived on GitHub after its last commit on 2020-10-23. Graph display uses the commercial yFiles library: the repository ships a pre-built, obfuscated yfileswrap JAR, and changing the yfileswrap packages needs a yFiles license. - **License:** Apache-2.0, apart from the yFiles dependency. ##### Primary sources 1. 2. 3. #### flare-emu > Mandiant FLARE Python library that pairs IDA Pro, Rizin or Radare2 with the Unicorn emulator so analysts can script emulation of the binary they are analyzing, for 32- and 64-bit x86, ARM and ARM64. Its interfaces emulate an instruction range or function with chosen register and stack values, force execution down the branches needed to reach target addresses or every cross-reference to a function, walk all paths through a function, run a standalone byte blob, or emulate from an address until nothing is left, with hooks on instructions and calls. A common use in its README is decrypting malware strings by emulating the decryption routine at each call site and commenting the results. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs Unicorn and its Python bindings plus IDA Pro 7.x or later (older IDA APIs are not supported), Rizin with rzpipe, or Radare2 with r2pipe; the README also shows use through IDA's idalib. Installation means copying flare_emu.py, the framework module and flare_emu_hooks.py into IDA's python directory or onto Python's import path. - **Limits:** The repository was archived on GitHub after a final release tagged 2025-08-14, which has no notes. With Rizin it runs as a command-line script or in a Python shell. - **License:** Apache-2.0 per LICENSE-APACHE.TXT. ##### Primary sources 1. 2. 3. 4. #### IDA Pro > Hex-Rays' commercial interactive disassembler, decompiler and debugger, which turns compiled code for more than 70 processor families into annotated, cross-referenced assembly and decompiled pseudocode. Its 15 decompilers cover 32- and 64-bit x86, ARM, MIPS, PowerPC and RISC-V as well as ARC, V850, TriCore, Hexagon and Android DEX; the Dalvik decompiler, new in IDA 9.5 alongside TriCore and Hexagon, renders DEX bytecode as Java pseudocode. Documented loaders include PE, ELF and Mach-O with Apple dyld shared caches and kernelcaches, DEX, UEFI firmware images, WebAssembly modules and console formats such as Xbox XBE, N64, SNES ROM and PlayStation PSX executables, and the processor list names console CPUs from the NES and Game Boy to the PlayStation 3 Cell, Xbox 360 Xenon and PSP Allegrex. The debugger runs locally or through remote debug servers for Windows, Linux, macOS and Android, and analysis can be scripted with IDAPython, IDC and the C++ SDK, run without a GUI through the idalib library, or driven from MCP clients through IDA MCP. - Type: Tool - Targets: App · Binary · Firmware · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** Release at review: IDA 9.5 (build 9.5.261026), announced 2026-10-26. Hosts: macOS 12+ (x64 or ARM64); x64 Windows 10 1607+ for the GUI, Windows 7+ for text-mode or headless use; 64-bit Linux, where the installation guide names CentOS 7 or Ubuntu 16.04 and the IDA Free page glibc 2.28 (Debian 10, Ubuntu 18.10, RHEL 8) on x86-64 or ARM64. IDAPython needs Python 3.11+. - **License:** Commercial, sold only as yearly subscriptions; perpetual licenses ended on 2024-09-30, and those bought earlier keep working for the version purchased. IDA Pro Essential has two cloud decompilers from one family, Expert two, four or six local ones and Ultimate all local ones, on Named, Computer or Floating licenses; IDA Pro Headless is an OEM license for servers, CI and embedding in products. - **License:** IDA Free and IDA Home are Named licenses for non-commercial use only. Free disassembles only x86 and x86-64, decompiles them in the cloud and debugs locally on x86/x64; Home has 70+ disassemblers, 11 cloud decompilers (32- and 64-bit x86, ARM, MIPS, PowerPC and RISC-V, plus Android DEX) and local or GDB-server debugging. Cloud decompilers need an Internet connection. - **Limits:** The IDA 9.5 release notes say the Dalvik decompiler does not rebuild try-with-resources, can emit output that is not valid Java and gives obfuscated files no special treatment, and that the new UEFI plugin focuses on the DXE environment and is still being refined. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Binary Ninja > Vector 35's commercial interactive disassembler, decompiler and debugger, whose decompiler is built on the BNIL family of intermediate languages and shows either C or BNIL for every officially supported architecture. Depending on the edition it decompiles x86/x86-64, ARMv7/Thumb2, AArch64, PowerPC, MIPS, RISC-V, MSP430, 6502, nanoMIPS, TriCore, C-SKY, M·CORE, Hexagon, NDS32 and TMS320C6x, and it loads raw binaries and PE/COFF, ELF, Mach-O, TE, Intel HEX, Motorola S-Record, TI-TXT, MD1ROM and VxWorks files. C++, Python and Rust APIs automate analysis inside or outside the UI; the open-source debugger runs locally or remotely on Windows, Linux and macOS and also connects to GDB, LLDB and iOS debugserver targets; patches can be made by editing assembly, in the hex editor or with the bundled SCC compiler; and 6.0 added an MCP server. Ultimate adds Firmware Ninja for embedded firmware, which finds code and data regions by entropy and detects memory-mapped I/O accesses, while the EFI Resolver workflow types protocol usage in UEFI PEI, DXE and SMM modules. - Type: Tool - Targets: Binary · Firmware - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** Stable release at review: 6.0.10905 (6.0 Release 2, 2026-10-20), a bug-fix update to 6.0 (2026-09-03). One license covers Linux, macOS and Windows; tested hosts are Ubuntu 24.04/26.04 and macOS 15/26 (x64 or arm64) and Windows 10/11 (x64); minimums: 2 GHz multi-core CPU, 8 GB RAM, 4 GB disk. Needs Python 3.10+. - **License:** Four editions: Free, Non-Commercial (Personal, non-commercial use only), Commercial and Ultimate. Paid licenses include a year of updates; versions released during support keep working after it. Online purchases are named licenses (one person, several machines). Only Commercial and Ultimate run plugins headlessly (import binaryninja without the GUI); Non-Commercial uses the API only from GUI-loaded plugins or the Python console. - **License:** By edition, Free decompiles x86, x86-64, ARMv7, Thumb2 and AArch64; Non-Commercial and Commercial add PowerPC, MIPS, RISC-V, MSP430, 6502 and the MD1ROM loader; only Ultimate decompiles nanoMIPS, TriCore, C-SKY, M·CORE, Hexagon, NDS32 and TMS320C6x and has the VxWorks loader, Firmware Ninja, Binary Similarity and Ghidra Export. - **Limits:** Free (non-commercial use or commercial evaluation) has no API or plugins and only disassembly, HLIL and Pseudo C views. The free browser-based Binary Ninja Cloud supports all architectures but requires uploading binaries to Vector 35, reads only PE, Mach-O and ELF, lacks API and plugins and has strict performance limits. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Hopper Disassembler > Cryptic Apps' commercial disassembler, decompiler and debugger for macOS and Linux, which reads Mach-O (macOS and iOS), PE and ELF executables built for 32- and 64-bit Intel, ARMv6, ARMv7, ARM64 and PowerPC processors. Each procedure can be viewed as assembly, as an interactive control-flow graph that exports to PDF or as C-like pseudocode, with Swift name demangling and extraction of Objective-C selectors and messages, and binaries can be patched through the hex editor, the built-in assembler or Python. Debugging of Mac applications uses LLDB or GDB, Python scripts reach most features, an SDK adds file-format parsers and CPU backends, and Hopper 6 brought a new decompiler and an MCP server for LLM clients. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** Version at review: 6.6.1, released 2026-10-29. The Mac build is a Universal Binary for Intel and Apple Silicon and requires macOS 12.4 or later; 5.19.6 is the last version for macOS 10.13 to 11. The Linux build needs a 64-bit Intel processor and is tested only on Ubuntu 24.04, Fedora 41 and Arch Linux (DEB, RPM and tar.xz packages). There is no Windows version. - **License:** Commercial, with a per-user Personal License or a hardware-bound Computer License and no restriction on commercial use. Licenses are permanent and include one year of updates; after the update plan lapses, Hopper is limited to the last version released during it, and another year can be bought from within the application. - **Limits:** The free demo has all analysis features but cannot save or export disassembly or modified binaries, disables the debugger backend and limits sessions to 30 minutes. - **Limits:** Hopper cannot read iOS apps taken from an iTunes library, which are encrypted with FairPlay DRM, until the user removes the DRM. Its pseudocode is usually not directly compilable, and the tutorial warns that code wrongly judged unreachable can drop out of it. ##### Primary sources 1. 2. 3. 4. 5. 6. #### WinDbg > Microsoft's WinDbg debugger and the Debugging Tools for Windows, documented on Microsoft Learn, for debugging live user-mode and kernel-mode code, analyzing crash dumps and examining CPU registers and memory. The current app keeps the engine, commands and extensions of WinDbg (Classic) and adds Time Travel Debugging, which records a user-mode process and replays it in both directions, JavaScript and NatVis scripting and Linux ELF dump analysis; since 1.2610.1001.0 it also offers WinDbg MCP for supported AI clients. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** WinDbg installs from Microsoft's installer, the Microsoft Store or winget on x64 or ARM64 Windows 11 or Windows 10 1607 and later, not Windows 10/11 S, and direct and Store installs self-update; the release notes, updated 2026-11-05, list 1.2611.4001.0 as newest. - **Prerequisites:** Debugging Tools for Windows (WinDbg Classic and the KD, NTKD, CDB and NTSD console debuggers) ships with the WDK or Windows SDK or as an SDK-only install, with archived SDKs for older Windows. Kernel debugging typically needs a second machine or VM, local kernel debugging and TTD need elevation, and full analysis needs symbols, which for commercial code depend on the vendor. - **License:** Free in the Microsoft Store under Microsoft's proprietary WinDbg license terms (updated 2026-10-08): the software is licensed, not sold, may not be redistributed and may send usage data to Microsoft. - **Limits:** TTD records user-mode processes only, and not protected ones such as PPL; recording is typically 10–20x slower, traces can reach several gigabytes in minutes, with index files about twice as large, and may hold personal or security data; anti-virus software can interfere. - **Limits:** WinDbg MCP officially supports GitHub Copilot in Visual Studio Code and GitHub Copilot CLI, one client per session; clients may send debugger context to their model service, AI findings are not authoritative, and default secure mode blocks high-risk commands such as .shell. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### 010 Editor > SweetScape Software's commercial hex and text editor whose Binary Templates, C/C++-like struct definitions with control flow and functions, parse binary files into hierarchical, editable structures. Templates can run when a file opens and are shared through an online repository, scripts with C/C++-like syntax automate edits and batch runs, and the tools include a Capstone-based disassembler for x86, ARM, MIPS, PowerPC and other code, byte-by-byte comparison, checksums and hashes, and editing of drives and, on Windows, process memory. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** Version 17.0.1, released 2026-11-04, has 64-bit builds for Windows 11/10, macOS 10.14 to 27 on ARM and Intel, and Ubuntu 18.04 to 26.04, plus 32-bit Windows and Linux builds and a portable Windows build. Version 10 dropped Windows XP, macOS 10.7–10.11 and Ubuntu 10.04–14.04, where older releases still run. - **License:** Commercial: the evaluation version works for 30 days, after which a license must be bought. Licenses are per user and perpetual, with a year of free upgrades and support, and come as commercial or lower-priced home/academic licenses; the EULA bars home/academic licenses from commercial use, except for members of registered non-profits, and from government or military organizations. - **Limits:** The disassembler only converts bytes to assembly: the manual says 010 Editor cannot execute the result and points to a separate emulator or debugger. Process editing is Windows-only, and the manual warns that incorrect process edits can make programs misbehave or crash the system. - **Limits:** Only ZIP, BMP and WAV templates ship with the editor; templates in the online repository are written and submitted by other users. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### pestudio > Winitor's Windows tool for initial malware assessment, which statically inspects Windows executable files and reports key indicators such as hard-coded URLs and IP addresses, flagged imports, resources and overlay data. The free basic edition also detects file signatures, debug information and TLS callbacks, computes entropy and imphash, shows the rich header and .NET metadata and looks up VirusTotal scores by hash; pestudio-pro adds MITRE ATT&CK mapping, XML reports and the pestudiox.exe command-line version. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** Version 9.61, whose feature and licensing sheets are dated March 2025, ships as a ZIP that needs no installation; the download page says it is fully portable, does not alter the system it runs on and runs on any Windows system. - **License:** The free basic edition may be used only in a private context for occasional malware static analysis, not in a professional or corporate environment. pestudio-pro is sold as a one-year license per user that includes free updates, is not renewed automatically and is delivered as a password-protected ZIP. - **Limits:** VirusTotal lookups send only the file's MD5 hash, never the sample, and an XML switch disables them; searching VirusTotal by imphash needs a VirusTotal Intelligence account. The software is provided as-is without warranty, and its bundled XML files may not be used outside pestudio without the author's permission. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### OllyDbg > 32-bit assembler-level analyzing debugger for Windows that emphasizes binary code analysis for programs without source; its site says development is frozen, and the newest version it lists is 2.01 of 27 September 2013. Its analysis recognizes procedures, loops, API calls, switches, tables, constants and strings and decodes calls to more than 1,900 standard API and 400 C functions; it attaches to running programs, debugs DLLs directly, sets conditional, logging, memory and hardware breakpoints and writes patches back to the executable. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Version 2.01 (27 September 2013) is the newest the site lists, and 1.10 is offered as the final 1.x version. The requirements page lists Windows 95, 98, NT 4.0 SP2 or later, or Windows 2000 and later, and says debugging on NT or 2000 may need administrative rights; the 2.x notes say version 2 does not run on Windows 95 or 98. - **Limits:** OllyDbg is a 32-bit debugger. The 64-bit version is offered only as incomplete, and its latest progress note, of 5 February 2014, put the debugging engine at 70% and analysis at 15%. - **License:** Shareware that may be downloaded and used for free; the FAQ says it is rated shareware for copyright reasons only. The download page's agreement covers only version 1.10 and its Plugin Development Kit: permanent or commercial use needs a free registration, the software comes as is, and copies may be shared only complete, unchanged and without a fee. Disassembler 2.01 is released under GPL v3. - **Limits:** The download page warns that many vendors forbid disassembling, decompiling or reverse engineering their programs, including third-party and system libraries, and suggests asking a lawyer whether fair use applies. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Tenet > IDA Pro plugin for exploring execution traces of a binary: it loads an externally recorded trace and lets the analyst step forwards and backwards through time while the disassembly shows the execution flow in both directions. Execution, memory and region breakpoints mark every execution of an instruction or every read and write of an address or range along a trace timeline, register seeking jumps to the instruction that set a register's value, and a timestamp shell seeks to a position or percentage of the trace. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** IDA Pro 7.5 or newer on Windows, macOS or Linux; Tenet is a pure Python 3 plugin with no third-party dependencies, installed by copying the repository's plugins folder into IDA's user plugin directory. Release at review: v0.2.0, published 2021-09-14, whose tag is the reviewed master commit. - **Limits:** Tenet only reads traces in its own text format, which records general-purpose register changes and memory reads and writes; a separate tracer must record them, and the repository's Intel Pin tracer for Windows and Linux user-mode programs and its QEMU tracer are marked experimental. - **Limits:** It loads only x86 and AMD64 traces, and its pure-Python reader gives no guarantee that traces of more than 10 million instructions stay reasonable to navigate. - **License:** MIT per LICENSE. ##### Primary sources 1. 2. 3. 4. #### findcrypt-yara > IDA Pro plugin that scans the loaded database with YARA rules for cryptographic constants and similar signatures, lists the matches in a results window and names each matching address after its rule. Its bundled findcrypt3.rules has 126 rules covering constants and tables of hash, cipher and checksum algorithms such as MD5, SHA-1, SHA-256, SHA-512, RIPEMD-160, Whirlpool, DES, Blowfish, RC6, TEA and CRC32, big-number and prime constants, crypto API names and functions of libraries such as OpenSSL, Crypto++, MIRACL and FGint; users can add their own .rules files. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** IDA Pro with IDAPython and the yara-python package; the README warns against installing the yara pip package, which is not compatible. Custom rule files go in .idapro/plugins/findcrypt-yara/ under the home directory on Linux and macOS, or in the Hex-Rays IDA Pro plugin folder under %APPDATA% on Windows. - **Scope:** The repository has no releases; the plugin reports version 0.2 with the default hotkey Ctrl-Alt-F, and the reviewed master commit is dated 2024-11-19. - **License:** BSD-3-Clause per LICENSE. ##### Primary sources 1. 2. 3. 4. #### deREferencing > IDA Pro plugin that adds register and stack views to the debugger in which pointers are dereferenced and colored, similar to the context displays of GDB plugins such as PEDA, GEF and pwndbg. It supports x86, x86-64, ARM, ARM64, MIPS32 and MIPS64; both views open from Debugger > Debugger Windows or with Alt-Shift-D and Alt-Shift-E, and a saved desktop layout reopens them in later debugging sessions. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** IDA Pro 7.1 or later. Install it with hcli plugin install dereferencing, or copy dereferencing.py and the dereferencing folder into IDA's plugin directory (.idapro/plugins under the home directory on Linux and macOS, %AppData%\Hex-Rays\IDA Pro\plugins on Windows). Release at review: v2026.09.03, published 2026-09-03, whose tag is the reviewed master commit. - **Scope:** Options are changed in the plugin's config.py file. - **License:** GPL-3.0 per LICENSE. ##### Primary sources 1. 2. 3. #### HexRays Toolbox > IDAPython scripts that find code patterns in Hex-Rays decompiler output, independent of the binary's processor architecture, by running user-written lambda queries over the decompiled ctree. Queries run from the hxtb-shell GUI inside IDA, from IDAPython through functions such as find_expr() and find_item(), from interactive command-line helpers or in batch mode over a set of files. The README's use cases include finding vulnerabilities and their variants, locating code patterns from previously reversed executables in newly decompiled code, malware variant analysis and finding patterns across binaries built for different architectures. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs a valid IDA license and a valid Hex-Rays decompiler license for each target architecture. The repository has no releases; the reviewed master commit dates from 2023-06-20. - **Scope:** Example queries for hxtb-shell are in the hxtbshell_queries folder, and the shell also accepts Python expressions copied from the context viewer of the separate HRDevHelper plugin. - **License:** CC0-1.0 per LICENSE. ##### Primary sources 1. 2. 3. 4. #### Virtuailor > IDAPython tool that reconstructs C++ virtual tables in IDA Pro for 32- and 64-bit Intel and AArch64 code by observing indirect calls while the program runs under IDA's debugger. Its static part finds indirect calls and hooks the assignment of their targets with conditional breakpoints; when those breakpoints hit, the dynamic part creates vtable structures, renames vtables and virtual functions, adds structure offsets to the call instructions and cross-references from each indirect call to the virtual functions it reached, and for AArch64 firmware tries to fix undefined vtables and their functions. - Type: Tool - Targets: Binary · Firmware - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** IDA Pro 7.0 to 7.5: the master branch targets 7.5, and IDA versions older than 7.4 need the beforeIDA-7.4 branch. Run Main.py through File > Run script, ideally after taking an IDB snapshot as the README recommends, then exercise the program under IDA's debugger; AArch64 targets can be debugged through a remote GDB server. The repository has no releases; the reviewed master commit dates from 2020-06-06. - **Limits:** Only vtables used by virtual calls that are hit at run time are reconstructed, and the README says some breakpoints may be missed. - **License:** GPL-3.0 per LICENSE. ##### Primary sources 1. 2. 3. #### xAnalyzer > x64dbg plugin that annotates the static code of the debugged x86 or x64 executable with function-call, argument and loop analysis. It adds argument and type information from over 13,000 API definitions for almost 200 DLLs, handles undefined and register-based calls generically and detects loops automatically. Analysis runs on a selection, a function or a whole module from menus or the xanal commands, can run automatically at the entry point like OllyDbg's initial analysis, and users can extend its .api and header definition files. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs x64dbg; copy xAnalyzer.dp32 or xAnalyzer.dp64 and the extracted apis_def folder into the matching x64dbg plugin directory. Release at review: 2.5.12, published 2025-08-13, the same day as the reviewed master commit. - **Limits:** The README lists known limits: the first undefined call with generic arguments in a function is not processed unless a jump precedes it, nested calls work correctly only in some cases, loops are detected only within function boundaries and can be misdetected around unconditional jumps, and extended analysis can take much longer and use large amounts of RAM. - **License:** MIT per LICENSE. ##### Primary sources 1. 2. 3. 4. #### Voltron > Extensible Python debugger UI toolkit that attaches utility views to LLDB, GDB, VDB and WinDbg/CDB sessions. Each view retrieves data from the debugger host and can run in its own terminal, so users can assemble a custom debugger interface; built-in views cover registers, disassembly, stack, memory, breakpoints and backtrace, and any debugger command can be split off into a view highlighted with a chosen Pygments lexer. The views complement the debugger's command line rather than replace it. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Runs on macOS, Linux and Windows; WinDbg/CDB support goes through PyKD and is described as fairly new. The install script fully supports only macOS and Debian derivatives, and the debugger's init file (.lldbinit or .gdbinit) loads Voltron's entry.py. Architecture support differs by debugger: x86 and x86_64 with all four, ARM except with WinDbg, ARM64 only with LLDB and PowerPC only with GDB. - **Scope:** The newest release is the v0.1.8 pre-release of 2025-01-30, following v0.1.7 from 2016; the reviewed master commit is from the same day as v0.1.8. - **License:** MIT per LICENSE. ##### Primary sources 1. 2. 3. 4. #### Remill > Static binary translation library that lifts AArch64, SPARC32, SPARC64, x86 and amd64 machine code, including AVX and AVX512, into LLVM bitcode, with AArch32 support underway. It focuses on lifting individual instructions accurately and is meant as a library for other tools such as McSema; its documentation walks through how an instruction is lifted, how instruction semantics are implemented and the overall design. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supported on Linux and tested on Ubuntu 22.04; it also works on macOS, and Windows support is experimental. Building uses the superbuild in dependencies/ with CMake 3.21+, Ninja, LLVM and Clang 15+, Intel XED, Google Flags, Log and Test and Python 3, and Linux builds can also run in Docker. Release at review: v6.0.1, published 2026-04-21; the reviewed master commit dates from 2026-08-27. - **License:** Apache-2.0 per LICENSE. ##### Primary sources 1. 2. 3. 4. 5. #### iaito > Official Qt-based graphical interface for the radare2 reverse-engineering framework, aiming for parity with radare2's commands, features and keybindings so that existing r2 plugins and scripts keep working. Its README lists forensics, binary diffing and binary patching alongside disassembly; iaito was the original name before the project was forked as Cutter. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs radare2 and Qt 5 or Qt 6. CI builds and releases cover Linux, macOS and Windows, Linux and WSL users can install it from Flathub (org.radare.iaito), and on macOS the app may need its signature fixed with xattr and codesign as the README shows. Release at review: 6.2.2, published 2026-09-06; the reviewed master commit dates from 2026-11-05. - **License:** GPL-3.0 per COPYING. ##### Primary sources 1. 2. 3. #### HexRaysCodeXplorer > Hex-Rays decompiler plugin for navigating and reconstructing C++ code in IDA's pseudocode window. It reconstructs C++ object types from a selected pointer variable into IDA's local types, identifies virtual function tables and generates structures for them, lets the analyst click through virtual calls once objects are typed, visualizes a function's ctree as a graph, jumps from a pseudocode line to its disassembly and dumps ctrees and types to files. Its Object Explorer lists vtables with cross-references and RTTI parsing, and a batch mode processes many files without user interaction. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Written in C/C++ for x86/x64 IDA with the Hex-Rays decompiler on Windows, Linux and macOS; the README says only the latest IDA and decompiler versions are tested. The newest GitHub release is 2.1, the IDA 7 edition, from 2018-03-14; the reviewed master commit dates from 2025-11-25. - **License:** The repository has no license file and GitHub detects no license. ##### Primary sources 1. 2. 3. #### GDB dashboard > Standalone .gdbinit file written with GDB's Python API that shows a modular status interface each time the debugged program stops, reducing the commands needed to inspect its state. No GDB command is redefined; its features sit under a single dashboard command. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs GDB with Python API support; the single .gdbinit file goes in the home directory, and Pygments is optional for syntax highlighting. - MIT per LICENSE. ##### Primary sources 1. #### REHex > Cross-platform hex editor for reverse engineering that handles files over 1 TB. It adds inline disassembly, integer and floating-point decoding, byte-range annotations, side-by-side comparison, virtual address mapping and bitmap visualisation, with Binary Templates that annotate data automatically and Lua scripting. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs on Windows, Linux, macOS and BSD. Releases provide standalone Windows and macOS packages and Linux packages; 0.64.0 was published on 2026-04-04. - GPL-2.0 per LICENSE.txt. ##### Primary sources 1. #### Dobby > Lightweight, modular hook framework for Windows, macOS, iOS, Android and Linux on x86, x86-64, ARM and ARM64. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Compiled from source as described in docs/compile.md, or downloaded as a prebuilt library from the release tagged latest, dated 2024-03-14. - Apache-2.0 per LICENSE. ##### Primary sources 1. #### XLMMacroDeobfuscator > Command-line tool and Python library that extracts and decodes obfuscated Excel 4.0 (XLM) macros from xls, xlsm and xlsb files. An internal XLM emulator interprets the macros without fully performing the code, and results can be exported as JSON. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed with pip. Loading xls files through Microsoft Excel requires Windows, pywin32 and the --with-ms-excel switch; otherwise the xlrd2 library reads them. The newest release is v0.2.7 from 2022-09-21. - Apache-2.0 per LICENSE. ##### Primary sources 1. #### PE Tree > Python module that shows Portable Executable files in a tree view using pefile and PyQt5, as a standalone application and as a plugin for IDA Pro, Ghidra, Volatility, Rekall and minidump. It reads PE images from files, ZIP archives, Windows memory dumps and analysis databases. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The standalone application needs Python 3.5+ and runs on Windows, Linux and macOS; each plugin needs its host tool. The repository is archived, with the last release 1.0.29 from 2020-10-05. - Apache-2.0 per LICENSE. ##### Primary sources 1. #### RpcView > Open-source Windows tool that explores and decompiles the RPC functionality present on a Microsoft system. New rpcrt4.dll runtime versions are added by extending its version table or by reversing the runtime's internal structures. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs the Microsoft Visual C++ 2019 Redistributable; building takes Visual Studio, CMake and Qt5. The README lists runtime support for Windows XP, 7, 8, 8.1 and 10. - GPL-3.0 per LICENSE. ##### Primary sources 1. #### amoco > Python package for symbolic analysis of binaries. It combines an instruction-decoding framework for adding architectures, a symbolic algebra module that describes instruction semantics, an abstract memory and execution model, and disassembly techniques from linear sweep and recursive traversal to solver-based path-predicate exploration. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README marks version 2.9 as under development: x86 FPU semantics and ARM SIMD, VFP, NEON, TrustZone and Jazelle instruction sets are not implemented, some solver-based disassembly strategies are unmerged, and IDB import and export are missing. - GPL-2.0 per LICENSE. ##### Primary sources 1. #### Chisel > Collection of LLDB commands for debugging iOS apps. Commands print view and view-controller hierarchies, find views by class-name regex, show or hide views without resuming the process, mask or border views, set symbolic breakpoints on a class's method and watchpoints on instance variables, and can be extended with custom commands. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed with Homebrew or by download, then imported from the .lldbinit file in the home directory. Command support differs between iOS and macOS, as the README's command table marks. The newest tagged release is 2.0.1 from 2020-08-17. - MIT per LICENSE. ##### Primary sources 1. #### gdbgui > Browser-based frontend to the GNU debugger, gdb. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Documentation lives on gdbgui.com; release 0.15.3.0 was published on 2025-06-29. - GPL-3.0 per LICENSE. ##### Primary sources 1. #### Porosity > Decompiler that turns Ethereum Virtual Machine bytecode into readable Solidity-syntax contracts, supported on Linux and macOS. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README marks the project unmaintained and points to the JEB decompiler for smart contracts as an alternative; the newest release is v20180116.2 from 2018-01-16. - The repository has no license file. ##### Primary sources 1. #### Xori > Automation-ready disassembly and static analysis library for shellcode and PE binaries that outputs disassembly, functions and imports as JSON. It offers a light emulation mode that enumerates all paths and a slower full emulation mode, simulated TEB and PEB structures, and FLIRT-style signatures. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Covers i386 and x86-64 PE, PE+ and plain shellcode. Built with Rust and Cargo; the README cites rustc 1.27.0, and the browser GUI needs Node.js. - AGPL-3.0 per LICENSE.txt. ##### Primary sources 1. #### binglide > Visual reverse-engineering tool that gives a quick overview of the data types present in a file. It reads no particular format, so it also works when headers are missing or corrupted or the format is unknown. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs Python 3, PyQt4 with OpenGL, pyqtgraph and numpy, with numba for JIT speed-ups. The author points to Veles as a more mature successor. - MIT per LICENSE.txt. ##### Primary sources 1. #### ERESI > Reverse Engineering Software Interface built around ELFsh, an interactive and scriptable shell for reading and modifying ELF objects, and e2dbg, an embedded ELF debugger. ELFsh analyses sections, edits headers and symbol and relocation tables, disassembles through libasm, draws control-flow graphs and injects code into ELF files. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README.FIRST describes ELFsh 0.65 and is marked as not updated for ERESI 0.8; e2dbg is described for Linux on IA32. The newest release is 0.83-a3-phoenix from 2018-07-09. - The repository has no top-level license file. ##### Primary sources 1. #### pixd > Terminal tool that visualises binary data like a hexdump, but draws each octet as a coloured square from a palette. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs a terminal emulator that supports 24-bit colour SGR escape sequences. - MIT per LICENSE. ##### Primary sources 1. #### Universal Extractor 2 > Unofficial, extended continuation of Universal Extractor that unpacks files from standard archives, application installers, disk images and game archives. Version 2 adds batch mode, a scan-only mode that detects a file's type, password lists and silent mode. - Type: Tool - Targets: Binary · Game - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs on Windows XP or newer; on XP online features are disabled and some extractors may not work. The README links v2.0.0-rc.3. - GPL-2.0 per LICENSE. ##### Primary sources 1. #### ElleKit > Function hooking toolkit for arm64 XNU devices: a C function hooker that patches memory pages directly, an Objective-C function hooker, an arm64 assembler, JIT inline assembly for Swift and a reimplementation of the Substrate and libhooker APIs. The README lists the Dopamine, palera1n and meowbrek2 jailbreaks as users. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs an arm64 device running the XNU kernel. Tested on iOS 15-27 (arm64), iOS 15-17 (arm64e) and macOS Ventura; the README says it is unsupported on the latest macOS because of code-signing changes. - BSD-3-Clause per LICENSE. ##### Primary sources 1. #### ProcDump for Linux and macOS > Linux and macOS reimagining of the Sysinternals ProcDump tool that writes process dumps in response to performance, runtime, signal and resource-tracking triggers, including native dumps through a Rust ELF writer and managed dumps through .NET diagnostics IPC. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs on Linux kernels 3.5+ or macOS Sierra+. Building needs stable Rust with rustfmt and clippy, plus Clang, pkg-config, libelf and zlib headers, gdb and gcore on Linux, or Xcode command-line tools, gdb and gcore on macOS. The macOS version has no resource tracking. Release 3.5.3 is from 2026-09-10. - MIT per LICENSE. ##### Primary sources 1. #### fishhook > Small library that dynamically rebinds symbols in Mach-O binaries running on iOS, on device and in the simulator, by updating the lazy and non-lazy symbol pointers that dyld uses. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Used by adding fishhook.h and fishhook.c to a project. - BSD-3-Clause per LICENSE. ##### Primary sources 1. #### pcode2code > VBA p-code decompiler based on pcodedmp, written for Office documents whose macro source has been stomped to leave only bytecode. It takes a document or a previously saved pcodedmp dump and also works as a Python module. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Works with Python 2.6+ and Python 3.x and installs with pip along with pcodedmp. - GPL-3.0 per LICENSE. ##### Primary sources 1. #### rust-deobf > rust-deobf analyzes compiled, mainly Rust, ELF, PE and Mach-O binaries to recover hidden strings and related artifacts. It combines static call-site analysis with Unicorn function emulation, identifies Rust metadata and library functions, and offers unpacking and Ghidra annotations. CLI and MCP interfaces expose the core analysis; deeper control-flow and virtualization modules have separate licensing. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10 or newer is specified for the core package. - **Scope:** The documented analysis covers x86-64, ARM64 and 32-bit x86 across ELF, PE and Mach-O. - **License:** The core is Apache-2.0; premium modules are dual-licensed under AGPL-3.0-or-later or a commercial license. ##### Primary sources 1. 2. #### CFG Visualizer > CFG Visualizer extracts function control-flow graphs from ELF, PE and Mach-O binaries with radare2 and presents them in an interactive 3D browser view. Its FastAPI backend returns graph JSON, while the frontend shows branch edges and node disassembly. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10+ and radare2 on PATH are required for local binary analysis. - **Limits:** The public upload service lacks authentication, rate limiting and subprocess sandboxing. - **License:** MIT. ##### Primary sources 1. 2. #### Cpp2CS > Cpp2CS recovers managed methods from Android ARM64 Unity IL2CPP ELF binaries and matching metadata, emitting CIL assemblies, C# source and per-method diagnostics. Its pipeline models machine IR, IL2CPP runtime idioms, memory SSA and type recovery while marking unresolved portions. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** .NET 10 SDK, the Il2CppDumper submodule, and a matching binary and metadata pair. - **Scope:** Recovery is modeled for Android ARM64 ELF, Unity 2022.3.62f2 and metadata v31. - **Limits:** Generated project files do not establish that the source compiles or runs. - **License:** MIT license. ##### Primary sources 1. 2. #### ghidra-c6000 > ghidra-c6000 adds Texas Instruments C64x, C67x and C674x DSP support to Ghidra 12.x. Its SLEIGH languages decode full-width and compact instructions, supply p-code for decompilation, and add C6000 calling conventions and packet-aware analyzers for ELF or raw images. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a matching Ghidra 12.x build and its declared JDK: JDK 21 for Ghidra 12.0 or 12.1, JDK 25 for 12.2. - **Prerequisites:** Raw images require a chosen base address and entry point. - **Limits:** C66x-specific instructions and complete C66x ISA support are absent. - **License:** Apache-2.0 license. ##### Primary sources 1. #### cocos2d-dumper > cocos2d-dumper extracts defined function symbols from ELF shared libraries and demangles C++ names with GNU binutils. It produces a map of ELF symbol values and names for inspecting unstripped cocos2d-x binaries and other native libraries. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.9 or newer and GNU binutils readelf and c++filt are required. - **Limits:** Unstripped libraries provide the usable function symbols described by the tool. - **License:** MIT license. ##### Primary sources 1. #### Binary Ninja Security Analysis Plugin > Binary Ninja Security Analysis Plugin batches binary analysis from a Rust plugin and exports Parquet reports. It records architecture, hashes, functions, strings, segments, cyclomatic complexity, entropy and references to selected process-execution functions. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires Binary Ninja, a stable Rust toolchain and Binary Ninja API development headers. - **Testing evidence:** The author reports testing the rebuilt command in Binary Ninja Personal 6.1.10951-dev. - **License:** MIT License. ##### Primary sources 1. #### Human-Readable Decompilation > Human-Readable Decompilation restructures C produced by Ghidra's binary decompiler using an ANTLR parser and AST transformations. It recovers switches from conditional chains, introduces guard clauses, flattens nested branches and simplifies selected expressions. A GUI can launch Ghidra headlessly before transformation, while a CLI handles existing C output. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Ghidra 11.4.2 or later, a Java runtime and Python 3 are specified for the full workflow. - **Prerequisites:** ANTLR Python runtime and tools are needed to generate the parser. - **Limits:** Further transformation coverage, including iteration statements, remains planned. - **License:** BSD-3-Clause license. ##### Primary sources 1. #### BinStruct Inspector > BinStruct Inspector is a GUI for examining binary file layouts through user-defined field trees. It parses files as structures are edited, shows parsed values beside synchronized hex and JSON views, and tracks byte-level insertions, deletions, and replacements; plugins add custom data types. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The package manifest requires Python 3.11+ and PySide6 6.0+. - **License:** MIT license. ##### Primary sources 1. 2. #### SimpleParserPE > SimpleParserPE is a C++ command-line inspector for PE32 Windows executables. It reads DOS and NT headers, section metadata, data directories, and imported DLL functions, translating RVAs through the section table without Windows headers or external libraries. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A C++17 compiler and a PE32 executable input are required. - **Limits:** PE32+ is rejected; bounds checking is absent, and exports, relocations, and resources are not parsed. - **License:** MIT license. ##### Primary sources 1. #### tenet_tracer > tenet_tracer uses Intel Pin to record instruction-level execution traces for Tenet. It captures program counters, register changes and memory accesses, stores them in SQLite tables, and provides a script to export the trace text. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Intel Pin is required; the documented Windows build uses Visual Studio 2022 and Pin 3.31 with LLVM clang-cl. - **Prerequisites:** Kernel debugging must be disabled for the documented Pin setup. - **License:** No licence file in the repository. ##### Primary sources 1. #### m0rph: tracing an obfuscated ELF flag checker > The m0rph investigation examines an obfuscated x86-64 ELF CTF flag checker with readelf, strings, Cutter and Radare2. Its write-up traces indirect CALL RAX execution into allocated memory and describes recovering expected characters by breaking at the call and inspecting RDI during each loop iteration. - Type: Case study - Targets: Binary - Category: Native analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The m0rph x86-64 ELF challenge binary and a Linux analysis environment are needed to repeat the investigation. - **Prerequisites:** Radare2, Cutter and standard Linux inspection utilities are used in the described workflow. - **License:** MIT license. ##### Primary sources 1. #### BinScan > BinScan scans files in bulk and emits per-file JSON containing format identification, structural metadata, hashes and entropy. Its C++ library includes parsers for PE, ELF and Mach-O executables alongside archives, packages, documents and images, with a staged read, analyze and write pipeline. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** C++20, CMake and OpenSSL; the README provides Windows, Linux and macOS build instructions. - **Limits:** The author describes the current version as unreleased and warns that results may contain inaccuracies. - **License:** MIT license. ##### Primary sources 1. #### Patch-0xC0000022 > Patch-0xC0000022 instruments the running Windows SysMain service by changing its NtCreateFile response to STATUS_ACCESS_DENIED. The C++ program finds the service process, resolves the remote function address and applies a six-byte patch to study the effect on prefetch behavior. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows 10 or 11 x64, Visual Studio C++ tools and administrator permission are required. - **Scope:** The source calls for a controlled test environment and says restarting Windows restores runtime state. - **Limits:** Restoring or removing the patch is listed as future work. - **License:** No licence file in the repository. ##### Primary sources 1. #### CPQ IO Scheduler: reconstructing Xiaomi's block scheduler > CPQ IO Scheduler reconstructs Xiaomi's proprietary cpq.ko Linux block scheduler from a stripped ARM64 kernel module. Its out-of-tree C implementation combines priority classes, thread-group queues, deadline handling, and blk-mq elevator integration, with a whitepaper and author-reported benchmarks. - Type: Case study - Targets: Binary - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Building requires Linux kernel headers for the block layer and scheduler APIs; the author reports testing on Linux 6.1 with RK3588 and eMMC 5.1. - **Testing evidence:** The author reports a 5-of-6 workload win against mq-deadline, with about 1.9% average IOPS uplift. - **License:** GPL-2.0 license, as stated in the README and source-file notice. ##### Primary sources 1. #### iMonitor > iMonitor is a Windows endpoint activity monitor for examining running software. It records process, file, registry and network events, adds DLL-load analysis, and supports custom columns and matching rules through plugins and scripts. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows is required. - **License:** MIT license. ##### Primary sources 1. #### m68kdasm > m68kdasm disassembles Motorola 68000-family machine code in Go and returns assembly with structured instruction metadata. It supports selectable CPU variants, optional FPU and PMMU decoding, symbol and label formatting, streaming input and helpers for 68000 ELF binaries. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Go 1.27, as specified in go.mod. - **Limits:** Some CPU instructions, including CPU32 TBLS/TBLU and 68040 MOVE16/CINV/CPUSH, remain unimplemented. - **License:** MIT license. ##### Primary sources 1. 2. #### Malware Analysis: njRAT and Casdet behavior investigation > A malware investigation examines njRAT and a UPX-packed Casdet executable with PEStudio static triage and ANY.RUN sandbox telemetry, alongside a malicious PDF and benign comparison files. The author reports process, registry and network behavior, extracted indicators and MITRE ATT&CK mappings in a report and screenshots. - Type: Case study - Targets: Binary - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The investigation used PEStudio 9.56 and ANY.RUN on a Windows 10 guest. - The author reports that Infected.exe crashed because libelf.dll was missing, so no sandbox behavior was observed for it. ##### Primary sources 1. #### IR Lifting Benchmark > IR Lifting Benchmark compares binary lifting workflows across Ghidra P-code, angr VEX, BAP BIL and optional LLVM IR paths. Shell and Python scripts run analyses on binary samples, collect performance and control-flow metrics, check lifted semantics and generate reports and visualizations. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux, Python 3.8 or later, Ghidra 10.x or 11.x and the selected analysis tools. - **Prerequisites:** User-provided samples are needed for malware analysis. - **Limits:** BAP and LLVM lifting are optional; true binary-to-LLVM IR lifting needs RetDec or llvm-mctoll. - **License:** MIT license. ##### Primary sources 1. 2. #### Bin-Hunter > Bin-Hunter is a Python command-line tool for initial static inspection of binary files. It identifies formats from magic bytes, calculates whole-file and peak-region Shannon entropy, extracts readable strings, and finds URLs, IP addresses, email addresses, and suspicious keywords in those strings. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python standard library; no external dependencies are stated. - **License:** MIT license. ##### Primary sources 1. #### BinaryInsight > BinaryInsight inspects ELF, PE, and Mach-O executables and libraries in an interactive terminal view or a text-report CLI. Its Rust core uses goblin to parse binary structure and exposes sections, symbols, printable strings, and security mitigation indicators such as PIE, NX, RELRO, ASLR, and DEP. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Rust and Cargo are required to build from source. - **License:** MIT License. ##### Primary sources 1. #### rust-sig-gen > rust-sig-gen generates IDA FLAIR library signatures from compiled Rust crates for executable analysis. Its Python script obtains the top 100 crates, builds them for Linux and x86-64 Windows, and processes the outputs with sigmake, pelf and pcf. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python packages requests and toml, a Rust compiler, and IDA Pro FLAIR tools sigmake, pelf and pcf are required. - **Scope:** The documented scope is the top 100 Rust crates and Linux and x86-64 Windows builds. - **License:** No licence file in the repository. ##### Primary sources 1. #### 1C 7.7 Configuration Parser (MD Parser) > 1C 7.7 Configuration Parser inspects 1C:Enterprise 7.7 1cv7.md configuration containers. Its Win32 interface displays OLE streams, decompresses ZLib data, removes the documented XOR layer and parses Main MetaData Stream into an object hierarchy. - Type: Tool - Targets: App - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows and a 1cv7.md configuration file are required. - **Prerequisites:** Building uses Visual Studio or Build Tools with NMAKE. - **License:** MIT license. ##### Primary sources 1. #### x64dbg-tenet > x64dbg-tenet is a native x64dbg plugin that records execution steps in Tenet trace format. Commands start and stop logging or trace a specified number of steps, with an option to stop when execution leaves the current module. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** x64dbg is required. - **License:** MIT license. ##### Primary sources 1. #### NullSec BinGaze > NullSec BinGaze analyses ELF executables by parsing headers, listing sections and calculating entropy. It also reports NX stack, PIE, RELRO, stack-canary and RWX-segment properties through command-line modes for full analysis, section listing or security assessment. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A C++20 compiler and CMake are required to build it. - **License:** The README labels the licence NullSec Proprietary; the file list contains no licence file. ##### Primary sources 1. #### pdbinspector > pdbinspector analyzes Microsoft PDB files to list structures, classes, enums, functions, public symbols and exports. It demangles MSVC C++ names, decodes MSVC string literals and emits text, JSON or tab-separated reports through a CLI; a WebAssembly version runs online. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Microsoft PDB file is required as input. - **Prerequisites:** Building from source requires Rust; the manifest specifies Rust 1.75 or later. - **License:** MIT License. ##### Primary sources 1. #### 8086 Register Command Debugger > 8086 Register Command Debugger is an MS-DOS machine-code inspection tool written in 8086 assembly. It loads a program into a 64 KB segment, decodes 8086 instructions and lets users inspect or edit memory and registers while stepping through real CPU instructions using the Trap Flag. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** MS-DOS or a compatible environment such as DOSBox is needed to run the executable. - **Scope:** The program uses a 64 KB memory segment and original 8086 instructions. - **License:** MIT license. ##### Primary sources 1. #### advantage > advantage is a Windows research tool for inspecting Lenovo Vantage and add-in RPC commands. It injects a stub into a Lenovo-signed process, supplies an RPC JSON payload from a local server, and returns the command response through a CLI or web interface; the repository also contains Frida contract and request dump scripts. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Windows Lenovo Vantage process is required for the documented RPC path. - **Prerequisites:** Go 1.25 or newer and donut are required by the documented build procedure. - **License:** Apache-2.0 license. ##### Primary sources 1. #### Valkyrie > Valkyrie analyzes suspect binaries through static inspection and Docker-based execution. Its documented pipeline examines PE headers, entropy and packing, then captures system calls, file activity and PCAP traffic for reports and threat-intelligence output. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.9+ is required; dynamic analysis requires Docker Desktop or Docker Engine. - **Prerequisites:** Optional API keys enable VirusTotal and OpenAI integrations. - **License:** MIT License. ##### Primary sources 1. #### PE Disassembler > PE Disassembler is a WPF application that extracts the .text section of 32-bit Windows PE executables and displays decoded x86 instructions. It checks MZ and PE signatures, handles a limited set of movement, arithmetic and control-flow opcodes, and can save the listing as text. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows with .NET Framework 4.7.2+ or .NET 5/6/7/8 with WPF support; Visual Studio 2019/2022 to build. - **Limits:** Only 32-bit x86 PE files and implemented opcodes are supported; output uses raw file offsets without relocation handling. - **License:** MIT License. ##### Primary sources 1. #### SIC/XE Disassembler and Linking Loader > SIC/XE Disassembler and Linking Loader converts SIC/XE object code into assembly listings and reconstructed symbols. Its first pass identifies instruction boundaries and addressing modes; its second emits assembly, while a separate loader resolves external symbols and applies relocation records. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A C++17 compiler is required. - **Limits:** Character-literal reconstruction is limited, and the loader assumes well-formed object files. - **License:** MIT license. ##### Primary sources 1. #### Malware Deobfuscator > Malware Deobfuscator analyzes obfuscated malware scripts and generates code, behavior and indicator reports. A deterministic pass extracts indicators with regexes and maps keyword signatures to MITRE ATT&CK; an OpenAI or Ollama model supplies deobfuscated code and execution-flow explanations. The CLI handles individual files or directories and can emit JSON. - Type: Tool - Targets: App - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.9 or later is specified in the package metadata. - **Prerequisites:** Full analysis requires an OpenAI API key or a configured Ollama model; IOC extraction works without one. - **Scope:** The included samples are described as defanged educational examples. - **License:** MIT license. ##### Primary sources 1. 2. #### flashkit > flashkit is a Python toolkit for examining Adobe Flash SWF files and AVM2 bytecode. It parses and rebuilds SWF and ABC structures, disassembles instructions, constructs call and reference indexes, and decompiles classes or methods to ActionScript 3 through a control-flow pipeline. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10 or later. - **Prerequisites:** SWF or AVM2 bytecode input for analysis. - **Limits:** Dead-code detection is heuristic because ActionScript 3 dynamic dispatch cannot be fully ruled out. - **License:** MIT License. ##### Primary sources 1. 2. #### Kaiju > Kaiju is a Rust reverse-engineering framework with a headless CLI for binary loading and analysis. Its current crates parse selected ELF, PE and Mach-O metadata, extract strings, decode a limited x86-64 instruction subset and inspect saved network evidence. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Rust 1.76+ is specified by the workspace. - **Limits:** ELF, PE, Mach-O and x86-64 support is limited to the documented parser and decoder subsets. - **License:** Apache-2.0. ##### Primary sources 1. 2. #### sqlce > sqlce reads SQL Server Compact .sdf database files using a cross-platform C++ parser informed by analysis of decompiled SQL CE components. Python and WebAssembly bindings expose table names, schemas and rows, including files encrypted with a supplied password. - Type: Tool - Targets: App - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An existing .sdf file is required; encrypted files need a password. - **Testing evidence:** The comparison test suite requires Windows with SQL Server Compact 4.0 installed. - **License:** MIT license. ##### Primary sources 1. 2. #### inkterop > inkterop converts native handwriting files from note apps and e-ink devices through a documented intermediate representation. It reads stroke data including pressure and tilt where present, implements readers for formats such as GoodNotes and Notability, and publishes format investigation notes and conversion fidelity modes. - Type: Tool - Targets: App - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.12 or later and uv for the documented setup. - **Prerequisites:** Native note files in a supported input format. - **Limits:** Several formats are read-only or partial; GoodNotes reads ink and color, while Nebo's BINK ink codec remains under investigation. - **License:** MIT License for code; CC BY 4.0 for documentation. ##### Primary sources 1. 2. #### wMatcher > wMatcher compares two Java archives to match classes renamed or obfuscated between releases. Its desktop workflow loads old and new JARs, accepts dependency JARs, lets the analyst correct uncertain matches and saves the comparison as a .wmatch project. - Type: Tool - Targets: Binary - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Old and new JAR files are required; dependency JARs may be added. - **Prerequisites:** Building from source uses Gradle and a Java 21 toolchain. - **License:** GPL-3.0 license. ##### Primary sources 1. 2. #### tasm-rs > tasm-rs implements TVM bytecode assembly and disassembly in Rust, with a tdisasm CLI, instruction tables, Fift parsing and trace and coverage reports. It uses checked-in conformance fixtures to compare output with the upstream TypeScript implementation; the author reports 959 matching fixtures. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Rust 1.85 or newer for the workspace build. - **Testing evidence:** The author reports byte-identical results on 959 conformance fixtures. - **Limits:** Deeply nested continuations have a documented compilation-time growth problem. - **License:** MIT license. ##### Primary sources 1. #### Sogen Dart bindings > Sogen Dart bindings expose Windows and Linux binary emulation through a Dart FFI package and native bridge. The API covers execution, snapshots, memory and registers, process views, callbacks and low-level hooks; Windows API calls and Linux symbols can also be intercepted. Its example hooks a Sleep call in an emulated executable. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Dart 3.12 or newer and Git are required. - **Prerequisites:** Building requires the Visual Studio C++ desktop workload on Windows, a C++20 compiler and development headers on Linux, or Xcode command-line tools on macOS. - **Limits:** The example requires a Sogen emulation root. - **License:** GPL-2.0-only license. ##### Primary sources 1. 2. #### cupertino-files > cupertino-files is a TypeScript library for reading and writing modern Apple Pages, Numbers, and Keynote documents. It models their undocumented file structures from real documents, exposes editing APIs and CLI tools, and publishes format notes and a language-neutral conformance suite. - Type: Tool - Targets: App - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Node.js 22 or later or a modern browser; the package is ESM-only. - **Prerequisites:** Modern Pages, Numbers, or Keynote documents for reading and editing. - **Limits:** iWork ’09 XML and password-protected documents are declined. - **License:** MIT License. ##### Primary sources 1. 2. #### PackerScope > PackerScope scans Windows PE executables for packer signatures and structural indicators, including entropy, sections, imports and entry-point instructions. It can invoke supported unpackers and check PE integrity, entropy and import-table recovery before generating reports. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10–3.13 is listed as the supported range. - **Prerequisites:** Capstone, yara-python and ppdeep are optional analysis dependencies. - **Prerequisites:** UPX unpacking requires an external upx executable. - **License:** MIT licence. ##### Primary sources 1. #### imprint > imprint analyzes Windows PE files by parsing import, delay-import and export directories without executing the image. It maps imported Windows APIs to categories and MITRE ATT&CK techniques, then reports capability patterns with the imports that triggered each finding in text or JSON. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A C11 compiler such as gcc, clang or MinGW is required to build it. - **Limits:** Imports indicate possible capabilities, not observed execution; dynamically resolved APIs and packed payloads may be hidden. - **License:** MIT license. ##### Primary sources 1. 2. #### kdemulator > kdemulator executes Windows x86-64 kernel-driver binaries outside a live kernel for IOCTL analysis. It maps PE sections into Unicorn, intercepts imported NT API calls and supplies minimal kernel-object and memory stubs. The CLI can invoke DriverEntry, send one IOCTL or run a mutation loop over an IOCTL input buffer. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** Windows x86-64 driver .sys files are the documented inputs. - **Limits:** Emulation covers only the driver's own code and directly imported functions; hardware-facing drivers need additional stubs. - **License:** Unlicense. ##### Primary sources 1. 2. 3. #### angr-management > Cross-platform graphical binary analysis tool powered by the angr platform, with disassembly and decompilation views. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Powered by the angr platform; v10.0.5 is dated 2026-10-22. - BSD-2-Clause per LICENSE. ##### Primary sources 1. #### QIRA > QIRA is a tool for examining program execution traces. Its interface lets users navigate instruction changes, register values, memory reads and writes, and forks. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Ubuntu 14.04 and 16.04 are supported out of the box. - The QEMU tracer requires a Linux host; native Mac OS X and Windows support is very limited. - QIRA code is licensed under MIT; other code in the repository retains its respective licenses. ##### Primary sources 1. #### Dependencies > Dependencies is a Windows PE dependency analysis tool with command-line and graphical interfaces. It shows imports, exports, and DLL load dependencies to help diagnose loading problems. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires the Visual C++ Redistributable to run properly. - Does not detect dependencies loaded dynamically through LoadLibrary. - Recursive analysis must be enabled in the options and can use substantial memory. - The repository declares the MIT license. ##### Primary sources 1. #### Hachoir > Hachoir is a Python library for viewing and editing binary streams as trees of fields, down to individual bits. Its command-line tools can search binary files for text, extract or remove metadata, and display file contents in text mode. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python 3.7 or newer. - Licensed under GNU GPL v2. ##### Primary sources 1. #### Pigaios > Pigaios is a tool that matches C source code against binaries in IDA. It extracts function features from source code, finds corresponding functions in an IDA database, and imports symbols, structures, and enumerations. It can work with partial source code that does not compile. - Type: Tool - Targets: Binary - Category: Binary comparison tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python Clang bindings; the README indicates Clang 3.9 or later should work. - Requires IDA with IDAPython to match binaries and import the results. - On Windows, LLVM must be installed and added to PATH. Colorama is optional for colors, and scikit-learn is optional for machine learning features. - License: GPL-3.0. ##### Primary sources 1. #### MachOExplorer > MachOExplorer is a desktop and command-line tool for inspecting Mach-O binaries, Universal binaries, static archives, and dyld shared caches. It displays file structures, symbols, disassembly, and Apple-specific metadata, and can export analysis as text or JSON. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building from source requires CMake 3.16 or later, Qt 6, and a C++14 compiler. - Capstone is optional and enables disassembly. - Prebuilt releases are available for macOS; Linux and Windows require source builds. - The repository declares the MIT license. ##### Primary sources 1. #### FLEX > FLEX is an in-app tool for exploring and debugging running iOS applications. It can inspect and change views and object state, browse app files and databases, and show network request history. - Type: Tool - Targets: App - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs an app that targets iOS 9 or higher, and FLEX should be excluded from release builds. - BSD-style terms per LICENSE. ##### Primary sources 1. #### classdump-dyld > classdump-dyld is a command-line tool that generates Objective-C headers from Mach-O app binaries, libraries, frameworks, bundles, and images in the dyld shared cache. It can dump a single class or process compatible files recursively. - Type: Tool - Targets: App · Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a command-line shell on an iOS 5+ device or Mac OS X. - Works with Mach-O files only. - Some files cannot be dumped when protection prevents dynamic loading from another process. - GPL-3.0 per the README. ##### Primary sources 1. #### Process Dump > Process Dump is a Windows command-line tool that saves code from running processes to disk for malware analysis. It can find hidden modules and loose executable code, reconstruct PE headers and imports, and use a clean-hash database to skip known modules. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Runs on 32-bit and 64-bit Windows through the matching standalone executable; run as Administrator for best access. Release v3.0.0 is dated 2026-10-03. - MIT per LICENSE. ##### Primary sources 1. #### mal_unpack > mal_unpack is a Windows dynamic unpacker based on PE-sieve. It runs a packed malware executable, waits for its payload to unpack, dumps the payload, and terminates the original process. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Run on Windows and provide a packed malware executable. - Use only in a virtual machine because the tool launches the original malware. - License: BSD-2-Clause. ##### Primary sources 1. #### Bloaty > Bloaty is a binary size profiler that attributes file and memory usage to sources such as symbols, compilation units, and sections. It can compare sizes between binaries and supports ELF and Mach-O, with experimental PE/COFF and WebAssembly support. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - CMake is required to build the project. - Check out the Git submodules when building from a clone that did not include them. - PE/COFF and WebAssembly support is experimental. - The repository declares the Apache-2.0 license. ##### Primary sources 1. #### bingrep > bingrep is a command-line tool for inspecting and colorizing binary files. It displays details from ELF, Mach, Unix and BSD archives, and PE files, with experimental views of hexadecimal data and file offset ranges. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building requires rustc 1.74 or later. - PE support is debug only. - The repository declares the MIT license. ##### Primary sources 1. #### libPeConv > libPeConv is a Windows library for loading and manipulating PE files. It supports tasks such as section remapping, relocation, import loading, resource parsing, and rebuilding import address tables from memory dumps. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Windows. - Applications that use MUI are unsupported. - License: BSD-2-Clause. ##### Primary sources 1. #### Viper > Viper is a framework for binary analysis and for organizing malware samples, exploit samples, and research scripts. The Viper 1.x repository is archived and development has ended. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Install with pip3. - Viper 1.x is archived and no longer developed; the refactor continues as Viper 2. - BSD-3-Clause per LICENSE. ##### Primary sources 1. #### Cuckoo3 > Cuckoo3 is a malware analysis tool that tests suspicious files and links in sandboxed platform emulators. It reports what the files or websites did during the test. - Type: Tool - Targets: Binary · Website - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a Linux (Ubuntu) host with Python 3.10 and Windows sandboxes. - The README says it is not ready for production use. - License: EUPL-1.2. ##### Primary sources 1. #### Cuckoo Sandbox > Cuckoo Sandbox is an automated malware analysis system that executes suspicious files in an isolated environment and reports their behavior. - Type: Tool - Targets: Binary - Category: Debugging and dynamic analysis - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README marks Cuckoo Sandbox 2.x as unmaintained and the repository is archived. - GPL-3.0 per docs/LICENSE. ##### Primary sources 1. #### fq > fq is a command-line tool and query language for inspecting and decoding binary formats. It provides a structural hex viewer, bit-level decoding, nested format parsing, and an interactive query interface. - Type: Tool - Targets: Binary · Protocol - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Go 1.22 or later is required to build from source. - The repository declares the MIT License. ##### Primary sources 1. #### innoextract > Unpacks Inno Setup installers on non-Windows systems without running them. It also handles modified variants, including GOG.com's Inno Setup-based game installers. - Type: Tool - Targets: Binary - Category: Native analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Building requires Boost 1.37 or newer, CMake 2.8 or newer, and a working C++ compiler. - liblzma is optional, but most installers made with newer Inno Setup versions cannot be extracted without it. - Individual components cannot be selected for extraction, and filtering by name is limited. - License: ZLIB. ##### Primary sources 1. #### Metasm > Metasm is a Ruby suite for assembling, disassembling, debugging, and modifying executable binaries. It supports formats including PE, ELF, Mach-O, and shellcode. - Type: Tool - Targets: Binary - Category: Binary analysis libraries - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Ruby is required to use the suite and its sample scripts. - LGPL per the README; the LICENCE file carries LGPL-2.1. ##### Primary sources 1. ### Firmware and hardware (89) #### ThinkPad IMX471: recovering camera tuning for Linux > Recovers selected camera-tuning structures from an Intel Windows driver package and uses them to repair Linux image capture on one ThinkPad model. Public CPFF/AIQB parsers, kernel patches and libcamera changes accompany the author’s Claude-assisted investigation and bounded before/after measurements. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The Python 3 analysis tools use NumPy and assume a 1928x1088 RG10 stream with a 3904-byte stride. Some scripts embed the author’s local layout and need path adaptation. Repeating the tuning analysis requires the corresponding vendor driver-package data or device captures. - **Scope:** The reviewed target is a Lenovo ThinkPad X1 Carbon Gen 14 (Aura Edition), with a Sony IMX471 sensor behind Intel IPU7. The author tested Fedora 44 kernel 7.2.8 and a libcamera 0.7.1 backport. The published kernel package omits BTF/debug information and is described as a test kernel, not a daily-driver recommendation. - **Testing evidence:** The author’s controlled low-light comparison holds 400 frames for convergence and reports frame brightness rising from 31.1 to 90.9. The test record describes crop-selection, colour-bar and analogue-gain checks on the affected device. Its 46/46 v4l2-compliance passes occurred before and after the crop fix, so that pass count alone did not detect the defect. - **Limits:** The work adds three kernel fixes plus lens-shading and white-balance-statistics changes to an existing Linux driver and software ISP. Low-light blue remains about 17% short, an 18.8 ms exposure ceiling is not fixed here, and the second IR camera is outside scope. It does not recover the entire Windows driver, emulate the laptop or establish compatibility across camera models. - **Attribution:** The dated investigation includes corrected and withdrawn hypotheses. The patch cover letter attributes Claude assistance and hardware checking to the author. The later blog reports submission/review activity. - **License:** No top-level project license is present at the pinned revision. Newly added libcamera implementation files in the patch declare LGPL-2.1-or-later, and the tuning-data section declares CC0-1.0; these are component notices, not a blanket license for every script or vendor-derived input. Existing kernel/libcamera code and vendor materials retain their separate terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### MXQ PRO RK3229: an Android firmware investigation and Linux repurposing > An owner documents identifying an RK3229 TV box, investigating its stock Android ROM and repurposing it with a userspace gamepad driver and Armbian. REA assisted ADB inventory and Android-provider routing; APK analysis and device changes are reported as a mixed workflow, not firmware reconstruction. - Type: Case study - Targets: Firmware - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an owned, correctly identified RK3228/RK3229-class board and its matching firmware/backups; the MXQ PRO sales label alone does not identify the hardware. - **Attribution:** The author limits REA's role to device inventory and the Android provider pointer; JADX and separate host/device tools perform other parts of the work. - **Testing evidence:** The report covers one unit and describes replacing its stock system. Partition layout, board support and boot behavior are device-specific. - **License:** Large/proprietary images, system APKs and decompiled third-party source are excluded upstream. A project-wide license grant is not stated in the reviewed README. ##### Primary sources 1. 2. #### iCSee LocalMod: a stock-firmware camera control extension > An owner-authorized XM530V200 camera case uses REA/Ghidra to investigate native Sofia command handlers, then adds local control and Home Assistant integration while preserving stock drivers and recording. The source-only extension documents separate static, emulated-protocol and physical-device evidence. - Type: Case study - Targets: Binary · Firmware · Protocol - Category: Community REA investigations - Relationship: Author-reported mixed workflow - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Tested only on one XM530V200 / IPG-X2-WQ-BL unit. There is no universal image or public flash installer; source builds need a compatible ARM toolchain and matching Dropbear crypto library. - **Attribution:** The documented investigation used REA 6.8.0 and Ghidra 12.1.4. Binary addresses are specific to the analyzed Sofia build; the project is stock firmware with additions, not OpenIPC or a full DVRIP implementation. - **Testing evidence:** The owner reports physical PTZ/LED/audio and restart/SD-recording checks. QEMU tests use fake backends. - **Limits:** The local bridge uses the existing device account over plain HTTP; the route-removal guard is not a firewall. Original additions are MIT, while stock firmware/drivers and third-party components retain their own rights. ##### Primary sources 1. 2. 3. #### Binwalk > Identifies embedded formats and optionally extracts their contents, with entropy analysis for firmware triage. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The current v3 implementation is Rust-based; extraction needs the appropriate external tools or the documented container environment. ##### Primary sources 1. #### unblob > Recursively extracts archives and filesystems from binary blobs while reporting chunk boundaries and unknown regions. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python package plus external extractors, or the bundled Docker image; check the project's dependency inventory for the formats needed. ##### Primary sources 1. #### Ghidra Firmware Utilities > Ghidra loaders and helpers for PCI option ROMs, UEFI firmware volumes, Intel flash descriptors and coreboot images. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed build instructions require Ghidra 12.0+ and JDK 21+; build against the same Ghidra/JRE environment used for analysis. ##### Primary sources 1. #### EMBA > Extract firmware, combine static checks with emulation-based analysis, inventory software components, and generate web reports and SBOMs for further investigation. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Upstream recommends an x86-64 Kali Linux VM and the default Docker mode; Ubuntu 22.04/24.04 is also listed. Native ARM execution is not supported. - Documented resource guidance is at least 16 GB RAM, 8 CPU cores recommended, and 30–100 GB free disk space; larger firmware or more parallel workers need more resources. - Install the external dependencies through the project installer. Emulation can execute firmware content; upstream reserves developer mode for development, and findings still require interpretation. ##### Primary sources 1. #### Firmware Analysis and Comparison Tool (FACT) > Unpack and analyze firmware through an extensible platform whose web interface and HTTP API make component contents and analysis results searchable and comparable across samples. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed installer supports Debian 13 and Ubuntu 22.04/24.04/26.04; Kali support is experimental. The README lists Python 3.10–3.14. - Minimum documented resources are 4 CPU cores, 8 GB RAM, and about 10 GB for installation, plus storage for unpacked firmware and results. - The standalone FACT_docker distribution is marked unmaintained; use the documented local or Vagrant setup. Some analysis plugins have separate licenses. ##### Primary sources 1. #### OFRAK > Recursively identify, unpack, analyze, modify, and repack firmware and binary formats using a resource-tree GUI and Python API, with optional disassembler backends. - Type: Tool - Targets: Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The PyPI installation guide requires Python 3.9+ and format-specific external tools; macOS also needs cmake and libmagic, avoiding the documented libmagic 5.47 regression. - Docker builds require BuildKit; Docker 23+ enables it by default. Analysis backends such as Ghidra or Binary Ninja have their own installation and licensing requirements. - OFRAK uses its own Community License for personal and educational use; commercial users should review the separate Pro or Enterprise licensing terms. ##### Primary sources 1. 2. 3. #### FirmAE > Emulate router and IP-camera firmware to inspect network services and runtime behavior, with automated emulation checks and separate analysis, run, and debugging modes. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README documents Ubuntu 20.04 as the tested host; prepare the recursive source checkout, downloaded dependencies, initialized database, and a supported firmware image. - The installer configures QEMU, PostgreSQL, extraction tools, and other host packages; documented run modes require elevated privileges. Docker orchestration is also provided. - Successful emulation depends on the firmware image; upstream benchmark results are not a guarantee for an untested device or newer host distribution. ##### Primary sources 1. 2. #### PulseView > Examine captured logic and analog waveforms with sigrok's graphical frontend. Protocol decoders and decoder stacking expose bus messages and higher-level device operations, making hardware communication traces useful for firmware and interoperability investigations. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supply a supported recorded trace, or use a compatible logic analyzer/oscilloscope with the needed device access. Device support is narrower than the whole sigrok suite; PulseView is not the multimeter frontend. - Protocol decoding requires libsigrokdecode and operates on logic signals; analog captures need suitable conversion. The reviewed source accepts Qt 5.3+ or Qt 6.2+, libsigrokcxx 0.5.2+ and libsigrokdecode 0.5.2+. - GPL-3.0-or-later. GitHub is the official mirror. Development snapshots and packaged releases may differ. ##### Primary sources 1. 2. 3. 4. 5. #### UEFITool > Parse UEFI firmware images into an inspectable tree and check their structure. Companion UEFIExtract and UEFIFind tools extract parsed contents and locate patterns, supporting analysis of firmware components and vendor formats. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Provide a compatible firmware image. A75 has Windows, macOS, Linux and FreeBSD builds; building the GUI requires a C++ compiler and Qt5 or Qt6. - The current new engine does not rebuild images. Editing requires the explicitly outdated, unsupported 0.28 old engine. - A75 still disables AMD image parsing. Some vendor update containers are unsupported or may parse incorrectly. The project uses the BSD-2-Clause license. ##### Primary sources 1. 2. 3. #### Glasgow Interface Explorer > Use FPGA-based open hardware and Python applets to read and write SPI flash, I2C EEPROM and parallel memory chips, determine JTAG pinouts, debug supported processors and analyze UART, SPI and QSPI transactions on physical devices. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Glasgow hardware, bought pre-assembled or built from the open design, plus physical access and correct wiring to the target; some targets need external power. The manual lists its features as working with a revC board, except the analyzer2 logic-analyzer applet, which is currently revD0+ only. - Windows has self-contained MSI installers for Windows 7 SP1 or newer (Windows 7 also needs update KB4457144). Other platforms use the documented git and pipx source install with Python >=3.13,<3.16; Linux also needs the supplied udev rules. The repository has no tagged releases, and the package metadata marks the software as alpha. - Dual-licensed 0BSD or Apache-2.0. The built-in cycle-accurate logic analyzer for debugging applets is documented as temporarily removed pending internal architecture improvements. Applets cover the documented interfaces and memory or processor families; the target interface and parameters must still be identified, and Glasgow does not extract firmware automatically. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Penguin > Rehost embedded Linux firmware from an extracted root filesystem using a generated, editable configuration of emulation transformations, then refine it through a guest root shell, forwarded network services and recorded dynamic-analysis output. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed release: v3.1.21, published 2026-10-06 and tagged at the reviewed commit. Install by pulling the rehosting/penguin container from Docker Hub and installing its penguin wrapper script; source and Nix builds are documented separately. - Input is a root-filesystem tarball with permissions and ownership preserved, made with the bundled fw2tar or by hand. Penguin uses whole-system emulation with a replacement kernel selected for the detected architecture; it does not reproduce the original device faithfully or recover source code. Failed rehostings are refined by editing the configuration and rerunning. - The BAR 2025 workshop paper, co-located with NDSS, reports author-run results on 13,649 embedded Linux images from 69 vendors, with working rehostings for 75% more firmware than the prior state of the art. That evaluation predates this release. - GPL-2.0-or-later; the README also carries a U.S. Government rights notice. Findings from the emulated system need analyst interpretation. ##### Primary sources 1. 2. 3. 4. 5. 6. #### flipper-telink: replacement firmware for Tuya Zigbee remotes > A Flipper Zero app that bit-bangs Telink’s SWire debug interface to dump and reflash TLSR825x Zigbee devices, with static-analysis notes on the dumps and freshly written firmware for two of them. For Tuya TS0044/TS0046 scene remotes, the notes trace the stock ~500 ms single-click delay to a double-click window; the replacement firmware drops that window while presenting the stock model IDs to Zigbee2MQTT. The latest Zigbee build is marked unverified for pairing, actions and battery reporting. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Hardware: a Flipper Zero on Unleashed firmware (the notes name API 87.8; apps built with the official SDK will not load), wired to the target’s SWS pin, ground and 3.3 V. The flasher app builds with ufbt and a project-local SDK; the firmware builds with the Telink Zigbee+BLE SDK in a Docker tc32 toolchain and, once installed, updates over BLE OTA. - **Prerequisites:** Inputs are the user’s own devices and their flash dumps. dumps/ publishes sanitized stock images of four devices, with Zigbee network state and Tuya credentials blanked by tools/sanitize_dump.py; raw dumps stay private. Stock firmware rights stay with its vendors, and the repository states no terms for these images. - **Scope:** The TS0044/TS0046 notes derive GPIO roles from the factory JSON config and trace a single click through a 300 ms double-click window plus event-queue, debounce and wake overhead, citing code addresses in the dump. Disassembly uses an included TC32 disassembler built from a third-party opcode table; the TS0046 application image is reported byte-identical to the TS0044 one apart from factory data. - **Testing evidence:** Replacement firmware v00.14 sends short presses on release and holds after 1 s, identifies as the stock TS0044/TS0046 to Zigbee2MQTT and keeps a BLE service mode for OTA. The progress table records hardware checks for earlier versions; v00.14 was flashed to a TS0046, but pairing, actions and battery reporting in Zigbee2MQTT are marked unverified. The separate ZG-226Z alarm firmware is documented as built but not yet run on hardware. - **License:** The repository has no top-level license. Firmware directories carry a permissive notice for build files taken from pvvx/BZdevice and the Telink SDK’s Apache-2.0 license, and the notes credit pvvx’s SWire work. The README calls the project highly vibe-coded; the author’s post credits a pi agent running GLM-5.3. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### ipsw > Command-line toolkit for Apple firmware research and reverse engineering. It downloads and unpacks IPSWs, OTAs and KDKs and compares builds; inspects Mach-O load commands, symbols, signatures and entitlements with ARM64 disassembly; finds symbols and cross-references in dyld shared caches, extracts dylibs and dumps Objective-C headers and Swift metadata; extracts KEXTs and compares kernelcaches; and parses IMG4, decrypts AEA archives and inspects iBoot and coprocessor firmware. - Type: Tool - Targets: App · Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v3.1.739, published 2026-10-16, with Linux, macOS, Windows and iOS builds plus deb, rpm, apk and Arch packages; the reviewed master commit is three cache and documentation commits ahead. Install with Homebrew (tap or core formula), snap or Scoop. The extras build (Unicorn-based dyld emulation, libusb device commands) and the Frida build are macOS only. Source builds need a C toolchain for CGO and, per the README, Go 1.26+, although go.mod declares go 1.27. - Firmware, caches and binaries are supplied by the user or fetched with the download commands. With --dec, macho disass and dyld disass send disassembly to the LLM provider chosen with --dec-llm: hosted OpenAI-compatible, Anthropic, Gemini or router APIs, ACP agent CLIs, or local Ollama. The separate ipswd daemon exposes a REST API, and the README points agents to the separate ipsw-skill repository. - MIT license. The README notes that extracted dylibs can still reference metadata elsewhere in the cache, so it recommends Objective-C analysis on the cache itself. LLM decompilation output is model-generated and needs verification. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Supermodel: initial Real3D Pro-1000 image-generator emulation > Adds emulation of Real3D’s Pro-1000, the SCSI-attached image generator from which Sega’s Model 3 graphics hardware derives, to the Supermodel arcade emulator. It boots user-supplied Pro-1000 firmware from the SDK disc, emulates the board’s interrupt, JTAG and UART hardware, and exposes the firmware’s built-in monitor on the console. Nothing renders yet, and SCSI host communication is unimplemented. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply the Pro-1000 firmware images p1_p4.bin and p2.bin from the SDK disc; Config/Games.xml lists their CRC32 values, and the repository does not include them. The PR says the default scene and model data sat in a SCSI ROM that the SDK lacks and would have to come from original hardware that likely no longer exists; a synthetic SCSI ROM only gets past renderer initialization. - **Prerequisites:** Supermodel documents builds with GCC and Make on Windows (MSYS2, with SDL2 and SDL2_net), Linux and macOS, and a Visual Studio project; the PR adds its sources to the shared Makefile rules and that project. No Pro-1000 test or rendering comparison accompanies the change. - **Scope:** Reviewed at merge commit 4f5d686 of pull request #343, merged 2026-10-14, which adds a CPro1000 emulator class beside the Model 3 one. The PR boots the firmware to its UART monitor and accepts console commands such as help; it states that nothing is drawn, not even the start-up logo, and that SCSI communication is the next step. - **Limits:** Source comments describe the hardware findings as reverse-engineered working hypotheses drawn from firmware disassembly, logs of unmapped accesses and UART output, embedded SCCS module strings, address cross-references, part datasheets and the SDK manuals. Some registers and the JTAG scan chain remain unknown. - **License:** Supermodel’s source headers declare GPL-3.0-or-later; the firmware, SDK material and demo databases keep their own rights. The author’s X post credits Claude with doing the reverse engineering and writing the emulation, and credits co-author Ian Curtis with the earlier SCSI-interception demos. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### avatar² > Python framework from EURECOM's S3 group that orchestrates emulators, debuggers and physical devices for dynamic analysis of embedded firmware. An analysis script declares targets, such as a modified QEMU, PANDA, Unicorn, a gdbserver or an OpenOCD or J-Link debug probe, then a memory layout whose ranges can forward accesses from one target to another, and an execution plan. Execution and register or memory state can move between targets, so firmware can run in an emulator while its peripheral accesses go to the real device. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.4.7, uploaded to PyPI on 2022-02-10 and tagged v1.4.7; GitHub lists no release pages. The reviewed main commit, from 2024-10-23, is nine commits ahead of that tag, adding ARMv7-M interrupt forwarding and hardware-runner plugins and pinning Unicorn 2.0.1.post1. - The core installs with pip; CI tests Python 3.7-3.9 on Ubuntu 20.04. Target endpoints are separate: python -m avatar2.installer or the targets/build_*.sh scripts build the avatar-qemu fork and PANDA, with build scripts provided for Ubuntu 20.04 only, and the scripts add a restricted deb-src repository to /etc/apt/sources.list, so the README suggests a VM or container. A Dockerfile generator builds images with selected endpoints. - An analysis needs the user's own firmware image and, for hybrid setups, the physical device reachable through a gdbserver, an OpenOCD script or a Segger J-Link probe. Architecture definitions cover ARM, including Cortex-M3 and big-endian variants, MIPS and x86/x86-64. The analyst writes the memory layout, forwarding rules and execution plan in Python. - Apache-2.0; avatar-qemu and PANDA come from separate repositories with their own licenses. The README lists research publications that describe, use or extend the framework. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### efiXplorer > IDA Pro plugin and loader that automate static analysis of UEFI firmware. The plugin annotates Boot, Runtime, SMM and PEI service calls, lists the EFI protocols and known GUIDs a module installs or consumes, applies protocol interface types in the Hex-Rays decompiler, flags suspected SMM callout and GetVariable out-of-bounds write patterns for review and saves a JSON report. The efiXloader module opens a whole firmware image in one IDA database, with driver entry points, navigation between drivers and a DXE driver dependency graph. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v6.3.0, published 2026-08-20 as a zip of prebuilt binaries; the reviewed master commit is two GUID-database submodule updates ahead. ida-plugin.json declares IDA 8.3 or newer on Windows x86_64, Linux x86_64 and macOS x86_64/aarch64; the plugin is listed in Hex-Rays' plugin repository and can be installed with ida-hcli. - Needs a licensed IDA Pro. Applying protocol interface types also needs the Hex-Rays decompiler, and the build instructions cover building without it. Source builds use CMake or build.py against the IDA SDK, UEFITool and GUID database submodules; a manual install copies the plugin and the guids directory into IDA's plugins folder and the loader into its loaders folder. - Input is a UEFI firmware image or individual UEFI driver the analyst already has. The wiki's feature table lists SMM services and the dependency graph for 64-bit modules only and PEI services for 32-bit only. Its loader page still says only 64-bit drivers are supported, while the v6.3.0 notes add 32-bit modules in the loader, and the wiki pages still link the earlier binarly-io repository. - GPL-3.0; ida-plugin.json declares GPL-3.0-only. Vulnerability-scanner hits are suspected findings presented for analyst review, not confirmed bugs; the authors' Black Hat Europe 2020 and EKO 2020 publications describe the approach. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### vmlinux-to-elf > Rebuild an analyzable ELF with function and variable symbols from a Linux kernel image, whether a raw or compressed vmlinux, vmlinuz, zImage or bzImage blob, certain Android boot.img files or a stripped kernel ELF, by locating and decoding the embedded kallsyms symbol table. It detects the compression format, instruction set, endianness, word size, entry point and an approximate base address and writes an ELF for IDA Pro or Ghidra; a kallsyms-finder listing, a standalone decompressor and a GTK GUI are included. - Type: Tool - Targets: Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.3.6, published 2026-05-20 on GitHub and PyPI; its notes include provisional support for reserializing section-stripped ELF kernels and uImage LZMA decompression. The reviewed master commit is four commits ahead, with GUI and packaging updates, and carries a 1.3.6.1 tag that has no release. PyPI classifies the project as beta. - Requires Python 3.9+ with lz4, zstandard, minilzo and peewee. The README installs the CLI and GUI with snap on Ubuntu, from the AUR, or with uv plus GTK 4, libadwaita and PyGObject development packages; Flathub provides the GUI on distributions whose libadwaita is older than 1.6. - Input is a kernel image the analyst already has; kernels built without CONFIG_KALLSYMS are not supported. The README states support for Linux 2.6.10 through 6.4 as of August 2023, raw-kernel architecture detection for MIPS, ARM, ARM64, PowerPC, SPARC, x86, x86-64, SuperH and ARC, XZ, LZMA, GZip, BZ2, LZ4, LZO and Zstd decompression, and OpenWrt's uncompressed kallsyms variant. Instruction set, bit size, file offset and base address can be overridden when detection fails. - GPL-3.0-or-later. Recovered symbols carry only the name, address and nm-style type stored in kallsyms, and the base address is a heuristic: the first text symbol address with the low 12 bits cleared. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Sony-PMCA-RE > USB tool built from reverse engineering Sony digital cameras. On supported models it reads camera information and installs Android apps through the PlayMemories Camera Apps mechanism, while its firmware-updater and service-mode shells can dump firmware, run Linux commands and change settings. The repository's notes describe the app-installation exchange between the Sony app store, the browser plugin and the camera. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.18, published 2022-04-08, with Windows and macOS builds of the pmca-console command line and the more limited pmca-gui. The reviewed master commit, from 2022-08-18, is 22 commits ahead of it. On Linux the Python 3 sources run with the listed requirements and libusb; the CI builds use Python 3.6 and PyInstaller. As checked on 2026-10-20, the reviewed 2022-08-18 commit is still the master head, GitHub’s last recorded push was 2024-07-27, the repository is not archived and the README does not mark it as maintained, superseded or archived. - Needs a supported Sony camera connected over USB; the README links an external OpenMemories compatibility list. App installation needs a camera with PlayMemories Camera Apps support. Firmware-updater mode uses the operating system's mass-storage driver and excludes CXD90045 and CXD90057 devices, whose firmware is cryptographically signed. Service mode is console-only and needs libusb drivers on Windows; macOS mass-storage access needs Sony's camera driver. - The README calls the project an early-stage experiment based on reverse engineering and warns that it could harm the camera, with no responsibility taken. Firmware-file unpacking lives in the separate fwtool project. - MIT. The repository holds no Sony firmware or apps; the prebuilt updater payloads under updatershell/fdat are packed by pack.py from the project's own sources. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### cpu_rec > Statistically recognize the CPU instruction set in an arbitrary binary file, such as an unknown firmware image, by comparing Markov-chain byte statistics with a default corpus covering dozens of architectures, from 6502 and 8051 to ARM, MIPS, PowerPC, RISC-V, x86-64 and WebAssembly. It reports a match for the whole file, then the largest chunk that matches one architecture, and shows entropy so that encrypted or compressed regions can be discounted. It runs standalone, as a Python function or as a binwalk module. - Type: Tool - Targets: Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.1, published 2024-03-19 and tagged at the reviewed commit; it adds an optional pickled corpus for faster startup and LIEF as an alternative to elfesteem. There is no package: cpu_rec.py and the cpu_rec_corpus directory are copied into the same directory. As checked on 2026-10-20, nothing has been pushed since v1.1 and the repository is not archived; the README’s Development status section holds only CI badges and does not mark the project as maintained, superseded or archived. - Runs on Python 3 or Python 2; the portability workflow covers Python 3.10, PyPy 2.7 and 3.9 and GraalPy on Ubuntu and macOS. Without the lzma module the .xz corpus files must be decompressed first. Optional elfesteem or LIEF extracts the text section of ELF, PE, Mach-O or COFF files. The README reports about one minute of analysis per MB, and 1 GB of RAM to build signatures for 70 architectures, on the author's laptop. - Binwalk mode installs into binwalk's module directory and needs a binwalk that includes devttys0/binwalk pull request 241; these instructions point to the earlier Python binwalk. - Results are heuristic: the README warns that files can contain several architectures, small chunks can be misdetected, and results for data with entropy above 0.9 are probably meaningless. 78k and TriCore are left out of the default corpus for licensing reasons and can only be added from the user's own binaries. - cpu_rec.py is Apache-2.0. The README describes the default corpus as a composite of code chunks under their own licenses, mostly from Debian, BusyBox, C-Kermit and the author's own cross-compiled open-source builds, plus a few of unknown license, including an H8S binary distributed by Dell; build_default_corpus records each origin. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### ME Analyzer > Parse Intel Management Engine (CS)ME, TXE and SPS firmware, Graphics System Controller firmware and their independent PMC, PCHC, PHY and option-ROM images to report family, version, release, SKU, platform, size and health status. Research options print flash partition, BPDT/IFWI and CSE layout tables, validate RSA signatures and checksums, and unpack the supported CSE and GSC code and file systems. A bundled database identifies known images and reports those not yet listed in the community firmware repositories. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.312.0 with database r378 (tag v1.312.0-r378), published 2026-09-06 at the reviewed commit, with no attached builds. The README describes the tool as the MEA.py script plus its bundled MEA.dat, Huffman.dat and FileTable.dat databases, and says MEA.dat is required to run. - Requires Python 3.7+, which the script checks at startup, and the third-party colorama, crccheck and pltable modules. The README lists Windows, Linux and macOS hosts; the script also accepts BSD. - Input is an Intel Engine, Graphics or Independent firmware image the user already has, given as files or scanned from a directory with -mass. The README lists ME 2-15, TXE 0-4, SPS 1-5, GSC 100 (DG1) and selected PMC, PCHC, PHY and OROM generations, and states that any family or version not listed is unsupported, with no plans to add others. - By default the script contacts GitHub to compare its version and database with the latest ones (-duc disables this) and copies any input that triggers a note, warning or error into a __CHECK__ folder in the output directory (-dcm disables this). - BSD-2-Clause-Patent. The README describes parsing, validation and unpacking, not rebuilding or modifying images; reported details depend on the bundled database. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### OpenDMCUFirm: a reimplemented Wii U DMCU display firmware > Reimplements in C the firmware of the Wii U’s DMCU, the M68HC11-compatible display microcontroller in its AMD graphics controller, which in Wii mode reads the Video Interface state and configures display output, deinterlacing, scaling and overscan. The README says the work is based on reverse engineering of the original firmware but is not a byte-for-byte matching decompilation, and calls it a work in progress. The built image replaces the stock firmware in Wii mode when loaded through the evWii plugin. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The build uses only the project’s C sources and needs no original firmware. Running the result needs a Wii U with the Aroma plugin environment and evWii: dmcu.d.hex goes in the SD card’s wiiu folder and is loaded with evWii’s “Load DMCU Firmware from SD Card” option for Wii mode. - **Prerequisites:** The compiler is GCC 3.3.6-m68hc1x-20060122 from the GNU 68HC11/12 packages. The Dockerfile sets it up on Ubuntu 24.04 from the checksum-verified Windows installer run under Wine, and a prebuilt garyodernichts/dmcubuilder image is offered; Python 3 runs hexconv.py to turn the S19 output into the DMCU hex format. - **Scope:** The reviewed main commit has no releases or tags. The README describes a work-in-progress reimplementation with potential issues expected; recent commits name registers and state fields, and one reports a function fully matched after a missing variable caused problems in 240p titles. link.ld warns that Nintendo’s nn_cmpt writes values into the middle of the DMCU’s ERAM and can overwrite the code. - **Testing evidence:** CI only builds dmcu.d.hex in that container and uploads it as an artifact. The reviewed files contain no test suite, hardware test log or comparison with the stock firmware’s behavior. - **License:** The repository has no license file and GitHub detects none; project source files state only that they are part of OpenDMCUFirm. The bundled 68HC11 and stdint headers keep their FSF GPL and BSD notices, evWii is GPL-2.0, and the original firmware keeps its own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### reflecticon-224: running Lexicon 224 reverb firmware on emulated hardware > Emulates the Lexicon 224, 224X and 224XL digital reverbs so that their own firmware runs in a browser page or a JUCE plugin. The repository layers KiCad schematics, gate-level and board-level Verilog models, an 8080-hosted C++ emulator and analog input/output models, and checks faster layers against slower ones using user-supplied ROMs. It is a work-in-progress hardware-and-firmware emulation whose documentation is still pending, not recovered algorithm source. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin is from 2026-10-13; the repository was created on 2026-09-28. README calls it a work in progress whose documentation will follow, so the Makefile is the main map: it links the schematics, gate-, board- and ISA-level models, the C++ emulator, analog models, the WebAssembly page and the plugin. Recognized firmware sets include several 224 versions, 224X v8.1 and 224XL v8.1A and v8.21. - Users supply their own Lexicon ROM chip files, which README says stay on their computer. The page and plugin recognize known sets by SHA-256, and the repository lists those hashes, not ROM bytes. Firmware checks read a LEXICON_FIRMWARE folder with one subfolder per set and skip when it is absent. The web demo does ship program-name and slider-value catalogs keyed to specific firmware sets. - make check runs the firmware-free checks, and any target whose tool is missing, such as Verilator 5 or KiCad’s command-line tool, reports itself as skipped. The page builds with Emscripten 5.0.1 for GitHub Pages. The plugin builds with CMake and JUCE 8.0.14 as macOS AU, VST3 and standalone targets, and CI validates the AU with auval; the tagged v0.1.0-alpha.1 prerelease is an ad-hoc signed macOS 11+ build that contains no firmware. - make check-firmware runs the user’s ROMs through several layers, including service-manual signature tables at gate level. Qualification compares the emulator’s CPU state, control-store writes and DAC captures with board-level runs, and qualified.json stores expected hashes for two scenarios. A byte-exact gate compares the WebAssembly build bit for bit with the native reference. These project checks need the ROMs. - GitHub detects no repository license, so no reuse terms beyond viewing are granted; the included 8080 cores carry zlib and MIT notices. README disclaims affiliation with Lexicon or its owners, and the original firmware remains theirs. In the Hacker News thread for a related report, a commenter who identifies the repository as theirs describes paid schematic tracing and LLM agents turning schematics into Verilog. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### TeddyCloud: a self-hosted replacement for the Toniebox cloud > Reimplements the Boxine cloud services a Toniebox talks to as a self-hosted C server, so the box can fetch audio, settings and over-the-air content locally while the owner controls what reaches the manufacturer. It serves and caches tonie audio, converts other audio into the box’s TAF format, can pass requests through to the original cloud, and adds a web interface, MQTT and Home Assistant integration. Protobuf definitions in the repository describe the box’s freshness-check, RTNL log and TAF header messages. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the stable master head of 2026-08-25, the v0.7.0 merge; release tc_v0.7.0 was tagged the same day, and active development continues on the develop branch. The project’s setup guide covers Toniebox 1 boxes with CC3200, CC3235 or ESP32 chips, and the README lists Toniebox 2 support as planned. - Setup is invasive and specific to each box: the project guide has owners dump their own box’s client certificates, flash a replacement CA into the box and redirect its DNS, and the server can extract or inject certificates in an ESP32 firmware dump. The repository ships no box certificates, firmware or tonie audio (those directories are empty placeholders). The dev-sandbox’s pre-generated certificates are self-signed and meant only for local testing. - Builds with a hand-written Makefile, protoc-c and a C toolchain, plus submodules for CycloneTCP/SSL/Crypto, cJSON, Opus, Ogg, the teddycloud_web frontend and emsdk; Linux debug builds enable AddressSanitizer and UBSan, and Docker is the recommended path on macOS. Release tc_v0.7.0 attaches an amd64 zip from the Windows/Linux release workflow, and Debian, Ubuntu and Alpine Docker images are published for several platforms. Stream conversion uses ffmpeg. - Python API tests for the custom-tonie JSON endpoints and a WASM TAF-encoder test run through Makefile targets; the reviewed workflows build and publish without running them. A dev-sandbox serves mock tonies, box and TAF data. Behavior with real boxes and the Boxine cloud remains project-reported. - GPL-2.0 (LICENSE); the vendored Cyclone stack, Opus, Ogg, cJSON and FatFs keep their own terms. Tonie audio, box firmware and Boxine’s services keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### CHIPSEC > Platform security assessment framework, with Intel Corporation copyright notices, for analyzing PC hardware configuration, BIOS/UEFI system firmware and platform components from Windows, Linux or the UEFI shell. chipsec_main runs check modules that report whether expected protections are in place, such as BIOS and SPI flash write protection and locks, SMM and SMRR protection, memory-map locks and Secure Boot variables, as PASSED, FAILED, WARNING or informational results with JSON, XML and Markdown output. chipsec_util gives command-line and Python access to low-level interfaces and firmware data, including dumping the SPI flash to an image, decoding flash images into firmware volumes, files and NVRAM variables, and listing UEFI variables and tables. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 2.0.9, published 2026-09-24 with a source zip; the reviewed chipsec2 commit is five configuration and bug-fix commits ahead. The installation guide says the PyPI package is outdated. The README sends older Intel platforms (clients before 12th-generation Core, servers before 3rd-generation Xeon Scalable) to the chipsec1 branch, and almost all bundled platform configurations are Intel ones. - Runs as Administrator/root and loads a kernel driver that is distributed as source and built locally. Linux needs Python 3.8+, kernel headers, gcc and nasm; Windows 8 to 11 and Server 2012 to 2025 need Visual Studio with the WDK, and loading the self-built driver requires disabling driver signature enforcement or enabling test signing. The UEFI shell route boots a USB drive with the repository's prebuilt UEFI Python 3.6.8 package and requires Secure Boot to be off; a mkosi recipe builds a live Linux image. The --no-driver option works only for some commands and modules. - chipsec/WARNING.txt says to use it only on test systems, never production machines: the driver gives user mode access to physical memory and other hardware resources, and incorrect hardware access can hang or crash the OS. Some utility commands write or erase SPI flash or change UEFI variables and can leave a system unbootable. A WARNING result requires manual analysis, and the results guide is marked as a draft. - Flash images and platform data come from the machine under test or the user's own dumps; the repository bundles no vendor firmware images. CI builds the Linux driver across distributions and runs unit tests on recorded platform data plus a QEMU UEFI-shell test. GPL-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### Valetudo: local replacement for robot-vacuum vendor clouds > Replaces the vendor cloud of supported robot vacuums with a local service that runs on the rooted robot beside the vendor firmware and emulates the cloud endpoints that firmware expects, including a miio dummycloud and a counterpart for Midea's MSmart protocol. Its FAQ says each new vendor backend meant reverse engineering data formats, authentication and communication without vendor documentation; Valetudo converts the proprietary map formats into one ValetudoMap format and keeps Kaitai Struct descriptions of Dreame, Roborock and Viomi map files and a Midea protobuf schema as references. It adds a web interface, a REST API with Swagger UI and MQTT/Home Assistant integration, while feature parity with the vendor apps is an explicit non-goal. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026.10.0 release commit of 2026-10-18. The README says Valetudo is not a custom firmware but a 'brain parasite' for the vendor firmware, whose own functions it relies on. The backend has Dreame, Roborock, Viomi, 3irobotix and Midea implementations, and the supported-robots page lists 50 model entries under 10 brand headings and calls the list exhaustive. - Requires a supported robot that its owner has already rooted. The docs describe rooting as model-specific and permanent ('Reverting to stock is impossible'), and say the vendor app stops working because cloud connectivity is cut. The repository and its releases ship no vendor firmware: release assets are Valetudo's own armv7, armv7-lowmem and aarch64 binaries with UPX-compressed variants, an OpenAPI schema and a release manifest, while the repository also commits pkg Node.js base binaries for packaging and small captured map files as test fixtures. - Valetudo runs on the robot's Linux system as a static Node.js 22 binary built with pkg; development needs Node.js >=20 according to the root package.json. The docs require Linux and computer skills, and sometimes hardware work, for installation, and offer peer support only. - CI on Node.js 22 runs type checks, lint, the frontend and backend builds and the backend node:test suite, including Dreame, Roborock and 3irobotix map-parser tests on captured maps and miio and MSmart packet tests. The supported-robots page says each listed robot was tested by the author personally unless noted. These are project-reported checks. - Apache-2.0, although the README describes its governance as 'Freeware with source available'. The Kaitai structs declare CC-BY-SA-4.0, and a bundled robot model and tracker song are credited under CC-BY-NC-SA. Vendor firmware, apps and clouds keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. #### binbloom > Quarkslab command-line tool that infers basic properties of a headerless raw firmware image from simple statistics on its content, which is why the README says it works with any architecture. It guesses endianness from how the high bytes of pointer-sized values cluster under each byte order, and ranks candidate loading (base) addresses by how many values would then point at indexed text strings and pointer arrays. Given a base address, it also searches automotive ECU firmware for a table of Unified Diagnostic Services (UDS) command IDs and prints the inferred structure layout for use in a disassembler. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.1, published 2024-06-06 and tagged at the master head, commit 95cfaac from 2022-11-07, whose source reports version 2.1.0. The release adds a -m option for base-address alignment and fixes a crash on very small files and null-pointer and floating-point errors; configure.ac and the man page still say 2.0, and master has no later commits. - The README documents a Linux-only source build with autoreconf, configure, make and make install; configure.ac needs a C compiler, libm and pthreads. The release attaches no prebuilt binaries. - Each run takes one raw firmware dump supplied by the user and assumes a 32-bit target unless -a 64 is given. The README warns that endianness detection may be unreliable below about 10 KB and offers -e to force it; -t adds threads, -f takes a file of known function addresses, and the experimental -d deep search is slower. Output is a ranked list of candidate base addresses, sometimes marked not sure, and the UDS search runs only when -b supplies the base address. - The README calls the UDS search heuristic and prone to false positives, so each candidate table has to be checked by hand. The repository contains no tests or sample firmware and publishes no accuracy results. - Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### m1n1 > Asahi Linux's bootloader and hardware-research environment for Apple Silicon Macs. It bridges Apple's boot chain to Linux by loading appended device trees, initramfs and kernels; in proxy mode a USB link lets a Python client probe hardware live and run macOS or Linux under m1n1's hypervisor while tracing its hardware accesses. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Under active development: the reviewed main commit (2026-10-19) is 53 commits past the v2.0.0 tag (2026-10-02), whose message calls it the first GPL release, otherwise identical to v1.9.9. The latest GitHub release, v1.9.9, ships a stage-2 m1n1.bin and a UEFI-only package holding just an m1n1 boot.bin. - Runs only on Apple Silicon Macs. Builds need an aarch64-linux-gnu-gcc cross toolchain (or a native ARM64 one), LLVM and lld on macOS, or the bundled compose setup, plus Rust's aarch64-unknown-none-softfloat target for chainloading builds. The Python proxy client (pyserial, construct, asn1) talks to m1n1 over USB from another host. - Apple's kmutil installs m1n1 as a custom boot object from macOS recovery, normally via the Asahi Linux installer. run_guest.py takes a Mach-O guest such as an XNU kernelcache from the user's own macOS install; the repository ships no Apple firmware, kernels or macOS components. proxyclient/hv holds 27 tracers for blocks such as AGX, DCP, NVMe and SMC. - CI builds main, checks C and Rust formatting and runs the proxy client's pytest suite on Ubuntu and macOS 14 and 15; those tests cover its assembler, object loading and toolchain handling, not behavior on Mac hardware. - Code through v1.9.9 stays MIT; from v2.0.0 m1n1 is GPL-2.0-or-later, and embedded third-party code such as libfdt, Arm Trusted Firmware portions and dlmalloc, and vendored Rust crates keep their own licenses. Asahi Linux's LLM policy broadly forbids generative AI for material contributions, citing its clean-room reverse-engineering rules; AGENTS.md, CLAUDE.md and GEMINI.md say the maintainers forbid any AI or LLM use for legal reasons. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### SVD-Loader for Ghidra > Ghidra script from leveldown security that reads a CMSIS-SVD file, the XML format describing a microcontroller's memory-mapped peripherals and their registers, and applies it to firmware already loaded in Ghidra. It creates memory blocks for the peripheral address ranges, a structure type for each peripheral with its registers as fields, and a label at each peripheral base address, so register accesses can be read by peripheral and register name. It targets little-endian Arm Cortex-M devices and bundles a fork of the cmsis-svd parser ported to Ghidra's Jython. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository has no releases or tags. The reviewed master head is a 2024-02-01 merge that expanded the installation instructions; the last code changes, merged on 2023-03-04, added error handling to the script and fixed derivedFrom handling for peripherals in the bundled parser. The README names no supported Ghidra release, a 2019 commit fixed compatibility with Ghidra 9.1, and the repository has no tests. - It runs inside Ghidra's CodeBrowser: add the cloned repository as a script directory in the Script Manager, then run SVD-Loader.py on the open program. The script is written for Ghidra's Jython environment, and it imports the bundled cmsis_svd package (version 0.4) from the same directory. - Supply the CMSIS-SVD file for the target chip, which the README suggests taking from the cmsis-svd collection or a Keil software pack, and the firmware image already imported into Ghidra. The script stops on an SVD that declares a big-endian CPU and warns but continues when the CPU is not a Cortex-M. Peripheral ranges that conflict with existing memory blocks are reported and skipped. - Only peripherals and registers are applied: the generated memory blocks are uninitialized, volatile and read/write, and register bit fields, enumerated values and interrupts from the SVD are not added. Results depend on the supplied SVD file; when a block or structure cannot be created, the script prints the failure and moves on. - SVD-Loader.py is GPL-3.0; the forked cmsis_svd/ code keeps upstream cmsis-svd's Apache-2.0 license. The blog post the README links for usage details returned HTTP 404 at review. ##### Primary sources 1. 2. 3. 4. 5. 6. #### UEFI Firmware Parser > Python library and uefi-firmware-parser command for identifying, parsing and extracting PC firmware images: UEFI firmware volumes, capsules, firmware file systems, files and sections, Intel PCH flash descriptors, Intel ME modules and Dell PFS update packages. An AutoParser picks the format, or a brute-force scan looks for volumes and other known objects inside an unidentified blob; results print as an object hierarchy or dump to files, with Tiano/EFI and LZMA sections decompressed by a bundled C extension. Helper scripts replace a section or file by GUID inside a volume, generate an FDF flash description from parsed volumes and output GUID labels for IDA scripts. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.16, published 2026-06-04 on GitHub and PyPI with abi3 wheels for Linux, Windows and macOS. The reviewed master commit, from 2026-10-12, is three commits ahead: it adds AMI capsule support and a safe-path utility for dumped files and drops the future dependency, so those changes are not yet released. - Python 3.10+. A source install compiles the bundled efi_compressor C extension, which the README says needs the Python development headers and gcc; the package declares no other runtime dependencies. CI runs the unit tests on Python 3.12 on Ubuntu. - Input is a firmware file the user supplies, such as a vendor BIOS/UEFI update or a flash dump. The README warns that not every vendor update parses and that some must first be decompressed or unpacked from the update mechanism, typically a PE executable; --test reports the detected type, -b searches a blob for volume headers and --superbrute checks every byte offset for any known object. It lists ASRock, Dell, Gigabyte, Intel, Lenovo, HP, MSI, VMware, Apple and Qualcomm updates as tested, without per-version results. - GUID injection with fv_injector.py only replaces existing sections or files, with no addition or removal, and asks interactively which section to replace inside a firmware file. It parses containers and extracts their contents; analyzing the extracted modules needs a separate disassembler or decompiler. CI also parses a separately hosted samples repository. - LICENSE carries MIT-style permission text and points to inline licenses in contributed work, while setup.py and the PyPI metadata declare BSD-3-Clause. The bundled Intel Tiano compression sources are BSD-2-Clause-Patent and the LZMA SDK files are public domain. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### ESP32 Bit Pirate > Open-source firmware that turns ESP32-S3 boards into a Bus Pirate-inspired multi-protocol hardware tool, operated from a USB serial terminal, a Wi-Fi web CLI or the M5 Cardputer's own keyboard and screen. Its modes talk to, sniff and script I2C, SPI, UART, 1-Wire, CAN and other buses, read EEPROM and flash chips, and scan for JTAG and SWD pinouts. USB adapter modes let host tools such as flashrom, OpenOCD and sigrok/PulseView use the board as an SPI programmer, debug adapter or logic analyzer. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.8, published 2026-10-11, with prebuilt images for 17 board builds that the README installs through the project's web flasher or, for M5Stack devices, M5Burner; the reviewed pioarduino branch commit is identical to that tag. Source builds use PlatformIO with the Arduino framework on a pinned pioarduino ESP32 platform, and CI runs the native unit tests. - Needs an ESP32-S3 board with at least 4 MB of flash. The README lists ESP32-S3 dev kits and M5Stack, LILYGO, Heltec, Seeed Studio, Waveshare and Unexpected Maker boards with the same feature set, warns that the default pin mapping may not match other boards, and notes that some features need additional hardware. Connected devices must run at 3.3 V or 5 V. - Analysis needs physical access and wiring to the target's buses, memory chips or debug pins; the firmware talks to and captures what it is connected to and does not interpret recovered firmware. The README also lists Wi-Fi, Bluetooth, sub-GHz, RFID and cellular modes, some of which transmit, and limits use to educational, diagnostic and interoperability testing on authorized devices. - MIT-licensed; the lib directory vendors third-party drivers under their own licenses, including GPL-2.0 for RF24. The repository holds firmware sources, board profiles, tests and images, with no target firmware. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Firmware Analysis Toolkit (FAT) > Attify's firmware security toolkit, rewritten for version 2 as a Rust command-line tool built around per-image projects. It classifies unknown blobs and firmware images, extracts filesystems, inventories startup scripts, credential strings and crypto material, triages ELF binaries with radare2-based decompilation and source-to-sink taint, and inspects bare-metal MCU images, BMC flash, Edge AI model files and Android APKs. Projects can then go through preflight checks and QEMU emulation on native, FirmAE, Firmadyne or EMUX backends. - Type: Tool - Targets: Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.0.1, published 2026-09-26, with archives for macOS (Apple Silicon and Intel), Linux x86-64 (glibc 2.35+) and ARM64 (glibc 2.39+) and Windows x86-64, plus a separate runtime-data bundle. The reviewed master commit adds unreleased BMC inspection, native JFFS2 recovery, hash-pinned BMC emulation profiles and Redfish session and process debugging. Version 2 is a rewrite; the FAT 1.x setup.sh and fat.py workflow belongs to the older release. - Source builds need Rust 1.91+ and Python 3; the installer can add system packages and builds pinned binwalk-ng 4.0.0 and Sasquatch. The Windows build covers native analysis commands only, and workflows that need Linux filesystem semantics or Unix tools run under WSL. Optional workflows need radare2 with r2ghidra, Ghidra, Joern, angr, QEMU, GDB, tmux or Docker, and FirmAE, Firmadyne and EMUX backends are configured separately; fat doctor reports what is missing. - Users supply the firmware images, extracted filesystems, binaries or APKs to analyze. The third-party notices state that the source tree and release bundles contain no firmware images, kernel or U-Boot binaries, proprietary model files or extracted device filesystems. BMC emulation profiles require an exact input SHA-256 for a named OpenBMC or ASUS BMC image, and the README warns that emulation executes untrusted vendor code. - docs/epistemics.md treats results as bounded observations: startup intent does not prove reachability, Edge AI hits do not show that a model executes, shell taint is deliberately unsound and reports weak candidates, and an emulation validator proves only what it checked in that run. Test fixtures are synthetic, including Cortex-M images built from in-repo C sources with arm-none-eabi-gcc; a prebuilt MIPS PID-1 trampoline ships with its assembly source. DEVELOPMENT.md documents local cargo tests, while the GitHub workflows build and smoke-test release archives. - FAT 2.0 is source available under FSL-1.1-ALv2, which GitHub reports as NOASSERTION: use, modification and redistribution are permitted except a commercial Competing Use, and each version also becomes available under Apache-2.0 two years after Attify first makes it available. FAT 1.x history stays MIT, the optional QEMU hook plugin source is GPL-2.0-or-later, and third-party dependencies and external assets keep their own terms. Users must be authorized to analyze their targets. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### FujiHack > Research codebase for reverse engineering Fujifilm cameras so that custom code can run on them under a patched firmware. It holds ARM firmware patches, chiefly a PTP/USB debugger that adds memory read, write and execute commands, a host CLI that uploads code and dumps memory over USB, and C headers documenting Fujifilm’s RTOS API with per-model firmware addresses and function stubs. On-camera code adds POSIX, graphics and I/O wrappers over that RTOS, a video record-limit mod, button remapping and the Frontier UI and module system. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit dates from 2024-08-17. Its two GitHub releases carry no files: 0.1.0, the debugger release of 2022-10-27, is marked deprecated in favour of a separate fffw project, and 0.2.0, a 2023 DOOM-port demo for the X-A2, is marked no longer supported. The README says FujiHack runs only under a patched firmware, that custom firmware is always dangerous and can damage the camera, and that recovery of bricked devices through the SoC boot ROM has not been reverse engineered. It reports the debugger patch ported to the XF1 and X-A2; model headers with firmware addresses cover ten cameras, from the Z3 and HS20EXR to the X-T4. - The repository contains no Fujifilm firmware, dumps or keys: model headers reference the vendor’s own firmware download URLs, and patching happens in the separate browser-based patcher, which the README says unpacks, injects, patches, repacks and downgrades a firmware DAT file the user selects. Helper programs in etc/, including a Unicorn emulation script, read firmware or RAM dumps the user makes from their own camera. - On-camera code is built per model with arm-none-eabi-gcc, plus rustc for a few Rust files, through make hack.bin model=. The host fuji CLI needs libusb-1.0 and the camlib PTP library submodule, and its Windows build downloads the author’s libwpd DLL. A workflow that compiled the X-A2 target sits in a disabled .github/workflows_ directory, so no CI runs, and there are no tests. - GPL-3.0 per LICENSE and the README, copyright 2021–2024 Daniel C and contributors; usb/dbg.c carries another contributor’s copyright notice, and the camlib submodule keeps its own license. The README frames the work as interoperability research; Fujifilm’s firmware and trademarks remain the vendor’s. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### efiSeek > Ghidra analyzer extension from Digital Security for individual UEFI modules, enabled by default during auto-analysis of x86 and x64 PE images with an EFI subsystem. It labels known GUIDs from a bundled database, applies UEFI types from bundled data-type archives, passes the image handle and system table from the entry point into called functions, and marks protocols located with LocateProtocol or installed with InstallProtocolInterface, protocol-notify callbacks and SMI handlers registered for software, hardware and child interrupts. Findings are also kept as JSON in the program, which a headless-mode script uses to sort SMM modules into project folders by handler type. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository has no releases or tags; the latest master commit, from 2022-04-26, adds compatibility with a Ghidra 10.2 development build. Open issues report that the pinned Gradle 7.4.2 wrapper does not work with Ghidra 11.2 and newer and that a PE header API change in Ghidra 12.0 causes errors; the pull requests proposing fixes were unmerged at review, so building for current Ghidra releases may need those or similar changes. - Built from source with the bundled Gradle wrapper against a Ghidra installation named by GHIDRA_INSTALL_DIR; the build fetches the org.json library from Maven Central. The README then has the zip from dist copied into Ghidra's Extensions/Ghidra folder and the extension enabled, after which the analyzer is preselected when an EFI file is opened. - Input is a single UEFI module the analyst already has: the analyzer accepts only PE images with an EFI subsystem and only the x86 and x64 machine types, so modules must first be taken out of a full firmware image. It rebases the program to 0x80000000 and makes every memory block readable, writable and executable. - Apache-2.0, per LICENSE and the source headers. The repository bundles the Behemotx32.gdt and Behemotx64.gdt data-type archives and the guids-db.ini GUID database that the analyzer loads, plus the Gradle wrapper JAR. Labels and handler classifications are heuristic annotations for analyst review. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### FwAnalyzer > Rule-based checker for filesystem images taken from firmware: it reads ext2/3/4, FAT/VFAT, SquashFS and UBIFS images, cpio archives or a directory, and writes a JSON report of every file that breaks the rules in a TOML configuration. Rules cover SUID and world-writable files, allowed owners, SELinux labels and Linux capabilities, per-file metadata, content regexes, SHA-256 digests, JSON fields and external scripts such as the bundled checksec wrapper; it can also extract values such as version strings and compare the file tree or selected files with a previous run. Cruise describes it as part of a firmware security check suite, and check.py with an Android OTA unpacker runs it over each image in a firmware package. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.4.4, published 2022-10-24 without an attached binary; releases 1.4.1 to 1.4.3 attach a prebuilt Linux fwanalyzer. The reviewed master commit, from 2023-10-08, only fixes typos after that release and is the latest commit; the repository is not archived, and the Makefile still sets VERSION=1.4.1. - Built from source with Go (go.mod declares Go 1.13; the Makefile defaults GOOS to linux) through make deps and make, giving build/fwanalyzer. Each filesystem backend calls external programs: e2ls and e2cp from e2tools for ext images, mdir and mcopy from mtools for FAT, unsquashfs, ubireader_list_files from ubi_reader, and cpio. SELinux and capability data need the author's patched e2tools and squashfs-tools forks, and ext symlink handling needs e2tools' link_support branch; the Dockerfile lists the full dependency set on a golang:1.13 image. - Input is a filesystem image or unpacked directory the user already has; FwAnalyzer itself does not unpack firmware packages. check.py needs an unpacker script that maps configurations to images, and the bundled Android OTA unpacker relies on the separate extract_android_ota_payload and mkbootimg_tools projects. Findings depend entirely on the user's configuration: the devices folder supplies sample Android user-build, Android property and generic Linux root-filesystem rules, and the report lists rule offenders rather than assessed vulnerabilities. - make test runs Go unit tests, and the integration target runs test/test.py, written for Python 2, against bundled fixtures in test/: small ext2, SquashFS, UBIFS, VFAT and cpio images, hello-world ELF builds for ARM32, ARM64 and x86-64, and prebuilt e2cp and unsquashfs helper executables; make testsetup uses sudo setcap. CircleCI builds and tests inside the Docker image, while the GitHub workflow only lints with golangci-lint v1.29. - Apache-2.0, copyright Cruise LLC; the external filesystem tools keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### FwHunt Community Scanner (fwhunt-scan) > Binarly's Python scanner that checks UEFI firmware modules against FwHunt rules, the YAML detection format for known UEFI firmware vulnerabilities whose rules are kept in the separate fwhunt repository. Its rizin-based analyzer reports a PE or TE module's Boot, Runtime and PEI service calls, protocols, PPIs, GUIDs, NVRAM variables and SMI handlers, which rules combine with code patterns, strings and hex strings. The CLI analyzes or scans one module, or extracts the modules of a whole firmware image and scans them, and the same classes work as a Python library. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository has no GitHub releases or tags. The reviewed master commit, from 2025-05-02 and the latest at review, follows the setup.py bump to 2.3.8, the version uploaded to PyPI that day; a separate release branch publishes Docker images to GHCR tagged by commit. - Needs Python 3 (README: tested on 3.6 and above; CI runs on 3.9 to 3.13) with click, rzpipe 0.4.0, PyYAML and uefi_firmware, plus an installed rizin. The README names rizin v0.6.2, and the Dockerfile builds that release from source on a python:3.11 image. Passing an in-memory blob instead of a file path works only on Linux. - Input is a UEFI module or firmware image the user already has, plus FwHunt rule files; no rules are bundled, and the README's rules/ and test/fw.bin example paths are not in this repository. scan-firmware applies firmware-target rules to the whole image and module rules only to modules from the volumes their volume_guids name, unless --force applies them to every module; extract writes all found modules to a directory. - The only test checks GUID table lookups, and CI runs it after a flake8 syntax check. A scan reports, per rule and variant, whether a known pattern matched, printed as threat detected or not; no match does not show that a module is free of other vulnerabilities. - GPL-3.0: setup.py declares GPL-3.0 and source headers GPL-3.0+; the separate fwhunt rule repository is CC0-1.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### sniffROM > Python tool that reconstructs serial flash contents from passive bus captures: it parses SPI or I²C analyzer exports from Saleae Logic, recorded while a device reads and writes its own flash chip, and writes the observed data into a binary image at the original memory addresses. It recognizes more than 100 SPI flash commands from vendors such as Winbond, Macronix, Spansion and GigaDevice and currently parses 12 of them, reports manufacturer and device IDs seen in JEDEC ID reads, and can print a command summary, show a visual map of the captured address ranges and plot the timing of reads and writes. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags; the script was last changed in July 2020. A README note added on 2023-12-07 says Saleae Logic 2 breaks the SPI analyzer export that sniffROM depends on, so it currently works only with data exported from Logic 1.x, and that it was unknown when this would be fixed. - A single Python 2 script (it uses print statements) that needs matplotlib for the data map and timing plot; the README's usage text calls it sniffROM_new.py. Input is a CSV export from Saleae Logic's SPI or I²C analyzer, with options for 2-, 3- or 4-byte SPI addresses, byte endianness and analyzing only read or only write commands. - Capturing needs a Saleae logic analyzer connected to the flash bus of a device the analyst is permitted to examine; the wiki's Getting Started page points to an external guide for the capture itself. Only data the device accessed during the capture is recovered, and unseen bytes are filled with a padding value; the wiki's boot-time SPI examples captured about 29% and 42% of the rebuilt images. - GPL-3.0 (COPYING). The repository also stores manufacturers' datasheet PDFs for the supported SPI and I²C chips and a commands.xlsx command table; the datasheets remain their vendors' documents. No firmware images or bus captures are committed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Pawn > Linux command-line tool from Google that reads the BIOS/UEFI firmware image out of the SPI flash of Intel-based workstations and laptops. Running as root, it identifies the chipset's LPC bridge over PCI, maps the chipset's root-complex registers through /dev/mem, and reports the flash descriptor regions and the BIOS write- and read-protection settings it finds. It then reads the flash through the SPI controller's hardware sequencing into a single image file, which the README suggests processing further with tools such as UEFITool. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Releases v0.1 and v0.2, published 2017-08-30 and 2017-09-09, each ship a Debian amd64 package with its source; the reviewed main commit, from 2026-02-17, updates dependencies and GitHub Actions and still declares version 0.2. The README states that Pawn is not an official Google product. Builds need Linux on x86_64 (FreeBSD might also work, per the README), CMake 3.31+, GCC or Clang 7+ and Ninja or Make; CMake fetches Abseil, and GoogleTest for tests, at pinned commits. CI builds and runs the unit test on Ubuntu 24.04 and keeps the binary only as a workflow artifact. - Runs as root on the machine whose firmware is read, using I/O-port access to PCI configuration space and /dev/mem. On Linux kernels newer than 4.8.4 the README requires CONFIG_IO_DEVMEM=n or booting with iomem=relaxed; the program's own error message names IO_STRICT_DEVMEM. Only Intel ICH8, ICH9 and ICH10 and 6 to 9 Series chipsets are recognized, the newest being the 9 Series whose datasheet the source cites from May 2014; the BIOS must boot from SPI flash in descriptor mode. - It always reads 16 MiB from flash address 0, so flash beyond that size is not dumped, and failed block reads are ignored; the default output name is bios_via_spi_hs.bin. The repository contains only source, build and Debian packaging files, with no firmware images; a dump is the machine vendor's firmware and keeps the vendor's rights. - Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### EMBArk > Web-based enterprise interface for the EMBA firmware security scanner, which it installs and runs as its scanning backend. In the browser, users upload firmware, configure and follow EMBA scans, open the full EMBA HTML report and a security overview per firmware, and compare results in an aggregated dashboard; results are access-controlled per user and can be archived. The current main branch adds a REST API for upload, scan status and SBOM retrieval, and an orchestrator that distributes scans to EMBA worker nodes reached over SSH. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.3, published 2025-06-24. The reviewed main commit is 941 commits ahead of it and identifies itself as 0.3-630649d1 in VERSION.txt; the REST API and worker orchestrator described here come from that branch. The installation wiki calls the software alpha and strongly recommends a virtual machine, and the README notes that the new tracking application does not work offline and that device, vendor and version tracking is not yet in every dashboard. - The README names Ubuntu 24 LTS as the only supported OS. installer.sh -d installs Docker, pipenv and EMBA and configures the MySQL and Redis containers defined in docker-compose.yml; EMBA is pinned as a git submodule (at review an EMBA commit from 2026-04-07, older than EMBA's latest releases) and runs in its Docker mode, while -s skips it. The wiki suggests 8–32+ GB RAM, 4–16+ CPUs, at least 20 GB of disk (100+ GB recommended) and an isolated network, and EMBA's own requirements also apply. - run-server.sh serves HTTP on port 80 on all interfaces under the default name embark.local, which must resolve through a hosts file or DNS; -a adds names or addresses and -b opens the admin pages beyond localhost. The installer and server script run with sudo, and the server is deployed to /var/www under a dedicated service user. API calls carry an API key in a header or query parameter, and the orchestrator scans an IP range and installs EMBA on workers using SSH credentials the user supplies. - Supply the firmware images yourself; the repository contains no firmware, and its test fixtures are EMBA result exports such as a CycloneDX SBOM and module CSV/JSON files. Scan findings come from EMBA and still need analyst interpretation. CI installs the server without EMBA and runs Django and server tests, linters, ShellCheck and CodeQL, so no firmware scan is part of it. - MIT license, copyright The AMOS Projects and Siemens Energy AG; EMBA and the tools it installs keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### IDAPython Embedded Toolkit > Maddie Stone's IDAPython scripts for triaging and annotating embedded-device firmware images in IDA Pro, presented at RECON Montreal and DerbyCon in 2017. Triage scripts define code and functions from per-architecture prologue and epilogue patterns, mark address ranges as bytes, words or double words and turn unexplored bytes into strings; analysis scripts resolve memory accesses made at offsets from a known base value and add cross-references and value comments, and annotation scripts list CPU port (GPIO) use, tag functions without cross-references as possible dead code and trace where an operand is used. An Android folder adds a script that comments JNIEnv function calls in native libraries and one that decrypts the strings of ARM32 libraries packed with the WeddingCake anti-analysis wrapper. - Type: Tool - Targets: App · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Ten Python scripts and the slides of the two 2017 talks as PDFs, with no releases or tags; the reviewed master commit, from 2019-08-14, is the latest. The README says the scripts have only been tested on IDA Pro 6.95, with IDA 7.0 testing in progress, and runs each one separately through File > Script file in an open IDA database with IDAPython. Most use Python 2 print statements and pre-7.0 IDC calls such as MakeCode, MakeComm, MakeStr and AskAddr; jni_translate.py, added in 2019, uses Python 3-compatible print calls but still calls idc.MakeComm. - The user supplies the firmware image or Android native library and its IDA database, and enters address ranges, regular expressions or base values at prompts or in each script's user-defined section. Processor-specific syntax is chosen from IDA's processor name: define_code_functions.py covers 8051, PIC18, Mitsubishi M32R, TI TMS320C28x and AVR, and find_mem_accesses.py only 8051, while identify_port_use_locations.py ships one active PIC18 pattern with commented 8051 alternatives. Unsupported processors stop with an error until the analyst adds patterns, and find_mem_accesses.py cannot create references into segments that do not yet exist. - Several scripts rewrite the database: define_data_as_types.py first undefines the range, overwriting code or strings there, and WeddingCake_decrypt.py overwrites encrypted strings with their decrypted contents and needs JNI_OnLoad defined and exported. The WeddingCake files accompany Maddie Stone's Black Hat USA 2018 talk on that packer. - MIT, copyright 2017 Maddie Stone, in LICENSE; the README's copyright notice instead names The Johns Hopkins University Applied Physics Laboratory, and the Android README and WeddingCake script carry a Google LLC 2018 copyright line without separate license terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### fiano > LinuxBoot's Go tools and libraries for parsing and modifying UEFI firmware images. Its utk command shows an image's firmware volumes and files as a table or JSON, finds, dumps, inserts, removes or replaces files, and extracts an image into a directory that can be reassembled, with a DXE cleaner for deleting unneeded DXE drivers. Further commands cover flash maps (fmap), coreboot CBFS, Intel FIT tables, FSP headers, microcode and LZMA data, and its Go packages also parse Intel ME regions, Boot Guard and CBnT manifests and AMD firmware structures. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No GitHub releases; the newest tags, v7.0.2 and v6.0.1, both point to commits from 2021-12-01, while main keeps receiving fixes, documentation and dependency updates, the reviewed commit being from 2026-05-14. The README installs utk and fmap with go install at @latest and still says Go 1.13 is required, whereas go.mod declares Go 1.21 and CircleCI uses Go 1.22. - Pure-Go command-line tools; go install places the executables in the go/bin folder of the user's home directory. Input is a firmware image the analyst already has, such as a full flash ROM, and fspinfo supports only FSP 2.0 files. CI checks formatting, runs ineffassign and the unit and race tests, and the Go tests include an extract, reassemble and extract round trip and a JSON regression check on a bundled OVMF image. - BSD-3-Clause, copyright LinuxBoot. Test fixtures include an OVMF.rom built from EDK2's open-source vUDK2018 tag, coreboot ROMs, compression samples and manifest samples, plus two Intel binaries kept under Intel's own redistribution terms with their license files: the Apollo Lake FSP blob Fsp.fd under the FSP License, and the Purley ME Ignition firmware MeRegion.bin for Cascade Lake servers, whose binary-only license forbids reverse engineering that image. - Modification commands rewrite firmware images; the README does not discuss flashing or recovery. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Pyrrha > Quarkslab's firmware cartography tool, which indexes an extracted firmware filesystem into a database browsed with NumbatUI, Quarkslab's fork of the Sourcetrail code explorer. The fs mapper uses LIEF to map ELF and PE files, their imports and exports and the symlinks that point to them; fs-cg disassembles every executable with IDA Pro or Ghidra and links their call graphs across binaries, and decomp indexes one executable's decompiled functions with call cross-references. JSON exports can be post-processed in Python, for example to diff two firmware versions. - Type: Tool - Targets: Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.0.3, published to GitHub and PyPI as pyrrha-mapper on 2026-09-21; the reviewed main commit sets the same version. v2.0.0 (2026-07-07) added the Ghidra backend and removed the earlier Quokka dependency. pyproject.toml marks the package Beta and lists Linux and Windows. - Input is a firmware root filesystem that the user has already extracted or mounted, or a single executable for decomp; Pyrrha does not unpack firmware images. The fs quick start uses an OpenWrt x86-64 rootfs downloaded from the OpenWrt project. - pyproject.toml requires Python 3.11+, although the installation page says 3.10. fs needs no disassembler, but fs-cg and decomp need a local IDA Pro 9.1+ or Ghidra 12.0+, found on PATH or through IDADIR or GHIDRA_INSTALL_DIR; a Ghidra-based Docker image is published on GitHub's registry, and the IDA CI image is built from the user's own Hex-Rays installer and licence. Results are viewed in NumbatUI or, without newer features such as node renaming, Sourcetrail 2021.4.19. - The GitLab CI file runs pytest unit tests and CLI runs of each mapper, with IDA and Ghidra images for fs-cg and decomp; the GitHub workflows only build documentation and publish releases. tests/test_fw is a small 32-bit ARM Linux fixture holding an OpenSSL 1.1.1n executable built with Buildroot and glibc libraries. - Apache-2.0; NumbatUI is a separate GPL-3.0 project, and IDA Pro is commercial software. The README lists SSTIC, Hack.lu, Pass The SALT and RE//verse talks by the authors. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. #### RETracker > Python reverse-engineering framework for the Polyend Tracker music device that patches the vendor's stock firmware, replacing an unused USB RAWHID handler with its own command handler. With the patched firmware flashed, a host CLI reads, hex-dumps and disassembles device memory in ARM or Thumb mode, writes memory, runs code at an address, assembles and executes position-independent "Polyp" modules such as a pad text scroller and screen fades, and copies files to the SD card over USB. Its fwtool.py also unpacks and repacks the Intel HEX .ptf firmware images for loading into a disassembler. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Only Polyend Tracker firmware 1.5.0 is supported; the README says a private 1.6.0 port was not released because Polyend removed the code the patches relied on. The reviewed main commit of 2024-06-19 only announces a discussion thread, the last code change dates from 2022, and there are no releases or tags. - Patching needs the user's own copy of the stock PolyendTracker_1.5.0.ptf image, which the repository does not include, and the patched image is flashed through the device's normal firmware-update menu. The README warns that the update screen behaves differently with patched images, recommends backing up the SD card first and points to the Tracker's emergency update procedure for recovery. - Needs Python 3 with capstone, keystone-engine, pyusb, intelhex and simple-hexdump; the host finds the device over USB by vendor and product ID. The README's reverse-engineering notes treat the hardware as a Teensy 3.6-class MK66FX microcontroller, give the firmware load address and a RAM address used for Polyps, and say IDA Pro, and probably Ghidra or Binary Ninja, can load the Intel HEX image directly. - There are no tests or CI. Behaviour is documented through README examples and a linked demo video. - No license file was found and GitHub detects none, so reuse terms are unstated. Polyend's firmware keeps its own rights, and the README disclaimer places any device damage at the user's risk. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Titan M tools (Quarkslab) > Tools Quarkslab published from its research on Google's Titan M security chip in Pixel phones: a Ghidra loader for Titan M (Citadel) firmware files, nosclient for tracing and sending the chip's protobuf-based commands from Android with a black-box fuzzer built on libprotobuf-mutator, a parser for sigrok SPI captures, and scripts that convert firmware images to the rec files of the chip's SPI rescue feature. The repository also holds the Black Hat Europe 2021 white paper and slides, the ROOTS'21 paper and the Black Hat USA 2022 slides, which describe reverse engineering the firmware, sniffing its SPI communication with the application processor, and black-box and emulation-based fuzzing; the authors say the vulnerabilities they found were disclosed to Google. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A research release with no tags or packages: the last commit, on 2022-08-22, added the Black Hat USA 2022 slides two days after nosclient was updated for that talk. The emulation-based fuzzer those slides describe is not in the repository, and no Titan M firmware images, Boot ROM dumps or keys are committed. - Firmware files must come from the analyst's own Pixel device; the white paper notes that Titan M first shipped with the Pixel 3. Sending commands with nosclient needs root access on the device, as the white paper explains, and the SPI parser expects a sigrok CSV export of the analyst's own capture. - citadelimgloader builds with Gradle against a local Ghidra installation named by GHIDRA_INSTALL_DIR; no supported Ghidra version is stated. nosclient builds with CMake for Linux, for Android arm64 with the NDK, or in the provided Debian 10 Docker image with NDK r21e, after the libnos (AOSP), protobuf, libprotobuf-mutator and sqlite submodules are initialized. - The ROOTS'21 paper reports that the black-box fuzzer rediscovered several known vulnerabilities within seconds and found a new one in the then-latest firmware; these are the authors' results on their own devices. The README says the toolkit also contains an exploit for a known vulnerability. - LICENSE is Apache-2.0. The fuzzer bundles a generated libradamsa.c without its own license notice, the client includes protobuf sources generated from the nugget/app message definitions and small KeyMint enum headers, and the presentation PDFs state no license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### uefi_retool > Python command-line tool and IDA Pro plugin for UEFI firmware reverse engineering. uefi_retool.py unpacks a firmware image with uefi-firmware-parser, collects its executable modules and runs IDA in batch mode on each one, writing their boot-service calls and protocol GUIDs to JSON; a separate command lists protocols whose GUIDs are absent from its EDK2, AMI and vendor GUID tables as proprietary. Inside IDA the plugin applies EFI system-table types and names, lists protocols in an explorer window and, from the JSON, shows a dependency browser and graph across the firmware’s modules. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository is archived. Its last commit (2024-12-28) only updates the README, the last code changes date from 2021-08-03, and the only tag, 1.2.0 from 2020-05-07, is eight commits older; there are no GitHub releases. The tree contains an IDA plugin only and no Ghidra component. - Needs a licensed IDA Pro with IDAPython and PyQt5: copy uefi_analyser.py and the uefi_analyser package into IDA’s plugins directory, then set the IDA and IDA64 executable paths and the module, dump and log directories in config.json, whose example points to IDA Pro 7.6 on Windows. The script uses Python with Click, colorama, terminaltables, tqdm and uefi-firmware-parser 1.8, installed from a tarball named in requirements.txt. - Input is a UEFI firmware image the user supplies; README examples name a ThinkPad X1 Carbon 5th-generation image that the repository does not include, and no firmware images are committed. The analyser recognizes x86 and x86-64 instruction patterns and chooses IDA or IDA64 from each image’s machine type. The bundled GUID tables come from EDK2 and EDK, from ida-efiutils for AMI, and from Dell, Lenovo and ASRock lists, and tools/update_edk2_guids.py refreshes the EDK2 table. - MIT license (2018–2021, yeggor). The repository has no tests or CI. Labels and dependency graphs come from GUID matching and instruction patterns, so they need analyst checking. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Shannon Modem Loader for IDA Pro > IDA Pro loader and post-processing scripts for Samsung Exynos "Shannon" baseband modem images that carry a TOC header, including crash dumps. The loader maps the TOC entries to aligned segments and entry points; after auto-analysis the post-processor restores debug-trace structures, names functions from strings and debug-log calls, rebuilds the MPU table and memory map, comments MMU-related coprocessor instructions, performs the ARM scatter-load with its decompression, and labels platform-abstraction-layer and task-initialization functions. The README adds the author's notes on ShannonOS, the PAL and the move from Cortex-R to Cortex-A cores. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 01.2025, published 2025-01-01; the reviewed main commit of 2025-01-03 only adds IDA Essential 9.0 to the installer's search list. The README calls the code work in progress and reports testing on a larger set of images from older models such as the G8700 and S7 up to the S22 and S24, with task identification working on recent images. - The README reports testing with IDA Pro 9.0, IDA Pro 8.3 to 8.4 SP2 and IDA Home ARM, and says 7.x with the revamped IDAPython API might work. install.sh copies the loader, Python modules and signatures into a Linux IDA installation; on macOS or Windows the files are copied by hand following the README's table. - Users supply a TOC-format Shannon modem image or crash dump; the repository contains no modem firmware. The README reports that a complete analysis takes about 10 minutes on average hardware. - sig/ holds 17 premade FLIRT signature files for ARM Compiler/RVCT runtime functions, from version 3.1 to 5.06u7. The post-processor reads the image's RVCT build string, applies the matching signature, and on Linux offers to use the include directory of a matching legacy ARM compiler installed in the user's home directory. There are no tests or CI. - MIT License. Modem firmware, IDA Pro and ARM compilers keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### EchoMuse: replacement software that turns the Echo Dot 2nd gen into a Home Assistant voice satellite > Replaces the software on an unlocked second-generation Amazon Echo Dot (2016, codename biscuit) so it works as a local Home Assistant voice satellite over the ESPHome API: EchoMuse's own Go firmware drives the microphones, speaker, LED ring and buttons, and a controller on the LAN handles wake words, devices and a dashboard. Its default emOS mode swaps Amazon's Android userspace for the project's own init and busybox while keeping the Dot's kernel from the owner's boot image. An engineering journal records how codec routes, the mute key and other hardware behavior were worked out by measuring the device and diffing the mixer and DAPM state while stock FireOS plays a sound. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed main commit 4bbf7ff (2026-10-27) is in active development. At review the latest stable device firmware is v2.18.1 (2026-10-15) and emOS 0.10 (2026-10-02), the controller add-on declares 2.26.3, and early-access v2.19.0-ea.2 and emos-v0.11-ea.1 builds followed. Only the Echo Dot 2nd gen is supported; README calls ports to the Echo Dot 3, Echo 2 and Echo Show 8 in progress and lists open issues, including no WPA3 on emOS under FireOS 6. - Needs the user's own Echo Dot 2nd gen, first unlocked with third-party tools (firebreak running R0rt1z2's amonet-biscuit); README says this is done at the user's own risk and can soft-brick the device. The setup wizard keeps a copy of the device's own boot partition and builds the emOS image from its kernel and device trees, and emOS mounts bionic and tinyalsa read-only from the device's /system. The emOS README says no bootable image is published because it would contain Amazon's kernel; releases carry the project's own firmware binary, init and userspace payload, and busybox with its source. - Requires a working Home Assistant with an Assist pipeline, an always-on host for the controller as a Home Assistant add-on or Docker container, and Chrome or Edge for the one-time WebUSB setup. Source builds use the project's Docker compiler image for the Go device firmware, Python 3.12 for the controller, and emos/build.sh, whose release workflow compiles the init with a pinned Android NDK. - CI runs the controller pytest suite with coverage floors, dashboard and Go device tests, dependency audits and image builds, and the journal and acceptance-test reports describe runs on the maintainer's own devices. It does not reproduce Alexa, and no Amazon software or service is recovered. - MIT, with vendored SpeexDSP (BSD-3-Clause), an ONNX Runtime header, aioesphomeapi protocol buffers and a CC BY 4.0 timer sound listed in NOTICE.md; the project states it is not affiliated with Amazon. README says EchoMuse is written largely with Claude, directed by the maintainer, and that more than half the commits carry a Co-Authored-By: Claude line. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### IMSProg > Qt desktop programmer that reads, writes, erases and verifies I2C, SPI and MicroWire EEPROMs, FeRAM, DataFlash and SPI NOR/NAND flash chips through low-cost CH341A, CH347T and FT232H USB programmers. It identifies SPI flash by JEDEC ID against an editable chip database, shows SFDP, status and security registers, scans NAND bad blocks, and keeps the chip image in a hex-editor buffer that can save or load parts of the image and import or export Intel HEX. Companion programs edit the chip database and update it from the author's web server. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.9.1, published 2026-09-04 with a Flatpak and a macOS arm64 build; the ChangeLog says it added FT232H v1.2 support. The reviewed main commit is 41 commits ahead, mostly macOS packaging and path fixes. README lists Debian, Fedora, openSUSE, AUR, ALT, ROSA and RED OS packages and an Ubuntu PPA; a Windows build is maintained separately by a third party. - Builds with CMake, g++ or clang, Qt5 or Qt6 with the Linguist tools, libusb 1.0, libftdi, pkg-config and udev on Linux, where README says Debian before 11 and Ubuntu before 20.04 are unsupported, or with Homebrew packages and the Xcode command-line tools on macOS. build_all.sh compiles and installs the programmer, database editor and updater with the udev rules and chip database. CI builds Ubuntu 22.04, 24.04 and 26.04 DEB packages, a Fedora 44 RPM checked with rpmlint and a macOS 15 build; no automated tests are published. - Needs one of the supported USB programmers and, per README, adapters for 93xxx MicroWire, 45xxx DataFlash, WSON-8 SPI NAND and 1.8 V chips. CH347 devices do not support MicroWire, and Verify and Check erase do not skip bad blocks on NAND chips. Images come from the user's own chips; the repository holds no firmware dumps, only its IMSProg.Dat chip database, which the updater downloads from the author's antenna-dvb-t2.ru site. - GPL-3.0-or-later per README, with SNANDer-derived parts under GPL-2.0+, QHexEdit2 under LGPL-2.1 and CH347 code under BSD-1-Clause. IMSProg transfers chip contents only; analysing a dump needs other tools. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### rbasefind > Multithreaded Rust command-line tool that brute-forces the load address of a flat 32-bit firmware image, reimplementing mncoppola's basefind.py and rsaxvc's basefind.cpp. It records the offsets of ASCII strings, reads every 32-bit word as a possible pointer, and ranks candidate base addresses by how many strings each one would turn into pointer targets. The README calls it a simple heuristic that works rather well on some ARM (non-Thumb) binaries and will not work miracles. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest tag at review: v0.1.3, on the reviewed master commit of 2020-09-27, with no GitHub release binaries and no crates.io package. Build it from source with Cargo; Cargo.toml declares no edition and Cargo.lock is ignored, so dependencies such as clap 2.33 and regex 1.3 resolve within their version ranges at build time. The README's TODO lists an automatic mode that would detect endianness and narrow the offset around the best match. - Input is a flat 32-bit image supplied by the user, little-endian by default or big-endian with -b; no firmware or samples are included. By default it takes NUL-terminated printable ASCII strings of at least 10 characters, reads 4-byte-aligned words from the start of the file as pointers, and tests candidate bases every 0x1000 bytes across the 32-bit address space, splitting the range across one thread per CPU core. The whole file is loaded into memory. - Results are a ranked list of candidate bases with match counts, 10 by default, that the analyst must confirm. The README's example takes about 41 seconds on 8 threads for one image and shows that raising the minimum string length to 100 cuts the time at some cost in accuracy. Unit tests cover only the address-range split between threads, and there is no CI. - MIT License (2017, Scott Gayou). Analyzed firmware keeps its own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Aptio V UEFI Editor > Browser-based editor for the setup menus of AMI Aptio V UEFI firmware, offered as an alternative to AMIBCP. From four sections the user takes from their own BIOS image, it rebuilds the setup forms and their references and shows each setting's VarStore, offset, size, options, failsafe and optimal defaults, access level and Suppress If conditions. Changes to top-level menu targets, suppressions, access levels and defaults are written back into the section files with a change log, and a session can be saved as hash-checked JSON; a separate IFR-Formatter.js script condenses IFRExtractor-RS output into a per-setting VarStore and offset listing. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed master commit 44e8c9b (2026-03-15, hash-check changes); the previous source change was in April 2025. There are no releases or tags: the app, version 0.1.0 in its source, is served from GitHub Pages by a workflow that builds it with Node 20, npm ci and Vite. Building locally uses the React, Mantine and TypeScript package.json scripts. - Inputs come from the user's own Aptio V UEFI image, found with UEFITool NE: the Setup PE32 image section, its text output from IFRExtractor-RS 1.6.1 (the only version the editor accepts), the AMITSE PE32 image section and the setupdata body. The page reads them in the browser, rejects non-UEFI IFR output, and checks saved JSON against the files' SHA-256 hashes. The repository includes no firmware images or extracted sections, only screenshots of the tools. - README says the modified files are put back with UEFITool 0.28.0 and that setting visibility methods vary between firmware, so either may need trying. - The repository has no license file, and package.json marks the package private, so reuse terms are not stated. No automated tests are published. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### FirmLoader > IDA plugin that applies a microcontroller's memory map to a raw firmware image: once the analyst picks an MCU model, it creates RAM and other memory segments, adds peripheral segments with named registers and, where a vector table is described, labels its entries and turns the handlers they point to into functions. The README compares it to IDA's built-in SVD loader, but it uses a simpler JSON description that can be written by hand from public datasheets. The reviewed commit bundles 813 descriptions for Microchip/Atmel, ST, NXP, TI, Silicon Labs and other MCUs. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The only release is tag 1.0, titled “IDA 8.X” and published 2024-12-05; it points to a February 2024 commit. The reviewed main commit 5c9c1a1, the last change on 2024-12-05, is four commits ahead: a contributed pull request adds IDA 9.0 support and another adds an STM32L4x1 SRAM2 segment. - Installed by copying firmloader.py and the firmloader_data folder into IDA's plugins directory; it needs IDA with IDAPython, and the plugin code uses Python 3.8+ syntax. The analyst loads the image at the base address the processor documentation gives, renames the main code segment to ROM and chooses the model under Edit > FirmLoader; applying it marks the ROM segment for IDA auto-analysis. - Input is a firmware image the analyst has already read out of a microcontroller; the repository contains no firmware, only the plugin, MCU description JSON files, a data_template.json and two README images. Of the 813 descriptions, 812 are 32-bit; the 16-bit ATmega328 one lists no peripherals, and four for SPC5 and AURIX TC27x parts have no vector table; README says that where a series has several memory sizes, every unit was generated with the largest RAM. Other MCUs need a hand-written description. - Apache-2.0. README names SPC560B64x as a purely hand-written description and otherwise presents the files as a supplement to SVD data without documenting how they were generated. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### IFDA (IoT Firmware Deep Analysis) > Static analysis pipeline for extracted IoT firmware: pointed at one ELF or an unpacked root filesystem, it disassembles binaries with Capstone for x86, ARM/Thumb-2, AArch64 and MIPS, recovers functions, call graphs and exploit mitigations, and reports candidate issues from dangerous-function calls, call-graph taint paths, CVE correlation through cve-bin-tool, embedded secrets, script injection patterns and filesystem hardening checks. Reports come out as JSON, Markdown and a CycloneDX SBOM. Optional add-ons are Ghidra headless pseudocode, moria-based extraction of raw images and a Go service with a job queue, REST API, bilingual web UI and an LLM agent that triages a finished scan's findings. - Type: Tool - Targets: Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit 90c11c2 of 2026-09-21 is the 29th since the project began on 2026-06-10. CHANGELOG calls it v4.4, while the latest tag is V4.1, five commits earlier, there are no GitHub releases and pyproject.toml still declares 2.0.0. README describes a first iteration covering binary reverse engineering and vulnerability discovery; emulated or dynamic validation is listed as planned, not built. - The Python 3.10+ core needs capstone, pyelftools, cryptography, Pillow and cve-bin-tool, which README calls required: it keeps a local CVE database of 1 GB or more and needs network access on first use, and without it correlation falls back to a small curated database with a warning. Optional parts are yara-python, Ghidra headless with JDK 17+ for pseudocode, CuPy for GPU chart rendering, the Go 1.22+ service for the REST API and web UI, and the moria submodule, built with CMake and a C++20 compiler, for unpacking raw images. Linux and macOS are supported; Windows only through WSL2. - Input is a single ELF, an extracted firmware tree or, through the service's extract job, a raw image whose filesystem region the analyst chooses. README and the requirements document limit use to firmware the operator owns or is authorized to assess. The repository contains no firmware; its tests build cross-compiled x86_64, MIPS, ARM and AArch64 samples, and README reports 25 passed and 2 skipped with cross-compilers and Ghidra installed. - README calls decompilation-free static analysis heuristic: findings carry confidence scores, and taint results are candidate paths for analyst validation, not proven exploits. The optional AI analysis sends a finished scan to an OpenAI-compatible or Anthropic-protocol endpoint the user configures, storing API keys encrypted; the model pulls finding evidence, pseudocode, init scripts and service data through tools. README says these features were tested with Claude models. - Apache-2.0, added on 2026-09-17; cve-bin-tool (GPL-3.0) is only invoked as a subprocess, and moria is MIT. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### basefind2 > Python script that estimates the load address of a flat 32-bit little-endian firmware image without brute-forcing every candidate base, building on mncoppola's basefind.py and rbasefind. It searches the gaps between sorted pointer values for a run of consecutive gaps between string offsets, takes each match as a candidate base, and scores it by the share of sampled strings whose rebased address also appears as a pointer. The README's example finds the correct base of one image in about 26 seconds. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The whole tool is basefind2.py; the reviewed main commit of 2022-05-02 is the last of six commits made between 2022-04-07 and 2022-05-02, and there are no releases, tags or packages. It needs only Python 3 and its standard library. - Input is a flat image supplied by the user; no firmware or samples are included. Pointers are read as little-endian 32-bit words at 4-byte alignment, with no big-endian or 64-bit option. Strings are runs of at least 10 printable ASCII characters, tabs or line breaks (-sl), a match needs 10 consecutive gaps by default (-dl), and scoring samples every 20th string (-s). The whole file is read into memory. - Output lists each candidate base with its sampled match percentage, and the analyst must choose and confirm one. The README's only example raises -dl to 40 and reports the correct base of one image at 81.64% after about 26 seconds. There are no tests or CI, and the README gives no comparison with rbasefind or basefind.py on shared images. - MIT License (2022, soyer). Analyzed firmware keeps its own terms. ##### Primary sources 1. 2. 3. 4. #### JTAGulator > Joe Grand's open-source hardware tool and Parallax Propeller firmware for locating on-chip debug interfaces among an unfamiliar board's test points, vias, component pads or connectors. Driven from a serial terminal, its 24 level-shifted channels try pin permutations to identify JTAG pinouts by IDCODE or BYPASS scans, SWD pinouts by IDCODE and UART pinouts with their baud rates. With a known JTAG pinout the firmware can also read device IDs, discover instruction and data registers and map a chip's pins to boundary-scan positions with EXTEST, and other modes pass UART traffic through, act as a SUMP-compatible logic analyzer or emulate a Bus Pirate so OpenOCD can use the board as a JTAG adapter. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Firmware 1.12, tagged 2023-06-05, is the newest version; the repository publishes tags but no GitHub releases, and the README calls master a development branch whose interim commits may be unstable. Later commits, up to the reviewed one of 2026-09-02, update links and the license text and add the Rev. C hardware design files, and since July 2025 the README names EXPLIoT as maintainer and supporter. - Requires JTAGulator hardware, for which the repository commits the Rev. C design files (Altium project, Gerbers, schematic, bill of materials, assembly drawing and test procedure), a serial terminal on the host and physical wiring to the target's candidate pins. The target I/O voltage, 1.4–3.3 V, must be set before scanning, and the firmware warns that use may affect target behavior; it also warns that its front-end circuitry is incompatible with many SWD-based targets and points to hardware modifications described in the wiki. - The firmware is Spin code for the Propeller P8X32A: the README recommends Propeller Tool 1.3.2 for Windows and calls other environments untested and unsupported, while also giving OpenSpin and PropLoader commands for compiling, loading to RAM or writing to EEPROM. The repository commits the compiled image JTAGulator.eeprom (32 KB), last updated for 1.12. The OpenOCD and logic-analyzer modes need OpenOCD's Bus Pirate driver or an Openbench Logic Sniffer client, and both persist across resets and firmware updates until exited manually. - The README distributes the design under CC BY-SA 4.0 and says the JTAGulator name and logo are registered trademarks of Grand Idea Studio that may not be used on derived works without permission; the Spin source headers still state CC BY 3.0 United States, and GitHub detects no license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### BIOSUtilities > Python collection of 16 parsers and extractors for vendor BIOS/UEFI update formats, including AMI BIOS Guard (PFAT) and UCP, Dell PFS, Insyde iFlash/iFdPacker, Phoenix TDK Packer, Award, Fujitsu, Panasonic, Portwell, Toshiba and VAIO packages and several Apple EFI containers. Each utility checks whether an input matches its format and unpacks the firmware components, such as SPI/BIOS/UEFI, EC and ME images, plus bundled utilities into an output folder, optionally reporting structure information; an Apple EFI identifier names images from their IBIOSI tag. A main.py script tries every utility on the given files, and the biosutilities package exposes the same classes to Python. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest version at review: 25.07.01, published on PyPI as 25.7.1 on 2025-07-01. The reviewed main commit adds one later change, from 2026-10-18, that falls back to the system PATH when a tool is missing from the external folder. The README targets Python 3.10 to 3.13 on Windows, Linux and macOS; pyproject requires Python 3.10+ and offers pefile 2023.2.7 and dissect.util 3.20 as pinned extras. - Several utilities call external programs found on PATH or in an external folder next to the package: 7-Zip, UEFIFind and UEFIExtract from UEFITool, TianoCompress from EDK II and ToshibaComExtractor. The README says comextract must be compiled from source on Linux and TianoCompress on Linux and macOS. Decompiling Intel BIOS Guard scripts optionally uses the author's separate BIOS Guard Script Tool. - Users supply the vendor update executables, packages or images they already have. The repository holds only Python source, documentation and packaging files, with no BIOS images, sample packages or tests. The README warns that AMI PFAT components may have no explicit order, so the merged 00 -- ALL file usually is not a proper SPI/BIOS/UEFI image and trailing OEM data is left for the user to assess. - BSD-2-Clause-Patent, per LICENSE and pyproject. The README presents the collection for research and modding; extracted firmware remains under its vendors' terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### allyourbase > Python script that estimates a firmware image's base address by comparing string addresses with the targets of every possible pointer, for any pointer size and either endianness. Instead of trying each base in turn, it computes the overlap as an FFT cross-correlation modulo several pairwise-coprime numbers and recovers the base with the Chinese remainder theorem, which keeps 64-bit address spaces tractable. The author keeps it small so that analysts can swap in their own heuristic, such as matching absolute call targets with the instructions that follow returns. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The whole tool is allyourbase.py; the reviewed main commit of 2025-03-07 only added comments to code written in April 2023, and there are no releases, tags or packages. It needs Python 3 with NumPy (requirements.txt: numpy>=1). - Input is a raw image supplied by the user; no firmware or samples are included. -l, the pointer length in bytes, is required; -e selects endianness (little by default), -a the alignment (the pointer length by default), -n the minimum string length in code points (5 by default) and -f a slack factor that trades speed and memory for accuracy. Only NUL-terminated UTF-8 strings count. The README says memory grows linearly with file size with a high constant factor, so images of tens of megabytes are the practical range. - It prints a single best offset, which may be negative, or reports that none was found; there is no candidate ranking or confidence score, and the README models stray pointer matches as noise that the slack factor lowers. The README's only example runs on /usr/bin/ls rather than a firmware image. There are no tests or CI. - MIT License (2023, 8051Enthusiast). Analyzed firmware keeps its own terms. The README calls it similar to rbasefind but gives no comparison on shared images. ##### Primary sources 1. 2. 3. 4. #### ghidra_kernelcache > Ghidra script framework for reverse engineering Apple kernelcaches and kernel extensions on iOS and macOS. Starting from the C++ class information that Siguza's iometa extracts, it symbolicates the kernel, rebuilds IOKit class hierarchies, structures, namespaces and virtual tables with typed method definitions, and resolves virtual call references, either through arm64e pointer-authentication constants or with a p-code data-flow pass. Other scripts fix the externalMethod and getTargetAndMethodForIndex dispatch tables, apply XNU function signatures from header files, propagate types, load KDK DWARF symbols and copy structures between projects. - Type: Tool - Targets: Binary · Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags. The reviewed master commit, from 2022-01-19, is the latest. The README says the framework works on iOS 12–15 kernelcaches and on macOS 11–12 kernelcaches and single KEXTs (arm64e and x86_64). It was tested on Ghidra 10.1_PUBLIC and 10.2_DEV and is not backward compatible. Support for later Ghidra releases or for kernelcaches after iOS 15 and macOS 12 is not documented. - Installation means adding the clone to Ghidra's Script Manager directories; the scripts then appear under iOS→kernel with toolbar buttons and key shortcuts. They are Ghidra Jython scripts with Python 2 syntax. Their toolbar icons point to a logos/ folder that the repository does not include, and the README's utils/class.py corresponds to utils/ios_kc.py in the tree. - Analysts supply their own kernel images: a decompressed iOS kernelcache loaded as a single Mach-O image (the README warns against batch import), or a macOS kernel and KEXTs from their own system or KDK. Symbolication first needs the output of Siguza's separate iometa tool (MPL-2.0), which describes itself as an arm64 Darwin class dumper; jtool2 symbols are optional. The README notes that Ghidra could not parse a whole macOS kernelcache at the time and suggests initial analysis in IDA followed by an XML import, a step it leaves out of scope. Symbolicating a single KEXT first needs the kernel symbolicated into a shared Ghidra project archive. - The repository holds only Python scripts, the C++ signature files under signatures/ and README screenshots; it commits no Apple kernelcaches, KEXTs or keys. The README calls type propagation basic and likely to fail with complex casts, and says kc.process_kernel_kext() can fail on symbols Ghidra could not demangle until DemangleAllScript is run. Apache-2.0 license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### esp32_image_parser > Tenable's Python command-line tool, described in its repository as a toolkit for reverse engineering ESP32 firmware, that reads the partition table of an ESP32 flash dump and rebuilds an app partition such as factory or ota_0 as an Xtensa ELF file. Other actions list the partitions, dump a partition's raw bytes and parse an NVS partition's key-value entries as text or JSON; create_elf loads the app image with esptool, maps its flash, DRAM and IRAM segments to ELF sections and adds symbols from a bundled ROM symbol table. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No commits since 2020-02-29 and no releases or tags. Setup is pip install -r requirements.txt, which lists makeelf, esptool and hexdump without versions; the script imports esptool's module namespace and calls its LoadFirmwareImage for the original esp32 chip type. - Input is a full flash dump from the analyst's own device. The parser reads the partition table at the default 0x8000 offset, and create_elf accepts only app-type partitions and needs an output file name; segments it cannot map, such as RTC IRAM, are reported rather than converted. - The repository commits no firmware images: besides the Python scripts it holds symbols_dump.txt, a readelf-style table of about 890 symbols mostly at ESP32 ROM addresses, which create_elf reads from the current working directory into every ELF. MIT licensed (LICENSE.md). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Tigard > Open-hardware board built around the FTDI FT2232H that connects a computer to a target device's UART, SPI, I2C, JTAG and SWD interfaces through level shifters that operate from 1.8 to 5.5 V. One of the chip's two ports is dedicated to UART and the other is shared by the remaining interfaces; switches select the reference voltage and the SPI/JTAG or I2C/SWD wiring, and a logic-analyzer header lets an external analyzer watch the traffic. Tigard has no software of its own: it is designed to work with existing x232H tools, and the README gives settings for reading SPI flash, JTAG debugging with OpenOCD or Black Magic Debug, SWD debugging with OpenOCD, boundary scan, and iCE40 or AVR programming. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a Tigard board, bought assembled from the sellers the README lists (Crowd Supply, Mouser, 1BitSquared and SecuringHardware.com) or built from the published design, plus physical access and wiring to the target. The README's hookup sequence starts with the voltage switch on VTGT and distinguishes target-powered, Tigard-powered and self-powered setups; for in-circuit SPI work it says to make sure no other device is communicating with the flash chip. - master holds the v1.1 design files for KiCad 5 (schematic, PCB, footprints, 3D models and a render), unchanged since release v1.1 of 2021-09-21 apart from README and .gitignore updates; the newest commit, from 2026-10-08, adds Black Magic Debug to the README. Release v1.2, published 2026-05-29 from a separate v1.2 branch, moves the design to KiCad 9 and attaches Tigard_v1.2.zip, and its notes state no functional difference from v1.1. The repository contains no firmware or host software. - Host tools are separate projects with FT2232H support: USB-serial drivers for UART, flashrom, pyftdi or libmpsse for SPI and I2C, OpenOCD (the README's JTAG and SWD configurations need v0.12+), Black Magic Debug, UrJTAG and the commercial, Windows-only TopJTAG for boundary scan, iceprog, and avrdude, which has built-in Tigard support from 7.1. The README notes FT2232H limits for I2C (controller mode only, no clock stretching, possible conflicts with other controllers) and reports that UrJTAG runs TCK about five times faster than requested. - CC-BY-SA 4.0 (LICENSE.txt, copyright 2020 Franklin Harding), which GitHub does not classify. The README encourages home-built boards but asks their makers to use another color, accurate USB manufacturer descriptors and serial numbers without the TG prefix. Data read from a target keeps its owner's rights. ##### Primary sources 1. 2. 3. 4. 5. 6. #### UBI Reader > Python module and command-line scripts that read UBI and UBIFS images, including ones inside raw NAND dumps, by locating the first UBI or UBIFS data in a file. They extract files or whole UBI and UBIFS images, list and copy single files, display UBI headers, volume tables and the UBIFS super and master nodes, and search physical erase blocks when debugging failed extractions. ubireader_utils_info also derives the mtd-utils parameters, written as a shell script and config file, needed to rebuild an image to the same specification. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main commit 5f45e50 (2026-09-13). The latest release is 0.8.16, published on 2026-09-04 on GitHub and as the ubi-reader package on PyPI; pyproject lists ONEKEY and Jason Pruitt as authors, and unblob's reviewed main commit depends on ubi-reader>=0.8.15. The README's separate testing branch, with repair tools and parameter overrides for broken images, was last updated in 2018. - Requires Python 3.10+, installed from PyPI or from source with Poetry; dependencies are lzallright for LZO, zstandard and cryptography. Creating special files during extraction needs root, and socket files are skipped unless settings.py is changed. Files encrypted with an fscrypt v1 policy are decrypted only when the user supplies the master key. - Input is a UBI or UBIFS image or NAND dump that the user supplies. The repository commits no firmware or flash images; its only test checks the guard against path traversal in extracted file names, and CI runs it with pytest on Python 3.10. - Known issues in the README: the journal is not replayed, so uncommitted data is not recovered, and depending on how the NAND was dumped the data bits may not be error-corrected. Offsets and PEB or LEB sizes can be given when guessing fails. GPL-3.0 (LICENSE; pyproject says GNU GPL); extracted firmware contents keep their vendors' rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### payload-dumper-go > Go command-line tool and library that extracts partition images from Android A/B OTA payloads, reading either a raw payload.bin or the OTA zip that contains it in place. It decompresses operations in parallel, can list partitions or dump only selected ones, and verifies operation data, source images and final images with SHA-256, exiting non-zero on any mismatch. Incremental (delta) payloads are applied onto previously extracted base images, and it regenerates the dm-verity hash tree and FEC parity that delta payloads omit, so the README reports bit-exact output. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2.1.0, published 2026-09-23 and identical to the reviewed main commit, with prebuilt binaries for Linux (amd64, amd64 AVX2, arm64, armv7), macOS (amd64, amd64 AVX2, arm64) and Windows (amd64, amd64 AVX2, arm64) and a checksum file; the README also lists a Homebrew package. The changelog says macOS builds need macOS 13 or later since 2.0.2 moved to Go 1.27. The README requires xz on the system because decompression uses the C xz library through cgo; the Dockerfile builds with CGO and liblzma-dev. - Input is an OTA zip or payload.bin the analyst supplies; an incremental OTA also needs the base images extracted from the matching earlier full OTA, passed with -old. The README says PUFFDIFF, ZUCCHINI and LZ4DIFF delta operations are not supported yet, so affected partitions, usually system, product or system_ext, fail with an error while the rest can be extracted with -p; images written with -no-fec skip FEC and final verification and must not be flashed. - The repository commits no OTA images: its tests build synthetic payloads, and two opt-in tests read a real payload path from environment variables (E2E_PAYLOAD, DBG_PAYLOAD). The payload format follows AOSP's update_metadata.proto. Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### mithril > Offline C++ scanner for the contents of firmware and IoT software, pointed at a single file or an already unpacked root filesystem, that reports embedded secrets, a software bill of materials, known CVEs, open-source licenses, boot-security configuration and weak or publicly known keys, each finding with its evidence and a confidence level. Its SBOM also recovers components from ELF version banners, libc filenames and the kernel banner in stripped images and is written as CycloneDX and SPDX, while the CVE pass joins it against a local OSV and NVD mirror annotated with CISA KEV and EPSS. It does not unpack images; the author's companion tool moria handles identification and extraction. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A young, fast-moving project: the repository was created on 2026-09-07, and v0.4.0, published 2026-10-22, is the latest release at review, with Linux x86_64 and arm64 and macOS arm64 archives plus Debian packages for amd64 and arm64; the reviewed commit is the merge of that release. - Source builds need CMake 3.20+ and a C++20 compiler and link no third-party libraries; flake.nix, package.nix and Debian packaging are included. Input is a firmware file or a directory already extracted by moria or another unpacker; the --boot pass also reads a raw AMI or EDK2 BIOS image to report UEFI Secure Boot posture. - Scans make no network calls. The CVE pass needs a local mirror in .local/share/mithril under the home directory (or $MITHRIL_DB), downloaded once with --fetch-db from the project's weekly rebuilt db-latest release and checked against published SHA-256 sums (needs curl), or rebuilt from OSV.dev, NVD, CISA KEV, EPSS and the optional kernel.org feed with --update-db. README notes that the kernel checklist is curated rather than exhaustive, so an empty kernel result does not mean the kernel is clean, and that secret findings are well-formed matches, never confirmed live credentials. - The compiled-in key corpora are built from public keys and certificates vendored under data/: the public halves of rapid7 ssh-badkeys, the Vagrant insecure public key, eMudhra intermediate CA certificates, AOSP test-key public halves and the PKfail AMI test Platform Key certificate. THIRD_PARTY.md states that no private-key material is stored, and the key tests generate their keys with openssl at run time. - MIT; the vendored key data keeps its upstream MIT or Apache-2.0 terms, and the mirrored vulnerability feeds belong to their sources. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### img4tool > tihmstar's command-line tool and C++ library for Apple's IMG4 firmware container format. It prints the ASN.1 contents of IMG4 files, IM4P payload containers and IM4M signing manifests, including payload types, descriptions and key bags, and extracts IM4P or IM4M parts from IMG4 or SHSH files and payloads from IM4P files, decompressing LZSS or BVX2 (LZFSE) data and decrypting it when given an IV and key. It can also check an IM4M ticket or a signed IMG4 against a BuildManifest, convert IM4M files to SHSH, and build or rename containers for restore tooling. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: build 218, published 2026-01-29, which provides the CI's macOS and Ubuntu buildroot archives rather than packaged installers. The reviewed master commit (merged 2026-08-20) is two commits ahead of it, merging a fix to the generator argument. The version number is the repository's commit count. - Source builds use autoconf, automake, libtool and pkg-config with a C++11 compiler and require tihmstar's libgeneral. libplist-2.0 (for SHSH reading, verification and conversion) and a crypto backend (OpenSSL, or CommonCrypto on macOS) for decryption and payload hash checks are optional; without one, decryption fails and verification warns that it cannot check payload hashes. BVX2 support needs Apple's libcompression or liblzfse, and an optional libfwkeyfetch build adds a key-lookup option. - Input files are the user's own IMG4, IM4P, IM4M or SHSH files and BuildManifests. The repository is source only and commits no Apple firmware, tickets or keys, and decrypting a payload requires an IV and key that the user supplies. The bundled LZSS decoder (lzssdec.c) is adapted, per its header, from Jonathan Levin's joker code. - LGPL-3.0 license. Container creation, renaming and the IM4R generator option exist for restore workflows. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### payload dumper > Python script that extracts the partition images, such as boot.img and system.img, from the payload.bin inside an Android OTA update package. It handles full OTAs directly and incremental OTAs with --diff by applying the update to original images that the user copies from a full OTA or dumps from the device, and it can also run from a Docker image. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.6 or later with the protobuf package from requirements.txt; the user supplies the OTA package's payload.bin. The README says the script was tested on Yandex Amber OTAs, both full and incremental, under Linux and may also work on Windows. - **Scope:** The repository has no releases, and the reviewed master commit dates from 2025-04-18. - **License:** The repository has no license file and GitHub detects no license. ##### Primary sources 1. 2. 3. #### PMCA-RE RELOADED > PMCA-RE RELOADED is a Rust desktop and CLI toolkit for Sony cameras that includes experimental analysis of where menu settings reside in camera settings memory. It also parses firmware files, backup images and usage logs offline, and provides USB access to camera information, apps, firmware updates and settings. Supported operations depend on the camera generation. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows, macOS or Linux and a supported Sony camera connected by USB for device operations. - **Prerequisites:** App installation, settings memory and function analysis require user-imported key material. - **Limits:** Function analysis is experimental; firmware flashing is reported on one camera and unconfirmed on other models. - **License:** MIT license. ##### Primary sources 1. 2. #### OSIRIS: replacing Onkyo receiver firmware through MCU protocol research > OSIRIS replaces the DSP-board software of Onkyo TX-NR515 and TX-NR717 receivers with its own boot loader, Linux services and DSP code. The project documents the SPI exchange between the main MCU and DSP board, including 1032-byte transfers, frame structure and command meanings recovered from stock firmware and logs. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An Onkyo receiver with a D830 or OMAP-L137 DSP board; installation requires a DSP-board serial connection and BOOT-pin switching. - **Limits:** The README reports TX-NR717 working and TX-NR515 working with incomplete testing; DTS, Spotify, internet radio and DLNA are unfinished. - **License:** Original OSIRIS code is BSD-2-Clause; bundled upstream components retain the licenses stated in the README. ##### Primary sources 1. 2. #### ThisFirmwareDoesNotExist > ThisFirmwareDoesNotExist maps Arturia MicroFreak firmware 5.0.0.2084 and provides freakpatch to modify a user's official update file. Its notes cover the update format and firmware subsystems, while Ghidra scripts and assembly sources support the documented patch locations. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.11 or newer and the official MicroFreak 5.0.0.2084 .mff update file are required. - **Limits:** Some MIDI CC assignments may interfere with an untested stock function. - **License:** MIT license. ##### Primary sources 1. 2. #### Virtual MPC Sample: rehosting Akai MPC Sample firmware in QEMU > Virtual MPC Sample rehosts Akai MPC Sample 1.3.0.12 firmware in QEMU using a custom lab kernel and a browser panel for the device controls. The repository documents firmware and device architecture, emulates the panel's UART communication and provides a shell, tracing and mod testing against the user's own firmware files. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires the user's own MPC Sample 1.3.0.12 firmware partitions; the factory library additionally requires the user's own device. - **Prerequisites:** Requires QEMU 9 or later, Docker for building, Python 3.9 or later and an OpenSSH client. - **Limits:** USB audio, other firmware versions and a Windows test run remain unfinished. - **License:** MIT licence, except Linux kernel patches under GPL-2.0. ##### Primary sources 1. 2. #### OpenJooki: replacing the Jooki 2 software and recovery path > OpenJooki replaces the Jooki 2 music speaker's embedded Linux core and provides phone-based control, updates and SD-card recovery. Its technical notes map the device's Ingenic Linux and ESP32 split, storage partitions, Mender update slots and recovery behavior, while the repository contains the replacement Lua services and installer tooling. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Jooki 2 device is the target hardware. - **Scope:** The replacement system is installed on the device's SD-card based embedded Linux environment. - **License:** MIT license. ##### Primary sources 1. 2. #### intel_ma > intel_ma inspects PC management firmware in ME/TXE/CSME region images and full SPI dumps. Its Rust library and CLI parse partition tables, AMD PSP directories, UEFI firmware volumes and FIT records, and report Boot Guard, BIOS Guard and descriptor locks. It can also remove selected Intel ME components and set documented disable flags in an output image. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A compatible firmware region image or full SPI dump is required for image analysis. - **Prerequisites:** The source lists x86_64 Linux and FreeBSD/amd64; live ME probing is Linux only. - **Limits:** AMD PSP support is inspection only. - **License:** GPL-3.0-or-later. ##### Primary sources 1. 2. #### Stickwalker: porting Pokéwalker firmware to the Stick S3 > Stickwalker ports a matching reconstruction of Pokéwalker firmware to the M5Stack Stick S3. The repository includes firmware source, build tooling and placeholder artwork; users can build with artwork extracted from their own ROM, and a BPV10NF photodiode supplies infrared reception. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An M5Stack Stick S3, BPV10NF photodiode and USB-C data cable are specified. - **Prerequisites:** Original graphics require artwork extracted from the user's own ROM; downloads use placeholder artwork. - **License:** MIT license. ##### Primary sources 1. 2. #### qemu-rtd2841 > qemu-rtd2841 adds a Realtek RTD2841/RTK284x TV machine model to QEMU for bare-metal diagnostics and local firmware experiments. Its board profile models AArch32 Cortex-A53 cores, GICv2, timers, SDHCI, Ethernet, UART, and a framebuffer, with diagnostic assembly and a staged test runner. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Build against the pinned QEMU revision with the RTD2841 patch and the documented host toolchain. - **Prerequisites:** Linux boot requires a compatible local RTD2841 zImage and composite eMMC image. - **Limits:** The author reports that public tests cover bare-metal and synthetic storage tiers; full Android init and framework services remain open. - **License:** GPL-2.0 license. ##### Primary sources 1. 2. #### sony-bravia-linux: pre-Android BRAVIA platform and media behavior > sony-bravia-linux investigates the Linux-based, pre-Android Sony BRAVIA platform and reconstructs selected media and portal behavior for owner-run services. Its documentation records observations from 2011–2012 AZ1, AZ2 and AZ3 sets, including remote input, browser media handling and 3D signalling. The repository also contains tools for H.264 3D SEI and related media workflows. - Type: Case study - Targets: Firmware - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The documented platform scope is 2011–2012 pre-Android Sony BRAVIA AZ1, AZ2 and AZ3 chassis families. - **Testing evidence:** The author reports testing media behavior on two owned TVs. - **License:** The main LICENSE file is GPL-2.0; the README also identifies separate licences for parts of the repository. ##### Primary sources 1. 2. #### MS4X > MS4X analyzes Siemens MS42 and MS43 engine-control firmware for BMW M52TU and M54 engines. Its Python tools disassemble and assemble C166 instructions and inspect image checksums, stock-code differences and TunerPro patchlists; companion documents cover memory maps and findings in the factory programs. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3 and a user-supplied MS42 or MS43 image. - **Limits:** New material is paused; the author says error reports are still addressed. - **License:** Code is Apache-2.0; documents and data are CC BY-SA 4.0. ##### Primary sources 1. #### AC46 Firmware Tool > AC46 Firmware Tool unpacks firmware images for JieLi AC4600/BT15 devices. It accepts a dumped flash image or a BFU file with its first 512 bytes removed, detects an encryption state, extracts bootloader and resource files, and writes a repacking batch script. The repository also lists cipher, CRC16, and chip-key utilities. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A flash image from a JieLi AC46/BT15 device, or a BFU file with its first 512 bytes removed, is required. - Repacking requires an AC46 SDK. - No licence file in the repository. ##### Primary sources 1. #### VanMoof BLE: a client for S5, A5 and S6 bicycle protocols > VanMoof BLE implements a Python client for the S5, A5 and S6 bicycle BLE protocols. It authenticates with an Ed25519 certificate, reads and writes documented topics, decodes captured messages, and exposes controls and telemetry according to each model's message format. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A VanMoof S5, A5 or S6, a BLE-capable device, Python 3.8+, and the bike certificate and private key. - **Scope:** Region changes, streaming telemetry and module status are listed for S5/A5 only. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### Bin X-ray > Bin X-ray visualizes byte patterns in unknown files and firmware blobs through a 256×256 byte-pair matrix and a 3D byte-trigram plot. A sliding window, ribbon overview, transition-offset search and hex view let analysts move from a pattern to its bytes in the file. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows 10 or 11; building requires Visual Studio 2022, Windows SDK 10.0 or newer, and Python 3 for the version helper. - **Limits:** Bookmarks, entropy strips, comparison mode and structured decoders are roadmap items. - **License:** MIT license. ##### Primary sources 1. #### PIC microcontrollers disassembler > PIC microcontrollers disassembler converts Intel HEX dumps for MidRange and Enhanced MidRange PIC12/PIC16 devices into disassembly listings, HI-TECH PICC assembly files, or both. Processor descriptions and instruction definitions are supplied as JSON configuration files. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An Intel HEX dump and the matching PIC12/PIC16 processor selection are required. - **Scope:** Support is stated for MidRange and Enhanced MidRange PIC12/PIC16 devices. - **License:** MIT. ##### Primary sources 1. #### premium5 > premium5 emulates the Volkswagen Premium 5 car radio at the register and signal level so its original firmware can run without patches. It models the NEC microcontroller, LCD controller, EEPROM and selected vehicle interfaces, with live disassembly, memory inspection and execution controls for firmware research. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Premium 5 firmware binary is required. - **Prerequisites:** PyPy and a modern CPU with strong single-threaded performance are needed to emulate the original 4.19 MHz speed. - **Limits:** Audio output and the tape deck are not emulated. - **License:** BSD-3-Clause. ##### Primary sources 1. #### open-picpak: reconstructing the PicPak frame's BLE protocol and device behavior > open-picpak documents the PicPak 4.2-inch e-ink frame's stock firmware behavior, BLE GATT protocol, and image conversion pipeline. The author reports deriving byte-level findings from the stock ESP-IDF image and a device client, then using those findings in custom ESP-IDF firmware, host tools, and a self-hosted backend. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A PicPak e-ink frame is needed for device use and hardware checks. - **Limits:** Firmware and backend development remain in progress; the web-usb component is not public. - **License:** MPL-2.0 license. ##### Primary sources 1. 2. #### SPRD Flash Tool > SPRD Flash Tool implements the SPRD/UNISOC PAC download protocol in Rust for RDA8910 and UIS8910 devices. Its analysis functions read partitions or whole flash through READ_FLASH and infer a proposed BMAConfig layout from U-Boot, LuatOS and filesystem regions; the author reports byte comparisons on an Air724UG. - Type: Tool - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Rust 1.85 or newer and a compatible SPRD/UNISOC device; PAC input supplies the download stages for device reads. - **Limits:** The proposed layout uses generic content-type names because flash data does not store partition roles. - **Testing evidence:** The author reports hardware checks on an Air724UG RDA8910. - **License:** MIT license. ##### Primary sources 1. #### Hisense AEH-W41H1: local A/C control over a reconstructed RS-485 bus > Hisense AEH-W41H1 local control replaces the air conditioner's cloud-connected Wi-Fi module with ESPHome firmware for an ESP32 board or the stock RTL8710C module. The implementation speaks the A/C's RS-485 bus and exposes climate controls and diagnostics to Home Assistant. Protocol notes describe the frame envelope, checksum, bus roles, and command/status behavior derived from device observation. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Hisense A/C with an AEH-W41H1 module; the ESP32 route requires a 3.3 V RS-485 transceiver. - **Prerequisites:** ESPHome 2026.10.1 for the documented ESP32 build path. - **Limits:** The stock-module path has no rollback without a pre-flash whole-chip dump and a SOIC-8 recovery clip; other ESPHome chips have only compile checks. - **License:** MIT License. ##### Primary sources 1. 2. #### PCM Explorer > PCM Explorer is a read-only Python browser for Porsche PCM and Audi MMI head-unit images. It parses QNX4/QNX6 drives, compressed firmware, update discs, persistence flash and HBM5 HMI files, and supports search, image comparison, extraction and filesystem checks. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Supply an image or extracted files from a supported Porsche PCM or Audi MMI head unit. - **Limits:** HMI screen export produces labelled boxes rather than the original pixels. - **License:** MIT license. ##### Primary sources 1. 2. #### nRF52 e-paper tag: reconstructing an undocumented display interface > nRF52 e-paper tag reconstructs control of an undocumented electronic shelf label with an nRF52832 board and SSD1675A-class panel. The repository records the pinout, 9-bit SPI connection, waveform-table layout and refresh behavior, and provides replacement Zephyr firmware plus a portable C99 display driver. - Type: Case study - Targets: Firmware · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented hardware uses an nRF52832, HINK-E029A10-A3 panel and ESL.CB-LR.010-00C.203 board. - **Prerequisites:** The first installation requires SWD programming; building requires nRF Connect SDK v3.0.1. - **License:** MIT license. ##### Primary sources 1. 2. #### me_cleaner > me_cleaner is a Python script that modifies Intel ME firmware images to reduce the firmware's ability to interact with the system. Depending on the ME generation, it removes the firmware or retains only modules needed for boot. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python and an original Intel ME firmware image. - Flashing the modified image often requires an external SPI programmer. - Board support varies; some OEM firmware will not boot after modification, and Intel ME features will no longer work. - License: GPL-3.0. ##### Primary sources 1. #### Black Magic Debug > Black Magic Debug is a self-contained debugger for microcontrollers. It detects and configures connected targets without configuration files. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs a connected microcontroller target. - The project moved to Codeberg, and this GitHub repository is archived. - GPL-3.0 per COPYING, with BSD and MIT license files for parts of the code. ##### Primary sources 1. #### OpenOCD > OpenOCD is a tool for programming and debugging embedded targets through hardware debug adapters. It supports flash programming, breakpoints, single stepping, and remote debugging through GDB. - Type: Tool - Targets: Firmware - Category: Firmware tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Hardware access requires a supported adapter and a target configuration. - Source builds require GCC or Clang, make, libtool, pkg-config 0.23 or newer or pkgconf, and libjim 0.79 or newer. - GPL-2.0-or-later per COPYING. ##### Primary sources 1. ### Protocols (140) #### open-appleremote: Siri Remote protocol reconstruction > Reconstructs first-generation Siri Remote Bluetooth reports for Linux, decoding buttons, touch and tvOS-style gestures. The Python implementation and protocol notes distinguish measured behavior, historical reports and inferred meanings. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Package 0.1.0; live use requires Linux, BlueZ, Python 3.8+ and access to the device’s hidraw interface. The core uses the Python standard library. - **Testing evidence:** Project hardware checks cover A1962 with BlueZ 5.72 and Linux 6.17. A1513 is expected but untested; second- and third-generation Siri Remotes are unsupported. - **Limits:** The virtual keyboard has not been hardware-tested. Voice is unreleased and checked with synthetic or recorded frames, not live use in this package; it additionally needs libopus and HCI-monitor privileges. - **Limits:** Protocol notes label measured, previously reported and guessed facts. The public sample does not reproduce every claim from the larger unpublished capture. - **License:** MIT-licensed repository. ##### Primary sources 1. 2. 3. 4. #### GAMEKB-K17: reconstructing a macropad configuration protocol > Implements the vendor HID configuration protocol for the GAMEKB-K17/HCY-K017 macropad. It writes key mappings, firmware macros and RGB settings, then reads them back; protocol notes separate tested commands from unconfirmed observations and other-device findings. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Package 3.0.0 requires Python 3.11+ and hidapi; the optional editor uses tkinter. Hardware identity is USB 0816:0220. - **Testing evidence:** Windows is project-tested; other hidapi platforms are untested. Linux configuration requires suitable device permissions. - **Scope:** The documented scope includes 18 remappable controls and up to 16 firmware macros. The volume dial is fixed in firmware. - **Testing evidence:** Read-back verification and interruption ordering are project claims backed by protocol documentation. - **License:** MIT license. The reviewed primary files establish reverse engineering of the vendor WebHID configurator. ##### Primary sources 1. 2. 3. 4. #### cooler-lcd: a Thermalright display protocol implementation > Implements a USB picture-transfer driver for Thermalright Vision cooler displays, with a Rust dashboard replacing the vendor display application. The documented protocol sends a header and JPEG frames, with periodic resends to prevent the device reverting to its logo. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Its documented environment is Linux with udev/systemd and Omarchy integration. Hyprland supplies away/lock state; NVIDIA telemetry uses NVML, and individual screens need their own optional services. - **Scope:** Package 0.1.0 uses Rust edition 2024 and targets the 480×480 USB 87ad:70db display family. - **Scope:** The driver cites TRCC Linux reverse-engineering notes for its 64-byte frame header and JPEG payload, with one-second keepalive resends. - **Limits:** Only one process can own the display at once; the vendor TRCC application must relinquish it. - **License:** MIT-licensed code. Optional traffic/map feeds and other external services retain their own terms. ##### Primary sources 1. 2. 3. 4. #### NJFE: a Soulear camera protocol bridge for desktop inspection > Reuses otoscope's reverse-engineered i4season/Soulear protocol in an ESP32-C3 bridge and Python desktop viewer. The author credits Claude Code for implementation and reports streaming one Hopefox Find T to a Windows PC, with recording, orientation and LED controls. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Builds with PlatformIO espressif32 6.11.0, Arduino core 2.0.17 and U8g2 ^2.35.30; the desktop tools need Python with Tkinter, pyserial >=3.5, opencv-python >=4.8, NumPy >=1.24 and Pillow >=12.3.0. Only Windows testing is reported. - **Scope:** Input is the camera’s Wi-Fi i4season/Soulear UDP traffic. An ESP32-C3 SuperMini with a 0.42-inch, 72×40 SSD1306 OLED reassembles JPEG frames and sends them with accelerometer data over custom USB CDC serial to the viewer. It is not a UVC webcam, the camera’s USB port is charge-only, and no vendor firmware or full app source is recovered. - **Attribution:** Packet format, commands, frame assembly and rotation logic are credited to rbeilvert/otoscope, which reverse engineered Soulear’s libWifiCamera.so; NJFE does not pin the borrowed revision. - **Testing evidence:** Results come from a single HKV41B-firmware Hopefox Find T (480×480 JPEG at about 17 fps). The --test N mode needs the hardware and there is no offline conformance suite. - **Limits:** The camera network is open: the bridge accepts unauthenticated UDP that can inject images or replies, serial access is trusted and recordings are unencrypted. It is an inspection tool, not a medical device. - **License:** GPL-3.0-or-later, with protocol code and roll calculation derived from GPL otoscope; third-party libraries keep their licenses, and no rights to vendor software or images are granted. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Wireshark > Inspect captured application and device traffic as decoded protocol fields, with filtering and shared GUI/TShark dissection. Custom dissectors let an analyst encode newly understood packet formats and compare protocol implementations. - Type: Tool - Targets: App · Firmware · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Use a supported Windows, macOS or Linux/Unix build and a compatible capture file. Live capture additionally needs a supported interface, capture driver and appropriate capture permissions. - Media support depends on the operating system and hardware. Custom formats need an appropriate dissector; packet inspection does not automatically recover a peer's full implementation. - Distributed under GNU GPLv2, with additional component notices. The GitLab repository is upstream; GitHub is its official read-only mirror. ##### Primary sources 1. 2. 3. 4. 5. #### hw-harness: scanner USB protocol investigation > Documents an author-reported scanner investigation comparing vendor-driver USB control transfers with Linux-driver traces to infer initialization, timing and resolution parameters. The released harness organizes reference capture and comparison; it does not automatically recover a complete protocol specification. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Developed on Fedora with libvirt/KVM and a Windows 11 Pro guest running the vendor driver. The documented USB case uses a Plustek scanner with device ID 07b3:1825; physical hardware is required. - **Prerequisites:** USB passthrough, host-side usbmon capture, appropriate host privileges and a matching Linux-side operation are needed for comparable traces. The harness supplies capture/control tooling rather than an automatic protocol decoder. - **Scope:** The generic harness was published after the original bespoke investigation. Its separate MIPI camera example inspects configuration, ACPI and calibration data rather than using the scanner’s USB capture path. - **Testing evidence:** Hardware outcomes and Claude involvement are author-reported. - **License:** The pinned harness code is MIT-licensed. Vendor software and driver dependencies remain separate inputs. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Netzob > Model communication protocols and infer message layouts from traces, with configured active learning for protocol state machines. Python APIs expose message fields, symbols and automata for parsing, traffic generation and fuzzing. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The upstream README requires Python 3.8+; the reviewed release metadata lists Linux x86/x64. Source builds need native build tools, Python headers, libpcap/libffi development libraries and the documented Graph::Easy dependency. - Latest PyPI release at review: 2.0.0, uploaded 2023-01-08. The reviewed source head identifies itself as 2.0.1.dev0, not a newer stable release. Its build pins Cython 0.29.32 and older dependencies including NumPy 1.24.1. As checked on 2026-10-20, the reviewed 2023-01-08 commit is still the master head and GitHub’s latest release is also 2.0.0; GitHub’s last recorded push was 2024-04-18, the repository is not archived and the README does not mark it as maintained, superseded or archived. - Provide representative raw/PCAP messages and analyst-selected models or symbols. Active grammar learning requires input/output symbols, a communication channel and target process control. The current inference documentation is explicitly unfinished. - GPL-3.0-or-later in the reviewed source notices; documentation uses CC-BY-SA. Inference and generated models require analyst validation. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Scapy > Script packet dissection, construction, request/reply matching and capture-file analysis in Python. Custom packet fields and layer bindings let analysts encode understood wire formats and investigate protocol behavior. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed stable release: 2.8.0, published 2026-10-02. Its package metadata requires Python >=3.7,<4; upstream says the 2.8 major version is the last to support Python 3.7 and 3.8. Use release-matched documentation rather than older cached version pages. - Linux, macOS and BSD have documented platform support; Windows requires Npcap. Live capture or packet transmission needs suitable interfaces and privileges. Offline capture analysis is a separate workflow, and libpcap requirements vary by platform and feature. - Optional features have additional dependencies, such as cryptography for cryptographic functionality and plotting tools for visual reports. Unknown formats require suitable custom Packet/Field definitions and bindings; dissection does not automatically infer complete protocol semantics or peer implementations. - GPL-2.0-only in the reviewed package metadata, with dependency and capture-driver licenses separate. The 2.8.0 release notes describe security fixes. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Universal Radio Hacker (URH) > Demodulate and decode signals captured with software-defined radios, with automatic modulation-parameter detection and customizable decodings. Analysts assign protocol fields and message types by hand or review rule-based automatic field inference; a fuzzer targets stateless protocols and a simulator supports stateful exchanges. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - GitHub marks the repository archived and read-only since 2026-03-29. The last release is v2.10.0, published 2025-12-17 with a Windows x64 installer and a macOS DMG; PyPI 2.10.0 requires Python >=3.9. - Install options are the Windows installer, the macOS DMG (macOS 13+ recommended) or Homebrew, pipx on Linux (recommended, with precompiled native extensions), distribution packages and the Docker image. Source installs need Python 3.9+ and setuptools, and build C++ extensions. - Recording and sending need a supported SDR with a native or external backend; several listed devices are receive-only. Non-root Linux access requires the documented udev rules, and native support from distribution packages needs the SDR -dev packages installed first. - GPL-3.0. Automatic field inference gives the analyst a rule-based starting point. Fuzzing and simulation transmit through a TX-capable SDR. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### SavvyCAN > Capture or load CAN bus traffic and investigate frames with sniffer, graphing, file-comparison and ISO-TP/UDS decoding views; loaded or analyst-edited DBC files map raw bytes to named signals. Separate custom-sender, fuzzing and UDS-scan windows transmit frames on a live bus. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest GitHub release: V220, published 2025-05-09, with Linux AppImage, Windows x64 and macOS builds; the README says the current macOS build appears to need macOS 10.15+. The project site's binary links and changelog end at V208 (2022) and are not V220 release notes. Its continuous build follows the newest commit without stability promises. - Source builds need Qt 5.14+ with QtSerialBus support; a Qt 6 work-in-progress branch is described as beta quality. The interface needs at least a 1024x768 display. - Live capture uses GVRET-firmware boards such as the recommended CANDue, or Qt SerialBus drivers including SocketCAN, Vector, PEAK and TinyCAN. Loading the listed log formats needs no capture device; CANDump/Kayak, PCAN Viewer and Wireshark SocketCAN PCAP support is read-only. - MIT. Fuzzing and UDS scanning send frames to connected vehicles or devices, and the fuzzing help warns this can cause unsafe behavior. Signal meanings come from DBC definitions or analyst work rather than automatic recovery. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### AALpy > General-purpose Python automata-learning library that infers deterministic, non-deterministic, stochastic and pushdown models of black-box systems from active queries or passive traces. Its README links a separate Bluetooth Low Energy study whose repository reports learned connection and legacy-pairing state machines; message formats are not inferred. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest PyPI release: 1.6.2, uploaded 2026-08-03, requiring Python >=3.6. The reviewed master branch identifies itself as unreleased 2.0.0 and requires Python 3.10+; upstream says 1.6.2 is the last release for older Python versions. - Active learning needs a user-written system-under-learning adapter, an input alphabet and an equivalence oracle; passive learning needs traces in the documented format. Learned models are bounded by the chosen alphabet, abstraction and oracle. - pydot is the only Python dependency; visualizing models needs Graphviz on the PATH. MIT-licensed. - The ble-learning study repository is separate: it needs an nRF52840 dongle or development kit flashed with the supplied SweynTooth-derived firmware, Python 3.9 and its listed libraries, and it has no repository license file. ##### Primary sources 1. 2. 3. 4. 5. 6. #### rtl_433 > Receives and decodes transmissions from ISM-band devices such as weather sensors, remote controls, doorbells and alarm sensors, using RTL-SDR or SoapySDR receivers or recorded I/Q files, and emits decoded fields as JSON, CSV, MQTT and other outputs. For signals no built-in decoder recognizes, a pulse analyzer reports OOK/FSK timings and hints for a flexible -X decoder that slices frames into bits; its analysis guide leaves mapping those bits to values to the analyst, working from known readings. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Live reception needs an RTL2832-based RTL-SDR dongle or a SoapySDR device; the README names LimeSDR, PlutoSDR, HackRF One and SoapyRemote among actively tested devices, and rtl_tcp servers are accepted. Without a receiver, it reads recorded CU8, CS16 or CF32 I/Q and AM sample files, and -S saves captured signals as files. - Written in portable C99 and built with CMake; RTL-SDR and SoapySDR libraries are optional at build time, and OpenSSL is needed only for TLS outputs. Packages exist for Debian/Ubuntu (rtl-433), FreeBSD and Homebrew; release 25.12 (2025-12-12) ships Linux, macOS arm64 and Windows binaries, and the reviewed master commit is dated 2026-10-11. - At review the README listed 380 device protocols numbered up to 386, 44 of them disabled by default and enabled with -R or a configuration file. Built-in decoders cover those listed models only; for other signals the analyzer and flex decoders frame OOK/FSK pulses and slice them into bits, and do not infer field meanings or protocol semantics. - GPL-2.0. The optional HTTP API output listens on 0.0.0.0:8433 by default. ##### Primary sources 1. 2. 3. 4. 5. #### Blackbox Protobuf > NCC Group's tools for decoding and re-encoding Protocol Buffers messages without the matching .proto definition. The decoder returns the message data with an editable type definition built from best-effort guesses based on wire types; analysts can name fields, correct types and re-encode edited messages, which protoc --decode_raw cannot do. It ships as a Python library with a bbpb CLI, a Jython Burp Suite extension and a mitmproxy addon, and its README traces it to modifying messages during mobile penetration tests. - Type: Tool - Targets: App · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The library and CLI install from PyPI as bbpb (1.4.2, Python >=3.8,<4.0); the README calls the blackboxprotobuf PyPI package an older fork. The mitmproxy addon loads mitmproxy/bbpb.py with bbpb installed in the same environment; edited types survive restarts only with the bbpb_project_file option, and editing commands are unavailable in mitmweb. - The Burp extension needs Burp Suite configured with Jython 2.7+ and a clone with git submodule update --init. gRPC needs Burp's HTTP/2 support, and only uncompressed gRPC payloads are handled. - Field types are guessed from wire types and occasionally field content, so type definitions may need analyst correction; field names and meanings are not recovered, and a type-discovery tool is listed only as future work. .proto import and export use a partial parser that does not resolve import statements. - MIT. The default branch was last committed on 2025-03-14, the day of release v1.4.2. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### furiousMAC Continuity > Reverse-engineering notes and a Wireshark dissector for Apple's proprietary Continuity Bluetooth LE advertisements, continuing the authors' PETS 2019 privacy study. Per-message pages document field layouts and observed values for 14 message types, including AirDrop, Handoff, Proximity Pairing, Nearby Info and Find My, and the dissector replaces Wireshark's packet-bthci_cmd.c so captured advertisements decode into named btcommon.apple fields. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No GitHub releases; the reviewed commit, from 2025-08-29, merges a typo fix. The dissector README calls the March 2021 version for Wireshark 3.4.4 the most up to date: the 4.4.0 file contributed in 2024 ports it to build on Wireshark 4.4.0 without dissector changes and may not correctly dissect messages from the latest iOS versions. Fields the message tables mark as unknown or uncertain remain open. - On Linux and macOS, users download the Wireshark source for the matching version, replace epan/dissectors/packet-bthci_cmd.c with the project's file and build Wireshark. The repository also commits prebuilt 64-bit Windows Wireshark installers for 3.0.8 and 3.2.1, which the dissector README says are based on the original ShmooCon 2020 dissector and should not be used. - Capturing advertisements needs a BLE sniffer: HARDWARE.md recommends a Nordic nRF51 dongle with Nordic's sniffer firmware, or an Ubertooth One with the included btleshark.sh capture script. Analysis uses advertisements the analyst captures; the repository contains no sample captures. - GPL-2.0. The README credits many message types and field meanings to Celosia and Cunche's PETS 2020 paper. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### opendbc > comma.ai's repository of DBC files describing the CAN messages and signals of many car makes, with a Python library that parses and builds CAN messages from those definitions; its porting guide has contributors reverse engineer new messages from recorded drives in the cabana tool. Per-brand car ports built on it parse vehicle state, identify models from ECU firmware versions and generate openpilot's steering, gas and brake messages, while safety code for comma's panda interface restricts which messages can be sent. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.3.1, published 2026-04-22 on GitHub and PyPI; the reviewed master commit is 296 commits ahead of it. docs/CARS.md lists 406 known cars: 341 with upstream support, 14 community, 32 dashcam-only, 16 not compatible and 3 in a custom category. The README says it and that list are the project's only documentation. - The package requires Python 3.11 or 3.12 because pycapnp does not work with 3.13. From a clone, test.sh installs dependencies, builds with SCons, runs the tests and lints; the README roadmap still lists pip install opendbc as open even though PyPI carries the 0.3.x releases. For a live car, the porting guide starts with a comma four and a car-specific harness, and the DBC README connects through a panda. - New definitions come from the analyst's own recorded drives loaded in cabana, which lives in the openpilot repository; the README also points to the commaCarSegments dataset of CAN data from 300 car models. The DBC README recommends recording uncertain signal interpretations as comments, so definitions cover only what contributors have documented for each car. - MIT. The README says panda safety firmware starts with silent CAN buses and that some output modes are disabled in release firmware. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### FISSURE > GNU Radio-based RF framework that carries a signal from survey and detection through IQ capture, inspection, conditioning, feature extraction and classification into a protocol discovery workflow. Its demodulation workspace estimates symbol rates for OOK/ASK and binary FSK recordings, and the bitstream and framing stage applies Manchester or differential decoding, sync-pattern and CRC evidence and repeated-message detection to propose message boundaries. A Qt dashboard coordinates local or remote SDR sensor nodes, a library keeps protocol and packet definitions, dissectors and archived recordings, and plugins add inspection modules such as radar pulse analysis. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Development happens on the Python3 branch, reviewed at its 2026-10-17 commit; the README calls GitHub releases periodic snapshots that may lack recent fixes, and the latest, Python3_20260921 (published 2026-09-29), is seven commits behind. The changelog shows protocol discovery being rebuilt in October 2026: Demodulation and Bitstream & Framing are new, Packet Analysis is a placeholder, and the older Bit Slicing, Dissectors and Sniffer tabs are hidden as obsolete, while the Read the Docs operation pages still describe the older tabs. - Installed by cloning the repository and running its interactive installer as a normal user, not with sudo, preferably on a clean system. The README lists DragonOS, Kali, Raspberry Pi OS and Ubuntu 20.04 to 24.04 with PyQt5 and GNU Radio 3.8 or 3.10 (Ubuntu 18.04 only on the deprecated Python2 branch), beta support for a few other distributions, Windows 11 through WSL2 and Apptainer images on Ubuntu 24.04. Testing is most extensive on Ubuntu, and flow graphs may need recompiling across GNU Radio versions. - Live capture needs a supported SDR such as a USRP, HackRF, RTL2832U, LimeSDR, bladeRF, PlutoSDR or SDRplay receiver; the README says hardware support is being migrated into the plugin architecture, so not every legacy integration works in every workflow. Offline analysis uses the analyst's own IQ or SigMF recordings. - GPL-3.0; GNU Radio out-of-tree blocks come from git submodules under their own licenses. The framework also includes transmit, packet-crafting, fuzzing and attack workflows, plus geolocation, targeting and TAK sharing for distributed operations. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### friTap > Frida-based tool that hooks TLS libraries such as OpenSSL, BoringSSL, NSS and GnuTLS inside a running process and writes NSS key logs and decrypted payloads as PCAP, so analysts can inspect an application's encrypted traffic in Wireshark. For stripped or statically linked libraries it accepts byte patterns or offsets and can scan for renamed libraries, or it can recover TLS secrets by scanning heap memory instead of hooking. A terminal UI, a Python API and a Wireshark extcap integration wrap the same capture. - Type: Tool - Targets: App · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.5.2, uploaded to PyPI on 2026-09-29 and published on GitHub on 2026-10-04; the reviewed main commit is identical to that tag. The README describes Linux, Windows and Android as supported and macOS and iOS as partial and still under development, and says the Windows implementations were verified only on Windows 10. - Installed with pip as fritap on Python 3.10+. friTap 2.x requires frida 17.x and frida-tools 14.x; devices with an older frida-server need a legacy friTap line installed through the documented constraints files. Mobile apps need a frida-server running on the device, and the Android walkthrough uses a rooted phone or emulator with adb in PATH; the desktop example attaches with sudo. libpcap or Npcap is needed only for full packet capture, and live Wireshark piping works only on Linux and macOS. - Analysts name the process or app package to attach to or spawn. Coverage differs by library and platform: the README's support table marks many combinations as read/write hooks only, keys only or not yet implemented, so plaintext captures can be incomplete. Byte patterns for statically linked BoringSSL can come from the authors' separate BoringSecretHunter tool, which analyzes the user's own copy of the library. - GPL-3.0; setup.py declares GPL-3.0-only while its inline comment says GPLv3 or later. The README presents the tool for malware analysis and application privacy research and asks users to cite the authors' 2024 Forensic Science International: Digital Investigation paper on TLS key material extraction. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### pbtk > Recover Protobuf message definitions from compiled programs as readable .proto files. Extractors cover the Java runtimes in JAR, DEX and APK files (including ProGuard-obfuscated code), binaries that embed Protobuf reflection metadata, and web apps using the Protobuf-URL format. A GUI then binds a recovered message type to an HTTP endpoint, decodes hex-encoded captured samples into an editable field tree and resends edited messages, so analysts can relate each field to the response. - Type: Tool - Targets: App · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.1.3, published 2026-08-21 on GitHub and PyPI; the reviewed master commit is four commits ahead of it, adding a version display, a dependency bump and new brand colors, and carries a 1.1.3.1 tag with no GitHub release or PyPI upload. The README's 2026 notes say Java extraction now works mostly with older APKs and the Chrome-based Protobuf-URL web extractor needs an update; finishing the automatic fuzzing part is listed as forthcoming. - Requires Python 3.10+, PySide6 and the Python protobuf runtime. The README documents a snap for Ubuntu, the pbtk-git AUR package, and uv or pipx installs, and says Windows is supported. Java extraction needs a Java runtime (the Debian instructions install OpenJDK 8), and web extraction drives a Chrome or Chromium instance through websocket-client. - Analysts supply the APK, JAR, DEX or native library to analyze and, optionally, hex-encoded request samples they captured themselves with a proxy such as mitmproxy or Wireshark. Replay sends the edited messages to the live endpoint the analyst configures. Extracted .protos and endpoint definitions are stored in a .pbtk folder in the home directory (a pbtk folder under APPDATA on Windows). - GPL-3.0-or-later per pyproject.toml. The package bundles third-party executables: protoc builds, dex2jar 2.4 jars with their Apache-2.0 notice, and JAD decompiler binaries for which the repository includes no license text. Definitions recovered from minified code keep obfuscated names until the analyst renames them. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Roborock Local Server: a self-hosted stand-in for Roborock’s vacuum cloud > Runs a local HTTPS and MQTT stack in place of Roborock’s cloud, so supported vacuums keep live maps and controls on an isolated network without rooting or hardware changes. The maintainer’s technical write-up recounts earlier app and traffic analysis and a later investigation in which Claude Code and Codex worked against an emulated firmware environment. Compatibility is reported per model by the project and its users. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed version 1.2.1 (commit c3b3284) targets most Roborock vacuums on the v2 protocol; README excludes the entry-level Q series, and the tested-models page lists confirmed models, unresolved failures and certificate-chain notes. Documented limitations include firmware updates and schedules; camera streaming is verified on two models, and China-market devices reject commands outside China. - Setup needs a domain the user controls with local DNS rewriting, a valid TLS certificate, a LAN host for Docker Compose or the Home Assistant add-on, and a second Wi-Fi computer for one-time onboarding. The official Roborock app works only after an interception login step and, on Android, a patched APK; Home Assistant and the open-source LocalRock app are alternatives. - Python 3.11–3.13 with FastAPI, aiohttp, cryptography and python-roborock 4.20.0; a container image is published, and CI runs the pytest suite before building it. Tests cover onboarding, protocol authentication, MQTT proxying, certificates and scenes. - The write-up says long-running Claude Code (Opus 4.6) and Codex sessions, given the maintainer’s own rooted S7, its firmware, python-roborock and the decompiled app, helped find the remaining onboarding step after earlier manual attempts stalled. It credits Dennis Giese’s firmware research, Valetudo and other community work. - MIT license with an as-is disclaimer; the project is not affiliated with Roborock. It is a compatible server, not recovered Roborock server code, and vendor firmware or app changes may break it. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### pypush: a Python client for Apple’s push protocol > Reimplements the client side of Apple’s private Apple Push Notification service (APNs) protocol in platform-independent Python: it activates as an Apple device, connects to the APNs courier, mints app-scoped tokens and receives push notifications. The project began as the author’s proof of concept for iMessage reverse engineering, but the current rewrite has removed IDS and iMessage support for now. It uses Apple’s services outside Apple’s official clients. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-03-15 main head, identical to release v2.0.2 on PyPI. The README warns that the rewrite is unstable, that many features have been temporarily removed and that stability should not be expected before 3.0.0. The IDS, iMessage, GrandSlam and CloudKit packages are empty placeholders, so the earlier iMessage work is not part of this version. - Activation and connections go to Apple’s live activation and APNs servers through what the project calls Apple’s internal API, outside Apple’s official clients; the README notes that some APIs may need device identifiers. Apple’s terms for these services apply separately. - Requires Python 3.9+ with anyio, httpx (HTTP/2) and cryptography; the cli extra adds Frida, Rich and Typer. The CLI listens for notifications on a topic, and its proxy mode, meant for observing a Mac’s own APNs traffic, attaches Frida to the local apsd daemon and requires System Integrity Protection disabled and root. - Pull-request CI runs Ruff and pytest on Python 3.9–3.12 across Linux, macOS and Windows. The tests activate against Apple’s servers, open an APNs connection and round-trip a sandbox notification through a scoped token, so they depend on live services rather than offline protocol fixtures. - LICENSE is the Server Side Public License v1, and the package metadata classifies it as Other/Proprietary; the README says Beeper purchased the project and directs licensing questions to Beeper. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### SteamKit > .NET library that implements the client side of Valve’s Steam network protocol: connection-manager sessions, authentication, friends, unified service and Game Coordinator messages, Web API calls and CDN depot downloads. Message classes are generated from Steam protobufs tracked in a submodule and from the project’s own SteamLanguage definitions. Its Resources tree adds protocol-research tools: NetHook2, a Windows DLL that hooks a running Steam client to dump the network messages it exchanges, NetHookAnalyzer2 for viewing those dumps, and ProtobufDumper for recovering protobuf definitions from executables. - Type: Tool - Targets: Game · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master head is identical to GitHub release 3.5.0 of 2026-10-19; at review NuGet still listed 3.4.0 as the newest SteamKit2 package. The README requires the .NET 10 runtime to use the library and the .NET 10 SDK to build it, although the library project multi-targets net8.0 and net10.0. Documentation consists of XML API docs, the wiki and numbered samples covering login, QR authentication, web cookies, friends, Web API and a Dota Game Coordinator request. - Authenticated features need the user’s own Steam account. The library follows Valve’s undocumented, changing protocol: a weekly workflow regenerates message classes from the SteamTracking protobuf submodule and opens a pull request, and the NetHook2 readme notes that releases can lag behind Steam changes. - NetHook2 is a Windows-only C++ DLL built with Visual Studio 2022 and vcpkg that needs the x86 Visual C++ redistributable. Its readme says it depends on binary signature scans of the Steam client that updates can break, and that Steam may crash while it is attached. NetHookAnalyzer2 is a Windows GUI; CI publishes both as workflow artifacts. They inspect the user’s own client traffic. - CI builds the library, SteamLanguage parser, protobuf tools and samples on Windows, macOS and Linux (x64 and ARM) and runs the xUnit v3 test project, whose fixtures include recorded packets and small depot manifest and chunk samples. The tests check parsing, crypto helpers, async jobs and depot handling, not equivalence with Valve’s client. - LGPL-2.1 (LICENSE). The tracked Steam protobuf definitions come from a separate submodule, and Valve’s services and terms apply independently of the library license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### PixMob IR reverse engineering: controlling event wristbands at home > Recovers enough of the infrared protocol used by PixMob event wristbands to light them at home, starting from Flipper Zero recordings made at concerts and games and replaying them to bracelets. Pulse-timing analysis found 38 kHz signals with bit intervals of roughly 700 µs, and targeted brute forcing from an ESP32 discovered hundreds of colour, fade, random and motion-mode commands, now sent through Arduino, Python and web tools. The README calls the result far from exhaustive and points to a later repository that decoded most of the full IR protocol through MCU dumping. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-02-06 main head; there are no releases. The write-up covers IR bracelets, while the rf folder adds 915 MHz and 868 MHz OOK recordings and notes for RF wristbands, where a further encoding layer and a likely CRC remain unresolved. The project reports testing six IR bracelet versions made between 2014 and 2021, and a hardware table lists boards and MCUs where known. - Needs the user’s own PixMob bracelets with fresh batteries and an Arduino-compatible board or ESP32 with a 940 nm IR emitter, using the IRremote or IRremoteESP8266 library; a Flipper Zero can instead send codes from a separate repository. The Python tools need pyserial, PySimpleGUI and clipboard, and the web interface runs in Chrome and connects directly to the Arduino. - The evidence is recordings and observed bracelet reactions: the repository holds raw Flipper IR captures from several events, edited RF captures, the discovered effect definitions, a record of brute-force attempts and a dump of one bracelet’s 24C02 EEPROM. The README says brute forcing targeted only a few packet lengths, so the code list is far from exhaustive, and the programming and choreography signals used at events remain undiscovered. - Python unit tests cover the conversion functions and Flipper-file parsing; there is no CI. Effects are reported by the author and contributors from their own bracelets. - MIT (LICENSE). PixMob’s hardware, firmware and trademarks are outside that license, and the X-ray images are credited to Samy Kamkar. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### protobuf-inspector > Parses Protocol Buffers blobs (proto2 or proto3) without their .proto definition and prints a colored view of the fields in wire order, trying each length-delimited chunk as a nested message, then a packed array, a string and finally a hexdump. Analysts record what they work out in a protobuf_config.py file, with field types and names, message and enum types and custom native types, until the parser no longer has to guess. Field names, zig-zag encoding, signedness and integer-versus-float choices cannot be read from the wire, and the README says guesses can be wrong, especially for small chunks. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Development is dormant: the only release, 0.2 on PyPI and tagged v0.2.0, and the reviewed master commit both date from 2020-11-24, with no later commits. - Install with pip (setup.py declares Python >=3.3) and pipe one raw protobuf blob to protobuf_inspector on standard input, optionally naming the root message type. The README documents no capture, gRPC or HTTP handling, so blobs must first be extracted from traffic or files the analyst is entitled to inspect. - The CLI searches the working directory and each parent up to the filesystem mount point for protobuf_config.py and runs it with runpy, so a config file executes as Python code. A dump type writes matching chunks to dump.N files in the working directory, and parse errors stop inside the affected field and make the command exit non-zero. - ISC license. The README says the Python API was not designed as a library and may change. The repository has no tests or CI configuration. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### OpenDrop: an open reimplementation of Apple AirDrop > Python command-line reimplementation of Apple's AirDrop protocol from SEEMOO Lab's reverse-engineering research. It finds receivers via _airdrop._tcp DNS-SD, sends binary-plist /Discover and /Ask requests over HTTPS and uploads gzip-compressed CPIO archives to exchange files with iOS and macOS. It is not affiliated with Apple. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls OpenDrop experimental output of the Open Wireless Link reverse-engineering effort that lacks some AirDrop features and may break with future AirDrop versions, and says Apple neither affiliates with nor endorses it. The latest release is 0.13.0 (PyPI, 2021-04-29); the reviewed master commit of 2026-08-17 adds only a citation file and link edits since. - AirDrop runs only over Apple Wireless Direct Link, so OpenDrop is supported on macOS or on Linux with an open AWDL implementation such as SEEMOO's OWL; the default interface is awdl0. It needs Python 3.6+ (classifiers list 3.6–3.9), a current libarchive (Homebrew's on macOS), the openssl command and the packages in setup.py, including zeroconf and libarchive-c. - By default it creates its own self-signed key and certificate. Receivers in the default contacts-only mode need AirDrop keys, a certificate and an Apple ID validation record from the user's own Mac, which README says come from a separate SEEMOO extractor; the repository ships only Apple's public root CA certificate. - README lists known gaps: no Bluetooth Low Energy trigger, so Apple receivers may stay undiscovered; no peer authentication (neither TLS certificate chains nor validation records are checked) and automatic acceptance of every incoming file; and one file per transfer, with links sent but not received. CI runs black, flake8 and pytest on Python 3.6–3.9; its two tests only start the browser and server on loopback. - GPL-3.0. README points to the authors' USENIX Security 2019 AWDL paper and 2021 PrivateDrop paper for protocol details; AirDrop and AWDL remain Apple's protocols. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### libimobiledevice > C library and command-line tools that speak iOS devices' native service protocols without Apple's proprietary libraries or a jailbreak. Over usbmuxd or Wi-Fi sync it implements lockdownd pairing and services such as AFC file access, backup, app installation, crash reports, syslog, debugserver and WebKit inspection, plus Cython bindings. - Type: Tool - Targets: App · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release: 1.4.0 (2025-10-10), which NEWS calls a development release; it added MbedTLS support, Apple TV wireless pairing and iOS 17+ personalized developer disk image mounting, among other changes. The reviewed master commit of 2026-06-10 is nine commits ahead, mostly AFC and afcclient fixes. - Source builds use autotools and pkg-config with libplist 2.3.0+, libusbmuxd 2.0.2+, libimobiledevice-glue 1.3.0+ and libtatsu 1.0.3+ from the same organization (README says libtatsu must be built from source), plus OpenSSL by default, GnuTLS or MbedTLS; Doxygen and Cython are optional. The README dependency list includes the usbmuxd daemon and says the library is tested on Linux, macOS, Windows and Android. - Work starts from an iOS device the user controls and pairs with the host (idevicepair); the repository contains no Apple software. Screenshots and location simulation need a mounted Apple developer disk image, which is not included. README says library documentation is not yet available and points to the bundled utilities' source; each utility has a manual page. - GitHub Actions builds and installs the library on Ubuntu, macOS and Windows (MSYS2 MINGW64 and MINGW32) against the latest builds of its sibling libraries, on pushes, pull requests and a monthly schedule. The repository has no test suite, and no workflow exercises a device. - LGPL-2.1 for the library and utilities. The bundled ed25519 (zlib-style license) and Stanford SRP-based libsrp6a-sha512 (BSD-style) keep their own licenses. README states that the project is independent and not authorized, sponsored or approved by Apple. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Sniffle > NCC Group's sniffer for Bluetooth 5 and 4.x Low Energy, made of firmware for TI CC1352/CC26x2 radio boards and Python host tools. It captures advertising and connection traffic on the 1M, 2M and coded PHYs, follows connections through channel-map, connection-parameter and PHY changes, captures BT5 extended advertising, and filters by MAC address, IRK, RSSI or advertisement content; for a filtered target it hops all three primary advertising channels, which the README says makes connection detection nearly three times more reliable than single-channel sniffers. Captures are saved as Ubertooth-compatible PCAP, a Wireshark extcap plugin starts captures from the Wireshark GUI, and command-line decoders print advertising data, including Apple and Microsoft manufacturer-specific fields. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v1.11.0, published 2025-07-12 with prebuilt firmware hex files for each supported board; the reviewed master commit adds two relay-script fixes. The README asks users of prebuilt firmware to run the Python code from the matching release tag rather than master. The release notes describe SDR-based sniffing as an incomplete work in progress. - Needs one of the listed TI Launchpad boards (CC26x2R, CC2652RB, CC1352R, CC1352P, CC2652R7, CC1352P7, CC2651P3 or CC1354P10), a SONOFF CC2652P USB Dongle Plus or a CatSniffer V3. Firmware is flashed with TI UniFlash/DSLite, the cc2538-bsl bootloader utility for the SONOFF dongle or Electronic Cats' uploader; the README warns that flashing the wrong SONOFF build variant can brick the dongle. Building firmware needs the ARM GNU toolchain and TI SimpleLink Low Power F2 SDK 8.30.01.01, which the README patches for recent GCC. Host tools need Python 3.9+ with PySerial. - Encrypted connections are not decrypted: Sniffle follows their timing and detects parameter updates without the key, and reliable connection following needs a MAC or IRK filter on the peripheral. Later firmware can also transmit for active scanning, advertising, initiating connections and link-layer relaying. - GPL-3.0; source headers name NCC Group plc as the copyright holder, jointly with Jay Logue for the Wireshark extcap plugin. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Packetry > Great Scott Gadgets' USB 2.0 protocol analysis application for live capture with the Cynthion analyzer or for exploring previously captured traffic, working from physical-layer packet data at High, Full and Low Speed. Its GTK 4 interface offers a hierarchical view that expands high-level events into their transactions and packets, plus chronological transaction and packet views, while a device pane summarizes each observed device from its decoded descriptors, including HID report descriptors. Captures are opened and saved as pcap files with the LINKTYPE_USB_2_0 link type, and v0.5.0 added pcapng with custom blocks for non-packet events. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: v0.5.0, published 2025-09-30 with a Windows installer and a Linux x86_64 AppImage; the quick-start guide installs it on macOS with Homebrew. The reviewed main commit is 47 commits ahead with interface, dependency and minimum-Rust changes, while Cargo.toml still reports 0.5.0. - Live capture needs a Cynthion analyzer whose host software is installed and updated with cynthion update; the code also probes iCE40-usbtrace devices, which the documentation does not cover. Viewing existing capture files needs no hardware. - Source builds need Rust 1.93+ according to the README and Cargo.toml (the quick-start guide still says 1.85.1) and GTK 4 headers discoverable through pkg-config. The documentation warns not to build with --all-features, whose optional features are for debugging and testing and degrade normal use. - Captures come from the user's own USB devices and buses. The documentation notes that the hierarchical view can show packets out of chronological order. BSD-3-Clause. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### bluefluff: reverse engineering Furby Connect's Bluetooth LE protocol > Documents the Bluetooth Low Energy interface of Hasbro's Furby Connect toy, worked out, according to its notes, from the companion app's native library, sniffed BLE traffic and trial and error. It maps the GATT services and the command and response bytes of the toy's Nordic radio and GeneralPlus controller, covering action sequences, antenna colour, mood values, sensor reports and a hidden debug screen. fluffd, a Node.js daemon built on the noble BLE library, exposes these commands through an HTTP API and a browser control page. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Most research commits date from 2017 and 2018, with a few later fixes and a Docker setup added in March 2026. The README reports that large parts of the BLE protocol are understood, while the action list is incomplete, the update (DLC) format is only partly explored, and code execution, custom LCD animations and the sleep-mask connector remain untried. - Requires a Furby Connect and a host with Bluetooth LE, built in or through a USB Bluetooth 4.0+ adapter. The repository contains no Hasbro update files or app code. The README warns that interfacing in unwarranted ways can brick the toy and will almost certainly void its warranty. - fluffd needs Node.js 7.0 or later according to the README and pins @abandonware/noble 1.9.2-23. The README covers Linux, which needs libudev development files and a running BlueZ, and macOS, which needs xpc-connection, and also names FreeBSD and Windows. The Docker image uses node:16-bullseye, needs host networking for raw HCI access and supports Linux hosts only. - The findings are the author's documented observations, made without opening the toy. The repository has no tests or CI. - MIT (2017, Florian Euchner); the README's disclaimer says the information is for educational purposes only. Furby Connect, its companion app and Hasbro's content keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Caring Caribou > Python automotive security exploration tool, begun in the HEAVENS research project, that the README describes as a zero-knowledge tool to drop onto a CAN network and collect information about the services present. Passive modules dump CAN traffic to the terminal or a candump-format file and list every arbitration ID seen on the bus, while the UDS (ISO 14229-1), DoIP (ISO 13400-2) and XCP modules discover ECUs that answer diagnostic requests, enumerate their supported services and subservices, read data identifiers and query XCP capabilities. Its utilities provide reusable ISO-TP (ISO 15765-2) and UDS implementations, and new modules plug into a drop-in module architecture. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest GitHub release at review: 0.6, published 2024-03-28; the reviewed master commit is 45 commits ahead and its packaging already reports 0.7. The README installs it from the source tree; PyPI had no caringcaribou project at review. - Needs a CAN interface supported by python-can and configured in python-can's .canrc file. The install guide uses a PEAK PCAN-USB adapter with SocketCAN on Linux (kernel 3.4 or newer there, while the README asks for a pretty modern kernel) and suggests a Linux VM on Windows. The README requires Python 3.7+; the DoIP module also needs the doipclient and udsoncan packages. - Discovery and service scans transmit diagnostic requests on the connected bus or network. Other modules send, replay or fuzz frames and perform intrusive diagnostic operations. - GPL-3.0. The bundled unit tests run against mock ECUs on a virtual CAN bus. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### protodump > Go command-line utility that recovers Protocol Buffers schemas from a compiled binary or any other file: it scans the raw bytes for serialized FileDescriptorProto records embedded by generated code, locating them through their .proto file names, and writes each one back out as a .proto source file under its original descriptor path. The regenerated files use proto2, proto3 or editions syntax and include the package, imports, common file options, messages with reserved ranges, nested enums, oneofs, maps and default values, and services with their RPC methods, giving analysts message and API definitions to work with when decoding Protobuf traffic. - Type: Tool - Targets: Binary · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No tagged releases at review; the README installs it with go install from the latest module version, and go.mod declares Go 1.26.8. The reviewed main commit of 2026-09-27 confines output writes to the chosen directory and refuses to overwrite existing files. CI tests and builds it on Linux, macOS and Windows. - Input is a user-supplied binary or other file that embeds complete descriptors. The scan is a byte search rather than executable-format parsing, so descriptors that are absent or not stored as plain serialized records are not found, and records that fail to parse are skipped silently unless -v is given. - Field, message, enum, oneof, service and method options are not emitted yet (TODOs in the generator), and extension definitions are not written, so regenerated files can differ from the originals and need analyst review. - No license file or license statement was found at the reviewed commit, and GitHub detects no license, so the project states no reuse terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### pyatv: a reverse-engineered client for Apple TV and AirPlay protocols > Asyncio Python library and command-line tools that act as an independent client for Apple TV and AirPlay devices by reimplementing the DMAP/DACP, Media Remote Protocol, Companion Link, AirPlay and RAOP protocols, which its protocol documentation describes as reverse engineered. That page records the recovered binary formats, Zeroconf properties, the OPACK encoding, pair-setup and pair-verify exchanges and Companion commands, with some request headers taken from Wireshark captures of the iPhone Remote app, and the bundled atvproxy relays MRP, Companion and AirPlay sessions to print decrypted messages for further analysis. On this basis pyatv provides remote control, metadata with push updates, app and account switching, audio-output management and AirPlay streaming to Apple TVs, HomePods and third-party receivers. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Release at review: 0.18.0, published to GitHub and PyPI on 2026-06-19 as a tvOS-compatibility release; the reviewed master commit is the release commit, while the v0.18.0 tag points to a parallel commit that differs only in CHANGES.md and pyatv/const.py. The protocol page limits itself to what has been reverse engineered: its Companion Link section is called mostly speculation and guesses, the OPACK description is incomplete and unverified, and the MRP implementation section is still marked TBD. The acknowledgements say MRP support builds on Jean Regisser's mediaremotetv-protocol findings. - No Apple software, firmware or keys are bundled. pyatv connects to the user's own Apple TV, HomePod, AirPort Express or other AirPlay receiver on the local network; most protocols require pairing with a PIN shown on the device, and credentials and settings are kept in pyatv's storage. On tvOS 15 and later AirPlay must be set up because MRP moved into an AirPlay 2 stream, and RAOP supports only legacy pairing. - Requires Python 3.9+ and installs from PyPI or the project's container images; the installation guide lists build-essential, libssl-dev, libffi-dev and Python headers for building dependencies on Debian-style systems, and RAOP audio streaming relies on miniaudio. CI runs on Ubuntu, macOS and Windows with Python 3.9 to 3.14. - Tests are mostly unit tests, plus functional tests for DMAP, MRP, Companion, RAOP, mDNS and scanning that run against a fake device which, according to the testing guide, implements limited functionality and is only meant to be compatible with pyatv. atvproxy is described as an incubating script that depends on internal APIs. - MIT (LICENSE.md). Apple's protocols, devices and software keep their own rights; pyatv is an independent implementation. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### CAN Commander > A Flipper Zero app and earlier Arduino sketches for reverse engineering CAN bus traffic, chiefly in vehicles. The current app is a UART front end for a CAN Commander ESP32 board: it streams all or filtered frames, lists unique IDs, measures message rates, tracks per-bit and per-byte changes, and runs a two-phase Auto Reverse Engineer that first calibrates out background traffic and then shows which IDs change during an action. It also decodes live signals from DBC-based profiles and reads OBD-II PIDs, the VIN and trouble codes. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit of 2026-04-25 sets app version v2.3.1 (fap_version 2.3), and there are no GitHub releases. The app needs a CAN Commander board connected to the Flipper's GPIO and running ESP32 firmware v2.2 or newer. That firmware, and the converter from .dbc files to the app's .dbcprof and .injprof profiles, are offered at cancommander.com rather than in this repository. - The README lists limits such as 16 cached DBC signals, 10 tracked changed IDs on the reverse-engineering dashboard and 384 frames per replay recording, and warns that heavy traffic needs filtering and that streaming the Flipper screen during DBC decoding can exhaust RAM. A Wi-Fi TCP command line mirrors the USB command set; dedicated companion clients are described as planned. - Legacy/ keeps the earlier Arduino sketches for Arduino, ESP8266, ESP32 or RP2040 boards with an MCP2515 controller, a bundled MCP2515 library copy with an MIT notice, a JavaScript BLE companion app, OBD-II PID tables and about 80 vehicle DBC files without a stated source or license. The repository has no tests or CI. - The write, Smart Injection, Replay and Clear DTCs tools transmit on the bus and can change vehicle state; use them only on vehicles and networks you own or are authorized to test. There is no license file and GitHub detects none, so reuse terms for the project's own code are not stated. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Automated CAN Payload Reverse Engineering > Research Python and R scripts that automate reverse engineering of Controller Area Network (CAN) payloads recorded from passenger vehicles, implementing the pipeline from Brent Stone's AFIT dissertation. The Python pipeline pre-processes a CAN log into per-arbitration-ID data frames, pulls out public SAE J1979 diagnostic data, runs a lexical analysis that guesses individual signal time-series boundaries, then a semantic analysis that builds a correlation matrix and hierarchically clusters related signals, with plots and a dendrogram as output. A separate R script set applies the rEDM empirical dynamic modeling package to engine-RPM, brake-pressure and vehicle-speed time series to study causal relationships. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Dissertation research code with no releases or tags; the reviewed commit dates to 2022-02-01. The README says the scripts were developed and tested on Python 3.6 and need NumPy, Pandas, scikit-learn and (for plotting) matplotlib listed in requirements.txt; the R scripts need R with the rEDM package. There is no packaging or install step, and the README says the scripts will not run immediately after cloning. - Two Python folders implement the same concept: Pipeline is the basic single-file version driven from Main.py, and Pipeline_multi-file is the more complete batch version that the README says contains bug fixes not back-ported to Pipeline. Input is a CAN capture in the bundled loggerProgram0.log delta-time/ID/DLC/hex format; an April 2020 addition also reads the can-utils log format via a -c/--can-utils argument, and other formats require editing PreProcessor.py. - The user supplies their own CAN capture. The repository bundles the author's own example data: the loggerProgram0.log vehicle capture, example pipeline output, an OBD2 PID table, and R-folder CSV time series of engine RPM, brake pressure and vehicle speed for different driving conditions, plus the author's dissertation PDF. The results are signal-boundary and clustering estimates that need analyst validation, not confirmed signal definitions. - The repository includes a GPL-3.0 LICENSE file, while the README states the code is a work of the U.S. Government not subject to copyright protection in the United States, cleared for public release (case 88ABW-2019-0910). The scripts read passive logs and perform analysis only; no device interaction or frame transmission is described. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Deluder > Frida-based interceptor for the traffic of proxy-unaware applications. JavaScript hook scripts on the send and receive functions of WinSock, Linux libc sockets, OpenSSL, GnuTLS and SChannel pass plaintext buffers to Python interceptor modules, which log them or forward them to a proxy for inspection. It spawns or attaches to a process, optionally through a remote frida-server, and was designed mainly as the backend for the author's PETEP proxy; a proxifier interceptor works with other proxy tools, and new scripts and interceptors can be added. - Type: Tool - Targets: App · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v1.2.1, published 2025-11-14; the reviewed main commit is identical to that tag. The changelog adds remote frida-server support in 1.1 and GnuTLS and Linux sockets in 1.2. The README lists the hooked functions for each library and their Windows, Linux and macOS module names; other libraries need custom Frida scripts. - Python 3.9+ with the pinned frida 16.4.10, psutil 6.0.0 and argparse 1.4.0. It is installed from a release or clone with setup.py, or run as a module after installing requirements.txt. Analysts choose the process to spawn or attach to by path, PID or name, remote targets need a frida-server for their platform, and child processes are hooked unless that is disabled. - Captured messages go to log, debug, proxifier or PETEP interceptors. PETEP integration uses its own protocol on port 8008 by default, and the proxifier frames data by length prefix, suffix or buffer size. The README warns that dropping intercepted messages is unsupported and breaks interception. - Scripts resolve exported functions in loaded modules whose names match a configurable list, so applications that link these libraries statically or use other TLS stacks need custom scripts. The tests directory has pytest cases for the PETEP and proxifier interceptors and for byte formatting. The reviewed tree has no CI workflow and no automated tests for the Frida hook scripts. - LICENSE.md is GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### BudsPro-Headtracking: streaming Galaxy Buds Pro head tracking over Samsung’s serial protocol > Reimplements the Samsung Galaxy Buds Pro’s proprietary spatial-audio messages in a small Python script so that a PC can stream the earbuds’ head-tracking data in real time. It connects to the earbuds’ GEARMANAGER (or FACTORY) RFCOMM serial service, frames packets with start and end markers and a CRC16-CCITT checksum, enables the sensor stream with attach and two-second keep-alive messages, and decodes the rotation quaternion from the data events. A contributed script converts the quaternion to Euler angles and forwards it over local UDP to a Unity receiver; results are shown only as author-provided sample output. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit 63b321a (2024-12-30) merges a contributor change that also accepts the FACTORY service name reported for Galaxy Buds2; the README covers only the Galaxy Buds Pro, and the project has no releases, tests or list of tested earbud firmware. Headtracking.py prints the raw x, y, z, w quaternion (four signed 16-bit values divided by 10,000) or, with -b, frame-timing statistics, and reports gyro-bias and stuck-sensor events only in verbose mode. - It needs the user’s own paired Galaxy Buds Pro, addressed by its Bluetooth MAC address; no Samsung app or firmware is used at runtime or included in the repository. The repository does not document how the message IDs and framing were derived; code comments point to the author’s separate Galaxy Buds desktop client for the full parser and quaternion conversion. - Python 3 with PyBluez on Windows or Linux; the README requires PyBluez 0.22 on Windows because 0.23 fails to enumerate Bluetooth devices. buds_to_unity.py also needs NumPy, hardcodes a device address and sends to 127.0.0.1:12562, and getBudsUDP.cs is a Unity MonoBehaviour adapted from a receiver credited to KAIST UVR Lab. - The README shows sample quaternion output, and benchmark mode reports the average, minimum and maximum time between motion frames, but no captures, tests or recorded benchmark results are published. In the reviewed SpatialSensorManager.py the command payloads are built with Python’s bytes(n), which yields n zero bytes rather than the value n, so the bytes sent may differ from what the constant names suggest. - LICENSE grants MIT (2021, Tim Schneeberger); the Unity script carries an attribution to its original author but no separate license. Galaxy Buds and its services belong to Samsung. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Even G2 protocol: reverse-engineering Even Realities G2 smart-glasses BLE traffic > Documents the Bluetooth Low Energy protocol between the Even app and Even Realities G2 smart glasses, worked out from captured traffic: GATT characteristic UUIDs, an 8-byte transport header with sequence, multi-packet and two-byte service-ID fields, a CRC-16/CCITT over the payload, and protobuf payloads with draft .proto definitions. A Python example built on bleak sends the seven-packet session handshake and drives the teleprompter service to show custom text. The README’s status table marks connection, handshake, teleprompter and calendar widget as working, notifications as partial, and Even AI and navigation as still under research. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit of 2026-01-03 is a documentation snapshot with no releases or tags. Only the teleprompter has example code, and docs/teleprompter.md is marked work in progress; the .proto header says field numbers and types are inferred from captured packets and may be incomplete or wrong, and several field meanings carry question marks. The README reports the calendar widget working but includes no calendar example or detailed format, and CONTRIBUTING.md labels Even AI “Cracked!” with its request format unclear while the README still lists it as research. - Using the example needs Even G2 glasses and a host with BLE and Python with bleak 0.21+; it scans for device names containing G2 and connects to the left arm’s device, or the right one with --right. The README says the glasses use standard BLE with no special pairing, and the example’s handshake consists of fixed capability messages and the current time, with no keys. The repository contains no Even app or glasses firmware. - CONTRIBUTING.md describes collecting Android Bluetooth HCI snoop logs while using features in the official app, and the repository commits four such raw logs from the author’s sessions; they are not limited to the glasses’ traffic. No tests or verification beyond the README’s status table are provided. - No license file is present and GitHub detects none, so the documentation and code carry no reuse grant. The README calls this an unofficial community project for educational purposes, not affiliated with Even Realities, and credits the Even Realities community with the protocol research. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### fuji-cam-wifi-tool: reconstructing Fujifilm X-series Wi-Fi remote control > Reimplements the Wi-Fi remote-control protocol of Fujifilm X-series cameras as a C++ library and an interactive command-line client that joins the camera's access point. Its headers name the control, event and JPEG live-view ports, message types and camera property codes, and source comments keep hex traces of exchanges along with what "the app" sends; the client connects, fires the shutter, records video, adjusts exposure settings and focus point, and streams live view, optionally into a Linux webcam device. README calls the tool very limited and mostly undocumented, so the protocol knowledge lives in code and comments rather than a specification. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at master commit c597fc4 of 2021-03-17, the repository's last push; there are no releases or tags. The README describes an attempt to reverse-engineer the protocol, calls the tool very limited and mostly undocumented, and suggests reading the code. Its connection steps name the X-T10 and a source comment mentions focus-point ranges on the X-T100; no compatibility list for other X-series models is given. - Requires the user's own Fujifilm X-series camera with Wi-Fi remote control: the computer joins the camera's access point, the client connects to 192.168.0.1 on ports 55740–55742, and the first connection must be confirmed on the camera, where the tool registers as "HackedClient". The repository contains no camera firmware, Fujifilm app or capture files; the README gives Wireshark display filters for viewing control messages and streamed JPEG frames. - README documents CMake builds on macOS, Linux and Windows (CMake 2.8.11 minimum, C++11). The interactive shell needs the hkr/linenoise-ng submodule initialized, and Windows builds link Winsock. Optional OpenCV support adds stream_cv, which can feed live view into a Linux v4l2loopback device for use as a webcam. - The repository has no tests or CI. Message meanings are inferred in code comments, several of which are marked unknown or TODO, and command behavior on cameras remains contributor-reported. - Released under the Unlicense, a public-domain dedication; AUTHORS.txt lists five contributors. Fujifilm cameras, firmware, apps and trademarks keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### PiCCANTE > Raspberry Pi Pico firmware and hardware designs for a low-cost CAN bus interface aimed at exploring and reverse engineering vehicle networks. It runs two CAN 2.0B channels on RP2040 boards or three on RP2350 boards through the PIO-based can2040 library and exposes them over USB as a GVRET device for SavvyCAN and as per-channel SLCAN devices for Linux SocketCAN via can-utils. A configuration shell, a partial ELM327 emulator for OBD-II PID requests with ISO-TP multi-frame replies, and Wi-Fi, Bluetooth and a web interface on Pico W boards complete the firmware, alongside perfboard and KiCad PCB designs with 3D-printable cases for an OBD-II dongle. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Only release at review: v0.0.1, published 2025-05-03 with UF2 and ELF firmware for Pico, Pico W, Pico 2 and Pico 2 W; a dev-latest pre-release is rebuilt from main and was built from the reviewed commit of 2026-01-26. The README marks the ELM327 emulator as partial, lacking CAN setup, protocol auto-detection and filters, and lists SD-card logging and software CAN filters as planned. CAN FD and CAN XL are not supported. - Hardware is any Raspberry Pi Pico or Pico 2 board with one to three 3.3 V CAN transceivers such as the SN65HVD; the Pico 2 W is recommended for Wi-Fi and Bluetooth. The README warns that the 120-ohm termination resistor on most transceiver breakout boards must be removed before joining an existing, terminated bus, and urges caution when connecting to vehicle systems. The OBD-II dongle can add a buck converter, an SD card slot and a voltage divider for battery voltage. - Source builds need the Raspberry Pi Pico SDK, CMake 3.13+ and the GCC ARM toolchain, with FreeRTOS-Kernel, a can2040 fork, littlefs, TinyUSB, pico-extras and FreeRTOS-FAT-CLI as submodules; PICO_BOARD defaults to pico2_w, and the web interface is a separate Svelte project in Web/. CI builds firmware for the four Pico boards on pushes to main and on pull requests, and no test suite is documented. - GPL-3.0-or-later per LICENSE.txt and the README notice; the README attributes the CAN 2.0B-only limit to can2040's licensing, and the bundled DHCP server code carries an MIT notice. No separate license is stated for the KiCad, STL and STEP hardware files. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Gymnasticon: bridging proprietary exercise-bike data to standard cycling sensors > Node.js bridge that reads power and cadence from exercise bikes whose own apps or services are gone or closed, and re-broadcasts them as standard Bluetooth LE Cycling Power and Cycling Speed and Cadence sensors and as an ANT+ bike power profile, so that Zwift, TrainerRoad, bike computers and watches can use the bike. The author's development notes describe working out the Flywheel Home Bike's stats packets on its Bluetooth UART service after the vendor shut its home service down; Peloton support reads the bike's data cable through a USB serial adapter, while the Schwinn IC4 and Keiser M clients parse the standard Fitness Machine Service and Keiser's documented broadcasts. Bike and app compatibility is project-reported. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest GitHub release at review: v1.4.0, published 2021-02-21 with a Raspberry Pi SD card image; npm's latest is 1.4.1 from 2021-03-24, and the reviewed main commit of 2021-04-21, which adds autodetection for all supported bikes, is still the newest on main. The README lists the Flywheel, Peloton (with an additional cable), Schwinn IC4/IC8 aka Bowflex C6 and Keiser M3i, M3i-TBT and M3iX bikes as tested and the LifeFitness IC5 as probably working; a simulated bot bike serves testing. - Needs the user's own supported bike; no vendor app, firmware or account is used. A Raspberry Pi Zero W is recommended, and the tested hosts are Raspbian Buster on Pi Zero W, 3B+ and 4, macOS 10.14+ and Debian Buster on x86-64. BLE bikes need a Bluetooth 4.1+ adapter with multi-role support, or two adapters; ANT+ output needs an ANT+ USB stick, and Peloton bikes need the extra serial cable linked from the README. - The SD card image is the project's own Raspbian Buster build made with pi-gen scripts in deploy/, with the default pi/raspberry account and SSH disabled; on first boot it switches the root filesystem to an overlay with a read-only boot partition and reads gymnasticon.json from the boot partition. Manual installs use Node.js 12.16.1+ from npm, with libudev-dev on Linux and cap_net_raw or a systemd unit for Bluetooth access, and depend on the abandonware noble and bleno libraries, gd-ant-plus and serialport. - CI builds the package and runs tape unit tests on Node.js 12 and 14; they cover the Flywheel, IC4, Keiser and Peloton parsers on sample packets, the simulated bike and utilities, not live bikes or training apps. power-scale and power-offset options let riders correct bikes that report inaccurate power. - MIT. Bike and app names belong to their owners. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### garmin-ble: a Python client for Garmin's GFDI watch protocol > Python library that talks to Garmin watches over their proprietary GFDI V2 Bluetooth LE protocol, with no Garmin Connect, phone or cloud service. It implements the handshake, multi-link routing, COBS framing, CRC16 checks and protobuf service messages, streams typed readings such as heart rate, HRV, SpO2, stress, Body Battery and accelerometer data, and adds a simulator and recorded-session replay for work without hardware. Its acknowledgements credit Gadgetbridge for the protocol logic and schemas, while a published journal shows how the author decoded the accelerometer payload, which Gadgetbridge only logged, from labelled recordings. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main commit b662032 (2026-09-27), four commits after v0.3.2 of 2026-08-01, which is also the latest PyPI release; those commits add examples and an announcement video. pyproject marks the package Alpha and the CHANGELOG warns that the pre-1.0 API may change. The README roadmap lists BLE transport, live telemetry, the Watch API, simulator and replay as done, protobuf settings and device state as in progress, and notifications, media control and FIT/GPX file transfers as planned. - Requires the user's own Garmin watch and a Bluetooth LE adapter on the computer; the README warns that the watch allows one BLE connection at a time, so it must be disconnected from the phone first. No Garmin Connect, firmware or SDK is used, and the repository's data files are the author's labelled accelerometer recordings. The README gives no list of tested watches; the bundled simulator profiles model a fenix 7 and a Venu 3, and the CHANGELOG notes that GFDI has no capability query, so a metric's support shows only when the watch accepts or declines its service. - Python 3.10+ with bleak and protobuf, installed from PyPI or from source; development extras add pytest, pytest-mock and pytest-asyncio. Compiled protobuf modules are committed next to their .proto sources, and most examples accept --simulate. - CI runs the pytest suite on Ubuntu with Python 3.10–3.13. Tests cover COBS, CRC16, GFDI, MLR and Smart framing, the bleak-backed transport with mocks, frame tracing, capture files and replay, and watch lifecycle, protobuf and telemetry behavior against the simulator. rev_eng.md documents how the 17-byte accelerometer packet was decoded from nine labelled recordings. Behavior on real watches remains author-reported. - AGPL-3.0-only, matching the Gadgetbridge-derived code the README acknowledges, although the README also calls the library clean-room. Garmin watches, apps and trademarks keep their own rights. One commit message calls the tilt game example a test of unsupervised vibe coding. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### VanBus > Arduino library for ESP8266/ESP8285 and ESP32 boards that receives and transmits packets on the VAN (Vehicle Area Network) comfort bus that PSA fitted to Peugeot and Citroën models until about 2009. It decodes the signal from a GPIO pin, wired through a CAN transceiver or a receive-only resistor divider, in software into packets with identifier, command flags, data and a 15-bit CRC that it can check or try to repair by flipping single bits, and reports queue and error statistics. Example sketches dump raw packets, send a packet, and parse comfort-bus traffic into readable fields on the serial port or a live web page. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.5.1, published 2026-05-29, the version library.properties and VanBusVersion.h declare; the single later master commit (2026-08-22) only adds a pin-swap note to two example sketches. The README says the library supports only the 125 kbit/s VAN rate, with other rates such as 62.5 kbit/s still to be added. - Builds in the Arduino IDE (the author uses 1.8.19) with the ESP8266 board package (tested 2.6.3–3.1.2, CPU at 160 MHz) or the ESP32 package (tested 1.0.6, 2.0.17 and 3.3.5, CPU at 240 MHz), installing the library through the Arduino Library Manager. The LiveWebPage example also needs the arduinoWebSockets library and has the browser load jQuery from Google's CDN; dumping packets into a character buffer needs PrintEx. - Live use needs a PSA vehicle with a VAN comfort bus: the README locates it on pins 2 and 3 of ISO block A at the head unit and documents wiring through an MCP2551 transceiver with a 5 V–3.3 V level converter, an SN65HVD230 transceiver, or a receive-only resistor divider that it says works well only with ESP8266 boards. It warns that the transceiver boards' CAN terminator resistors may make other equipment on the bus malfunction, and transmitting puts packets on the car's bus. The only bundled traffic is the author's serial-monitor log, examples/PacketParser/example_log.txt. - CI compiles the example sketches for an ESP8266 D1 mini and for ESP32 board packages 1.0.6, 2.0.17 and the latest, and runs Arduino Lint in strict mode; it does not exercise a bus. PacketParser calls its packet interpretation highly experimental, gathered from various sources and from experiments on the author's own 2003 Peugeot 406, and the README points to external lists of known IDEN values. - MIT. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### bosectl: reconstructing Bose’s BMAP headphone protocol > Controls Bose headphones from Linux and macOS without the Bose app, account or cloud, through Python, Rust and C++ libraries and command-line tools that implement Bose’s BMAP protocol over Bluetooth RFCOMM. The author documents BMAP’s function blocks, operators, payload layouts and error codes in NOTES.md, reportedly worked out by probing RFCOMM channels, capturing Bluetooth traffic while changing settings in the Bose app and testing each operator, and the libraries cover noise cancellation, EQ, spatial audio, button remapping, profiles and device settings. Support is reported per model by the author and contributors. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed commit is the v0.5.0 release of 2026-09-28, which ships Linux x86_64 bmapctl binaries built from the Rust and C++ code with SHA256SUMS; the Rust crate is also on crates.io as bose-bmap 0.5.0, while the Python package installs from the repository through its install scripts or pipx. The README’s device table marks six models, led by the QC Ultra Headphones 2, as verified to differing extents and the Ultra Open Earbuds as partial from a device report; other cataloged BMAP products are recognized by product ID but have no tested configuration. - Needs the user’s own paired Bose headphones and a Bluetooth adapter: BlueZ on Linux, or macOS 10.15+, where the Python library uses PyObjC’s IOBluetooth bindings. The Rust crate is Linux-only, and C++ builds on Linux need CMake, a C++17 compiler and the BlueZ development headers. No Bose software or files are needed at runtime. - README reports probing RFCOMM channels, capturing Bluetooth HCI traffic while toggling settings in the Bose app and testing operators on each function block, and NOTES.md cites class names from the Bose Android app. The app, decompiled code and raw HCI or network captures are not in the repository: captures/ holds eight before-and-after setting snapshots from bmap-capture.py with the MAC address, serial number and other identifiers partly masked, and fixtures/ holds a packet used by the tests. - README says the project uses only BMAP operations the headphones accept without authentication, and that no keys are extracted, no encryption is broken and no traffic is replayed; writes that the app performs after cloud-mediated authentication stay out of reach. USB control is not implemented, and NOTES.md treats the USB interface as being for firmware updates. - CI runs the Python, Rust and C++ test targets on Ubuntu and macOS without headphones; integration tests that need a paired device run only when enabled. MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### Apple Continuity Reverse Engineering Toolkit > Three macOS helpers from SEEMOO Lab that the Open Wireless Link project used to study Apple wireless services such as AirDrop, Wi-Fi Password Sharing, Handoff and Offline Finding from the host side. process_recon summarizes which processes, log categories and subsystems emit log entries matching chosen keywords; keychain_access uses Frida to hook SecItemCopyMatching in a process and exports the keychain items it accesses to JSON; and lldb breakpoint commands print the Handoff and Universal Clipboard messages that the rapportd daemon sends and receives. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository has three commits: the initial release and a paper link on 2021-04-12, and a 2026-08-17 README edit that replaces the former Open Wireless Link website link with a note that the site is no longer associated with the project. There are no releases. The process_recon example was recorded on macOS 11.0 and the breakpoints name private Rapport framework methods; support for current macOS releases is not documented. - Runs on the analyst's own Mac with Python 3 in a virtual environment and Node.js; make install installs the pinned requirements, including frida 14.2.7 and frida-tools 9.1.0 from 2021, plus the prettier dev dependency. continuity_messages needs lldb and SIP's debugging protection turned off, and keychain_access needs SIP fully disabled for system processes; the README warns about the security implications. - Inputs are the analyst's own devices and accounts: the rapportd examples involve an iPhone next to the Mac and keys for the analyst's iCloud devices, so keychain_access output holds real secrets and should be handled accordingly. keychain_access/tests has small Swift and Objective-C hackme programs and a test.sh that stores and then extracts a dummy keychain password; there are no other tests. - The tools watch logs, keychain calls and daemon messages on the host; they do not capture or decode over-the-air Bluetooth LE or AWDL traffic, unlike the separately listed furiousMAC Continuity notes and Wireshark dissector for Continuity advertisements. The README lists the authors' USENIX Security 2021 Continuity and 2019 AWDL papers and a 2020 dissertation as related publications. - GPL-3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### lib-osmo-ble: DJI Osmo Pocket 3 Bluetooth LE protocol library > Reconstructs the DUML-over-BLE protocol that DJI's Mimo app uses with the Osmo Pocket 3 camera as a Node.js library and CLI for scanning, pairing, gimbal commands and roughly 20 Hz position telemetry without the vendor app. The author reports working from a third party's Wireshark captures and dissector of Mimo traffic, a Go client and trial-and-error debugging; PROTOCOL.md documents the frame layout, CRC parameters, BLE characteristic roles and command IDs. A write-up and bundled patch trace seven bugs that kept the earlier node-osmo library from working with the camera, and the author reports that the patched library completed pairing, Wi-Fi setup and RTMP streaming. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-02-21 main head, which is also the last push; package.json declares 1.0.0, and there are no releases or tags. The README says gimbal motor commands are built and parsed correctly but the camera silently ignores them over BLE alone, probably until Wi-Fi streaming is active, while telemetry works. The library itself implements pairing, gimbal control and telemetry only; Wi-Fi setup and streaming were reached with the patched node-osmo. - Requires the user's own DJI Osmo Pocket 3 and a Bluetooth LE host. PROTOCOL.md reports verification on that model only, from macOS, and the patch notes list Apple Silicon macOS Sequoia, Node.js v25.5.0 and @stoprocent/noble 1.18.2; other DJI devices may differ. Pairing sends a client-chosen PIN (love by default in the CLI) that the user approves on the camera. No DJI firmware, app files or the author's own captures are committed. - Plain Node.js ES modules with two runtime dependencies, @stoprocent/noble ^2.3.10 for BLE and crc-full for the CRC8/CRC16 checks, and no build step; npm link installs the dji-osmo CLI. Diagnostic scripts scan for DJI devices, list characteristic properties and decode and CRC-check DUML hex messages. The node-osmo patch applies with git am to a separate clone of datagutt/node-osmo and builds with pnpm and TypeScript. - There are no automated tests; the npm test script is a placeholder that exits with an error. Evidence is the author's write-up, analysis notes on characteristic mapping, byte order, the Node.js buffer-pool bug and a false-positive run, and an experiment index whose raw logs are gitignored. Device behavior remains author-reported. - LICENSE is MIT, although package.json still says ISC. The reference folder copies the CC0-1.0 Wireshark dissector and message notes from xaionaro/reverse-engineering-dji, and node-osmo is MIT. DJI firmware, apps and trademarks keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### Cabana (standalone openpilot-cabana) > Qt desktop CAN and CAN FD analyzer for decoding signals and reverse engineering unknown messages, split out of openpilot's cabana by Dean Lee, a frequent contributor to it, and now maintained on its own. It shows live per-bit change heatmaps, colors bytes by trend such as counters, toggles or noisy data, searches for signals by value or for bits that change together across messages and buses, mutes known bits, plots signals and edits DBC files with undo, while replaying openpilot drives with synchronized camera video. Sources are openpilot routes, Vector ASC, candump and PEAK TRC logs, SocketCAN, comma.ai Panda devices and live streams from a comma device, with a bundled set of opendbc DBC files. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository was created on 2025-12-30; its README says Cabana was originally developed as openpilot's CAN analysis tool and is now maintained independently, while openpilot still carries its own cabana under openpilot/tools/cabana. Latest release at review: v1.1.2, published 2026-03-16 as a Linux x86_64 tarball; the reviewed main commit, of 2026-06-09, is 66 commits ahead of it. - Source builds use SCons, a C++20 compiler and Qt 6 with Charts, SVG, SerialBus and OpenGL, plus capnproto, ZeroMQ, FFmpeg, libusb and the other Ubuntu/Debian packages the README lists, after initializing the openpilot-replay submodule from the same author. The README also names an AUR package for Arch Linux; SConstruct has a macOS arm64 branch, but the release workflow builds only on Ubuntu 22.04. - Analysis needs the user's own CAN data: logs or live buses from their own vehicle and interface, a Panda, or openpilot routes from their own comma device or comma connect account; --demo opens a demo route instead. The tool highlights candidate bits and signals. - MIT (LICENSE, copyright 2025 Dean Lee); the openpilot-replay submodule is also MIT, and data/opendbc holds 93 DBC files from comma.ai's MIT-licensed opendbc. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### DJI MIMO BLE artifacts: reconstructing the DJI Osmo control protocol > Documents the Bluetooth Low Energy message format that DJI's proprietary MIMO app uses to control DJI Osmo devices, as artifacts produced while building the independent djictl CLI. The author derives the framing — a magic byte, length, protocol version, header CRC8, subsystem and message-id fields, a payload and a message CRC16 — from the author's own Android BLE logs, and ships a Wireshark dissector plus an annotated catalog of message types. Many message types are labelled as guesses or unknown; the author reports reaching working livestreaming on a DJI Osmo Pocket 3 and pausing further analysis. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the main-branch head of 2025-06-08. The repository is a set of reverse-engineering notes, not a runnable application: the companion tool djictl lives in a separate repository. The README describes a DJI Osmo Pocket 3. - The method uses the user's own Android phone: the README captures a Bluetooth HCI snoop log through an adb bug report, then opens it in Wireshark. No DJI firmware, app binary or account is committed to or required by this repository, and no captured log is included beyond one Wireshark screenshot. - mimo/ble/message_types.md lists annotated sample frames for about two dozen message types, and the Wireshark dissector in mimo/ble/wireshark-dissector/ maps message-type codes to names; many entries are marked with a question mark or as unknown, so the catalog is partial and author-interpreted rather than a complete specification. - Building the dissector needs Wireshark development headers and pkg-config on a system with a C compiler; its Makefile installs a shared-object plugin into the Wireshark 4.2 plugin directory. The notes record protocol observations only. - The repository is licensed CC0-1.0 (public-domain dedication). DJI, MIMO and Osmo remain trademarks of their owners. ##### Primary sources 1. 2. 3. 4. 5. #### Cat Printer BLE: reconstructing the MXW01 thermal printer protocol > Replaces the vendor phone app for the MXW01 “cat printer”, a small Bluetooth Low Energy thermal printer, with a Windows command-line client. The author reports starting from the iOS-only Moblin implementation and then reverse-engineering the vendor's phone app further, and the client sends CRC8-checked commands to one GATT service while streaming 384-pixel image lines in 1-bit or 4-bit grayscale. Several command IDs remain marked as unknown, and the author tested only this one printer model. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the release 1.2.0 commit of 2025-05-22. The tool prints images with Bayer or Floyd–Steinberg dithering, feeds or retracts paper, and reads battery, paper, temperature and state information; README says it is not an editor and that other printer models are not planned because the author has none to test. - Requires the user's own MXW01 printer. The repository contains only original C# source and a photo; the vendor app the author analysed, any decompiled code and any traffic captures are not included, and no account or vendor software is needed at runtime. - Windows only: the project targets .NET 8 for Windows 10 build 19041 or later with native AOT publishing, using the InTheHand.BluetoothLE and SixLabors.ImageSharp packages; the README asks for the .NET 8 Runtime. - CatPrinter.cs names the GATT service and its command, notification and data characteristics and lists the command IDs, with comments marking several as unknown or guessed. The repository has no test suite or CI, so printing behaviour is author-reported. - MIT license. ##### Primary sources 1. 2. 3. 4. 5. 6. #### a0rfid: an open driver for A0-protocol UHF RFID readers > Reconstructs the A0 serial protocol of R2000-family 915 MHz UHF RFID desktop readers, which ship with only Windows software and an Android app, from the vendor app's native command encoder rather than its misleading Java SDK. A userspace CH340 driver, a Python CLI and GUI, and a small Android app then talk to the reader directly for inventory and tag-memory reads. docs/PROTOCOL.md records the frame layout, checksum, command table, response formats and the different field orders of READ and WRITE. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit of 2026-09-17 is the second of two commits, with no tags or releases. docs/REVERSE.md describes decompiling the vendor APK, finding that the app bypasses its Java codec and calls libnative-lib.so through JNI, reading per-command field layouts from that library's rfid_encode() jump table, and then confirming the frames on hardware. The result is a protocol description and new host software; no reader firmware or vendor app is recovered, and the reader model is not named beyond the R2000 family. - Using the tools requires a compatible A0-protocol reader on its CH340 USB-UART at 115200 8N1, plus tags to test with. Repeating the analysis requires the vendor's own software package and manual, which are not included: REVERSE.md states that the repository contains no vendor code, only frames observed on the wire and code written from them. android/RFID助手.apk is the project's own prebuilt app, built from android/app by android/build.sh. - The Python tools need Python 3 with pyusb and pyserial. --port USB uses the bundled ch340_usb.py userspace driver, which on macOS needs Homebrew libusb; Linux can instead use the stock ch341 kernel driver through /dev/ttyUSB0. The Android app needs Android 7.0+ with USB host; android/build.sh assumes macOS/Homebrew paths, JDK 17, Android SDK platform 34 and build-tools 34.0.0. - test_offline.py runs 17 hardware-free checks of checksums, frame construction and response parsing, several against frames the author recorded from a reader reporting firmware V2.4.1, and docs/ANDROID.md reports 261 offline Android checks against simulated tags. The author reports confirming the read and write paths on one reader and installing and reading with the app on one DJI Smart Controller Enterprise (Android 7.1.2); the app's multi-bank write features were checked only in simulation. The docs also note occasional firmware hangs and a 20 dBm maximum power on the author's unit. - MIT License (2026, a0rfid contributors); the vendor software, SDK and reader firmware keep their own terms. Write, lock and kill commands change real tags. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### eCapture > eBPF-based Linux and Android tool that attaches uprobes to TLS libraries such as OpenSSL, BoringSSL, GnuTLS and NSS, and to Go's TLS stack, recording the plaintext a process sends and receives without a proxy or an installed CA certificate, so analysts can inspect an application's encrypted traffic on a host they control. Output modes write plaintext text, NSS key logs, or pcapng files with embedded TLS secrets for Wireshark and tshark, and a text mode can rebuild complete HTTP/1.1 and HTTP/2 messages from the captured stream. Separate modules audit bash and zsh commands and MySQL and PostgreSQL queries. - Type: Tool - Targets: App · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.9.0, published 2026-10-24; the reviewed master commit is identical to that tag. Release assets are Linux amd64, arm64 and loong64 archives and .deb packages plus Android amd64 and arm64 archives; the Docker image is Linux only. The README states that Windows and macOS are not supported; the separate eCaptureQ GUI can connect from them to a remote eCapture service. - Needs Linux kernel 4.18+ on x86_64, 5.5+ on aarch64 or 6.6+ on LoongArch64, or Android on x86_64 or aarch64. Loading the eBPF programs requires root or, per the minimum-privileges guide, CAP_BPF, CAP_PERFMON and CAP_SYS_PTRACE on kernel 5.8+ (CAP_SYS_ADMIN on older kernels), plus CAP_NET_ADMIN for pcapng mode. Source builds need Go 1.26+, clang and LLVM 9+, cmake 3.18.4+, libelf and the pinned libpcap submodule; make nocore builds for kernels without BTF. - Analysts choose the library or program to observe: the tls module locates the system OpenSSL through ld.so.conf paths or takes --libssl, which can also name a statically linked program, and gotls takes the Go program's ELF path; pcapng mode also needs a network interface and capture filter. Pcap mode records TLS-protected HTTP/1.x and HTTP/2 over TCP and HTTP/3 over QUIC, while the pcapng text source rebuilds only HTTP/1.1 and HTTP/2 over TCP. The project documents root-only end-to-end tests per module (make e2e). - Apache-2.0; libpcap is a git submodule and the bin, dist, deps and bytecode directories hold only placeholders. Captured plaintext and keys can contain passwords, tokens and personal data: the project's defense-and-detection guide asks for written authorization before production use, scoping capture to chosen processes with --pid and handling the data under organizational policy, and describes how to detect eBPF capture tools. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### USBPcap > Tomasz Moń's open-source USB packet capture for Windows. A filter driver installed in the Windows USB device stack records the USB Request Blocks (URBs) exchanged with devices on each root hub, and USBPcapCMD writes them to pcap files in the LINKTYPE_USBPCAP format, which Wireshark dissects. Since 1.2.0.0 the project has recommended running USBPcapCMD as a Wireshark extcap: each root hub then appears as a capture interface, with options to capture selected, all or newly connected devices and to add the descriptors of devices that are already attached. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 1.5.4.0, published 2020-05-22, with a digitally signed USBPcapSetup installer for x86 and x64 Windows 7, 8 and 10 and a source archive that includes debug symbols. The reviewed master commit (2025-01-25) adds two unreleased driver fixes on top of it, one marked critical, for kernel buffer reallocation and the order of read completions. The installer refuses Windows versions older than 7 (1.5.3.0 was the last release for XP and Vista) and Windows To Go, asks Windows 7 users to install a SHA-2 update (KB3033929 or KB4474419) first, and requires a reboot after installation. - Capture runs on the analyst's own Windows machine. Either run USBPcapCMD.exe to choose a root-hub filter instance and an output file, or copy it into Wireshark's global or personal extcap folder; USBPcap support has been in Wireshark since 1.10.0rc1. The README notes that there is no capture engine DLL. The project's tour recommends capturing newly connected devices, or reconnecting a device after capture starts, so that its descriptors appear in the capture for Wireshark's dissectors. - Per the README, source builds use Windows Driver Kit 7.1.0 for the Windows 7 driver, or Visual Studio 2013 with WDK 8.1 Update for the Windows 8 build. Release drivers are attestation-signed through Microsoft's Hardware Dev Center with the author's own, non-public certificate. Self-built drivers are signed with the committed test certificate (certificates/USBPcapTestCert.*) and, as the README explains, load on 64-bit Windows only with test signing enabled. The only other committed binaries are the NSIS SysRestore.dll installer plugin and two public CA cross-certificates. - The project's capture-limitations page says USBPcap records URBs passed between the stack's functional and physical device objects. It therefore does not show bus states, packet IDs, split transactions, wire timing or transfer speed, nor the enumeration that happens before a device has its address; the page says those appear only in a hardware USB sniffer. Interpreting the captured payloads remains the analyst's own protocol work in Wireshark or another dissector. - The README and SPDX headers license the driver under GPL-2.0 and USBPcapCMD under BSD-2-Clause. GitHub detects no license because there is no license file at the repository root; the texts are in nsis/ and wix/. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### Xiaomi Kettle BLE protocol: reconstructing a smart kettle's control interface > Documents the closed Bluetooth Low Energy GATT protocol of the Xiaomi Kettle, which the author reconstructed by decompiling the Mi Home Android app and disassembling its native encryption library. The write-up covers the connection and authentication handshake, the layout of status notifications and the writable settings characteristics, with a small Go reimplementation of the cipher helpers. The author built a kettle-to-MQTT bridge for Home Assistant from it but did not publish that code, and gives no guarantee that the notes work for others. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the final commit of 2018-11-29; the repository is archived and consists of a README and one Go file. README says the kettle is built on a QN9020 MCU, and it names no specific model or firmware version. - Applying the notes needs the user's own kettle and any BLE library that can read, write and subscribe to characteristics; the author used Go with currantlabs/ble. The Mi Home app, its native library and any decompiled output are not included, and the handshake uses a token the client generates itself, so no vendor key is committed or needed. - README lists device limits it observed: heating cannot be started over BLE unless Keep Warm mode is already active, Keep Warm can only be re-enabled with the physical button, and its time limit tops out at 12 hours. - cipher.go contains only the cipher and byte-mixing helpers, not a client. There are no tests, captures or verification records, so the protocol description is author-reported; the README credits jadx-gui and IDA Pro. - WTFPL version 2 (LICENSE.txt). Xiaomi and Mi Home remain trademarks of their owner. ##### Primary sources 1. 2. 3. #### cantools > Python 3 library and command-line tool for CAN bus databases that parses DBC, KCD, SYM, ARXML 3/4 and CDD files and encodes and decodes CAN messages, including simple and extended signal multiplexing and diagnostic DIDs. Its CLI decodes candump output against a database, plots decoded signals from candump logs with matplotlib, dumps each message's bit layout, converts between database formats, generates C pack and unpack code, and monitors a live bus in a text interface through python-can. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 45.1.0, published 2026-10-20 on GitHub and PyPI; the reviewed master commit is 15 commits ahead of that tag. It installs with pip, and pyproject.toml requires Python 3.10+ with python-can, bitstruct, textparser, crccheck and argparse_addons, plus optional extras for plotting (matplotlib), caching (diskcache) and Windows curses support for the monitor. - Bring a database describing the target network and frames captured from it: decode reads candump output on standard input and plot reads candump log files, while monitor takes python-can bus arguments for a live interface, and the README's scripting example sends and receives frames on a SocketCAN channel. The repository's tests/files directory holds sample DBC, KCD, SYM, ARXML and CDD databases and generated C sources used by the examples and tests. - Decoding covers only what the supplied database defines; cantools applies existing message and signal definitions rather than inferring unknown layouts, and the README notes that generated C code is limited to signals of at most 64 bits. MIT licensed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### inspectrum > Desktop analyzer for recorded radio signals, primarily captures from software-defined radio receivers, which the README says handles files of 100 GB and more. A zoomable spectrogram with a tunable filter feeds sample, amplitude, frequency, phase and threshold plots, and cursors measure period and symbol rate and extract symbol values to stdout or the clipboard. Selected time spans, filtered samples and demodulated traces can be exported, and SigMF annotations can be displayed over the spectrogram. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.4.0, published 2025-12-06 as a source-only GitHub release; the reviewed main commit is that tag. Its notes add Qt 6 and SigMF dataset support, raise the CMake minimum to 3.5 and fix a crash on small files. The README points Linux users to distribution packages, macOS users to Homebrew or MacPorts and Windows users to radioconda or conda-forge. - Source builds need CMake 3.5+ (the README still lists 3.1), a C++14 compiler, Qt 6 or, as a fallback, Qt 5 Core, Widgets and Concurrent, FFTW 3, liquid-dsp 1.3.0+ and pkg-config; distribution-specific steps are on the project wiki. CI builds against Qt 5 and Qt 6 on macOS and Ubuntu 22.04 and 24.04, but the repository defines no automated tests. - It reads recordings only; the source has no SDR device, capture or transmit code. Users supply their own SigMF recordings or raw sample files, from complex cf32, cf64, cs32, cs16, cs8 and cu8 to real f32, f64, s16, s8 and u8, selected by file extension or --format (unknown extensions are read as cf32), and set the sample rate with --rate or in the controls. 64-bit samples are truncated to 32-bit internally. - Symbol timing comes from cursors the analyst places; the tool does not infer modulation, framing or protocol fields. GPL-3.0, with source headers allowing version 3 or later; the repository holds only source code, CMake modules and a screenshot. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### PULSAR > Research prototype by Hugo Gascon and colleagues that learns a model of an unknown network protocol from recorded traffic. Messages extracted from PCAP traces are embedded as token or n-gram vectors, clustered by matrix factorization through the PRISMA R module, and turned into a Markov-chain state model with message templates and rules linking fields to earlier messages, written out as model files and a Graphviz state graph. The same models drive the tool's session simulator and stateful fuzzer, described in the authors' SecureComm 2015 paper; this entry covers only the protocol-learning part. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at master commit 3c61178 (2022-06-07), the last push; the repository has no releases or tags, and the CLI reports itself as v0.1-dev. Contributed changes merged in 2021 converted the code from Python 2 to Python 3 with 2to3. There are no tests or CI configuration. - Learning takes PCAP traces of the protocol under study, or the captures that Cuckoo sandbox stored for analyzed samples. The repository commits one example model, models/itunes-xbmc, with the roughly 3 MB iTunes–XBMC capture it was learned from (itunes-xbmc.pcap, part of the 2015 initial commit) and its intermediate Derrick, Sally and Harry files; it bundles no other target data. - INSTALL.md has users clone the PRISMA R module into pulsar/modules, build Konrad Rieck's Derrick and Sally C tools from their repositories, install R, Wireshark's mergecap and Graphviz, and pip-install pygraphviz, progressBar, NumPy and python-Levenshtein, giving package commands for CentOS only. Dependencies are unpinned; PRISMA was last updated in 2018, and Derrick and Sally in 2019. - The README points to the SecureComm 2015 paper for the method and to an AISec 2012 paper on learning stateful models for network honeypots; results reported there are the authors'. Learned templates and state machines are statistical approximations that need analyst validation. - BSD-3-Clause (Copyright 2014 Hugo Gascon); the bundled pulsar/core/sippy SIP stack keeps its own GPL-2.0-or-later notices. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Ford Fiesta MK5 MS-CAN: decoding the dashboard and radio bus > Documents the medium-speed CAN bus that links the 6000CD radio and the dashboard of a restyled (post-2006) Ford Fiesta MK5, worked out by tapping the bus at the radio's QuadLock connector with a Seeed CAN-BUS Shield on an Arduino Uno. The README describes 18 partly or fully decoded message IDs on the 125 kbit/s bus, with byte layouts and scaling formulas: radio text sent to the dashboard LCD over ISO-TP, station names, volume, CD track and steering-column mode and seek buttons, as well as broadcast clock, door, lock, reverse-gear, indicator, light, handbrake, airbag-lamp, pedal, RPM, speed, coolant, key-position, battery and partial VIN data. An incomplete Kayak .kcd definition encodes only the clock and gas-pedal/RPM/speed messages. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Documentation-only project with 25 commits from 2020-08-22 to the reviewed master commit of 2020-09-30, and no releases or tags. It applies to a Fiesta MK5 built after 2006 (the restyled model) with the 2-DIN 6000CD radio; the README notes that the steering-column volume buttons do not appear on MS-CAN, and the decoding of some IDs is partial. - No Ford software or files are needed; reading the bus requires a CAN interface on the CANH and CANL lines at the radio's QuadLock connector, which the README says needs no 120-ohm terminator. The author used a Seeed CAN-BUS Shield V2.0 on an Arduino Uno R3, but the repository holds only the README, the Kayak .kcd file, a connector pinout image and dashboard indicator icons, with no capture logs, sniffer code or Arduino sketch. - Message layouts and formulas such as volume, track time, speed, coolant temperature and battery voltage are author-reported from the author's own car, and the ISO-TP reading of the LCD text messages is credited to a Reddit commenter. The README documents decoding of observed traffic and gives no procedure for sending frames to the car. - The repository has no license file and GitHub detects none. ##### Primary sources 1. 2. 3. 4. #### CanLab > PyQt6 desktop workstation and command-line tool for reverse-engineering CAN bus captures offline. It reads SavvyCAN/GVRET CSV, candump, pcap, Vector BLF/ASC, MDF4 and openpilot logs, then suggests counters, checksums and their algorithms, byte roles, flags, multiplexers, entropy-based field boundaries and cross-ID correlations, decodes J1939 and NMEA 2000 PGNs and reassembles multi-frame messages. A cantools-backed DBC builder checks signal definitions against the captured frames and exports DBC, openpilot DBC, CANdb++, ARXML and Wireshark Lua dissectors, and an optional MCP server offers 29 receive-only analysis tools to assistants. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls CanLab a beta, single-author project. The reviewed commit 8aaa6ff (2026-09-23) declares version 2.1.0 in pyproject.toml, while the latest release is v2.0.0 (2026-09-15) with a Linux x86_64 build and demo videos. README stresses that the analysis is heuristic, suggests candidates rather than identifying signals, and has not been validated on many real vehicles. - Python 3.11+ on Linux, macOS or Windows (developed on 3.12), with optional extras for AI, REST, MCP, hardware adapters, MDF4 (asammdf) and openpilot logs (pycapnp); README asks for 4 GB RAM, 8 GB for the machine-learning features. Live capture uses SocketCAN, a comma.ai Panda, GVRET boards or python-can adapters; README reports one physical adapter used, a CANalyst-II, and the others only on a virtual bus. - Inputs are the user's own captures. The bundled sample is a synthetic Hyundai-style capture generated by a script, the test fixtures are a few lines each, and the real-data acceptance runs fetch public SavvyCAN, CSS Electronics and comma.ai recordings instead of committing them. The opendbc matcher downloads the commaai/opendbc index on first use, and the optional AI analysis sends the selected ID's frame statistics to the configured Anthropic, OpenAI, Groq or Ollama provider. - The application also has bench-only transmit functions behind a global ARM TX switch that is off by default and a blocked-ID list; README restricts them to isolated bench setups. The MCP tools cannot transmit. - README's Testing section reports 753 passing pytest tests (its badge still says 578), interoperability tests against can-isotp, udsoncan and can-j1939, and 99 checks over public real-world recordings; diagnostic requests were tested only against scripted responders. MIT; the NMEA 2000 table derives from CANboat (Apache-2.0) and the cereal schema from comma.ai (MIT). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Facedancer > Python library for implementing USB devices in software, with a hardware peripheral such as Cynthion or GreatFET acting as a remote-controlled USB controller attached to the target host. Its USBProxy mode sits between a real device and a host, forwarding transfers while filters log, decode or modify them for USB protocol analysis; the README notes this suits devices whose software you do not control, such as embedded systems or game consoles. Version 3 is a ground-up rewrite of the emulation core that ships keyboard, mass-storage and FTDI serial device models plus HID and logging proxy filters, and no longer runs legacy 2.9.x scripts. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs a supported board selected with the BACKEND variable: Cynthion (cynthion), GreatFET One and other LPC4330 boards (greatfet), GoodFET-based Facedancers such as the Facedancer21 (goodfet), Raspberry Pi Raspdancer boards (raspdancer) or HydraDancer and HydraUSB3 (hydradancer). The README says MAX3420/MAX3421-based boards cannot emulate more complex devices or act as USBProxy MITM devices, and that HydraDancer boards do not support host mode. - Latest release at review: 3.1.3, published 2026-05-22 on GitHub and PyPI and identical to the reviewed main commit; pyproject.toml requires Python 3.10+ with pyusb, libusb1, pyserial, prompt-toolkit and hid-parser. The README says Facedancer 3.0 does not work on Windows and runs only on GNU/Linux, while the getting-started guide narrows the warning to Windows control hosts with GreatFET and the proxy guide says USBProxy must run as root on macOS to claim the proxied device. - USBProxy needs the real device being proxied, identified by its vendor and product IDs, and the analyst's filters decide what is forwarded, logged or changed; the README calls the proxy feature complete but in need of more documentation. The repository holds Python sources, examples, tests and documentation, with no board firmware. Emulate and proxy only hosts and devices you own or are authorized to test. - BSD-3-Clause licensed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Mirage > Python framework from IoT-security research at LAAS-CNRS for analysing wireless communications, with lightweight protocol stacks for Bluetooth Low Energy, Bluetooth, Enhanced ShockBurst, Mosart, Zigbee, Wi-Fi and infrared that a command-line interpreter drives through chainable modules. For protocol analysis it offers per-protocol scan, information and sniffing modules, BLE ATT/GATT discovery that saves the discovered attribute table, HCI monitoring of an Android phone through its btsnoop log over ADB, PCAP reading and writing, and an experimental HackRF software-radio receive path with FSK demodulators and BLE and Zigbee decoders. Its author has deprecated it in favour of the WHAD tool suite. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Version 1.2 according to mirage/__init__.py; the repository has no tags or GitHub releases. The README, last edited 2025-04-13 at the reviewed commit, declares the project officially deprecated and no longer maintained and points to its successor WHAD (whad-team/whad-client); the last code change is from 2022-11-24. It installs from this source tree with setup.py, since the PyPI package named mirage is an unrelated JWST data simulator. - setup.py depends on scapy, pyusb, pyserial, pycryptodomex, keyboard, psutil, terminaltables and matplotlib, and its classifiers list Python 3.6 and Linux. Live capture needs supported radio hardware: Bluetooth HCI adapters, a BBC micro:bit running BTLEJack firmware, Nordic and Sniffle sniffers, Ubertooth, a Crazyradio PA for Enhanced ShockBurst and Mosart, an RZUSBStick for Zigbee, a Wi-Fi interface, the IRma infrared device, a ButteRFly nRF52840 dongle or a HackRF One for the experimental SDR path. Their firmware lives in separate repositories; this repository holds only Python sources and no firmware images. - Without radio hardware, PCAP files serve as input interfaces (BLE link-layer PCAPs use DLT 256), and the ADB and hcidump interfaces read HCI traffic recorded on an Android phone or Linux host. The documentation site linked from the README returned HTTP 404 at review; its Sphinx sources are on the LAAS Redmine. - The README and setup.py describe Mirage as an offensive framework whose modules and example scenarios also cover man-in-the-middle, jamming, hijacking, cloning and injection, including experimental InjectaBLE attacks. Capture only devices and networks you are authorised to observe. - MIT (LICENSE.txt, copyright 2019 Romain Cayre). The README cites SSTIC 2019 and IEEE ISSRE 2019 papers describing the framework. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### uniden-r8-ble: reconstructing the Uniden R8 radar detector's BLE telemetry > Decodes the undocumented Bluetooth Low Energy output of a Uniden R8 radar detector into a receive-only collector for a Raspberry Pi, with live telemetry, alert start/update/end events, SQLite history and optional MQTT and Home Assistant publishing. The author worked the protocol out from the wire on a real detector, building on earlier R8w findings from AegisX86/UnidenR8wlink, and grades every claim in PROTOCOL.md by its evidence: measured on this R8, seen on another model, decompiled from an app but untested, or inference. Unknown fields are carried through raw rather than given invented meanings. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the main-branch head of 2026-09-09 (package version 0.1.0). README reports 1 Hz telemetry decoded without errors on a moving vehicle and one real Ka-band alert captured on the R8, while PROTOCOL.md still grades active-alert fields as inherited from R8w captures; it also states that the live stream carries no position, and that settings blocks remain undecoded. - Requires the user's own Uniden R8 and a Linux host with BlueZ, documented on a Raspberry Pi Zero 2 W with an optional systemd service, gpsd-connected GNSS receiver, PiSugar battery and MQTT broker. No vendor app, firmware or captures are committed; README says raw captures are kept in a git-ignored local store, and Bluetooth addresses and coordinates are redacted before publication. - Python 3.11+, with bleak as the optional BLE extra and paho-mqtt for publishing. README says the installed package sends no application commands to the detector and that an AST audit, run by selftest and in CI, checks this; commands used for the coordinate experiments were sent from separate scripts at the owner's instruction, as SAFETY.md records. - CI runs ruff and pytest on Python 3.11–3.13 plus a selftest job; README badges 754 tests, which need no hardware, broker, gpsd or network. README notes that MQTT and the dashboard have not met real hardware. - MIT license. README states the project is not affiliated with or endorsed by Uniden and is diagnostic software, not a substitute for the detector's own display or warnings. HANDOFF.md is written for a person or an agent taking over the project. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Protobuf Decoder > Pawit Pornkitprasan's React web application for decoding Protocol Buffers data without the original .proto files, offered as a hosted page or run locally, with all decoding done in the browser. Pasted hex or base64 input, or an uploaded file, is split into a table of byte ranges, field numbers, wire types and contents: varints are shown as unsigned, two's-complement and zigzag integers, fixed32 and fixed64 values as integers and floating-point numbers, and length-delimited fields as nested messages when they parse cleanly, otherwise as UTF-8 strings or bytes. It skips a leading gRPC message header and can optionally split a stream of varint length-delimited messages. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - No releases or tags; package.json declares a private 0.1.0 package. The reviewed master commit of 2026-10-17 is a Dependabot dependency bump, and the most recent functional changes added file upload in 2024 and varint length-delimited input in 2025. CircleCI runs the Vitest unit tests on Node 20.11 and uploads coverage to Codecov. - The hosted page at protobuf-decoder.netlify.app needs only a browser, and the app states that all decoding is done locally in JavaScript. Running it locally needs Node.js and npm: npm install, then npm start for the Vite development server, or npm run build for a static build. - Decoding is schema-less and heuristic: field names and declared types are not recovered, each length-delimited field is guessed to be a nested message, string or bytes, the source marks repeated-field support as a TODO, and the group wire types are not handled, so decoding stops there and the remaining input is shown as left-over bytes. It only decodes; there is no editing, re-encoding or proxy integration, and users supply their own captured messages. - MIT (Copyright 2019 Pawit Pornkitprasan). ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### opendash: reconstructing the Scanmatik SM3 J2534 adapter protocol > Speaks the undocumented protocol of the Scanmatik SM3, a J2534 vehicle interface that otherwise talks only to its own Windows software, and exposes it to an Android phone as an ELM327 bridge with a diagnostics app on top. The author recovered the framing — a 16-byte header with sequence, CRC-based and sum-based check words, opcode and length — by capturing the device's bundled driver and measuring the replies, and docs/protocol.md separates what was established from what is still open. Reported results come from one Opel Astra J over five sessions with the car present. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the main-branch head of 2026-10-16, one README-only commit after the v0.4.2-beta release. README reports reading identification, standard OBD-II data and GM service 0x22 parameters, and module-driven streaming at about 98.7 Hz per packet, on one Opel Astra J 1.7 CDTI; the ELM327 bridge has been exercised against emulated modules but not yet against the car, and two long recordings stopped early for reasons not yet understood. - Requires the user's own Scanmatik SM3 reached over its Wi-Fi access point. Standard SAE J1979 PIDs ship with the app; richer per-brand catalogues are generated from a GM GDS2 installation the user already has, and README says they are not distributed because the data belongs to GM. No catalogue data, vendor driver, firmware or driving recordings are committed. - The app is read-only by design: README lists the diagnostic services it permits, and requests that write data, control inputs and outputs or routines, clear codes or request security access are refused before reaching the socket. One known actuator command sits behind a settings switch that requires the phone's device lock and is off by default. - Android 8.0+ app built with Gradle, AGP 9.4.1, Kotlin 2.4.20 and JDK 21. A separate Rust core implements framing, check words, ISO-TP and ELM327 handling but is not yet wired into the app, whose Kotlin bridge README says has moved ahead of it. CI runs cargo test, which replays 200 recorded writes and checks the computed check word against what the device sent, and builds the debug APK without the Rust core; Kotlin unit tests exist but are not run in CI. - GPL-3.0 (LICENSE). Scanmatik, GM, GDS2 and Opel remain trademarks of their owners. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### gr-lora > GNU Radio out-of-tree module by Pieter Robyns and co-authors for receiving and decoding LoRa physical-layer frames with a software-defined radio, implementing the modulation features described in patents and blog posts. Its receiver channelizes the input, detects and synchronizes to LoRa chirps with clock-drift correction, and decodes symbols through Gray mapping, deinterleaving, dewhitening and Hamming decoding into header and payload bytes, which a message socket sink can forward over UDP port 40868. The bundled flowgraphs decode recorded traces or live captures, and the README lists HackRF One, USRP B201, RTL-SDR and LimeSDR as tested receivers. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The newest commit on master, from 2021-12-10, merged a port to GNU Radio 3.9: CMake requests GNU Radio 3.9, the Python bindings use pybind11, and the library links liquid-dsp and log4cpp. The README was not updated for the port and still lists Python 2, SWIG and wx dependencies, and its Docker image installs python2 packages on an unpinned Arch Linux base; the Travis CI configuration builds GNU Radio maint-3.8. A gr3.7 branch keeps the older code. - Input is IQ samples from an SDR or a recorded file. The receiver block takes sample rate, center frequency, channel list, bandwidth, spreading factor, coding rate, implicit-header, CRC and reduced-rate settings that must match the transmission. apps/lora_receive_file_nogui.py offers to download an example 868.1 MHz SF7 trace from the authors' university server, and further traces are in the separate gr-lora-samples repository. The README lists LoPy, Dragino HAT, Adafruit Feather 32u4, Microchip RN2483 and SX1276 boards as tested transmitters. - The README states that payload and header CRCs are not checked and that several channels cannot be decoded at once; its changelog marks version 0.7's downlink, reduced-rate implicit-header and arbitrary-bandwidth support as experimental. The newest version tag is v0.6.2, so 0.7 exists only on master. docs/test-results holds the authors' decoding rates from suites rerun on 2021-12-01 during the port, such as 100% on the short USRP traces, and the author considers LoRa fully reverse engineered as of version 0.6, citing close to 100% accuracy on clear signals; these are author-reported results. - GPL-3.0 (LICENSE). The README asks research users to cite the Zenodo record 10.5281/zenodo.853201. It covers the LoRa physical layer only. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### termshark > Graham Clark's terminal user interface for tshark, inspired by Wireshark and aimed at inspecting captures on a remote machine, for example over SSH, without copying them back to a desktop. It reads pcap files, fifos or standard input, or captures live from one or more interfaces, and shows a packet list filtered with Wireshark display filters next to the dissected packet structure and a hex view. Analysis views reassemble TCP and UDP streams with search and client- or server-only display, list Ethernet, IPv4, IPv6, UDP and TCP conversations that can be turned into display filters, and search packet contents; Wireshark-style profiles can reuse a linked Wireshark profile's packet colors. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v2.4.0, published 2022-07-11, with builds for Linux (x64, arm64, armv6), macOS (x64, arm64), FreeBSD, NetBSD, OpenBSD and Windows x64. The README also lists Arch, Debian, FreeBSD, Homebrew, MacPorts, Kali, NixOS, Snapcraft, Termux and Ubuntu packages. The reviewed master commit (2022-11-01) is 14 commits ahead of that release, including unreleased hex-view navigation changes, and master has had no commits since. - tshark from Wireshark, version 1.10.2 or later, must be on PATH at run time, because termshark relies on it for all packet analysis; protocol coverage is therefore whatever the installed tshark dissects. Live capture uses dumpcap and works only where the user is permitted to capture. By default, captured packets are saved in the user's cache directory (.cache/termshark/pcaps on Linux), or to a file given with -w. Copying packets to the clipboard over SSH needs X11 forwarding or a custom copy command. - Builds as a single Go executable with go install (module github.com/gcla/termshark/v2; go.mod declares Go 1.13). Besides theme files, the repository commits only small test captures (pkg/pcap/testdata and scripts/pcaps/telnet-cooked.pcap). - MIT license. The README notes that tshark has many features termshark does not expose yet. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### SigDigger > Qt graphical digital signal analyzer by Gonzalo José Carracedo Carballal, built on his Suscan and Sigutils libraries; its user manual names reverse engineering of radio signals with unknown parameters as the main use. It receives from SoapySDR-supported SDRs or plays back recorded I/Q and WAV files, shows spectrum and waterfall views, and lets analysts measure captured stretches in a time window with carrier recovery, transforms and symbol sampling. Inspector tabs run user-tunable PSK, FSK and ASK demodulators with parameter estimation and can forward demodulated samples; it also decodes analog video and previews AM, FM and SSB audio. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at master commit 70f688b (2026-02-11); the README says SigDigger, SuWidgets, Suscan and Sigutils all keep their latest working changes on master. The last stable release is v0.3.0 (2022-07-05, with an x86-64 Linux AppImage and a macOS DMG); a rolling pre-release tagged latest, rebuilt on 2025-04-08, provides a 0.3.0 Linux AppImage and a Windows zip. The bundled user manual is version 0.3.0, dated 2022-06-27, and calls itself a draft. - The README targets GNU/Linux and macOS: Linux users can run the AppImage (the manual asks for glibc 2.27 or newer), macOS DMGs are made on request, and the README says reproducible Windows builds with all DLL dependencies are not currently possible, leaving Windows users to build from source. Source builds install Sigutils and Suscan (CMake), then SuWidgets and SigDigger (qmake with Qt 5.9+ or Qt 6), in that order; SigDigger.pro also links FFTW through pkg-config. The README also offers the author's blsd script, which builds everything in a local directory. - Live analysis needs an SDR receiver supported by SoapySDR; without one, recorded RF/IF data can be loaded from WAV or raw complex-float I/Q files. The repository commits no signal recordings. Plugins such as AmateurDSN, APTPlugin, AntSDRPlugin and ZeroMQPlugin live in separate repositories. - LGPL-3.0 (LICENSE); the README says the spectrum widget is Gqrx's plotter with modifications. The manual describes symbol decision as human-guided, so recovered symbols and any protocol interpretation remain the analyst's work. ##### Primary sources 1. 2. 3. 4. 5. 6. #### OWL: an open Apple Wireless Direct Link implementation > Reimplements Apple Wireless Direct Link (AWDL), the proprietary Wi-Fi ad hoc protocol Apple devices use for peer-to-peer links such as AirDrop, as a user-space C daemon for Linux and macOS; the README calls it the result of reverse engineering by the Open Wireless Link project at TU Darmstadt's SEEMOO lab. OWL runs the master election, synchronises availability windows and the channel sequence, parses and crafts AWDL action and data frames, and provides an awdl0 virtual interface with a link-local IPv6 address, so unmodified IPv6 programs such as SEEMOO's OpenDrop AirDrop client can reach Apple devices. The authors describe the recovered protocol in a MobiCom 2018 paper. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Archived; the README calls OWL experimental and no longer maintained, says it does not support all AWDL features and may be incompatible with later AWDL versions, and states no affiliation with or endorsement by Apple. The last code change is a January 2022 buffer-overread fix; the 2026-08-17 and 2026-10-12 commits only replaced links to the former owlink website, which the README says is no longer associated with the project. There are no tags or releases. - Needs a Wi-Fi card with active monitor mode and frame injection, used directly: the authors developed and tested with an Atheros AR9280, and virtual machines without USB or PCIe passthrough and WSL are not supported. OWL runs with sudo on one wireless interface, which it then uses only for AWDL, so no access-point connection can run alongside it; channels 6, 44 and 149 are available subject to the local regulatory domain, and OWL can only monitor when it cannot use the chosen channel. - Builds with CMake 3.5+ and a C compiler against libpcap, libev and, on Linux, libnl; on macOS it uses CoreWLAN and needs a tun/tap driver such as tuntaposx. googletest and the radiotap library are git submodules. The workflow on ubuntu-latest and macos-latest builds the code and runs the googletest suite for frame-buffer parsing, election, peers and synchronisation; interoperation with Apple devices is the authors' report. - Nothing from Apple is needed to build it, and the repository holds only source code, tests, build files and an architecture diagram; using it requires nearby Apple devices with AWDL. README lists known gaps: static election metric and counter values, a channel sequence fixed at start-up because adapting it would need a better understanding of Apple's implementation, and no concurrent AP connection. It also cites the group's MobiCom 2018 protocol paper and demo and a USENIX Security 2019 security analysis of AWDL. - GPL-3.0 (COPYING); AWDL and AirDrop remain Apple's proprietary technology. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### grpc-tools > Bradley Kemp's suite of gRPC debugging tools, described as Fiddler or Charles for gRPC. grpc-dump runs as a local HTTP(S) proxy that logs every gRPC and gRPC-Web call an application makes as a JSON stream with service and method names, metadata, any error status and each message both raw and parsed; without the .proto files it decodes messages heuristically. grpc-replay re-sends the recorded requests and checks the server's responses, grpc-fixture answers clients from a saved dump, and the grpc-proxy Go library underlies them. - Type: Tool - Targets: App · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at master commit 928b1b9 (2023-11-14), the last push. The latest release is v0.2.6 (2020-06-30), and master has six later commits, mostly dependency bumps plus a 64 MB message-size limit. The README calls the tools alpha and warns of breaking changes between releases. - Install through the author's Homebrew tap, the release zips (amd64 builds for Linux, macOS and Windows) or go install; go.mod declares Go 1.13 and requires grpc-go v1.26.0, golang/protobuf v1.4.2 and protoreflect v1.7.0. The application under test must be pointed at the proxy, and the README notes that clients connecting to localhost usually ignore proxy settings; the system_proxy option is documented for macOS. - Clients that expect TLS need a certificate they trust for the intercepted domains; the README recommends mkcert-generated certificates installed on the user's own machine. Supplying .proto roots or descriptors gives exact decoding instead of the heuristic one. The integration tests use a small test.proto and their own recorded dump and fixture files; CircleCI configuration is included. - MIT license. Dumps contain full message contents and metadata, including any credentials in headers, so they should be treated as sensitive. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### QuestPad: a USB gamepad from the Quest Touch radio protocol > QuestPad implements the Quest Touch controllers' private 2.4 GHz radio protocol on nRF52840 firmware so a computer can use them as a USB gamepad. Its protocol reference documents pairing, AES-CCM encrypted controller packets, 2 ms link frames and input data; the firmware exposes generic gamepad, DS4 and XInput modes. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Nordic nRF52840 Dongle or nice!nano v2 and Quest Touch controllers are required. - **Prerequisites:** Python 3 is required for the control panel. - **Testing evidence:** Quest 3/3S controllers and Linux support are listed as untested. - **License:** The repository provides MIT and Apache-2.0 licence files. ##### Primary sources 1. 2. 3. #### Stadiacast: reconstructing the Stadia Controller's Wi-Fi service > Stadiacast recreates the network service used by the Stadia Controller's Wi-Fi firmware so the controller can connect to a local computer. The receiver answers boot and discovery requests, completes WebRTC and DTLS sessions, decodes input and sends rumble commands. Protocol notes record findings from firmware reading and live controller runs, with protobuf schemas and receiver code in the repository. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Stadia Controller with Wi-Fi firmware; the author tested ota.282115. - **Prerequisites:** A Windows, macOS or Linux host on the controller's network; running from source requires Python 3.11+. - **Prerequisites:** Linux needs root or CAP_NET_BIND_SERVICE to bind the required low ports. - **License:** MIT license. ##### Primary sources 1. 2. #### os-xgs-npu: reconstructing Sophos XGS coprocessor interfaces > os-xgs-npu reconstructs interfaces to Sophos XGS appliance coprocessors through FreeBSD kernel modules and an OPNsense plugin. The work documents undocumented registers, PCIe device families and measured coprocessor behavior to expose front ports and offload firewall flows and IPsec associations. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Sophos XGS hardware and a matching OPNsense or FreeBSD environment; kernel modules are built on the appliance. - **Limits:** The author says the project is still being completed; two coprocessor families currently respond. - **License:** BSD-2-Clause license. ##### Primary sources 1. 2. #### LibreMP: an Epson EasyMP screen caster from packet-capture research > LibreMP casts desktop screens to Epson EasyMP projectors using a protocol reconstructed from Windows client packet captures. Its Rust core handles registration and login messages, projector QR decoding, JPEG tile streaming and changed-region updates; a CLI and Tauri interface use the same core. The project documents control on TCP 3620 and video on TCP 3621. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An Epson EasyMP-compatible projector and a supported desktop operating system; building requires Rust, Cargo, Node.js, npm, NASM and CMake. - **Limits:** The keyword-protected login path has not been tried against real hardware; Windows and macOS casting still need hardware testing. - **License:** MIT License. ##### Primary sources 1. 2. #### Sony CDX-A250: reconstructing the LCD panel interface > Sony CDX-A250 LCD Panel reconstructs the serial control needed to drive the radio's detachable display independently through its LC75826W driver. Wiring notes, CCB transfer documentation, and an Arduino sketch cover display-data groups, control bits, test patterns, and experimental segment mapping. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented setup uses a Sony CDX-A250 front panel, an Arduino-compatible board, bench power, a pushbutton, and wiring components. - **Scope:** The project documents the demonstrated panel setup and the LC75826W interface used by its Arduino sketch. - **License:** Code is MIT licensed; original documentation and project media are CC BY 4.0. ##### Primary sources 1. 2. #### MacroPad: reconstructing a USB macropad configuration protocol > MacroPad reconstructs the USB HID configuration exchange of a 12-key, two-knob macropad identified as 1189:8840 and implements it in a Linux GUI. The author documents capturing MINI_KEYBOARD.exe traffic with usbmon, decoding configuration and commit reports, and replaying captured packets in tests. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux, Python 3.9+ and the 1189:8840 macropad are documented for the supported configuration path. - **Limits:** Other pad IDs are reported as unsupported until their layout and protocol are added. - **License:** GPL-3.0 license. ##### Primary sources 1. 2. #### Monix: reconstructing Audient iD USB mixer control on Linux > Monix implements Linux mixer control for Audient iD USB audio interfaces through a companion kernel module, protocol library and GUI. Its protocol documentation maps USB control requests from official-app captures and macOS binary analysis, covering routing, faders, metering and device profiles. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires Linux kernel 5.9 or newer and an Audient iD-series interface. - **Prerequisites:** Building requires a C++17 toolchain, CMake 3.16 or newer, kernel headers, ALSA, GLFW and OpenGL development packages. - **Limits:** The author reports hardware testing on iD24; other models have limited or unconfirmed routing support. - **License:** MIT license. ##### Primary sources 1. 2. 3. #### Scooter Link: a Xiaomi scooter client built from BLE protocol research > Scooter Link implements an Android client for Xiaomi Electric Scooter 5 Pro and 5 Max using a reconstructed BLE authentication protocol. Its research log covers GATT characteristics and investigation of the ECDH P-256, HKDF-SHA256, and AES-CCM exchange; the app reads ride and battery data and controls supported settings. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Android and a supported Xiaomi Electric Scooter; the author reports testing the 5 Pro and 5 Max. - **Limits:** Other listed models have experimental read-only support or remain untested. - **License:** PolyForm Noncommercial License 1.0.0. ##### Primary sources 1. 2. #### Sound Blaster AE-9: reconstructing Linux control from Windows driver analysis > Sound Blaster AE-9 Linux support reconstructs card and Audio Control Module behavior using static analysis of Creative's Windows drivers and hardware observations. The included investigations document CtxHda.sys, CtxHdb.sys, and the ACM's SysEx-framed UART protocol; the driver implements selected playback and controls. - Type: Case study - Targets: Binary · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux kernel 6.17 or newer, headers, DKMS, build tools, PipeWire, and WirePlumber are specified. - **Prerequisites:** A Creative driver package is needed to extract a DSP firmware segment locally. - **Limits:** The author reports support for 7 of 16 listed features across the card and Audio Control Module; recording is disabled because opening capture hard-locked the test machine. - **License:** GPL-2.0 license. ##### Primary sources 1. 2. 3. #### thermalmaster: a Go client for ThermalMaster camera USB commands > thermalmaster implements a Go USB client for ThermalMaster P3 and P1 thermal cameras using documented VDCMD control transfers. It captures PNG frames, streams thermal and IR video to Linux v4l2loopback, and records USB command framing and model identifiers for interoperability. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A ThermalMaster P3 or P1 camera, a C toolchain, pkg-config and libusb development files. - **Prerequisites:** Linux with v4l2loopback is required for video streaming; USB permissions must be configured. - **License:** CC0-1.0 license. ##### Primary sources 1. 2. #### open-rknpu: Rockchip NPU task-program reconstruction > open-rknpu reconstructs a task-program interface for the Rockchip RV1103/RV1106 NPU from board experiments and black-box comparisons. Its Python compiler emits register commands, weight and quantization blocks, and a container for bounded static ONNX convolution graphs; a C runtime submits them through /dev/rknpu. Research files document register and numerical findings. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Host compilation needs Python, NumPy and ONNX; hardware runs need a compatible board and cross toolchain. - **Prerequisites:** The reference board is a Luckfox Pico Mini B with the shared RV1106 NPU IP and driver v0.8.2. - **Scope:** Dynamic shapes, LSTM/GRU, 1-D convolution, MatMul/Gemm and multi-stage detection heads are outside the documented scope. - **License:** MIT license for the compiler, runtime, tests, examples and documentation. ##### Primary sources 1. 2. #### hardsid4u: reconstructing the HardSID 4U USB protocol > hardsid4u reconstructs the HardSID 4U USB protocol and implements a libusb Python driver for its SID-chip sockets. The investigation combines vendor-binary analysis, USB captures, and hardware probes to document command framing, initialization, register writes, timing, and flow control; a MIDI instrument uses the driver. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A HardSID 4U device is needed for hardware use; the core driver requires Python 3.9+, libusb1, and libusb. - **Prerequisites:** MIDI output additionally uses python-rtmidi and CoreMIDI as documented. - **Limits:** The author reports that a stalled device may require a physical power cycle; isochronous mode and SID file playback are unused or absent. - **License:** MIT license. ##### Primary sources 1. 2. 3. #### PyEilik: a client for the Eilik robot's USB protocol > PyEilik implements control of an Eilik desk robot over a recovered USB serial protocol. Its C library and Python wrapper move four servos, read and update the 128×64 display, and play video with synchronized movement. The protocol reference documents 125000-baud framing, command IDs, checksums and acknowledgements. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS and Python 3.9 or newer are required; the serial link uses an Apple-specific ioctl for 125000 baud. - **Prerequisites:** Video playback requires ffmpeg on PATH; PNG display requires the image extra. - **Limits:** The robot's speaker cannot receive audio through the documented protocol. - **License:** MIT license. ##### Primary sources 1. 2. #### libfprint-goodixtls: a reconstructed Goodix GXFP5187 fingerprint driver > libfprint-goodixtls reconstructs communication with the Goodix GXFP5187 SPI fingerprint sensor in the Huawei MateBook X Pro as a libfprint TOD driver. It reads a PSK from sensor RAM, establishes the sensor's TLS-PSK channel, decodes captured images, and uses local descriptors for host-side matching. The author reports enrolment and verification through fprintd and GNOME Settings; detailed reverse-engineering notes are kept outside the repository. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Goodix GXFP5187 sensor on the Huawei MateBook X Pro MACH-WX9, with a usable spidev node. - **Scope:** The detailed protocol-frame and matching-engine notes are kept separately from the repository. - **Testing evidence:** Matcher error rates in the README are author-reported results from the described capture sets. - **License:** LGPL-2.1 License. ##### Primary sources 1. 2. #### RazerStream: reconstructing Stream Controller device control > RazerStream replaces the retired control software for the Razer Stream Controller with a macOS app, Swift protocol library and CLI. Its documented device protocol runs over a USB serial port, performs a WebSocket upgrade, then exchanges framed commands and input events. The app configures touchscreen tiles, knobs, buttons and LEDs. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS 14 or newer and a Razer Stream Controller with USB VID 0x1532 and PID 0x0D06. - **Prerequisites:** Xcode 16 or newer to build from source; Accessibility permission is needed for keystroke and media-key actions. - **Limits:** The app targets macOS only. - **License:** MIT license. ##### Primary sources 1. 2. #### DABplay+: reconstructing USB DAB+ dongle control > DABplay+ implements an Android DAB radio using a reverse-engineered USB dongle protocol. It drives the DTR-100 family directly, decodes broadcast data and audio, and documents additional dongle protocols alongside hardware findings and tests. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Android 8+ and a supported USB DAB+ dongle are required. - **Prerequisites:** Building requires JDK 25 and the Android SDK. - **Testing evidence:** Only the first listed dongle family has been tested on real hardware; several on-air features remain unconfirmed. - **License:** MIT. ##### Primary sources 1. 2. #### PocketPrinter5890: reconstructing the Lidl 5890 printer protocol > PocketPrinter5890 reconstructs the BLE printing protocol of Lidl's Tronic, SILVERCREST, and Parkside model 5890 pocket printers. Its specification documents activation writes, flow-control credits, and raster bands; Swift, Kotlin, and TypeScript libraries implement printing for Apple devices, Android, and browsers. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The browser demo requires Web Bluetooth in Chrome, Edge, or Opera. - **Scope:** The documented reference device is model A2Y with firmware V1.06LY; other revisions may differ. - **Limits:** Firmware updating is not implemented, and roughly twenty transcribed commands were not executed on the reference firmware. - **License:** MIT license. ##### Primary sources 1. 2. #### Parking sensor kit: reconstructing its display protocol > This parking-sensor investigation reconstructs the signal sent from a kit's controller to its display. Oscilloscope observations and tests with different sensor states identify fields in roughly 48-bit frames for sensor address, connection and proximity. A PlatformIO example for ATmega328P reads and reports the parsed frames. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The example targets an ATmega328P microcontroller and a compatible parking-sensor kit. - **Prerequisites:** Check signal voltage before connecting a microcontroller; the documented unit exceeded 5 V. - **Limits:** Controller electronics vary across similar kits, so the code may need changes. - **License:** No licence file in the repository. ##### Primary sources 1. #### pyhaseiq: reconstructing the older Hase iQ stove's WebSocket protocol > pyhaseiq reconstructs the local WebSocket protocol of Hase iQ wood stoves used with the flamemonitor app and implements an asynchronous read-only Python client. The specification records base64-encoded request and response frames, serial dialogue and observation status for each finding; the client reads combustion phase, temperature and performance. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.13 or newer and a supported flamemonitor-generation Hase iQ stove on the local network. - **Limits:** The newer HASE iQ app generation is unsupported; the API is described as alpha. - **Scope:** The library implements no write commands. - **License:** MIT license. ##### Primary sources 1. 2. #### LED Controller: a BanlanX BLE client with audio-feed protocol findings > LED Controller uses BanlanX BLE commands to control SP611E-family LED strips from a desktop app. Its documentation maps GATT commands and state notifications, and reports probing an audio-feed message used by the controller’s music effects; included tools inspect advertisements, GATT state and Bluetooth captures. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A PC with Bluetooth Low Energy, uv and a compatible BanlanX controller. - **Limits:** PC audio input works on Windows only; BanlanX v3 models are implemented from UniLED documentation but untested on hardware. - **License:** No licence file in the repository. ##### Primary sources 1. #### Zemismart Blind Controller Protocol: RF command reconstruction > Zemismart Blind Controller Protocol documents the 433.92 MHz OOK PWM messages used by Zemismart motorized blind remotes. It records pulse timing, payload fields and formulas for channel and button commands, with Python scripts to capture IQ samples and encode or decode transmissions. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Zemismart motorized blind remote captures; the capture script uses LimeSDR and SoapySDR. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### vanmoof-certificates: decoding VanMoof bike certificates > vanmoof-certificates decodes the access certificates used with VanMoof SA5 and Series 6 bikes. It documents an Ed25519 signature followed by a CBOR payload containing bike serials, user identity, access role and expiry, and provides Go code to request, parse and check certificates. The source says the SA5 verification key was recovered from a bike BLE certificate. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A VanMoof account with a supported bike is needed to request certificates. - **Limits:** The source states that the Series 6 signing key is not yet known, so its signatures are not verified. - **License:** No licence file in the repository. ##### Primary sources 1. #### Holley EFI Parser > Holley EFI Parser decodes Holley DL and DLZ data logs and live ECU CAN messages. Its Python tools decompress DLZ with byte swapping and RLE, parse versioned DL records into pandas DataFrames, and decode CAN messages using supplied DBC files. The documentation records the proprietary 29-bit CAN identifier layout. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python and the package dependencies are required; live CAN use additionally needs a configured Linux CAN interface. - **Limits:** V4 DL support is partial, and V5 files require conversion to V6 with Holley software. - **Testing evidence:** The author reports DLZ decompression accuracy from nine file pairs. - **License:** MIT License. ##### Primary sources 1. 2. #### CAN Bus Parser > CAN Bus Parser decodes VanMoof SA5 and later bicycle CAN captures from CSV or candump input. It reassembles multi-frame CBOR messages, maps device IDs and heartbeat frames, and provides live or saved-capture diagnostics for components such as the electronic lock and shifter. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Go 1.24 or newer. - Live capture requires Linux SocketCAN and a CAN adapter supporting 1 Mbps and 29-bit extended IDs. ##### Primary sources 1. 2. #### Cosmic Byte Firestorm Controller: a USB protocol client for mouse settings > Cosmic Byte Firestorm Controller implements a Linux client for the mouse's recovered USB settings protocol. Its Python CLI sends control and interrupt transfers to configure lighting effects, per-DPI indicator colours and sensitivity levels, while PROTOCOL.md records packet structures and command sequences. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux and a Cosmic Byte Firestorm mouse with VID 0x04d9 and PID 0xa09f; USB access typically requires sudo. - **Prerequisites:** Running from source requires Python, pyusb and PyYAML. - **Testing evidence:** Device support was tested only with the named Firestorm model. - **License:** GPL-3.0 licence. ##### Primary sources 1. 2. #### Centerpiece Projects: decoding Finalmouse Centerpiece USB control > Centerpiece Projects documents observed USB control messages for the Finalmouse Centerpiece keyboard and implements scripts around them. Its notes describe HID framing and message types for uploads, status, slot switching and preview chunks; PowerShell and Python helpers expose device operations. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A connected Finalmouse Centerpiece, Windows 10 or later, PowerShell and Python for the public scripts. - **Limits:** The vendor-specific WinUSB bulk interface remains under investigation, and the notes are not a complete protocol specification. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### FAAC E145 Gate Connect: reconstructing EasyBoard gate commands > FAAC E145 Gate Connect implements local control of an FAAC E145 gate through serial commands reconstructed from EasyBoard software traffic. The documentation lists POLL, OPEN, CLOSE and STOP byte sequences and describes their framing and checksum. The Python gateway adds position monitoring plus web, REST and MQTT interfaces. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An FAAC E145 controller connected by serial or USB, Python 3.8+ and the documented dependencies. - **License:** MIT. ##### Primary sources 1. 2. #### stagg-net: investigating the Fellow Stagg EKG kettle UART > stagg-net investigates the Fellow Stagg EKG kettle's internal UART interface and documents its connector, serial settings, observed heartbeat packet, and startup message. The repository includes a logic capture, decoder source, probing scripts, and ESPHome configuration for an ESP32-C6 connection. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Fellow Stagg EKG kettle hardware and a 3.3 V serial connection are needed for the described investigation. - **Limits:** The author has observed status traffic but reports that the UART interface does not respond to the BLE packets tried. - **License:** No licence file in the repository. ##### Primary sources 1. #### TOZO Control: a Linux earbuds client built from the TOZO BLE protocol > TOZO Control provides a Linux GTK4 client for TOZO earbuds using a BLE GATT protocol recovered from the vendor's Android app. It sends commands to characteristic B611, receives notifications on B612, and documents GET and SET packet layouts and parameter IDs. The author reports testing the T10 model for battery, game mode, equalizer and balance controls. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux with GTK4, libadwaita, BlueZ and the Python bleak package; a compatible TOZO BLE earbud is needed. - **Limits:** Only TOZO T10 is reported as tested; command support varies by model. - **License:** MIT License. ##### Primary sources 1. #### BMS RS485 Service Suite: reconstructing a battery-service bus protocol > BMS RS485 Service Suite documents an observed ASCII RS485 protocol for battery-management services and implements frame building and decoding in Node-RED. The specification covers framing, length and checksum fields, request and response rules and decoded service IDs; the wider suite connects JK and DALY BLE data to MQTT and dashboards. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Raspberry Pi and Node-RED are the documented service environment; BLE gateways use MQTT and optional Python dependencies. - **Limits:** The specification records observed and currently decoded RS485 services; some write acknowledgements are handled generically. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### Lutron Protocols > Lutron Protocols researches CCA radio packets, CCX Thread and CoAP messages, the LEAP processor API and IPL Designer integration frames for Lutron lighting systems. Its documentation covers device behavior and firmware, while TypeScript tools capture and decode traffic and parse Designer project files. - Type: Project - Targets: App · Binary · Firmware · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Packet-capture hardware uses an STM32H723 Nucleo with CC1101 and nRF52840 radios. - **Prerequisites:** LEAP tools require mutual TLS certificates. - **Limits:** Native Vive pairing and a long-running LEAP connection watchdog remain future work. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### Petkit Local: reconstructing feeder cloud and fountain BLE controls > Petkit Local replaces selected Petkit D4 feeder cloud exchanges with a local Home Assistant server and relays Eversweet Max 2 CTW3 fountain messages over BLE. The integration implements device registration, heartbeats, schedules, events and commands based on observed device communication. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Home Assistant 2024.1 or newer, a D4-family feeder, port 80 and local DNS or IP redirection are required. - **Prerequisites:** CTW3 fountain support requires a D4 feeder already running the integration. - **Testing evidence:** The documented tested firmware versions are D4 1.267 and CTW3 1.11. - **License:** MIT licence. ##### Primary sources 1. 2. #### IPI STAY FLY Driver: reconstructing mouse configuration over HID > IPI STAY FLY Driver reconstructs mouse configuration in a Windows app using reverse-engineered 16-byte HID frames. It exposes DPI, polling, button and sensor settings, documents a frame checksum, and includes a WebHID capture extension plus protocol notes for ATK FIERCE X. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows 10 or 11, WebView2 and an IPI STAY FLY mouse are required for device control. - **Prerequisites:** Building from source requires Node.js 20 or later, Rust and Visual Studio Build Tools 2022. - **Limits:** Non-mouse button actions, including keyboard keys and macros, are not yet exposed. - **License:** MIT license. ##### Primary sources 1. 2. 3. #### Soundcore D3200: reconstructing BLE recording transfer and decryption > A Soundcore D3200 investigation reconstructs the BLE exchange used to list and transfer encrypted recordings. Its Python client performs a P-256 ECDH handshake, derives session and file keys, decrypts AES-256-CTR Opus packets and writes an Ogg/Opus file. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.12 or newer, a Bluetooth adapter and an available D3200 recorder are required. - **Prerequisites:** The recorder must be disconnected from the Soundcore app before connecting. - **Testing evidence:** A real-recording regression test requires the user's own capture fixtures. - **License:** GPL-3.0-or-later licence. ##### Primary sources 1. 2. #### K1 Pro OpenDeck Suite: a Linux driver for the Stream Dock K1 Pro > K1 Pro OpenDeck Suite includes a Linux OpenDeck driver for the HOTSPOTEK/Mirabox Stream Dock K1 Pro based on its reverse-engineered USB/HID CRT protocol. The driver handles connection and keepalive messages, 64×64 JPEG key displays, RGB ring controls, and three knob inputs. Four accompanying plugins add generic OpenDeck functions. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** OpenDeck, Linux, and a Stream Dock K1 Pro with USB ID 5548:1025 and protocol v3 are required for the driver. - **Prerequisites:** Building requires Rust 1.87 or later with the x86_64-unknown-linux-gnu target, plus just and zip. - **Testing evidence:** The driver README says this fork had not been compiled or tested on hardware before delivery. - **License:** GPLv3 license; the vendored mirajazz dependency retains MPL-2.0. ##### Primary sources 1. 2. #### iDotMatrix: Home Assistant control through a reconstructed BLE protocol > iDotMatrix Home Assistant integration controls the HXS-002 / NL-XSD-32 LED panel over a BLE protocol derived from analysis of the vendor Android app. Its vendored protocol module and hardware-capture tests support power, brightness, clock controls and chunked 32×32 image uploads with CRC32. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Home Assistant with a Bluetooth adapter or nearby ESPHome/Shelly Bluetooth proxy is required. - **Limits:** The panel accepts only one BLE connection at a time. - **Limits:** Some protocol modes, including carousel/GIF storage and rhythm/spectrum, are not exposed as Home Assistant entities. - **License:** No licence file in the repository. ##### Primary sources 1. #### Dell ControlVault 2 fingerprint on Linux: adapting a driver for BCM5880 > Dell ControlVault 2 fingerprint on Linux adapts a locally obtained Broadcom driver to the older BCM5880 fingerprint reader through five signature-matched byte patches. The accompanying investigation maps the device’s USB endpoints, command header and driver checks. The author reports working capture, while enrollment and matching remain unreliable or unconfirmed. - Type: Case study - Targets: Binary · Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Dell ControlVault 2 / Broadcom BCM5880 device with USB ID 0a5c:5834, Linux x86_64 and TOD-enabled libfprint. - **Prerequisites:** The proprietary stock driver must be obtained locally from Canonical’s OEM repository. - **Limits:** The author reports enrollment commit failures on many units and unconfirmed verification with the included patches. - **License:** MIT license applies to the repository’s original scripts, udev rule and documentation. ##### Primary sources 1. 2. #### epson-l3110-driver: investigating the printer's USB and ESC/P-R exchanges > epson-l3110-driver investigates the Epson L3110's USB printing exchanges while developing a Linux driver in C. Its notes use captured print-job traffic to identify the IEEE 1284 device ID, EJL session setup and ESC/P-R command framing. USB communication is still in progress, and the driver cannot yet print pages. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An Epson L3110 printer and Linux are needed; the current Makefile requires libusb-1.0 and libcups development files. - **Limits:** Printing, image processing and the CUPS filter and backend are pending. - **License:** GPL-3.0 license. ##### Primary sources 1. 2. #### MS5 WiFi Microscope: reconstructing the camera's UDP video protocol > MS5 WiFi Microscope reconstructs the MS5 camera's UDP command and video protocol and supplies a Python client that serves its reassembled JPEG stream as MJPEG. The documentation specifies command headers, the OpenVideo port handshake, chunk layout and resolution queries; the author reports 1280×720 streaming at roughly 25–30 fps on MS5 hardware. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.7 or newer and a computer connected to the microscope's Wi-Fi access point. - **Limits:** Compatibility is reported for the MS5; related i4season devices are suggested but unconfirmed. - **License:** MIT license. ##### Primary sources 1. #### lux-lat-long-log: reconstructing LUMIX S5 BLE GPS communication > lux-lat-long-log reconstructs the Panasonic LUMIX S5 Bluetooth LE GPS exchange in an ESP32 camera client. The project documents GATT identifiers, session ordering and GPS/time packets from Android HCI captures, then uses a GNSS module to send positions without the phone app. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an ESP32 and SIM868 GNSS module for the documented hardware build. - **Scope:** Builds with PlatformIO; the documented camera implementation targets the LUMIX S5. - **Testing evidence:** The author reports successful hardware and photo EXIF checks for the S5. - **License:** MIT licence. ##### Primary sources 1. 2. #### Magene L308: reconstructing a smart taillight's BLE control protocol > Magene L308 interop tools reconstruct the smart taillight's BLE control protocol and light_mode.bin pattern format. A protocol specification records GATT characteristics, command frames and upload sequences; browser, Python and Garmin clients use those findings to control settings and patterns directly. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Magene L308 light is required; the Python CLI uses bleak. - **Prerequisites:** The web client requires Chrome or Edge with Web Bluetooth in an HTTPS or localhost context. - **Limits:** Pattern uploads replace the whole on-device store, which has no read-back; keep exported .bin backups. - **License:** Code is MIT licensed; the protocol specification is CC-BY-4.0 licensed. ##### Primary sources 1. 2. #### xbloom-ble: a client for the xBloom Studio BLE protocol > xbloom-ble implements a Python client for the xBloom Studio coffee machine's recovered Bluetooth LE protocol. The author documents capturing app traffic and comparing GATT command frames; the CLI and terminal UI load recipes, program dial presets, optionally start brewing and display live scale telemetry. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An xBloom Studio machine and Bluetooth LE access are required; the phone app must disconnect before writes because the machine accepts one BLE link. - **Prerequisites:** Python 3.10 or newer, with bleak and PyYAML; Linux also requires BlueZ. - **Prerequisites:** Remote start dispenses near-boiling water and requires the machine to be physically ready. - **Testing evidence:** The author tested only one machine running firmware V12.0D.500. - **License:** MIT licence. ##### Primary sources 1. 2. #### ak820: reconstructing AJAZZ AK820 Pro HID control on macOS > ak820 implements macOS control of the AJAZZ AK820 Pro keyboard through its vendor HID feature-report protocol. The Python CLI sets the clock, RGB lighting, and sleep timer over USB; accompanying notes describe Windows-driver analysis, packet framing, transaction handshakes, and the unresolved key-remapping commands. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS, Python 3.11+, and an AJAZZ AK820 Pro connected with a USB-C data cable are required. - **Prerequisites:** The Python package depends on hidapi. - **Limits:** LCD image upload on macOS and key remapping are unsupported. - **License:** MIT license. ##### Primary sources 1. 2. 3. #### GameTrak Liberation: a client for the controller's HID protocol > GameTrak Liberation implements a client for the GameTrak controller's reverse-engineered USB HID behavior. It sends the initialization and rolling-key keepalive messages needed for sustained reports, then exposes six-axis data through stdout, OSC, MIDI or WebSockets. Protocol notes, report captures and Processing and p5.js examples accompany the Python tools. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A GameTrak controller is required for live capture; offline playback accepts recorded JSONL reports. - **Testing evidence:** The author tested a GameTrak V2.0 unit on macOS 15.6 with Python 3.10 and 3.14. - **Limits:** The footswitch was unavailable for testing and is unsupported. - **License:** MIT license. ##### Primary sources 1. 2. #### Cooper Hunter AC: UART and infrared protocol investigation > Cooper Hunter AC documents the COM1 UART and infrared control messages of CH-IF140RK and CH-IF140RK2 units with a Gree GRZQ3-R V1 board. The author inferred UART status fields by comparing packets while operating the infrared remote. The resulting ESPHome design receives UART status and sends control through an infrared signal path. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Cooper Hunter CH-IF140RK or CH-IF140RK2 with the documented Gree GRZQ3-R V1 board, plus an ESP32 running ESPHome for the described setup. - **Scope:** The final wiring uses UART receive only; control uses infrared signal injection. - **Limits:** Some protocol fields are marked tentative in PROTOCOL.md. - **License:** MIT license. ##### Primary sources 1. 2. #### aw5d-linux: driving an iBUYPOWER cooler LCD from USB-HID research > aw5d-linux drives the round LCD on an iBUYPOWER AW5/AW5D cooler from Linux using a 64-byte USB-HID output report. Its research notes document report ID 0x10 and byte positions for CPU usage, clock, temperature and gauge styling. The author reports a working display on one 3402:0407 unit; other device variants remain unconfirmed. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux, Python 3.8+ and an iBUYPOWER AW5/AW5D cooler with USB access. - **Limits:** Only the 3402:0407 variant is confirmed; custom image and GIF display modes are outside the current scope. - **License:** MIT License. ##### Primary sources 1. 2. #### MyJBxHeadsetControl: JBL Quantum 950 controls over USB HID > MyJBxHeadsetControl provides Stream Deck controls for the JBL Quantum 950 Wireless headset through its USB dongle's reverse-engineered HID exchange. It receives status packets for battery and sound modes, sends feature reports for settings, and uses the user's QuantumENGINE DLL to calculate EQ coefficients. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** JBL Quantum 950 Wireless and its 2.4 GHz USB dongle; Stream Deck software 7.1 or newer. - **Prerequisites:** EQ actions require a local QuantumENGINE installation and its DLL. - **Testing evidence:** Windows 10 or 11; the author states macOS is untested. - **License:** MIT license. ##### Primary sources 1. #### zlt: MTN ZLT T10D MAX router API reconstruction > zlt reconstructs the LAN JSON API of the MTN ZLT T10D MAX router from its served JavaScript and observed responses. Its Python client handles reqproc requests, login and CSRF behavior, while a CLI and local dashboard expose signal, network mode, SMS and USSD operations. The protocol document identifies firmware-specific fields and porting limits. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An MTN ZLT T10D MAX router on the LAN for the documented device behavior. - **Prerequisites:** Python 3.11 or newer; authenticated operations require the router administrator password. - **Limits:** The author reports live checks against firmware CPE_NV8645_230A_E_QX_CAN-P42U17-20250703; other firmware may differ. - **License:** MIT license. ##### Primary sources 1. 2. #### claude-rc-api: reconstructing Claude Code Remote Control endpoints > claude-rc-api reconstructs the private HTTP interface used to control local Claude Code sessions from claude.ai/code. Its reference derives session endpoints, OAuth authentication, event envelopes, and streaming behavior from the CLI binary; a Python library and CLI use that interface to observe and steer sessions. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Claude Code login through a claude.ai account and a running Remote Control session. - **Prerequisites:** Python 3.10 or newer. - **Limits:** Private endpoints may change; the author reports exercising list and read paths against the live API, while documenting write and control paths from client code. - **License:** MIT license. ##### Primary sources 1. 2. #### Hermes > Hermes is a Flipper Zero app for identifying unknown UART settings and inspecting a device's serial console. It timestamps line edges to estimate bit time, checks candidate rates and parity against received UART bytes, then offers a terminal with text, hex and capture features. The source states that detection leaves the transmit pin undriven until the user sends data. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Flipper Zero and access to the target device's UART line. - **Limits:** The source says edge timing cannot follow edges beyond roughly 230400 baud; the UART sweep needs traffic during its sampling window. - **License:** MIT license. ##### Primary sources 1. #### MSI Mystic Light on Linux: reconstructing B860/X870 lighting control > MSI Mystic Light on Linux implements lighting control for an MSI motherboard from USB traffic captured while MSI Center ran in a Windows VM. Its Python script sends a 290-byte HID Feature report to controller 0db0:0076, while the documentation maps modes, RGB palette bytes, brightness, direction and the flash-save flag. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux, Python 3 and write access to the controller's /dev/hidraw* node. - **Limits:** Reverse engineered on an MSI MAG B860 TOMAHAWK WIFI; support for other boards with USB ID 0db0:0076 is stated as an expectation. - **License:** MIT license. ##### Primary sources 1. #### LinkCam: controlling Insta360 Link 2 through UVC extension research > LinkCam implements macOS menu-bar and command-line controls for the Insta360 Link 2 webcam. It uses standard UVC controls for pan, tilt and zoom, while its extension-unit investigation identifies a feature-mask bit and selector for AI tracking. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS and an Insta360 Link 2 webcam. - **Prerequisites:** macOS Command Line Tools to build from source. - **License:** MIT license. ##### Primary sources 1. 2. #### shark-k86-mac: a client for the Attack Shark K86 HID protocol > shark-k86-mac reconstructs the Attack Shark K86 keyboard's vendor HID controls as a Python CLI and library for macOS and Linux. Its clean-room protocol notes describe 64-byte feature reports, checksums and opcodes; the client controls lighting and the TFT screen and reads device information. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An Attack Shark K86 connected by USB in Win + USB mode is required; other models are untested. - **Prerequisites:** Python 3.8+, hidapi and Pillow are required. - **License:** MIT License. ##### Primary sources 1. 2. #### fitdays: reconstructing a smart-scale cloud client > fitdays recreates read-only access to the Fitdays smart-scale cloud API from traffic observed in the vendor app. Its asynchronous Python client logs in with the service's password digest, follows regional redirects, renews sessions, and retrieves scale, profile, and body-composition measurement records. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Fitdays account is needed to retrieve its measurement history. - **Limits:** The client is read-only; the private endpoints may change or disappear. - **License:** MIT License. ##### Primary sources 1. #### trvision: implementing Thermalright Vision USB display control > trvision implements direct USB control of Thermalright Vision display panels using previously documented protocol research. It captures desktop frames, encodes JPEG or RGB565 according to the handshake reply, and sends framed data over bulk USB; a companion parser reads USBPcap captures. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows and Python 3.12 are specified; supported hardware is the 87AD:70DB panel family. - **Prerequisites:** Close TRCC before use because it holds the USB device open. - **Limits:** Only 87AD:70DB panels were tested; other revisions may differ. - **License:** MIT license. ##### Primary sources 1. #### pocket-client: a BLE client for the Pocket voice recorder > pocket-client implements the Pocket voice recorder's recovered BLE command protocol in a Swift library and CLI. It documents authentication, status and recording inventory exchanges, MP3 transfer and control commands, using findings from vendor-app HCI captures and live device probes. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires a Pocket recorder and a session key for authenticated commands. - **Prerequisites:** Requires Swift 6.0 and iOS 17 or macOS 14 or newer. - **Limits:** Protocol findings are based on one physical device and firmware version. - **License:** Apache-2.0 license. ##### Primary sources 1. 2. #### RoflLens > RoflLens is a Python library and CLI for analysing League of Legends ROFL v2 replay containers and network transport. It exports blocks and payloads, and offers patch-specific decoders for events such as movement, spells and deaths when the client version, protocol digest and executable hash match. - Type: Tool - Targets: Binary · Game · Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.11–3.13 and a .rofl replay file are required. - **Prerequisites:** Patch-specific semantic decoding requires optional dependencies and the user's exact matching League of Legends.exe. - **Limits:** Several gameplay semantics remain unresolved; mismatched clients receive transport-only output or an error. - **License:** MIT. ##### Primary sources 1. 2. #### KeyAxis: decoding a magnetic keyboard's analog HID stream > KeyAxis documents the HID travel stream of keyboards using the 0416:7372 controller and turns key depth into virtual gamepad axes. Its protocol notes specify the vendor interface, ARM and DISARM commands, 64-byte host reports and row, column and depth fields recovered from captured traffic. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A keyboard exposing USB ID 0416:7372 and Windows 10/11 x64 are required; gamepad output needs ViGEmBus. - **Prerequisites:** Running from source requires Python 3.9 or later. - **Limits:** The on-screen layout covers 68 keys; vJoy output is planned. - **License:** MIT license. ##### Primary sources 1. 2. #### A.O. Smith water heater: local CTA-2045 control and protocol findings > The A.O. Smith water-heater project implements local monitoring and demand-response control of an HPS10-50H45DV over its CTA-2045 RS-485 port, publishing readings to MQTT. Its documentation records frame structure, checksums, control responses and observed behavior of this specific tank. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Requires an A.O. Smith HPS10-50H45DV, a Raspberry Pi Zero 2 W and an isolated RS-485 adapter as documented. - **Prerequisites:** The documented setup uses Raspberry Pi OS Lite, Python 3.13 and a 19200 8N1 serial port. - **Limits:** Setpoint writes, water-temperature reads and operating-mode changes are unavailable through this tank's CTA-2045 port. - **License:** MIT license. ##### Primary sources 1. 2. #### j2208-band-tools: a direct client for the J2208 fitness-band protocol > j2208-band-tools implements a direct BLE client for J2208-family fitness bands using protocol findings recovered from the FitTrack Health companion app. Its Python tools read stored health history and live sensor values, probe GATT services and collect readings into SQLite. The author checked the documented 16-byte frame protocol against one Hume Band V2. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A J2208-family band and Python with bleak; the companion app must release its BLE connection before the tools connect. - **Testing evidence:** The author tested one Hume Band V2 with firmware v0.0.3.9; support for other family members is inferred. - **Limits:** Raw PPG is reported unavailable on the tested V2 firmware. - **License:** MIT license. ##### Primary sources 1. 2. #### Eufy Local Light: reconstructing BLE control for E10 and E22 lights > Eufy Local Light implements a Home Assistant client for Eufy Outdoor String Lights E10 and Permanent Outdoor Lights E22 using BLE traffic analyzed from the Eufy app. Its protocol notes describe GATT endpoints, packet framing, AES-128-CBC session setup, and light-control commands. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Home Assistant and a supported Eufy light are required; development and testing covered E10 T8L10 and E22 T8L02. - **Limits:** The integration does not yet expose per-segment DIY patterns on the E22; E10 state readback is untested. - **License:** GPL-3.0 license. ##### Primary sources 1. 2. 3. #### OpenPeats: reconstructing SoundPEATS earbud controls > OpenPeats reconstructs the SoundPEATS earbud control protocol for desktop and Android clients. Its specification describes frames and opcodes derived from analysis of the official Android app and checked against SOUNDPEATS H3 hardware. Go and Kotlin implementations expose ANC, equalizer and multipoint controls, plus battery status. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A paired SoundPEATS device is required; development and validation used an H3 with firmware S5_20250605_V0.4.9. - **Testing evidence:** The author reports read and write validation on Linux, Windows 11, and Android. - **Limits:** Writing the touch mapping and touch demo mode remain unvalidated; macOS transport is unfinished and iOS SPP is unavailable. - **License:** MIT license. ##### Primary sources 1. 2. #### hongtai-panel: reconstructing a cooler LCD's USB serial protocol > hongtai-panel implements Linux control of a LovingCool AIO cooler LCD using a USB CDC-ACM serial protocol reconstructed from the vendor's Electron application. Its documentation describes control-frame layout, checksums, JSON replies, and opcodes; the client displays system statistics, media, or screen mirroring. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Linux, Python 3.10+, and a supported USB LCD panel; media and mirroring features need the listed optional packages. - **Limits:** Other panel models are expected to work through device-reported geometry but are not identified as confirmed. - **License:** No licence file in the repository. ##### Primary sources 1. #### ESPHome ↔ L&S Emotion Control: reconstructing a smart-light radio client > An ESPHome component recreates L&S Emotion Control remote commands so an ESP32 with a CC2500 radio can control furniture lights and reflect physical remote presses in Home Assistant. Its documented radio configuration uses MSK at 2436.2 MHz, a sync word, and 14-byte payloads carrying the remote ID, command, and value. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** ESP32, a 2.4 GHz CC2500 module with a 26.000 MHz crystal, soldered wiring, and an L&S Emotion Control lamp or remote. - **Limits:** Lamp state is estimated because the lamp provides no feedback; brightness has five levels. - **License:** Apache License 2.0. ##### Primary sources 1. #### akp02: reconstructing the Ajazz AKP02 display protocol > akp02 reconstructs the Ajazz AKP02 secondary display's USB HID protocol as a Linux Python library. It documents command report framing and implements full or partial image updates, brightness and power controls, firmware queries, orientation and keepalive. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An Ajazz AKP02 display and Linux HID access are required; the README describes installing a udev rule. - **Prerequisites:** The package specifies Python 3.11 or newer. - **License:** MPL-2.0 license. ##### Primary sources 1. 2. #### RK M75: reconstructing wired and wireless RGB control > RK M75 reconstructs RGB control for the Royal Kludge RK M75 keyboard from wired USB HID captures and 2.4 GHz wireless experiments. A Python library sends per-key wired frames and grouped wireless frames; the repository also contains protocol notes, captures and a wired SignalRGB plugin. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented hardware is an RK M75 with wired VID:PID 258A:0163 or wireless 258A:0148; development and hardware checks used Windows. - **Prerequisites:** Python 3.10+ is required by the package. - **Limits:** The wireless protocol is partial: arbitrary per-key colors and smooth 30 FPS streaming were not achieved. - **License:** MIT license. ##### Primary sources 1. 2. 3. #### ACiQ K18W: reconstructing a mini split's UART protocol > ACiQ K18W documents the UART protocol between a mini split's indoor board and TCL WBR1 Wi-Fi module. Captures and decoders map 115200 8N1 traffic, 0xA5 frames, CRC-16/XMODEM, acknowledgments, and appliance fields; ESPHome configurations provide passive monitoring or local control after replacing the module. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An ACiQ ACIQ-K18W-W-32-HP2300 unit and ESP32 hardware for the documented ESPHome configurations. - **Limits:** Listen-only and module-replacement control are separate electrical configurations; transmit must not be enabled while the original module remains connected. - **License:** MIT license. ##### Primary sources 1. 2. 3. #### RND Companion: reconstructing the RND Synth SysEx protocol > RND Companion reconstructs the Cymaforma RND Synth's SysEx control vocabulary and implements a C++ codec and companion plugin for patch seeds. The protocol notes identify framing and seed or status commands from a web app and one hardware capture. The client can use a direct MIDI port or host MIDI routing and stores a curated seed library. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Cymaforma RND Synth is needed for hardware use and capture. - **Prerequisites:** Building the full companion requires JUCE and the separate music-suite UI source; codec tests do not require JUCE. - **Limits:** The wire vocabulary is based on one hardware capture and may change with firmware updates. - **License:** Unlicense public-domain dedication. ##### Primary sources 1. 2. #### viture-v2: a reconstructed VITURE Gen2 glasses protocol and driver > viture-v2 documents and implements the USB HID protocol used by VITURE Gen2 XR glasses. The author matched usbmon captures to SDK frame logs, then wrote a Rust driver with hidraw, usbfs and io_uring transports for queries and IMU streams. Measurements and compatibility claims cover the VITURE Pro 2 XR. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A VITURE Gen2 XR device and a supported Linux or Android USB transport are required for hardware use. - **Limits:** Only VITURE Pro 2 XR was measured; setters remain unmapped. - **License:** MIT License. ##### Primary sources 1. 2. #### BikeStation: local Echelon Connect control over Bluetooth LE > BikeStation is a local Windows client for Echelon Connect exercise bikes built on community research into their proprietary Bluetooth LE protocol. It reads cadence and resistance telemetry, queries the bike's resistance range, writes motorized resistance commands and records rides without the vendor cloud. - Type: Case study - Targets: Protocol - Category: Independent reconstruction cases - Relationship: Independent reconstruction project - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Windows PC with Bluetooth and an Echelon bike advertising a name beginning with ECH are required. - **Testing evidence:** The author reports end-to-end testing on a Connect EX-5 only; resistance writing requires a motorized resistance mechanism. - **License:** GPL-3.0-or-later. ##### Primary sources 1. #### LogicAnalyzer > LogicAnalyzer is a hardware and software tool for capturing digital signals and decoding communication protocols. It supports triggered capture, multiple channels, and Sigrok protocol decoders. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires supported Pico hardware, matching firmware, and capture software. - Licensed under GPL-3.0. ##### Primary sources 1. #### BtleJuice > BtleJuice is a framework for intercepting Bluetooth Low Energy GATT operations between devices. Its web interface displays intercepted operations and supports replay, data modification, and export. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Node.js 4.3.2 or newer, npm, and the listed Bluetooth system dependencies. - The core and proxy require separate machines with two Bluetooth 4.0 or newer adapters. - The proxy does not work in a Docker container. - The repository is archived and has no license file. ##### Primary sources 1. #### NearDrop > macOS menu bar app that partially implements Nearby Share and Quick Share to exchange files and links with Android devices. Its protocol document describes the protocol as understood from Chromium sources and a decompiled Google Services Framework APK. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a Mac and an Android device on the same Wi-Fi network. - Android devices must be publicly visible when connecting through NearDrop’s QR code. - Works over Wi-Fi LAN only and remains visible to everyone on the network while running. - License: Unlicense. ##### Primary sources 1. 2. #### Impacket > Impacket is a Python library for constructing and parsing network packets and working with protocol implementations. It covers protocols including SMB and MSRPC and includes example tools. - Type: Tool - Targets: Protocol - Category: Protocol analysis tools - Relationship: Foundation tool - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Python 3; the README recommends pipx for system-wide installation. - The README describes the software as intended for research and education, not production or commercial use. - Apache Software License with slight modifications, per LICENSE. ##### Primary sources 1. ### Agents and MCP (87) #### REA — Reverse Engineer Anything > The upstream CLI and MCP server for evidence-based investigations of shipped software and runtime behavior. - Type: Project - Targets: App · Binary · Firmware · Game · Protocol · Website - Category: Official REA: core and setup - Relationship: Official REA project - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - rea-agents 6.5.0 was the published npm version at review time. - Node.js ^22.19.0 || ^24.11.0 || >=26.0.0; additional tools depend on the target. ##### Primary sources 1. #### Official reverse-engineer-anything skill > Target routing, connection recovery and evidence practices for agents using REA. - Type: Integration - Targets: App · Binary · Firmware · Game · Protocol · Website - Category: Official REA: core and setup - Relationship: Official REA skill - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installing the skill provides instructions; it does not by itself register MCP or install analysis engines. - Use the connected server's actual tool schemas; repository main may be ahead of an installed release. ##### Primary sources 1. #### dsh-mcp-rea > A community MCP bridge presents a smaller selected tool surface and forwards explicit commands to the REA CLI. - Type: Integration - Targets: App · Binary · Firmware · Game · Website - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires REA and the relevant analysis providers; distributed as a local bundle rather than a public npm package. - Use the documented REA_ENTRY mode for direct execution; PATH fallback invokes a shell. ##### Primary sources 1. #### rea-jev > A Claude Code plugin adds Jev-based routing and evidence checks around a pinned REA MCP integration. - Type: Integration - Targets: App · Website - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Claude Code, supported Node.js and the plugin's documented macOS/Linux environment. - Optional Jev service credentials enable external model calls; excerpts may be sent to that service. - Hooks fail open on provider failure; they are not a security guarantee. ##### Primary sources 1. #### rea-casebook > A Claude Code mod collects received REA Evidence, tracks unknowns and records findings that cite delivered evidence IDs. - Type: Integration - Targets: Binary - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README requires Claude Code 2.1.296 or newer and an MCP server registered under the name rea. - Developed with REA 6.4.0 and Ghidra 12.1 on Windows. ##### Primary sources 1. #### Eleven > An agent-first desktop reverse-engineering app that opens Mach-O, ELF and PE binaries, Android packages and GPU kernels, and lets any Agent Client Protocol agent read code, rename functions, add notes and propose patches in a shared window. Native code is decompiled by Ghidra through a bundled REA build, with Rizin and jadx as alternative engines. It is a workbench around existing engines, not a new decompiler or a reconstruction case. - Type: Integration - Targets: App · Binary - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed version 0.1.9 (release dated 2026-10-16) targets macOS 14+ on Apple Silicon, Windows x64 and Linux x64. The documented macOS and Windows installers pipe a remote script into the shell; macOS builds are not notarized, so the installer clears the download quarantine. Users supply the apps, binaries or APKs they analyze. - Native analysis uses Ghidra 12.x with Java 21 through REA, or Rizin for faster opening; first-run setup downloads missing engines or reuses local copies, and Ghidra is not bundled. Android packages need jadx, with apktool optional for smali. Building from source needs Bun, Node 20+, Ghidra, a JDK and a REA 6.x checkout; the release workflow builds REA from the Zfinix/rea fork’s feat/set-code-type branch rather than an upstream release. - Agents connect over the Agent Client Protocol, including the README’s Claude, Codex, Gemini, Cursor and Copilot options; model access, cost and data handling follow the chosen agent. Agents receive Eleven’s own MCP server and an eleven-rea proxy that passes REA tools through but redirects REA’s name, comment, bookmark and code-type writes into Eleven’s project. Per-tool Allow/Ask/Never permissions and privacy prompts are settings. - Byte patches are written to a copy, agent patches arrive as suggestions, and project changes are logged with their author and can be undone. CI at the reviewed commit runs typechecks on Ubuntu and macOS; the Ghidra-backed test suite is a separate local script. - Eleven is Apache-2.0; the bundled REA and Node.js keep their MIT and other licenses, and agent logos remain their owners’ trademarks. The tool grants no rights to analyze, patch or redistribute third-party software, and its outputs are agent-assisted analysis. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### REA plugin for Hermes Agent > Nous Research’s Hermes Agent plugin package for REA. One catalog install registers REA’s MCP server, pinned to rea-agents 6.4.0 and launched through npx over stdio, with REA’s workflow skill adapted for Hermes and a separate crash-triage skill. About 170 REA tools stay behind Hermes’ on-demand tool search, and the adapted skill asks before tools that run programs, drive apps or change a connected Android device. - Type: Integration - Targets: App · Binary · Firmware · Website - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - plugin.json declares 0.1.0 under MIT. Hermes’ catalog lists it as an official Nous Research plugin for Hermes 0.22.0+, installed with hermes plugins install rea and hermes plugins enable rea; it is not published by REA. Requires Node.js 22.19+, 24.11+ or 26+ with npx, not 23 or 25. A later rea-agents setup for Hermes replaces the pinned server entry. - Static JavaScript/ASAR, package, Go/Rust, PE, .NET and HAR analysis needs nothing else. Core-dump and ELF-layout tools need a Python with pwntools 4.15.0, pyelftools 0.33 and Unicorn 2.1.2 set in Hermes’ .env. Native decompilation needs Ghidra with a JDK, Hopper or IDA; Android needs JADX and Java; firmware and captures need Binwalk/Unblob, TShark, sigrok or WABT. - Only the adapted skill asks: Hermes itself does not prompt before REA tools that run PTY commands, drive apps, change Android devices or overwrite files; skip them in unattended runs. Analyze untrusted programs in a prepared environment. - In the README’s WinSCP 6.7 test the GUI import took 663 seconds under a 1000-second call budget, an author observation rather than a guarantee. Ghidra’s startup deadline is 900 seconds, while each call keeps Hermes’ 300-second MCP default. - Hermes v0.22.2 installs the package; the per-server call budget needs v0.23.0. The about-170-tool and 460 KB schema figures describe REA 6.4.0. REA’s MIT notice is included and the crash-triage workflow credits crashlens (MIT); external engines and targets keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### crashlens > A crash-triage tool that turns Linux core dumps, runtime panics, exception traces and sanitizer reports into Markdown bug reports naming the crash type, the first frame in the user’s code and a stable signature. Its core-dump path calls the REA CLI to read the recorded crash and the binary layout, and can ask REA’s Ghidra provider for pseudocode of stripped functions; a Claude Code plugin bundles a skill and read-only MCP tools. It is a debugging integration around REA, not a reconstruction case, and its diagnostic accuracy remains author-reported. - Type: Integration - Targets: Binary - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Package 0.1.0 and plugin 0.2.0 are an early prototype. Panic, trace and ASan/LSan/UBSan text inputs need only Node.js 22.19+ or 24.11+. Core dumps need Linux x86-64, Python 3, rea-agents and a pwntools environment named by REA_PWNTOOLS_PYTHON; gdb, objdump and Ghidra 12.1.x with JDK 21 are optional. Windows minidumps and macOS crash reports remain roadmap items. - Supply the core dump and the exact binary that crashed; crashlens compares GNU build IDs and warns on a mismatch. rea-agents 6.4.0 or later is an optional peer dependency, and the author describes only a pinned 6.4.0 as compatible. - The plugin’s MCP server defines four read-only tools, analyze_failure, analyze_core_dump, decompile_function and analyze_crash_folder. Pseudocode is decompiler output, and crash types are heuristics with a stated confidence. - The analyzed program is not executed; gdb runs with script auto-loading and debuginfod disabled. The optional --ai flag sends the report, including code snippets and log lines, to the Anthropic API; the local web app binds 127.0.0.1 behind a session token. Core dumps can hold secrets, and reports include local paths and register values. - CI runs typechecks and unit tests on Node 22 and 24 plus an end-to-end NULL-dereference check with the latest rea-agents; the six-of-seven root-cause claim has no published transcripts. - MIT, using MIT-licensed REA through its public CLI; Ghidra, the Anthropic API and analyzed programs keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### REA Workspace Template > A clone-first Chinese workspace template for analyzing one target per workspace with REA from Claude Code or Codex. It ships project-level REA MCP settings, agent rules that require CONFIRMED/GUESS labels with evidence locations, seven task prompts and standard-library scripts that hash imported originals, stage writable copies and strip values from HAR captures. It organizes analysis rather than performing it, and its acceptance run used only synthetic samples. - Type: Integration - Targets: App · Binary · Website - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin is the repository’s only commit, dated 2026-10-17. It needs Git, Python 3.11+, Node.js with npm, and Claude Code or Codex; README installs rea-agents 6.4.0, the version it was validated with, and the bundled .mcp.json and .codex/config.toml both start a locally installed rea --mcp. The template supplies no REA program, decompiler or model configuration, and it adapts workflow ideas from a third-party post. - Engines are separate: APK DEX work needs JADX and a full JDK, native targets need a Ghidra, Hopper or IDA provider configured through REA’s installation guide, and commercial engines need their own licenses; source, JS/Electron and saved-HAR workflows need no native decompiler. The prompts cover source mapping, API reconstruction from a sanitized HAR to OpenAPI 3.1 and a TypeScript client, JavaScript, native binaries (at most 30 functions per round), APKs, unknown file formats and session handoff. - scripts/workspace.py copies one target into a Git-ignored target/ directory without running it, records SHA-256 baselines, sets files to 0444, rejects symlinks and special files, and creates a writable work/ copy; verify reports changed, added or missing files. sanitize_har.py rebuilds a structural HAR copy, removing header values, cookies, URL credentials and query strings and replacing JSON values with placeholders. README warns that hosts, paths and field names can still identify users and need manual review. - docs/VALIDATION.md (2026-10-17) reports 12 passing standard-library tests, a healthy rea mcp doctor run listing 170 tools, and REA static analysis of a synthetic JavaScript app and a synthetic HAR with Node 24.18.0 and Python 3.12.7. It lists client MCP connection after restart, real APK and native targets, real-HAR anonymization and runtime work as unverified, and its smoke-test outputs are not committed. - README states that the Claude Code permission rules, read-only file modes and SHA-256 baselines are not an isolation boundary, and recommends read-only mounts and controlled networking where strong isolation is needed. AGENTS.md defaults to static analysis and reserves running samples, connecting devices and contacting target services for authorized tasks. The repository has no license file, so reuse terms are unstated; REA, analysis engines, clients and targets keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### REA Reconstruction Companion > A third-party Agent Skill that works alongside REA’s own skill to turn reverse-engineering evidence into scoped requirements, design, staged implementation and validation, from one feature or format to a whole app. An optional installer can add a marked routing block to the user’s REA SKILL.md so that relevant reconstruction requests load both skills. Its bundled evaluation kit consists of source-exposed, maintainer-authored examples with literal oracles, not a model benchmark. - Type: Integration - Targets: App · Binary - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin is package version 1.3.27; the repository was created on 2026-10-15, and a v1.3.27 release followed on 2026-10-18. The core is plain-Markdown Agent Skills instructions with reference guides. It supplies no analysis engine and expects REA tools or supplied REA evidence for actual investigation. README documents Codex and Claude Code installation; other agents can use an explicit skills directory. - The installer and the optional weekly update helper need Node.js 20+ and only its standard library; release building needs Python 3.10+. With --integration on, the installer edits the selected REA SKILL.md between marked comments and keeps backups, while off leaves REA untouched. README warns that REA 6.5.0’s doctor reports the edited skill as stale, and that rea setup or rea update can remove the block. - The instructions forbid actions that could add charges, treat recovered target material as untrusted evidence, and require observations, inferences, unknowns and design choices to stay separate. These are instructions to the host agent, not enforcement: README says they do not override client policies, grant tool permissions or guarantee model compliance. - CI runs the installer, package-integrity and evaluation-harness tests on Windows, macOS and Linux with Node 20, 22 and 24, then builds and verifies a release archive. The evaluation kit supplies fixtures such as Pocket Tasks, a 5,120-byte .NET Parcel.exe built from included source, a browser app and file formats, with literal oracles and human-review rubrics. Its examples are disclosed as source-exposed and same-agent; no live model trial, independent evaluation or cross-host certification is recorded. - Original code, instructions, tests and documentation are MIT, and a small Wycheproof test-data subset is Apache-2.0. No REA code is bundled; REA, target applications and model hosts keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### App X-Ray > Builds evidence-linked HTML/JSON reports, summary cards and diffs from REA analysis of app packages, native build metadata and model files. Its component and configuration findings come from static inputs; they are not observed runtime traffic, a complete security audit or reconstructed software. - Type: Integration - Targets: App · Binary - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-11-01 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** README requires Node.js 22+; supported inputs include Electron/app.asar/source folders, APKs, Go/Rust executables and listed model formats. REA analysis requirements vary with the input. - **Limits:** Rules see literal values and metadata; runtime-generated addresses are missed. A detected setting or dependency does not prove runtime behavior or exploitability, and unsupported/obfuscated inputs can leave unknowns. - **Testing evidence:** The public gallery uses open-source app snapshots. Report-derived REA-Bench answers reuse those reports as their reference. - **License:** Code is MIT; bundled Inter fonts retain SIL OFL 1.1. Reports omit target app code, and upstream software/model rights remain separate. ##### Primary sources 1. 2. 3. #### Hex-Rays IDA MCP > Official Hex-Rays MCP server for agent access to IDA databases, with headless operation and optional GUI integration. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - IDA 9.4+ with idalib, Python 3.11+, Git and uv; the GUI plugin is optional for headless use. ##### Primary sources 1. #### GhidraMCP > Ghidra extension and MCP bridge exposing decompilation, symbol navigation and renaming to agents, with GUI and headless modes. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Match the extension to the documented Ghidra release; Python 3.10+ for the bridge, with additional PyGhidra requirements for headless mode. ##### Primary sources 1. #### Binary Ninja MCP (official) > Binary Ninja's own MCP interface exposes functions, symbols, disassembly, intermediate languages and decompiled text to agents. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Catalog page: ##### Requirements & limits - First shipped in stable Binary Ninja 6.0 (2026-09-03). The GUI server uses HTTP and is included in every edition, Free included; headless stdio binaryninja_mcp requires Commercial or Ultimate on macOS/Linux and is not yet in native Windows packages, where upstream suggests the Linux build under WSL. ##### Primary sources 1. 2. #### Binary Ninja MCP (fosdickio) > Community Binary Ninja plugin and bridge for MCP clients, including workflows that switch among multiple open binaries. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Binary Ninja, Python 3.12+ and an MCP client; install the plugin separately from the client bridge. ##### Primary sources 1. #### IDA Pro MCP (mrexodia) > Community IDA integration useful for existing setups and migration context; its maintainer now recommends the official Hex-Rays MCP server. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - IDA Pro rather than IDA Free, Python 3.11+ and an MCP client; consult the upstream migration notice before choosing a new setup. ##### Primary sources 1. #### Radare2 MCP Server > Native radare2 MCP server offering binary-analysis tools, reusable sessions and configurable read-only access. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A compatible radare2 build and r2pm, plus an MCP client; advanced HTTP session features depend on the radare2 ABI. ##### Primary sources 1. #### r2ai > AI plugins inside radare2 for function explanations, naming suggestions and model-assisted decompilation using local or remote models. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - radare2 with the matching r2ai/decai plugins; configure a local model or the credentials required by the selected remote provider. ##### Primary sources 1. #### DAILA > Decompiler-independent AI assistant for function summaries and naming across IDA, Ghidra, Binary Ninja and angr-management. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A supported decompiler and dailalib; configure a model backend. Ghidra requires the documented PyGhidra setup. ##### Primary sources 1. #### RevEng.AI Ghidra Plugin > Connects Ghidra to RevEng.AI for function similarity, recovered names, AI explanations and agent-assisted annotation. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A compatible Ghidra/Java build and a RevEng.AI API key; creating service-side analysis uploads the selected binary. ##### Primary sources 1. #### LLDB MCP > LLDB's official MCP interface gives agents debugger sessions and commands for breakpoints, memory inspection and stepping. - Type: Integration - Targets: App · Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Catalog page: ##### Requirements & limits - An LLDB distribution/build containing lldb-mcp and a compatible stdio MCP client; debug-target access follows the host platform's requirements. ##### Primary sources 1. 2. #### Claude Reverse Engineering Skill > Community agent skill for triage, headless exports and evidence-based RE reports; explicitly documents workflows with REA and other MCP servers. - Type: Integration - Targets: App · Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - An Agent Skills-compatible client and Python 3.8+ for bundled scripts; analysis engines and MCP servers are configured separately. ##### Primary sources 1. #### SpecterOps Reverse Engineering Skills > Focused Binary Ninja and Ghidra analysis skills that describe MCP tool use, analysis recipes and annotation practices. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Configure the chosen Binary Ninja or Ghidra MCP integration separately; the skill package does not install or wrap those servers. ##### Primary sources 1. #### pyghidra-mcp > PyGhidra-based MCP server that analyzes every binary in a Ghidra project and exposes decompilation, cross-references, call graphs, symbol and string search, indexed semantic code search, and renaming, typing and comment edits. A separate HTTP CLI client and an optional mode driving a Ghidra GUI it launches are included. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed release: v0.2.7, published 2026-09-25, with package metadata requiring Python >=3.10. The README describes the project as beta and under active development; main has later, unreleased MCP Python SDK 2 changes. - Outside the published container image, install Ghidra separately and point GHIDRA_INSTALL_DIR at it. Semantic search uses a local ChromaDB index built in the background, so it can lag behind decompilation on large projects; ChromaDB and GZF artifacts are stored beside the Ghidra project. - The CLI client and GUI mode require the streamable HTTP transport; GUI mode launches Ghidra in-process and cannot attach to an already-running Ghidra. Import, delete, rename, type and comment tools change the project. - Apache-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### LeanREA > An independent agent skill that routes application and binary investigations through ordinary command-line tools. It supplies batched triage recipes, targeted source/disassembly reading and explicit seen/inferred/unknown evidence labels, accompanied by a small author-reported comparison against an REA MCP workflow. - Type: Integration - Targets: App · Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A plain-text skill for a shell-capable agent; it installs no analysis engine or decompiler and needs no REA MCP server. Manual installation needs a compatible skill client, the optional npx route Node.js/npm. Recipes need their own tools, such as ripgrep, jq, Go, Electron asar tooling or Xcode command-line tools; DecompileAll.java is not bundled. - The author’s benchmark used Claude Code 2.1.301, Sonnet 5.5 and macOS arm64 on Notion 7.35.1 app.asar, mac_utils.node and a gh binary built with Go 1.27.1, against rea-agents 6.5.0 over MCP. Reproducing it needs those locally obtained targets, Python 3, Node/npm, macOS tools and model access. - Across 12 runs per arm, LeanREA scores 74/75 checks to REA’s 75/75 at lower time, cost and turn counts; these are author records, and the no-skill arm’s correction from 66/75 to 67/75 rests on an unpublished answer. - Ground truth is hand-written regex keys, not behavioral-equivalence tests. Transcripts, target hashes and the resolved model ID (the default is the mutable sonnet alias) are unpublished, and the arms ran concurrently. - The 400.7k-token figure is a separate all-tools context probe, not the comparison setup. Native analysis engines and Android were not tested, and REA also offers a CLI. - MIT for the skill and benchmark code, crediting REA’s code and documentation and disclaiming affiliation; external tools, model services and targets keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### Universal Modder > Packages agent skills, three role briefs, a Python CLI and preconfigured fal MCP settings for modding PC games the user owns. Its reverse-engineering guidance sends managed, native and data-format work to external decompilers and debuggers, and requires a round-trip check before a reverse-engineered file format is used; one worked example ships an Age of Empires II sprite writer built this way. It is a modding toolkit with agent-written field notes, not a game decompilation, and its example results remain project-reported. - Type: Integration - Targets: Game - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Package 0.2.0 ships twelve skills, three subagent role files, the um CLI and fal MCP settings for Claude Code, Codex, Gemini CLI, VS Code/Copilot, Cursor and OpenCode. Hosts need Git, Python 3.10+ and ffmpeg (uv recommended; Blender only for 3D-to-sprite rendering); Windows capture, input and launch run natively or from WSL. - Start from a game installation you own; no game files, ROMs or decompiled code are supplied, and decompiles and extracted assets stay out of the repository. Asset generation needs a fal API key or browser sign-in; ComfyUI is a local image alternative and Sprixen a separate paid API. Tools such as ILSpy, Cpp2IL, Ghidra, IDA, Cheat Engine, Frida and RenderDoc are installed separately. - The AoE2 DE .sld writer’s 0.9/255 mean error on a stock sprite, its September 2026 in-game test and a Terraria movement port’s 99.9% velocity match are author results. - CI checks the toolkit (tests, CLI help, index and a publish lint blocking game files, decompiled code and secrets). Field notes are agent-written with self-declared verification. - Rules limit work to owned games offline or on self-hosted servers and refuse injection into anti-cheat-protected online clients, cheats against other players, and DRM, anti-cheat or ownership-check bypasses. Code is MIT with fonts under the SIL OFL; generated assets follow fal and model terms, and games and tools keep theirs. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### ReVa (Reverse Engineering Assistant) > Ghidra extension that runs an MCP server inside Ghidra, giving agents decompilation with namespace and cross-reference context, symbol, string, data-type, structure and call-graph tools, program diffing, renaming and PyGhidra scripting. Its README attributes the project's distinction to tool design for LLM use: many small tools whose schemas tolerate other input, redirect correctable mistakes and return short fragments linked to related information. Assistant mode serves an open Ghidra project to several clients at once; headless mode starts Ghidra itself with session-scoped projects. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Ghidra 12.0 or later only. Install the release zip built for the matching Ghidra version through the extension manager, or build with gradle against GHIDRA_INSTALL_DIR, then enable the ReVa Application Plugin in the project view and the ReVa Plugin in the Code Browser. Release v7.3.1 (2026-09-03) ships zips for Ghidra 12.0, 12.1 and 12.1.3 with Sigstore bundles and a matching PyPI package; the reviewed main commit adds unreleased dependency updates and a breaking CLI migration to MCP Python SDK v2. - Assistant mode needs a running Ghidra with an open project and serves streamable HTTP on port 8080 by default. Headless mode needs GHIDRA_INSTALL_DIR, Python 3.10+ and the reverse-engineering-assistant package installed with uv, which provides the mcp-reva command; the README describes its projects as session-scoped and cleaned up automatically, created under .reva/projects in the working directory. - The server exposes Ghidra's PyGhidra scripting environment, and renaming and data-type tools change the project. Defaults bind 127.0.0.1 with scripting tools enabled and API-key authentication off; the README asks for API-key authentication or disabled scripting tools before listening on a public interface, and the reviewed source refuses an unauthenticated public binding in headless mode and asks for consent in the GUI. - Apache-2.0. The repository also publishes a Claude Code plugin marketplace with triage, deep-analysis, cryptography and CTF skills. README statements about context use and performance on large binaries or firmware images are the author's. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### x64dbg-MCP Server > Native x64dbg plugin, written in Zig for both x32dbg and x64dbg, that serves an MCP endpoint over streamable HTTP and SSE from inside the debugger. Agents can load or attach to a process, set software, hardware, memory and conditional breakpoints, step and trace, read registers, call stacks, threads, memory maps, imports, strings and cross-references, and run arbitrary x64dbg commands. A bundled SKILL.md guide tells agents to confirm the debugger state before every action. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows with x64dbg; the plugin loads into x32dbg or x64dbg and resolves the debugger API at runtime. Install by copying the x32 and x64 plugin folders from the v1.6 release zip (2026-10-12) or a dist/ build into the x64dbg root; building needs Zig 0.16-dev or later and can cross-compile from Linux, macOS or WSL. The server starts automatically with the debugger. - Ports are 9094 for x64 and 9095 for x32. The README lists 0.0.0.0 as the default bind address, but the reviewed configuration code has defaulted to 127.0.0.1 since v1.2; the plugin's config dialog changes the address, port and token and saves them to mcp_config.json beside the x64dbg executable. A bearer token generated on first run is required on every request, and traffic is unencrypted HTTP, so the README warns against exposing the server to untrusted networks. - Many tools change the target or debugger state: memory writes and patches, instruction assembly, register writes, memory allocation, thread suspension, breakpoint commands and arbitrary debugger commands. DumpMemory and DumpModule write files to disk, and OEP detection and module dumping are aimed at packed executables. - MIT. The README limits use to authorized reverse engineering, malware analysis, security research and education. ##### Primary sources 1. 2. 3. 4. 5. 6. #### mcp-windbg > Independent, community-built MCP server that runs Microsoft's cdb.exe and kd.exe headless, so agents can open and triage user-mode and kernel crash dumps, attach to cdb remote debug servers and KD kernel targets, and run arbitrary debugger commands in separately addressed sessions. Its README points users who want AI inside WinDbg to Microsoft's official WinDbg MCP and positions this project as an alternative for other MCP clients, remote HTTP use and batch dump triage; it calls itself a wrapper that runs real debugger commands, not an automatic fix. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Windows with Debugging Tools for Windows or WinDbg from the Microsoft Store, which provide cdb.exe and kd.exe. Install from PyPI (mcp-windbg 1.5.1, Python 3.10+), through the uvx-based Claude Code plugin, or as the signed standalone mcp-windbg.exe attached to each release with SHA256SUMS; optional plugins add four skills and a crash-analyst agent. The reviewed develop commit is one commit after v1.5.1 (2026-10-10). - Symbols come from _NT_SYMBOL_PATH or --symbols-path, typically the Microsoft symbol server. Remote user-mode debugging needs a running cdb or WinDbg debug server; kernel sessions need a KD-enabled machine or VM reached over KDNET, a named pipe or serial, and closing a kernel session resumes the target. - stdio is the default transport. The streamable HTTP transport binds 127.0.0.1:8000 by default and has no authentication: anyone who can reach the port can drive cdb.exe on the host, so the docs advise a trusted network, an SSH tunnel or an authenticating proxy. A --filter-script hook can redact data from tool arguments and output before they leave the machine. - MIT. Microsoft's official WinDbg MCP, which the README dates from WinDbg 1.2610.1001.0, is a separate product. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Wireshark MCP > MCP server that wraps tshark, and optionally other Wireshark command-line tools, so agents can query saved captures through Wireshark's dissectors: packet lists and details, stream following, arbitrary field extraction, protocol hierarchies and conversations, decode-as rules for non-standard ports, protocol preferences, TLS and WPA decryption with user-supplied keys, and one tool that applies preset fields and filters for 25 protocols such as Modbus, S7comm, MQTT, Zigbee and BLE. Separate security-heuristic, live-capture and capture-editing tools sit beside the dissection tools. - Type: Integration - Targets: Protocol - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python 3.10+ and Wireshark with tshark on PATH; capinfos, mergecap, editcap, dumpcap and text2pcap are auto-detected optional extras, and live capture needs the platform's capture drivers and permissions. Install from PyPI (wireshark-mcp 3.1.0, built on MCP Python SDK 2.x) with its client installer, or through the Claude Code or Codex plugin route with uv. Reviewed at the v3.1.0 tag, released 2026-10-18 at the main head; the project changes quickly. - stdio is the default transport. SSE and streamable HTTP bind 127.0.0.1 by default and are unauthenticated, so the server refuses a non-loopback bind unless --allow-insecure-http is passed behind a trusted authenticated TLS proxy. The 11 file-writing tools (live capture, merge, filter-save, editcap, text2pcap, frame and object export) fail closed until WIRESHARK_MCP_ALLOWED_DIRS names existing directories; --profile analysis or core advertises fewer tools. - Protocol results come from Wireshark's existing dissectors and preset field lists; decode-as rules and preferences only redirect or configure those dissectors, and the server does not infer unknown message formats. Credential, scan, tunnelling, beaconing, exfiltration and YARA tools are security heuristics rather than protocol reverse engineering, and their findings need analyst review. - MIT; Wireshark and its tools keep their own GPL terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### BINNY > An open-source terminal agent harness from OpenBin that runs a user-chosen hosted or local model over binary-analysis data. It reads decompiled functions, strings, imports and data from an OpenBin or OpenAPK project or a local Ghidra container run, follows triage, investigation and drafting playbooks, and saves a draft malware-analysis or vulnerability-research report for human review. It is an analysis harness with draft outputs, not a reconstruction project. - Type: Integration - Targets: App · Binary · Firmware - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin follows the v0.1.0-beta.2 release of 2026-10-15. BINNY is a Go terminal program; release builds use Go 1.22 and cover Linux, macOS and Windows, and the README installers fetch scripts from openbin.ai. Startup needs an OpenBin sign-in: main.go loads the openbin CLI’s stored credentials and stops with an instruction to run openbin login when none exist. Source comments describe planned paid access whose gating is deferred during testing. - Models are bring-your-own-key, with Anthropic, OpenAI, DeepSeek, Qwen, Kimi, Gemini through an OpenAI-compatible endpoint and Bedrock preconfigured; Ollama or LM Studio models must support tool calling and need a larger context window than Ollama’s 4k default. Analysis data comes from the user’s OpenBin or OpenAPK projects or a local file. Local decompilation and the sandbox need Docker, and the first local decompile downloads an OpenBin Ghidra worker image of about 700 MB. - The sandbox tool runs scripts in a container with no network, a read-only root and sample mount, dropped capabilities and CPU, memory and process limits. Triage labels samples with the STIX 2.1 malware vocabulary, malware and vulnerability modes change the report lens, and autonomous, supervised or collaborative modes decide when the agent stops to ask. The README treats existing reports as claims to check and saves drafts for review before publication. - The repository has Go unit tests, which the release workflow runs before cross-compiling; it publishes no benchmark, accuracy measurement or worked example report. Its README still calls the source repository private while it is public. - LICENSE is AGPL-3.0; the README states AGPL-3.0 or later. Contributors sign a CLA so OpenBin can also offer the code under a commercial licence, and the README says the OpenBin platform it talks to uses the same licence. Model services, OpenBin accounts, Ghidra and analysed samples carry their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### decomp.wtf > A discontinued local app and MCP server that hands AI coding agents one function of a user-owned console game at a time, compiles each C attempt with the game’s period compiler and accepts it only when the linked result matches the original bytes. It can start a project from a ROM or disc image, or work inside forks of public decompilation projects listed on decomp.dev, where objdiff judges the result. Its final commit, dated 15 October 2026, marks it discontinued in response to opposition in the decompilation community; the code stays under MIT without further fixes or releases. - Type: Integration - Targets: Game - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin is the discontinuation commit of the archived repository, at package version 0.10.6, which the README names as the last installable release. The author will not fix issues, review pull requests or publish releases; existing installs keep working without updates. It runs on Linux and, marked unstable, on Windows inside its own WSL 2 distribution; macOS is unsupported. It needs Python 3.12 or later, and its installer sets up uv, the app, pinned checksum-verified period compilers and the m2c draft decompiler. - Agents connect through the local decomp mcp server or a Claude Code plugin that adds a decompile skill. README lists Claude Code, Codex CLI, Antigravity CLI, opencode, other MCP clients and a built-in loop for OpenAI-compatible APIs, including local models. Agents receive only decomp.wtf’s tools, without a shell. Users pay their own model provider; the author reports about 8 cents for a small function with Claude Code and warns that large functions take many more attempts. - Users supply their own ROM, disc image or program file. The tool contains no game code or ROMs apart from a bundled demo N64 ROM built from public-domain code and zlib. Proprietary period compilers such as IDO and CodeWarrior are installed only after the user agrees. Continuing a public decomp clones that project locally and runs its build scripts, so the README advises forking only trusted projects. - README lists GameCube, Wii and N64 as recommended and PlayStation, PlayStation 2, Game Boy Advance and DS as beta, tested mostly on homemade games. It reports imports tested on named commercial titles and exports that rebuild the input byte for byte, with GameCube and Wii files linked and checksum-checked in dtk-template projects. These remain author statements: the repository has a pytest suite but no CI workflow at the pin, publishes no game results. - The repository is MIT-licensed. Its README asks users to work only on games they own, not to circumvent copy protection, not to publish decompiled code of games whose rights they do not hold, and to follow each public project’s contribution rules, noting that many community decomps reject AI-written contributions. Nothing is sent upstream automatically. The project disclaims affiliation with the tools it builds on. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Claude Intercept > A local man-in-the-middle proxy and dashboard that captures HTTP/S traffic from the user’s own computer and devices, stores it in SQLite and hands it to Claude Code through an /intercept skill and CLI. Exports such as API documentation and traffic summaries support investigating request patterns and undocumented endpoints. It is an agent-facing capture tool for authorized testing, not a reconstruction case, and it has no established REA connection. - Type: Integration - Targets: App · Protocol - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin is package version 1.0.0, last updated 2026-06-02. It combines a Node.js proxy with a per-machine CA, a live web dashboard, local SQLite storage, a CLI and a Claude Code /intercept skill, with Markdown or JSON exports shaped for agent analysis. README asks for Node.js 22.5+, while package.json declares 22.15.0 or later; the system-proxy toggle and certificate trust are automated on macOS and GNOME/KDE Linux, and Windows needs manual configuration. - HTTPS capture requires installing and trusting the generated CA and routing a device through the proxy; README covers macOS, Linux, iOS, Android and Firefox, and warns that leaving the system proxy enabled after stopping the server breaks connectivity. README says some certificate-pinned domains fail under the proxy, and the skill states that WebSocket connections are tunneled and logged without frame parsing. - In the reviewed source the proxy and the dashboard listen on all network interfaces, and the dashboard API has no access check; README warns against running it on untrusted networks. Captures and some exports can contain account credentials and personal data, and anything passed to Claude for analysis leaves the machine under the model provider’s terms. The project limits use to devices and accounts the user owns or is explicitly permitted to test. - Tests under src/__tests__ run with node --test, but the repository has no CI workflow, and the README’s install example still uses a placeholder repository URL. - The repository is licensed under CC BY-NC 4.0, a non-commercial Creative Commons license rather than a software license, so commercial use is not permitted. The reported post presents it as a Ship Systems project built with William Haesemeyer. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Ghidra MCP Server (bethington) > A Ghidra GUI plugin, standalone headless server and Python MCP bridge exposing a 209-tool catalog: decompilation, cross-references, renaming, typing, structures, comments and batch edits, plus P-code emulation, live debugging through Ghidra’s TraceRmi framework, shared Ghidra Server repository and version-control operations, and hash-based transfer of function documentation between binary versions. The bridge loads three tool groups on connect and lets the model search for and load the rest, while naming and type conventions are enforced in the tool layer. Its NOTICE says it began as a derivative of LaurieWired’s GhidraMCP in August 2025 and has since been substantially rewritten and extended. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin is the default dev branch at bridge version 7.0.0 plus unreleased changes; the README calls tagged releases stable, release candidates and main beta, and dev experimental, with tools renamed and merged freely. At review the newest published build was the 7.0.0-rc.3 pre-release of 2026-10-14, which ships the extension zip and bridge wheel, and the newest stable release was v6.0.0 of 2026-07-25. The README says the GUI plugin serves 205 of the 209 tools and the headless server 190, with the debugger tools GUI-only. - The extension loads only in the exact Ghidra version it was built for, Ghidra 12.1.4 at this pin, and needs Java 21; the bridge needs Python 3.10+, with uv recommended. Source builds use Maven 3.9+ or the committed Gradle wrapper, with install guides for Windows, Ubuntu/Debian, macOS and Arch Linux; Python Ghidra scripts need Ghidra’s optional Jython extension, and shared-server work needs a Ghidra Server version compatible with the 12.1 client. Clients connect over stdio or streamable HTTP, and a Docker Compose stack runs the headless server and bridge as two containers. - Users analyse programs imported into their own Ghidra project; the repository ships only two generated PE test fixtures for its regression tiers. Write tools change the project, and script execution, which runs arbitrary Java inside Ghidra, stays off unless GHIDRA_MCP_ALLOW_SCRIPTS is set. The HTTP server binds 127.0.0.1 without authentication by default and refuses a non-loopback bind without GHIDRA_MCP_AUTH_TOKEN, which the Docker stack always requires; GHIDRA_MCP_FILE_ROOT confines file-path endpoints to one directory. - CI builds the extension with Maven against a downloaded Ghidra, runs offline and real-Ghidra Java tests and Python unit and fake-server tests on Linux, and runs Python unit tests on Windows. docs/TESTING.md describes opt-in live tiers that import the fixtures into a running Ghidra and exercise endpoints and a debugger launch, and says the debugger tier is only partly restored. Sub-second responses, 93% fewer API calls through batching and workflows refined across hundreds of functions are the author’s claims. - Apache-2.0; NOTICE credits the original LaurieWired GhidraMCP code, whose copyright remains for any surviving portions. Ghidra, MCP clients, model services and analysed programs keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### DecompilerServer > Stdio MCP server built on the ICSharpCode.Decompiler engine that lets agents load managed .NET assemblies, including a Unity game's Assembly-CSharp.dll located from its game directory, then search symbols, string literals and attributes, read decompiled C# or IL, and trace callers, callees, usages and inheritance. Several assemblies stay loaded under aliases, so an agent can compare two versions structurally or diff individual method bodies, the README's example being RimWorld mod porting. Modding-oriented tools generate Harmony patch skeletons, detour stubs and transpiler anchor suggestions as text from the inspected members. - Type: Integration - Targets: App · Game - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed release: v1.4.0, published 2026-10-01; its tag points at the reviewed main commit. Release assets are framework-dependent single-file executables for Windows x64, macOS arm64 and x64, and Linux x64 and arm64 that need the .NET 10 runtime; building from source needs the .NET 10 SDK. The server speaks MCP over stdio, with README setup for Claude Desktop, Cursor, VS Code/Copilot and Codex, and an optional script installs a locally signed build and the bundled decompiler-mcp skill for Codex on macOS. - Users supply the managed .NET assemblies to inspect, such as a game's Assembly-CSharp.dll or a third-party library; the repository contains only its own test libraries, and the README notes that native libraries do not load. Loaded aliases are registered in LocalApplicationData/DecompilerServer/contexts.json and restored on demand, and at most four contexts stay resident by default (DECOMPILER_MAX_LOADED_CONTEXTS changes the limit). - Inspection tools carry the MCP readOnlyHint annotation; loading, unloading, context selection, decompiler settings and cache tools change server state. The patch, stub and wrapper generators return source text and do not modify the loaded assemblies. Responses are compact by default; DECOMPILER_RESPONSE_MODE=extended restores the earlier response fields. - The v1.4.0 release notes report 238 passing Release tests, and the release workflow builds and runs the test suite before publishing assets; these are project-reported results. MIT. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Gepetto > IDA Pro plugin that sends Hex-Rays pseudocode to a hosted or local language model the user selects, to explain a function, comment it or propose new variable and function names, which the user picks from before they are applied. A chat console inside IDA also lets the model call tools that read disassembly, decompilation, cross-references, strings and types, rename and comment the database and run Python. The README warns that these general-purpose models may well be wrong and asks users to treat every result critically. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit is 38 commits after the v1.5.1 release of 2025-11-19, while ida-plugin.json and pyproject.toml still declare version 1.5.0. The README requires IDA Pro 7.6 or later with the Hex-Rays decompiler. Installation uses Hex-Rays’ hcli plugin command, or copies gepetto.py and the gepetto folder into the IDA plugins directory and installs requirements.txt into IDA’s Python; pyproject.toml asks for Python 3.10+. - Each request sends the current function’s pseudocode, and in the chat console whatever the tools return, to the selected provider. Built-in providers include Anthropic, OpenAI, Gemini, Azure OpenAI, Groq, Together, Novita AI, Kluster.ai, DeepSeek and OpenRouter with the user’s own API keys, which the README notes are usually paid, plus local Ollama or LM Studio models. Further providers load as drop-in Python files or entry-point packages, which the README warns execute arbitrary code when IDA starts. - The chat console, chosen as Gepetto in IDA’s input bar, offers the model 22 tools: reading disassembly, bytes, pseudocode, cross-references, imports, symbols, strings, structures and search results; declaring C types; renaming functions, globals and local variables; setting comments; and run_python, which executes model-supplied Python inside IDA with no confirmation step. Its system prompt tells the model to carry out requested changes without asking. The Explain, Comment and Auto-rename menu actions work on one function, and Auto-rename lists the proposed names so the user selects which to apply; two actions the README does not describe, Generate C Code and Generate Python Code, save a model-written rewrite of the function to a file. - Repository tests use pytest with Hex-Rays’ idapro library and open a bundled manalyze.exe build, from the author’s Manalyze PE analyser, as a fixture; no CI workflow is published. The README’s before-and-after screenshot and its observation that renaming works better after an explanation are the author’s. - GPL-3.0 per LICENSE and ida-plugin.json; IDA Pro, the Hex-Rays decompiler and model services keep their own licences and terms. The README credits Kaspersky with initial funding and HarfangLab as the current backer. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### GhidrAssistMCP > Ghidra extension that runs an MCP server inside Ghidra over streamable HTTP and legacy SSE, with 100 explicitly named tools (93 enabled by default) for pseudocode, disassembly, P-code, control-flow and call graphs, cross-references, strings, imports and exports, plus renaming, retyping, comments and structure inference. Since version 3.0.0 the server starts with the project manager, so agents can create, open, save and close projects and open programs before a CodeBrowser exists, while one shared server tracks whichever CodeBrowser window has focus. Six program resource templates, seven analysis prompts and a bundled script for running the server under analyzeHeadless complete the package. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Ghidra 12.0 or 12.1 Public running on Java 25 or newer; extension zips are specific to one Ghidra version. Release 3.0.0 (2026-10-09), whose tag is the reviewed commit, publishes a zip for Ghidra 12.1; installation goes through File → Install Extensions, and source builds use the bundled Gradle wrapper with Java 25 and GHIDRA_INSTALL_DIR. The server listens on localhost:8080 by default, with streamable HTTP at /mcp (MCP 2025-11-25) and legacy SSE at /sse (2024-11-05); the Java MCP SDK 2.0.1, Jetty and Jackson are bundled under private package names. - Programs come from the user's own Ghidra project or imports; the extension supplies no target binaries. Headless mode runs the bundled GAMCPStartServerScript.java inside analyzeHeadless against the loaded program, with wait=true to keep the session open and a completion_file option to end it; the project lifecycle tools need the GUI project manager. - Write tools change the program or project, including names, types, comments, structures, disassembly, analysis options and saves, and read and write tools carry separate MCP annotations. import_file, export_program and the five Ghidra script tools are disabled by default; a headless agent_lab profile enables sandbox-local program export while arbitrary-path import and scripts stay disabled. The README describes no client authentication; the server rejects browser requests whose Origin header is not allowed. - The project's modernization review reports 90 passing tests in buildExtension test runs against Ghidra 12.0 and 12.1, and a live Ghidra 12.1 smoke test on 2026-10-09 that predates the four project-control tools; these are project-reported. MIT. The repository moved from jtang613/GhidrAssistMCP, and its README recommends the author's GhidrAssist client. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Android Reverse Engineering Skill > Claude Code plugin and agent skill that drives jadx and Fernflower/Vineflower to decompile Android APK, XAPK, JAR and AAR files and document their HTTP APIs. A fingerprint pass first identifies the app's framework, HTTP stack, obfuscation level and native libraries, then shell scripts extract endpoints and authentication patterns across Retrofit, OkHttp, Volley, Ktor and Apollo/GraphQL, trace call flows from UI down to the network layer, and rebuild original Kotlin class names from the metadata R8 leaves behind. It installs through the bundled Claude Code marketplace, and its scripts also run standalone with a /decompile slash command. - Type: Integration - Targets: App - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A Claude Code client with plugin/skill support; install by adding SimoneAvogadro/android-reverse-engineering-skill as a marketplace and installing the android-reverse-engineering plugin, or from a local clone. The reviewed plugin manifest is version 1.5.0 on the master commit, ahead of the latest GitHub release v1.1.0 (2026-04-27). - The skill runs external tools it does not bundle: Java JDK 17+ and the jadx CLI are required, and Vineflower or Fernflower plus dex2jar are optional for better Java output; a dependency checker and an OS-detecting install helper are provided. Bash scripts are the primary path, with experimental PowerShell equivalents for Windows. - Users supply the Android packages to analyze; the repository ships no app files. Work is static decompilation, API documentation, call-flow tracing and Kotlin name recovery; the author reports roughly complete recovery of the Repository/ViewModel/UseCase classes on a typical app, which is a project-reported figure. - Apache-2.0 for the skill; the decompilers and other driven tools keep their own licenses. The README limits use to lawful purposes such as authorized security research, interoperability analysis, and malware analysis, and places responsibility on the user. ##### Primary sources 1. 2. 3. 4. 5. #### Reverify > Python CLI and stdio MCP server that checks a model’s structured claims about a binary, such as bytes or typed values at an offset, strings, imports and exports, instruction mnemonics, emulation results and tested or Z3-proved equivalence, and returns VERIFIED, REFUTED or INCONCLUSIVE with the evidence the tools observed. Grounded and refuted results are kept in a per-binary ledger on disk, so a reset or later session resumes from them instead of from a summary, and a reconstruct loop has a model propose claims until an informative set verifies. A separate rollover command replaces context compaction in Claude Code, Codex, Gemini CLI or OpenCode with file hand-offs and fresh sessions. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit is 25 commits after the v0.11.0 GitHub release of 2026-09-04; PyPI’s newest version is 0.10.0, and the README’s status section still describes v0.9.0. The core is pure Python with no dependencies, and pyproject.toml declares Python 3.8+. The full extra adds capstone, unicorn, lief and z3-solver, and the angr extra adds the function, call and cross-reference claims, which return INCONCLUSIVE without an engine. The toolkit also parses PE, ELF and Mach-O files, scans byte patterns, decodes Protobuf and TLV data and generates Frida hook scripts. - The verifier and benchmarks need no model. reconstruct calls an OpenAI-compatible endpoint configured by OPENAI_API_KEY, OPENAI_BASE_URL and OPENAI_MODEL, orchestrate can drive Claude through the Claude Agent SDK on a Claude Code login, and the MCP server gives any MCP client parsing, disassembly, pattern-scan, semantic, claim, ledger and checkpoint tools. Ledgers and checkpoints are written under .reverify in the working directory. Users supply the binaries to analyse; the repository holds benchmark sources and result records, not target binaries. - reverify rollover install edits the user settings of each supported CLI it finds to add hooks and switch off native compaction, keeping backups and offering uninstall. The README warns that a Claude Code or Codex session not started through its launcher can then grow without limit, and reports one session that reached 909k tokens. - The headline benchmark applies a fixed textbook push rbp; mov rbp, rsp prologue guess, not a live model, to the entry points of system binaries. BENCHMARK.md reports that guess refuted on 69 of 71 Windows 11 files and never falsely verified, and 0 false VERIFIED among 475 known-false claims on 50 Windows binaries; CI repeats both checks on Linux, Windows and macOS and fails on any false VERIFIED. The author notes that 0 of N bounds the error rate rather than proving it zero. These are project-reported results. - MIT. SECURITY.md limits use to authorised work such as malware analysis, CTF, interoperability research and software the user owns or may analyse, and excludes circumventing licensing or copy protection on software the user does not own or license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### DecompAI > Gradio chat application whose LangGraph ReAct agent analyses an uploaded x86 Linux ELF binary: it lists and disassembles functions, decompiles them with Ghidra, drives radare2 and gdb, and runs shell commands and Python scripts in a privileged Kali Linux runner container. Workspaces are keyed by the binary’s SHA-256, so uploading the same file again restores the session. It came out of a school research project, and its CTF results are the authors’ own report. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit of 2025-11-10 containerised the app. The repository has no tagged releases; the README points to app and runner images tagged 1.0.0 on Docker Hub. Only x86 Linux ELF binaries are supported, and QEMU-based ARM, MIPS and Windows PE support is listed as future work. - The app needs Python with the pinned requirements.txt (Gradio 5.25, LangGraph and LangChain) and Docker. docker compose builds or pulls a Kali runner image with kali-linux-headless, Ghidra 11.3.1, OpenJDK 21 and radare2 plugins, and the app controls the host Docker daemon through a mounted /var/run/docker.sock. Runner containers start with --privileged on Docker’s default network, and the Gradio interface listens on 0.0.0.0:7860 by default; the README asks maintainers to audit any added dependencies. - An OpenAI or Gemini API key and an LLM_MODEL setting go in .env. The README suggests gemini-2.5-pro or gemini-2.5-flash, while the code defaults to gpt-4o-mini; disassembly, decompiled code and tool output are sent to that provider. Users upload their own binaries. None are committed, and tests/test_disassemble.py expects a binaries/ch2.bin that the repository does not include. - The README reports validation on Root-Me CTF challenges, consistently solving difficulty-3-of-5 exercises automatically or semi-automatically, with no published runs or logs. Session data under /tmp/decompai_analysis_sessions by default is lost on reboot. - LICENSE is MIT text with an added clause requiring any use, modification or distribution to display a “Based on DecompAI” attribution, so GitHub does not recognise it as a standard licence; Ghidra, the Kali packages and model services keep their own terms. The README limits use to lawful reverse engineering, education and security research. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Kong > Command-line pipeline that runs Ghidra in-process through PyGhidra and asks Claude, OpenAI or OpenAI-compatible models to name the functions, types and parameters of a stripped binary, working bottom-up through the call graph so callers see already-named callees. It matches known library and cryptographic signatures first, sends functions whose decompilation looks obfuscated through a tool-using deobfuscation pass with z3-based simplification, applies results to the Ghidra program and exports annotated C and an analysis.json file. Its README calls it the first agentic reverse engineer; that label and its accuracy and cost figures are the author’s claims. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit is 25 commits after the v0.2.2 release of 2026-03-18, which matches kong-re 0.2.2 on PyPI; those later commits add an unreleased Rust kong-ml crate and XDA model-training scripts that the README does not describe. Kong needs Python 3.11+ with uv, a local Ghidra installation and JDK 21+, which it detects or reads from GHIDRA_INSTALL_DIR and JAVA_HOME. Its commands are kong setup, analyze, info and eval, with a Textual interface or --headless output. - Analysis needs an Anthropic or OpenAI API key, or an OpenAI-compatible endpoint passed with --base-url, and sends each function’s decompilation with its cross-references, strings and neighbouring signatures to that service; Kong tracks token use and estimated cost per model. Users supply the binary to analyse, and the repository ships no target binaries. - The README rates its confidence by architecture and source language: high for C and C++ on x86, x86-64, ARM and AArch64, medium or low for Go, Rust, MIPS and PowerPC, and lower as binaries grow. Obfuscation is detected by patterns in the decompiled text before the deobfuscation pass. BENCHMARKS.md reports a single run with claude-opus-4-6 on a stripped liblzma.so.5.4.1 from the backdoored XZ Utils 5.6.1 (CVE-2024-3094): 355 of 396 queued functions analysed in 15 minutes for $6.63, with the five core implant functions found at model-reported confidence of 90–95%. These are author results. - The kong eval command scores analysis.json against ground-truth source, using word-based Jaccard matching for names and signature-component scoring for types; no evaluation results are published. CI runs the pytest suite on Python 3.11 to 3.14 for pull requests. - Apache-2.0 per LICENSE and pyproject.toml; Ghidra, model services and analysed binaries keep their own terms. The README names KeygraphHQ’s Shannon web-pentesting pipeline as its inspiration. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### Co-op Anything > Agent playbook, skill set and stdio MCP server for adding online or split-screen co-op to single-player games the players already have installed. Agents either revive an existing co-op mod or reverse engineer the game and engine to build one, test it with in-game bots and send their notes back, while the MCP server searches a directory of 223 co-op projects and 32 open gaps, detects a game’s engine from its install folder and records the executable’s identity. Its README and reverse-engineering skill pair it with REA for native code, and two game write-ups report observations made through REA’s Ghidra lane. - Type: Integration - Targets: Game - Category: Community REA integrations - Relationship: Community REA integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository was created on 2026-10-16, the reviewed commit is from 2026-10-18, and there are no releases, so the playbook, directory and reported results are changing quickly. The MCP server is a Python 3.9+ script without an SDK that needs PyYAML for its directory tools; Claude Code picks it up from .mcp.json, and the playbook gives Codex, Gemini CLI and Cursor settings. The same skills ship under .agents/skills and .claude/skills. - Every player needs the game installed, and the hub holds no game files or assets. AGENTS.md tells agents to work on a copied install, ask the owner before installing software or using their accounts, and pin downloads by SHA-256. Its rules allow building on existing decompilations or decompiling a game, with that code kept in the game’s own repository under the licence of what it builds on. Analysis tools such as REA, Ghidra, IDA MCP servers, Frida, Cheat Engine, BepInEx and UE4SS are installed separately, and the playbook leaves REA’s npx rea-agents setup for the owner to run before restarting the agent. - Networking guidance uses Steam relay through Valve’s free Spacewar test app, and split-screen guidance builds on Nucleus Co-op and PartyDeck. The project rules restrict it to co-op and forbid anti-cheat bypass for online services and cheating in other people’s multiplayer games. - Results are reported by the author and contributors. The README lists Deus Ex as released and Ocarina of Time as fully synced, with other games in progress; each directory entry carries a QA level, from none through player reports and automated bot tests to a verified playthrough, and the Deus Ex write-up reports automated tests with real game clients. CI only checks that DIRECTORY.md matches data/directory.yaml. - MIT for the hub; MinHook source vendored in one game experiment keeps its own licence, and linked mods, decompilations, tools and games keep their own terms. The REA connection is a documented pairing for native analysis plus reported use in game notes. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### DeepExtract (DeepExtractIDA) > IDA Pro 9.x plugin and PowerShell batch extractor that turn Windows PE files into material AI coding agents can read: a per-binary SQLite database of PE metadata, signatures, disassembly, Hex-Rays pseudocode, cross-references, strings, stack frames, loops and dangerous API calls, plus optional grouped C++ and assembly files with per-function caller, callee and string headers and JSON indexes. It runs headless over directories, file lists or the modules of a running process, or interactively on the open IDA database, keeping the analyst’s renames and comments. The agent commands that work on this output come from the separate DeepExtractRuntime project. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit is the v0.9.14 release of 2026-09-12; ida-plugin.json lists IDA 9.0 to 9.3 on Windows x86-64, and the plugin installs with Hex-Rays’ hcli or runs from a clone. The README requires Windows 10 or 11 and IDA Pro 9.x, with the Pro edition for headless mode. The Hex-Rays decompiler is needed only for pseudocode and C++ output, while assembly output works from disassembly alone. pefile is vendored; the batch script also checks for Python on PATH and needs symchk.exe from the Windows SDK Debugging Tools for its default PDB download from Microsoft’s public symbol server. - Users supply the PE files, from single binaries to whole directories such as System32 or the modules loaded by a running process. The README warns that large batches can run for days and produce tens to hundreds of gigabytes. Outputs contain disassembly and decompiled code of the analysed binaries, whose own licences still apply. - The extractor calls no model. With -EnableAI, the batch extractor writes a CLAUDE.md that tells the agent, without asking the user, to clone the DeepExtractRuntime repository’s default branch into .claude and install Cursor rules and hooks; that runtime and its agents are not part of this repository. - Vtable and indirect-call resolution are labelled experimental, with stated limits such as a single vtable at object offset 0 and a short intra-procedural instruction window. Tests load IDA-independent modules such as the schema, configuration and code formatters outside IDA, and the release workflow only packages the plugin. - MIT, with the vendored pefile under its own MIT licence; IDA Pro, the Hex-Rays decompiler and the Windows SDK tools are licensed separately. The README presents the output for AI-assisted vulnerability research, reverse engineering, threat hunting and code review. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Mizuchi > Plugin pipeline for matching decompilation that loops over functions in an existing decomp project: m2c drafts C, decomp-permuter mutates it, Claude rewrites it through a compile-and-diff tool, and objdiff accepts a result only when the compiled object matches the target assembly. A local Decomp Atlas web app indexes matched and unmatched functions with call graphs and code embeddings, helps pick the next function and builds prompts, while HTML reports summarise each run. An optional integrator places matched C into a git worktree, checks the build and can commit, push or open a PR. - Type: Integration - Targets: Binary · Game - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit of 2026-08-17 declares package version 0.1.0; the repository has no releases or tags and is installed from source with npm on Node.js 22+. m2c and decomp-permuter are optional git submodules with setup scripts. Code embeddings need Python 3.10+ and download torch, transformers and an embedding model of about 2–3 GB, using Apple-Silicon MPS or the CPU; --skip-embeddings avoids them. - The Claude phase runs through the Claude Agent SDK and needs ANTHROPIC_API_KEY or cached Claude Code credentials; responses are cached locally by prompt hash. The example configuration allows 25 retries per prompt, gives the model read-only codebase tools plus compile_and_view_assembly, and accepts code only at zero instruction differences. - Mizuchi works inside a decompilation project the user already has, configured with a map file, non-matching assembly folders, a compiler shell script and the project’s period compiler. It supplies no ROMs, game assets or decompiled game code; the original files come from that project and the user’s own copies. Listed target settings include GBA, DS, 3DS, N64, GameCube, Wii, PlayStation 1/2, PSP, Switch, Saturn, Dreamcast, Win32, Android x86 and IRIX. - CI on Ubuntu runs type checks, lint, formatting and the Vitest suite and builds the CLI, using bundled agbcc and KMC GCC compiler fixtures. The README links an author post on benchmarks, and the repository publishes no match results. The integrator can push branches and open PRs with gh, and its optional AI build fix lets Claude edit files and run shell commands in the worktree, so review its output before it reaches a shared project. - MIT-licensed. m2c, decomp-permuter, objdiff, the embedding model and the compilers keep their own terms, and decompiled code inherits the target project’s rights and contribution rules. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### ReAgent > An open-source Python agent, published on PyPI as auto-re-agent, that drafts C/C++ implementations of functions in a compiled program from Ghidra evidence and has a separately configurable checker model review each draft in a bounded fix loop. A candidate is accepted only after a structural comparison with the decompile, assembly, control-flow and P-code evidence, the project’s own build, test and optional differential commands, and 11 heuristic parity signals. The README calls these gates conservative evidence, not proof of equivalence, and the tool writes candidates to an overlay rather than patching the source tree. - Type: Integration - Targets: Binary · Game - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed pin follows the v0.4.0 release of 2026-09-09 by one documentation commit; pyproject.toml classifies the package as alpha. The re-agent CLI covers init, plan, reverse, parity, status, estimate and evidence commands, with generic-cpp, windows-x64, gta-reversed and openrct2 profiles, the last two carrying hook and stub patterns for those existing reimplementation projects. Outputs are per-function candidate code, per-call prompt and response logs, checkpoints and a knowledge graph; the README says it never commits, pushes or overwrites the original tree. - Users supply the target program, a local Ghidra project in which it is imported, and a C/C++ project whose matching function bodies candidates replace in a temporary copy; the FAQ says useful results depend on that project’s source context, types, symbols and validation commands. Evidence comes from Ghidra exports read through the author’s separate ghidra-ai-bridge, whose headless export needs PyGhidra and a local Ghidra installation; without Ghidra only source-only parity checks run. No target binary or Ghidra export is bundled, and the GTA example needs the user’s own San Andreas executable. - It needs Python 3.10 or later; CI runs the tests on Linux with Python 3.10–3.13, on Windows with 3.12 and on macOS with 3.13. At least one model provider is required: a Claude or OpenAI-compatible API key, or an authenticated local Claude Code or Codex CLI, with reverser and checker free to use different providers at the user’s cost. Build, test and runtime commands are project-owned; argument arrays run directly on Windows and POSIX, legacy string commands need /bin/sh, and their results count as acceptance evidence only after trust_configured_commands is set explicitly. - docs/validation-0.3.md reports 131 tests passing locally on Python 3.13 with Ruff and strict mypy, and CI skips tests that need a model or Ghidra. Its one reference experiment, dated 2026-09-04, generated three GTA San Andreas timer functions with Claude CLI; each is reported to have passed review in one round, compiled through the example adapter and matched the original x86 code under Unicorn on seven inputs, with all three wrong-output controls detected. The author calls these 21 matching observations. - The repository and ghidra-ai-bridge are MIT-licensed; Ghidra, model services and the analysed programs keep their own terms. The README warns that configured commands are arbitrary project-owned commands to be trusted only when the project owner controls them, and that the Ghidra integration has to be tested in the user’s own environment. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### lisa.py > LLDB extension that adds an MCP bridge to a debugging session, adapted from ida-pro-mcp: the plugin's mcp start command serves 18 debugger functions over local JSON-RPC, and a FastMCP stdio server generated from those functions exposes them to MCP clients such as Claude Desktop. The tools create, launch or attach to targets, step, manage breakpoints, read backtraces, variables, disassembly and memory, evaluate expressions and run arbitrary LLDB commands. The same script keeps lisa.py's earlier exploit-development helpers, including checksec, a register and stack context view, Mach-O header and load-command display, Capstone disassembly and an exploitable crash-triage command. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The default dev branch was reviewed at commit 9dd61e9 from 2025-03-29, the last of three commits that day adding the MCP integration to a 2021 rewrite of lisa.py. There are no releases or tags, the master branch still holds the 2017 version without MCP support, and the README's TODO list asks for updated manuals and more test cases. - Python 3.10+ and LLDB with Python bindings; the LLDB Python environment must also import capstone, pinned to 4.0.2 in requirements.txt, and the MCP server needs fastmcp and httpx. The README is partly out of step with the code: it names server.py, lldb_plugin.py and an lldb-mcp clone path, while the repository ships lisa.py and lldb_mcp.py, and the pyproject lldb-mcp entry point names a module that does not exist. - Load lisa.py into LLDB with command script import, run mcp start, and point the MCP client at lldb_mcp.py; the README shows a Claude Desktop configuration that runs it through uv. The plugin listens on localhost port 13338 without authentication, and the MCP server always connects to that port even if mcp start was given another. run_lldb_command passes any LLDB command through, so a connected client has full control of the debugger and the debugged process. - The helper commands parse Mach-O headers and load commands and handle x86_64 and arm64/arm64e registers; the README states no supported operating system or LLDB version. The tests directory holds small crash programs, including Objective-C and libdispatch cases, that make rtests runs through LLDB; no CI is configured. - LICENSE is Apache-2.0, but pyproject.toml declares MIT and lldb_mcp.py carries ida-pro-mcp's MIT notice. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### WireMCP > Node.js MCP server that runs Wireshark's tshark for LLM clients, aimed in its README at threat hunting, network diagnostics and anomaly detection. Three tools capture a few seconds of live traffic and return either a fixed set of IP, port, TCP-flag and HTTP fields, tshark's protocol-hierarchy statistics or TCP conversation statistics; analyze_pcap returns IPs, ports, HTTP URLs and protocol stacks from a saved capture. The remaining tools match captured IPs against the URLhaus blocklist and scan a capture for HTTP Basic, FTP, Telnet and Kerberos credentials, beside the dissection output. - Type: Integration - Targets: Protocol - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main commit 7f45f8b from 2025-07-09, the last of nine commits since 2025-03-28; there are no releases or tags, package.json says 1.0.0 and its test script is a placeholder. It runs with Node.js (the README recommends v16+) after npm install, finds tshark on PATH or in common install locations, and is started by the MCP client as node index.js over stdio; the README lists macOS, Windows and Linux. Each tool also has a matching prompt template. - The live-capture tools default to interface en0 for 5 seconds and need capture permissions on the host; they write temp_capture.pcap in the working directory and delete it afterwards, and packet JSON is trimmed to about 720,000 characters. The server builds tshark shell commands by inserting the interface and file-path arguments without escaping, so it should be exposed only to trusted clients. - Field sets are fixed in the code: there is no arbitrary field extraction, display filter, decode-as or protocol-preference control, and the server does not infer unknown message formats. - check_threats and check_ip_threats download the URLhaus text blocklist from abuse.ch and match IPs locally; although the README mentions multiple threat feeds, the reviewed code queries only URLhaus. The credential scan and threat checks are security heuristics, and their findings need analyst review. - MIT; Wireshark and tshark keep their own GPL terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### ReverserAI > Binary Ninja plugin that suggests function names from HLIL decompiler output with a language model run locally through llama.cpp; the README says it operates entirely offline once the model is downloaded. It can rename the current function, every function still carrying a default sub_ name in call-graph post-order, or only those referencing strings and imported or library symbols. The author presents it as a research proof of concept whose only implemented task is function naming. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit is the v1.2 release of 2026-05-20, and plugin.json and setup.py both declare version 1.2. It installs through Binary Ninja’s plugin manager, or by cloning into Binary Ninja’s plugins folder and installing requirements.txt (huggingface-hub, llama-cpp-python, networkx, toml, typer) and the package; setup.py asks for Python 3.10+, and plugin.json lists macOS, Windows and Linux with minimum Binary Ninja build 2487. - On first use the plugin downloads the selected GGUF model from Hugging Face: by default mistral-7b-instruct-v0.2.Q4_K_M.gguf, about 5 GB and needing about 5 GB of RAM, or a Mixtral-8x7B-Instruct quantization needing about 25 GB. Inference then runs on the local CPU or GPU, which the README describes as entirely offline. It advises at least 16 GB of RAM and 12 CPU threads and reports 20 to 30 seconds per query on CPU, or 2 to 5 seconds with GPU offload such as on Apple silicon. Model, memory mapping, CPU threads, GPU layers and seed are Binary Ninja settings that take effect after a restart. - Three Plugins → ReverserAI commands cover the naming modes: Rename Current Function, Rename All Functions, and Enhance Function Naming with Context, which limits renaming to default-named functions referencing strings or import, library or external symbols. Each request puts one function’s HLIL text into a fixed prompt asking for a name of up to 20 characters, keeps the first line of the reply and writes it to the database as the function name without a confirmation step, logging the old and new names. Functions whose decompiler output exceeds the 4,000-token context fail with a logged warning. - The README calls ReverserAI a proof of concept, notes that local models do not match cloud models, and plans code explanation, other decompilers and server-hosted inference only as future work. The examples folder ships a password-protected samples.zip of test samples, including the PowerPC stub triton_inject.bin from the Triton malware, and its README describes their results qualitatively. CI runs only ruff formatting and lint checks, a setup.py metadata check and a Python syntax parse; there are no tests. - GPL-2.0 per LICENSE; plugin.json and setup.py state version 2 or later. Binary Ninja and the downloaded model weights keep their own licences and terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### WPeGPT > IDA plugin, formerly WPeChatGPT and inspired by Gepetto, that sends the Hex-Rays pseudocode of a function to an OpenAI-compatible model (OpenAI, DeepSeek or another compatible endpoint) and writes the model's analysis back into IDA as comments. Interactive actions explain a function's purpose and behavior, suggest variable names, re-express small routines such as XOR decoding in Python and flag potential vulnerabilities. Version 3.0 adds WPeServer, a TCP command server inside IDA through which an external controller or the separate wpegpt-analyzer skill runs headless light, full or vulnerability-focused passes, with string classification, network-indicator extraction, function suspiciousness scoring and JSON plus Markdown reports. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at tag v3.0 (2026-05-27), which is the reviewed main commit; the GitHub release has no attached files. Install by copying WPeGPT.py and the WPeGPT_Config folder (config.py and wpe_ai_controller.py) into IDA's plugins directory. IDA must run Python 3, and the plugin imports ida_hexrays, so a Hex-Rays decompiler for the target architecture is needed. Python dependencies are openai >= 0.27.0 and httpx. - config.py ships with empty API_KEY, API_BASE_URL and MODEL values that must be set for an OpenAI-compatible provider, plus an optional forward proxy, worker count and default analysis mode (light); the interface defaults to Chinese (ZH_CN = True). The README estimates light, full and vuln runs at roughly 2–5, 10–30 and 5–20 minutes. WPeServer binds to 127.0.0.1 on an OS-assigned port, and headless runs start from the IDA menu or the separately maintained wpegpt-analyzer skill. - Works on a binary the user opens in IDA; the repository bundles only the plugin, its configuration and screenshots. Each request sends decompiled pseudocode to the configured model provider, and automated runs send many functions, so weigh confidentiality and API cost before analyzing sensitive samples. The README calls AI results for reference only; comments and reports are model suggestions that need analyst checking. - No license file is present and GitHub detects no license, so no reuse terms are granted. IDA, the Hex-Rays decompiler and model APIs are licensed separately. ##### Primary sources 1. 2. 3. 4. 5. 6. #### IDAssist > IDA Pro plugin by Jason Tang, who also wrote GhidrAssist, that adds a dockable PySide6 panel for LLM-assisted analysis of the open database. Its tabs explain decompiled or disassembled functions with a security summary, keep persistent chats with context macros and an optional ReAct agent mode, propose function, variable and type renames for review before they are applied, and build a semantic knowledge graph of functions, calls, data flows and security traits, with retrieval over reference documents the analyst adds. Models can call built-in IDA tools or external MCP servers, and a SymGraph tab imports and publishes names, types and graph data through the hosted symgraph.ai service. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2.4.0, published 2026-09-14 as a source-only GitHub release; the reviewed master commit is one commit later and only updates model guidance. The README and getting-started guide require IDA Pro 9.0+ with its bundled Python 3.11+ and PySide6, while ida-plugin.json lists IDA 9.1–9.4, and the 2.3.0 notes report fixes for IDA 9.3 and 9.4 on Windows with Python 3.14. Hex-Rays is recommended for pseudocode, with disassembly used otherwise. It installs with Hex-Rays' hcli plugin manager, or from a release archive in the IDA plugins directory with requirements.txt installed into IDA's Python; that file adds boto3 for Bedrock, which the manifest's dependency list omits. - Analysis needs at least one configured LLM provider. The reviewed provider types cover Anthropic, OpenAI, Gemini and xAI API keys, OpenAI and Gemini subscription sign-in through OAuth, the local Claude Code CLI, AWS Bedrock, a LiteLLM proxy, and local Ollama, LM Studio or Open WebUI endpoints; the README's table also lists an Anthropic OAuth type that the source does not define. Explanations, chats and agent runs send pseudocode or disassembly to the active provider, so only a local or self-hosted endpoint keeps code on the machine. The documentation says chats, graphs, settings and feedback are kept in local SQLite databases in the .idapro/idassist folder of the user's home directory, with API keys encrypted in the settings database. - Programs come from the user's own IDA databases. Rename suggestions show confidence scores and are written to the IDB only for the rows the user selects. During a chat, built-in tools and external MCP servers, reached by URL over SSE or streamable HTTP or launched over stdio, can read and modify the IDB; in the Query tab, calls to tools whose names do not look read-only wait for an allow-once, allow-for-session or deny decision unless the chat accepts all tools, and this classification relies on tool-name keywords. - The SymGraph tab looks up the input binary by SHA-256 without a key, but importing, publishing and uploading need a SymGraph API key, and publishing uploads the raw binary itself when the service does not already hold it. The repository has no tests or CI workflows. MIT, per LICENSE and ida-plugin.json; IDA Pro, the Hex-Rays decompiler, model providers and SymGraph keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### GhidraGPT > Ghidra extension that sends one function’s decompiled C to a hosted or local language model the user selects and streams the answer into a GhidraGPT console. Its three actions, offered in the Decompiler and Listing context menus, explain the function; rewrite it by writing recovered function, parameter and variable names, types, the prototype and inline comments back into the program; or audit it for likely security issues. Every action uses only the current function’s decompiler output, and the README calls audit findings leads to verify rather than sound static analysis. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit is the v1.4.0 release of 2026-07-22, which attaches GhidraGPT-1.4.0.zip. extension.properties declares Ghidra 12.1.2, and the README requires Ghidra 12.1.x, noting that the extension declares compatibility with the Ghidra version it is built against. Building from source needs JDK 21+, Maven and GHIDRA_INSTALL_DIR pointing at a local Ghidra; the zip is then added through Ghidra’s Install Extensions dialog. - Each request sends the function name and its decompiled code, prefixed with instruction addresses for Rewrite together with a list of its variables, to the configured provider: OpenAI, Anthropic, Google Gemini, Cohere, Mistral AI, DeepSeek, Grok, OpenRouter, a local Ollama model or any OpenAI-compatible endpoint. Hosted providers need the user’s own API key, which the README says is stored in config.properties in a .ghidragpt folder under the user’s home directory with XOR obfuscation that is not encryption; every provider except Ollama needs network access. - Rewrite applies the parsed names, types, prototype and comments in Ghidra transactions without a separate confirmation step. The README states that there is no interprocedural or whole-program analysis, so callers, callees and data flow outside the function are not given to the model. - CI downloads Ghidra 12.1.2, sets up JDK 21 and runs Maven unit tests for configuration handling, prompt building and parsing of model responses and rewrite edits; these do not exercise the Ghidra interface or model output. - Apache-2.0 license; the README names Mohamed Benchikh as author. Ghidra and each model provider keep their own licences and terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### GhidrAssist > Ghidra extension by Jason Tang, who also wrote GhidrAssistMCP, that adds a tabbed GhidrAssist window to CodeBrowser for LLM-assisted analysis of the open program. Its tabs explain decompiled or disassembled functions with a security summary, keep persistent chats with context macros, MCP tool calling and an optional ReAct agent mode, propose function and variable renames, retypes and structures for review before they are applied, and build a semantic knowledge graph of functions, calls and security features with community detection, alongside Lucene retrieval over reference documents the analyst adds. A SymGraph tab imports and publishes names, types, graph data and documents through the hosted symgraph.ai service. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2.2.0, published 2026-05-29 with extension zips for Ghidra 12.0 and 12.1 Public; the reviewed master commit is three commits later and only updates model guidance and max-token handling. The README and getting-started guide state a Ghidra 11.0 minimum, but release zips are built per Ghidra version and recent ones cover only 12.x. Installation goes through File → Install Extensions, after which the plugin is enabled under CodeBrowser's File → Configure → Miscellaneous; source builds use Gradle with GHIDRA_INSTALL_DIR. - Analysis needs at least one configured LLM provider. The reviewed provider types cover Anthropic, OpenAI, Azure OpenAI, Gemini and xAI APIs, OpenAI and Gemini subscription sign-in through OAuth, the local Claude Code CLI, a LiteLLM proxy, and local Ollama, LM Studio or Open WebUI endpoints; the documentation's provider tables also list an Anthropic OAuth type that the source does not define. Explanations, chats, Actions, agent runs and the graph's Semantic Analysis step send pseudocode or disassembly to the active provider, so only a local or self-hosted endpoint keeps code on the machine, while graph re-indexing and Security Analysis run without the model. Chats, explanations, graph data and feedback are kept in local SQLite databases and a Lucene index whose paths are set in Settings. - Programs come from the user's own Ghidra projects. Actions suggestions are applied only for the rows the user checks. Chats can reach MCP servers over SSE or streamable HTTP or launch them over stdio; built-in tools read the current function and address, apply the Actions edits and query the semantic graph, and the README pairs the plugin with GhidrAssistMCP for decompilation, cross-reference and other Ghidra-specific tools. Calls to tools whose names do not look read-only wait for an allow-once, allow-for-session or deny decision, and this classification relies on tool-name keywords. - The SymGraph tab looks up the program by SHA-256 without a key, but importing, publishing and uploading need a SymGraph API key, and publishing uploads the raw binary itself when the service does not already hold it. The repository has no tests or CI workflows. - MIT, per LICENSE and the README; Ghidra, model providers and SymGraph keep their own terms. The repository moved from jtang613/GhidrAssist. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### Rikugan > IDA Pro and Binary Ninja plugin that runs its own agent loop inside the disassembler: a model the user chooses streams its answers and calls more than 60 in-process tools for navigation, decompilation, disassembly, cross-references, strings, types, annotations, scripting and host IL or microcode edits. An orchestrator can map a binary and spawn parallel subagents, findings persist in a RIKUGAN.md file beside the database, and experimental commands apply plain-language patches or, on Binary Ninja, remove control-flow flattening and other obfuscation. README says it was vibecoded with Claude Code. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** README requires IDA Pro 9.0+ with the Hex-Rays decompiler or Binary Ninja in UI mode, and Python 3.10+, while pyproject.toml asks for 3.11+; ida-plugin.json lists IDA 9.0 to 9.2 on Windows, Linux and macOS. Windows also needs the latest Visual C++ 2015–2022 x64 redistributable, and the install scripts are piped from raw GitHub. - **Prerequisites:** Needs at least one model provider: Anthropic, OpenAI, Gemini, MiniMax, Codex, local Ollama or any OpenAI-compatible endpoint. Tool results from the open database go to the chosen provider; profiles limit which data the model may read and which tools it may use. - **Limits:** Version 1.4.0 (released 2026-09-25) at review. README says the agent asks permission before running scripts and never executes the target binary; natural-language patching (/modify) and the Binary Ninja /deobfuscation skill are marked experimental. - **Testing evidence:** CI runs Ruff format and lint checks, mypy on the core and provider modules, pytest with an IDA mock and a desloppify score-regression gate. The repository publishes no benchmark; a Synacktiv article of 2026-10-13 compared it with another Binary Ninja agent on two CREBench tasks and attributed most of the gap to a prompt difference. - **License:** MIT per LICENSE and both plugin manifests; IDA Pro, Hex-Rays, Binary Ninja and model services keep their own licences and terms. - **Attribution:** README calls the project a work in progress whose first version was built in a single night, and the repository carries an AGENTS.md developer guide. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### bn > Agent-oriented command-line interface for the Binary Ninja database already open in the GUI, reached through a companion plugin that listens on a local Unix-domain socket. Agents read decompilation, IL, disassembly, cross-references, callsites, types and data, export multi-function bundles and run unrestricted Python inside Binary Ninja; renames and prototype, structure and type edits can be previewed, are verified after they apply and roll back on failure. Large text output spills to hashed artifact files, and a packaged Codex skill describes the workflow. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v0.15.0, published on GitHub and PyPI as bn-cli on 2026-09-04; the reviewed master commit is that tag and the repository's last push. It needs Python 3.12+ and installs as a uv tool; bn plugin install links the BN Agent Bridge plugin into Binary Ninja, and bn skill install links the skill into the skills folder of the Codex home directory. The CLI and the loaded plugin must share bridge protocol 2, so Binary Ninja is restarted or its plugins reloaded after upgrades. - Work happens against a database open in the Binary Ninja GUI; the README says the companion works with a personal license and needs no headless license. The bridge socket lives in the user's cache directory, and the README names no supported operating systems or Binary Ninja versions. With several views open, commands need an explicit --target selector instead of silently using the active tab. - The analyst supplies the binary and database; the repository holds no target binaries. bn py runs unrestricted Python with the user's privileges inside Binary Ninja, and its writes bypass the preview, verification and rollback of built-in mutations; the reviewed bridge code adds no authentication beyond access to the socket path. Whole-database text and constant searches stop after a default five-second analysis budget and report incomplete results. - CI runs pytest on Python 3.12 and 3.14 against a stub binaryninja module, checks release metadata and smoke-tests plugin and skill installation from the built wheel, so no real Binary Ninja instance is exercised. Mutations report verified, noop, unsupported or verification_failed, and the README notes that decompiled output can stay stale after type changes until types are read back or analysis is refreshed. - MIT, added to the repository in v0.14.1; Binary Ninja keeps its own license terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. #### IDA Pro MCP Server (fdrechsler) > An IDA Pro plugin and a TypeScript MCP server by Florian Drechsler: the plugin starts an HTTP server inside IDA on 127.0.0.1:9045, and the stdio MCP server forwards agent requests to it. Its twelve tools run IDAPython scripts passed inline or by file path, list functions, exports and strings, search names, immediate values and byte sequences, return cross-references to and from an address, and disassemble address ranges. It is a separate codebase from the mrexodia and Hex-Rays IDA MCP servers listed here. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Dormant: its six commits date from 2025-03-24 to 2025-03-26, with no tags, releases or npm package. The README asks for IDA Pro 8.3 or later, Node.js 18+ and TypeScript; the MCP server is built from a clone with npm install and npm run build, and ida_remote_server.py is copied into IDA's plugins directory, where it starts its server when IDA loads. MCP clients launch the built dist/index.js over stdio. - IDA Pro is commercial software installed separately, and the tools act on whatever database the analyst has open; the repository holds only source files and a screenshot. The README documents eight of the twelve tools and an npm test command, but package.json defines no test script and the project has no tests. At the pinned commit index.ts imports llamaindex, which package.json does not declare, and the search_text tool queries a MongoDB strings collection at localhost:27017 instead of IDA, with its IDA call commented out. - Script tools run arbitrary IDAPython inside IDA, and while a script runs the plugin overrides IDA's prompt functions so that dialogs are auto-confirmed or suppressed. The HTTP server has no authentication: the README's security note relies on the localhost-only default bind and warns about the implications of changing DEFAULT_HOST. - The LICENSE file and README state MIT, while package.json declares ISC. IDA Pro, MCP clients and analysed binaries keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Ghidra Headless MCP > Headless-only MCP server that drives Ghidra through PyGhidra and is meant to share a container with the agent rather than attach to a Ghidra GUI. Its 212 tools in 34 groups cover program and project lifecycle, disassembly, decompilation and P-code, patching and memory edits, symbols, references, types and structure layouts, search and graph extraction, with raw Python, Java-API and script access for anything else. Programs open read-only by default, edits run in transactions with undo and redo, a fake backend lets development and CI run without Ghidra, and a ghidra_cli client exposes the same tools to shells and agents without MCP. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit (2026-09-16) reports version 0.1.0, with no tags or releases; the changelog keeps all changes under Unreleased, and RELEASING.md says source releases go to GitHub only, not PyPI, and that no public release tag should be created until a license is chosen. Install from a checkout with pip. The README says the code, tests and documentation are entirely vibe coded. - Python 3.11+ with pyghidra 3.0.2+ and a local Ghidra installation given through GHIDRA_INSTALL_DIR or --ghidra-install-dir; the README names no minimum Ghidra release. MCP runs over stdio or TCP, with setup examples for Claude Code, Codex and generic MCP hosts and a sample Kali-based Dockerfile that installs Ghidra beside the agent. Debugger, Version Tracking, FID, BSim and emulator workflows are listed as not exposed. - ghidra.eval, ghidra.call and ghidra.script run arbitrary Python, Java and scripts inside the Ghidra runtime, and both transports are unauthenticated; the TCP server binds 127.0.0.1, and the README limits use to trusted, containerized environments. Read-only sessions protect program state but do not sandbox filesystem or process access. - The repository bundles a stripped AArch64 GNU coreutils ls executable in samples/ as the feature fuzzer’s default target, and a small compiled hello test fixture with its C source. The README says CI also runs live Ghidra tests and a wheel check, but the reviewed workflow runs only Ruff and the non-live pytest suite on the fake backend. - GitHub detects GPL-2.0 from the LICENSE file added in the initial commit, while the README and RELEASING.md still treat the license as unchosen and pyproject.toml declares none. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Binary Ninja Headless MCP > A third-party, headless-only MCP server by Ruben Marks (mrphrazer) that gives agents a large Binary Ninja tool surface the project counts as 181 tools across 36 feature groups, including disassembly, intermediate languages, cross-references, types, search, patching with undo/redo transactions, and arbitrary scripting through binja.eval and binja.call. It speaks MCP over stdio or TCP, ships a schema-derived command-line client (binja_cli), and is meant to run in the same container as the agent runtime. A fake-backend mode runs the CLI, tests and a feature fuzzer without a Binary Ninja license, while real analysis needs a headless-capable license. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main 7fafd75 (2026-09-19); the pyproject declares package version 0.2.0 and there are no tagged releases. The README positions it against GUI-bound or limited Binary Ninja MCP servers as a headless-only, agent-driven alternative with mutation workflows and scripting, and states the whole project, including its code, tests and documentation, is vibe coded. - Needs Python 3.11+. Real analysis requires a Binary Ninja installation with a headless-capable license and the binaryninja Python module importable; the README notes enterprise and debugger APIs are not covered. A fake-backend mode (BINARY_NINJA_HEADLESS_MCP_FAKE_BACKEND=1) runs the CLI, the pytest suite and the feature fuzzer without a license, which is what CI exercises on Python 3.11 with ruff and pytest. - Install with pip from a clone or straight from the repository. Register it with an MCP host such as Claude Code or Codex over stdio (default) or TCP; the recommended deployment runs the agent and this server in one container. The repository bundles a sample binary, samples/ls (a stripped aarch64 GNU coreutils ls), as the fuzzer and verification target, plus small C fixtures. - The README's security model states that stdio and TCP transports are unauthenticated by default and that binja.eval and binja.call expose arbitrary scripting and broad API access, intended only for trusted containerized environments and not to be exposed to untrusted users or networks. Read-only mode is the session default, memory.read is capped at 65536 bytes, and mutations use undo/redo transactions. - The bundled CLI_VERIFICATION.md reports native coverage of all 181 tools on Binary Ninja 6.0.10601 Ultimate (AArch64 Linux host) across both architectures, transports and argument styles, but its evidence links point to files in the authors' analysis environment rather than the shipped package. GPL-2.0. Use it on binaries the operator is authorized to examine. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### IDA-Skill > Agent skill that has an AI agent triage malware samples statically in IDA Pro through headless idat. An initialization script builds the IDA database and exports a summary, imports, exports, entry-point decompilation and filtered strings, and an executor runs IDAPython snippets or files against that database. SKILL.md sets a static-only rule, a top-down method and a rule to hand large string dumps to a sub-agent, and bundled scripts add cryptographic-constant detection, an export-size check and REAI, which sends decompiled functions to a configured OpenAI-compatible model to describe them and rename them with an AI_ prefix. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main commit 4595864 of 2026-10-21; there are no releases or version numbers, and recent commits are titled only "update". The skill is a SKILL.md with name and description front matter for agent clients that load skill folders; the README demonstrates it with the author's Spore multi-agent framework and names no other tested client. Its commands use Windows PowerShell here-strings and paths under skills/IDA-Skill/tools/. - Requires a licensed IDA Pro installation whose idat executable is set in config.json (the README example is IDA Pro 9.0's idat64.exe) and Python on the host to launch it; decompilation calls rely on the Hex-Rays decompiler. Users supply the samples, and SKILL.md forbids debugging or executing them. REAI needs openai 1.0+ and an API key, endpoint and model edited into tools/reai.py, and it sends decompiled pseudocode to that endpoint. - API.md and docs/ hold a Markdown IDAPython API reference whose source and terms are not stated, analysis/ holds short method notes for tasks such as protocol, algorithm, firmware and driver analysis, and movie.mp4 is a 25 MB demo video. TOOLS.md tells the agent to run reai check first and not to run analyze when a call chain exceeds 40 functions. - The repository has no tests or CI and reports no evaluated samples or accuracy. REAI names and descriptions are model output that needs analyst review. - LICENSE holds the AGPL-3.0 text, while both READMEs call the project GPL-3.0 and add an education-and-research-only, no-commercial-use condition that neither license contains, so reuse terms are unclear. IDA Pro and model APIs keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### BinAssist > Binary Ninja plugin by Jason Tang, who also wrote GhidrAssist and IDAssist, that adds a BinAssist sidebar for LLM-assisted analysis of the open binary. Its tabs explain functions at the LLIL, MLIL and HLIL levels and individual instructions, keep chats with context macros, MCP tool calling and an optional ReAct agent mode, propose function and variable renames, retypes and structures with confidence scores for review before they are applied, and build a semantic graph of functions and calls with community detection and source-to-sink taint paths, alongside retrieval over reference documents the analyst adds. A SymGraph tab imports and publishes names, graph data and documents through the hosted symgraph.ai service. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: 2.1.0, published 2026-05-25 as a source-only GitHub release without notes; the reviewed master commit is four commits later and adds a default Claude Code CLI path on macOS and updated model guidance. plugin.json requires Binary Ninja build 5000 or later and lists Linux, Windows and macOS, while the README gives both 4000 and 5000 as the minimum; the README names Linux as the primary development platform and calls Windows and macOS less tested. The packages in requirements.txt, including openai, anthropic, mcp 1.23.3 and whoosh, plus pywin32 on Windows, are installed into Binary Ninja's Python, and a separate Windows guide covers installing them into its user site-packages. - Analysis needs at least one configured LLM provider. The provider types cover Anthropic, OpenAI, Gemini and xAI API keys, OpenAI and Gemini subscription sign-in through OAuth, the local Claude Code CLI, a LiteLLM proxy for services such as AWS Bedrock and Azure, and local Ollama, LM Studio or Open WebUI endpoints; the documentation's provider tables also list an Anthropic OAuth type that the source does not define. Explanations, chats, Actions, agent runs and the graph's Semantic Analysis step send code from the binary to the active provider, so only a local or self-hosted endpoint keeps it on the machine, while the documentation describes re-indexing, Security Analysis and community detection without the model. The settings documentation places the analysis and RLHF feedback SQLite databases and the RAG index in a .binaryninja/binassist folder of the user's home directory, with analysis results keyed by the binary's SHA-256. - Programs come from the user's own Binary Ninja sessions; the plugin supplies no target binaries. Actions suggestions are applied only for the rows the user selects. Chats can reach MCP servers over streamable HTTP or SSE or launch them over stdio, and the documentation recommends the author's separate BinAssistMCP server for Binary Ninja analysis tools. In the Query tab, calls to tools whose names do not look read-only wait for an allow-once, allow-for-session or deny decision unless the chat accepts all tools, and this classification relies on tool-name keywords. - The SymGraph tab looks up the binary by SHA-256 without a key, but importing, publishing and uploading need a SymGraph API key, and publishing uploads the raw binary bytes, not the .bndb database, when the service does not already hold them. The repository has no tests or CI workflows. MIT, per LICENSE and plugin.json; Binary Ninja, model providers and SymGraph keep their own terms. The repository moved from jtang613/BinAssist. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. #### Reversecore MCP > MCP server that puts radare2 with r2ghidra, LIEF, Capstone, YARA, CAPA, Detect It Easy, binwalk, angr, Volatility3, Scapy, Sleuth Kit and other engines behind 177 typed tools for AI clients such as Claude and Cursor. The tools cover disassembly and decompilation, binary parsing, string, IOC and capability extraction, ESIL emulation and symbolic execution, YARA scanning, memory, PCAP and disk forensics, source-code pattern scanning and session reports with MITRE ATT&CK mapping, alongside 22 guided analysis prompts and per-binary MCP resources. File access is confined to a configured sample workspace, and the server runs over stdio or HTTP/SSE, typically from the project's Docker image. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Latest release at review: v3.0.5, published 2026-09-28 on GitHub with a wheel, sdist, SBOMs and Sigstore bundles, on PyPI as reversecore-mcp and as a GHCR image. The reviewed main commit of 2026-10-17 is 147 commits ahead of that tag, while pyproject.toml still declares 3.0.5. The README's test and coverage figures (3,069 tests, 88%) are hard-coded badges and differ from the older counts in AGENTS.md. - Python 3.10–3.12, with angr installed only on Python 3.12. Local installs need radare2 on the PATH, plus Volatility3, Scapy and Sleuth Kit for forensics; the README recommends the Docker image, which bundles the engines, with x86 and Apple Silicon compose profiles. It lists Linux or macOS hosts or any Docker environment, at least 4 cores, 8 GB RAM and 20 GB storage; Redis backs the task queue and result cache, and an SQLite memory database keeps notes across sessions. - Binaries, memory images, PCAPs and disk images come from the analyst and are mounted into the workspace, where path validation confines tool access. Optional container sandboxing for dynamic-analysis tools is disabled by default, and HTTP mode accepts only loopback clients unless MCP_API_KEY is set. Some tools and prompts target exploit and PoC development. - CI runs linting, type checks, Bandit, pip-audit and CodeQL, unit tests on Python 3.10–3.12 with an 85% coverage gate, security-boundary, integration and MCP client end-to-end suites, and a wheel build-and-install check; ClusterFuzzLite and nightly fuzzing run separately. Test fixtures include small synthetic vulnerable C targets with seeds, proof-of-concept inputs and ASan logs, and scratch/binaries holds only a hello.c source. - MIT; the wrapped engines and the packages in the Docker image keep their own licenses. ORIGINAL_REQUEST.md records a 2026-08-22 brief asking an orchestrating agent to dispatch subagents for transport hardening, prompt expansion and output optimization, so parts of the code were developed with AI agents. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. #### AutoProber > Flying-probe control stack meant to let a coding agent or an operator take a circuit board on a GRBL 3018-style CNC from locating it on the plate, through XYZ-tagged USB-microscope frames and an annotated map of pads, pins and chips, to probing targets the operator has approved. Python wrappers, a Flask dashboard and AGENTS.md safety rules run every move under an oscilloscope-monitored optical endstop that triggers feed hold and a STOP state with no automatic recovery. The published code covers device control, camera-to-motion calibration and map and probe-candidate review; the README presents locating, stitching and annotating the board as agent tasks. - Type: Integration - Targets: Firmware - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README calls the reviewed commit ff0e01f ("1st Release", 2026-04-16) a source-available release candidate; pyproject.toml declares version 0.1.0, no releases are published, and the RELEASE_MANIFEST.md the README cites is not in the repository. There have been no commits since. - The tested hardware is a GRBL-compatible 3018-style CNC over USB serial, a UVC USB microscope served by mjpg_streamer, a Siglent oscilloscope over LAN/SCPI (Channel 4 for the optical endstop, Channel 1 for pogo-probe measurement), an optical endstop on an external 5 V supply, an optional Matter power strip controlled through chip-tool, and the 3D-printed toolhead parts in cad/. docs/BOM.md lists the parts. - Runs on a Linux control host with Python 3.8+ via uv; pyproject.toml declares only Flask and pyserial, while the calibration script also imports OpenCV. Lab hosts, ports and paths come from environment variables in the example config. README says calibration must be generated on the machine that moves and the microscope-to-probe offset measured before real probing, and that the dashboard must not be exposed to untrusted networks. No automated tests are published. - Works with whatever agent the operator uses: README has it ingest the project and drive the dashboard or Python scripts, and AGENTS.md sets the safety rules; no MCP server or specific agent is bundled. README limits use to equipment and targets the user is authorized to test. - PolyForm Noncommercial 1.0.0 with a required copyright notice for GainSec; commercial use needs a separate paid license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### ToCode > Python CLI that exports a binary, IDA database, Android APK, .NET assembly or whole application folder into a source-like project tree for coding agents: recovered C (Java for APKs, C# and IL for .NET) with matching assembly and function summaries, recovered headers and types, section dumps, JSON indexes of functions, strings, imports, exports, reachability and call-graph clusters, and generated AGENTS.md and CLAUDE.md files. It drives IDA, Binary Ninja, radare2 with r2ghidra or angr, and for folders links each import to the defining file's function using the platform's loader rules. Its tocode mcp server keeps the decompiler open so an agent can record names, types and comments and re-render only the affected files. - Type: Integration - Targets: App · Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - PyPI release at review: tocode-cli 0.3.2, uploaded 2026-10-16; the reviewed main commit is a merge commit one commit ahead of tag v0.3.2. The repository was created on 2026-05-20. It needs Python 3.10+ on Windows, Linux or macOS and installs with pip or uv, or with install.sh or install.ps1 from a clone. - A decompiler backend is not bundled: IDA through the ida-domain and idapro libraries, Binary Ninja headless where the license allows it or through its built-in MCP server or an RPC bridge in a running UI, radare2 with r2ghidra, or the optional angr extra of about 450 MB, whose pseudo-C the README calls lower quality. .NET exports need a .NET 9+ runtime and download dnlib and ICSharpCode.Decompiler from nuget.org after a prompt, checked against pinned SHA-256 hashes; APKs use the droidasc package. - Supply the binaries or application folders yourself. Exports copy section data, non-code APK entries and native libraries from the input, so they are as sensitive as the analyzed files. The README warns that the Binary Ninja RPC bridge exposes the whole Python VM without authentication and must stay bound to 127.0.0.1. - The eval directory defines a blind source-recovery benchmark: nine small C programs are built with and without debug info, a headless Claude Code agent restricted to the ToCode MCP server and file tools works on the stripped build, and a judge scores names, types, an LLM grade per function, behavior on test inputs and leakage. No benchmark results are committed; tests use generated fixtures and a fake Binary Ninja module, and the repository commits no binaries. - MIT (LICENSE, pyproject.toml). tocode skill install adds a workflow skill for Claude Code and Codex. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Reverse API Engineer > Python CLI that turns the HTTP traffic a website actually produces into a typed API client. A browser session, driven by the user through Playwright or by an AI agent through Playwright or Chrome DevTools MCP servers or Vercel's agent-browser CLI, is recorded to a HAR file; a coding agent run through the Claude Agent SDK, OpenCode, Cursor or GitHub Copilot then reads the capture and writes a client, README and usage example in one of ten languages. A separate collector mode gathers structured JSON/CSV data with web search and fetch. - Type: Integration - Targets: Website - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at main commit 4e15017 (2026-10-26). The latest release is v0.14.0, published on GitHub and PyPI on 2026-09-23; the changelog's unreleased section adds security dependency updates. pyproject marks the project beta and requires Python 3.11+, the README supports Linux, Apple Silicon macOS and 64-bit Windows because of its cryptography dependency, and CI runs ruff, mypy and pytest on Linux, macOS and Windows with Python 3.11 to 3.13. - Agent mode launches its browser tooling through npx, so it needs Node.js; the chrome-mcp provider drives the user's real Chrome with existing sessions and cookies and needs Chrome 146+ and Node.js 20.19+. Manual mode needs the [manual] extra and a Playwright Chromium. Generation needs a model backend: the default SDK is the Claude Agent SDK with Sonnet 4.6, and the README asks for an API key for agent mode, while OpenCode starts with a free default model and can use locally installed Ollama models that support tool calling and a 64k+ context. - The input is traffic from sites the user browses. The engineer prompt tells the model to hardcode every credential, cookie, token and session value found in the HAR, so captures and generated clients must be handled as secrets. The README warns that generated code runs locally and should be reviewed before it is executed, and that sites with aggressive bot detection may block capture; generated clients call undocumented internal endpoints that can change, and their use stays subject to each site's terms. - The examples directory holds generated clients for public endpoints of Apple and Uber careers, Ashby job boards, AutoScout24 listings, IKEA's catalog and Mintlify's documentation assistant. An optional local check generates a client for a fixture website and verifies it against changed live responses. MIT license. Its RAE abbreviation stands for Reverse API Engineer. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### OpenBaud > Rust MCP server and Codex plugin that gives coding agents audited access to local serial devices, from identifying ports by USB metadata and sending framed requests to recording every received and transmitted byte in lossless .obcap captures. Device behaviour confirmed during exploration is kept as YAML device profiles, typed commands and workflows that validate checksums and decode scalars, bit fields and record arrays, and the same commands can be replayed against a capture without hardware. Its worked demo decodes OBP/1, a small binary protocol the author wrote for an ESP32-S3 test board, not an existing vendor protocol. - Type: Integration - Targets: Protocol - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A young project: the repository was created on 2026-08-23 and had 48 commits at the reviewed v0.3.0 release commit of 2026-10-09. Cargo.toml declares version 0.3.0 and rust-toolchain.toml pins Rust 1.96.0. The README and plugin guide document installation only for Codex, through codex plugin marketplace add with the stable branch or a release archive; the server itself runs as openbaud mcp over stdio, and no other MCP client is documented. - The v0.3.0 release provides plugin archives for macOS ARM64 and Intel, Linux x64 and ARM64, Windows x64 and a universal bundle, each with a SHA-256 file. The Node launcher needs Node.js 18+, and macOS binaries are ad-hoc signed but not notarized. A source checkout commits only the project's own macOS ARM64 runtime build, plugins/openbaud/bin/darwin-arm64/openbaud with a SHA-256 sidecar; other hosts build their runtime with plugins/openbaud/scripts/build-runtime and a Rust toolchain. - Requires the user's own serial or USB-serial hardware. MCP tools cover listing and opening ports, raw read, send and request, running stored commands and workflows, captures, frame diagnosis and session statistics. Raw writes and device commands are marked potentially destructive, writes go to an append-only audit log, commands declared risk: danger need explicit acknowledgement, and commands with requires preconditions are refused until the session has established that device state. The README warns that serial writes can reconfigure or actuate hardware and advises starting unknown devices read-only. - The example workspace holds a real OBP/1 request/response capture recorded from the author's ESP32-S3 board on 2026-08-24, whose radar points are generated by test firmware and flagged simulated_scene on the wire, and further captures whose notes describe a serial protocol tester sweep of AT, ELM327 OBD-II, Marlin, GPS NMEA and particulate-sensor framings. The reviewed tree contains no firmware, including that test firmware, and the media/pv directory the README cites for the demo video source is absent at this commit. CI runs Clippy, package validation, tests, native builds and MCP smoke tests on the five supported hosts. - MIT (LICENSE, Cargo.toml). The bundled skill tells agents to use OpenBaud's tools instead of ad-hoc shell serial access and to record verified behaviour as reusable commands; these are the project's own workflow rules. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. #### JADX MCP Server (Qtty) > MCP server for Android APK analysis in which a Python FastMCP process talks to the agent over stdio and drives a long-lived local JVM daemon that embeds JADX 1.5.6 as a library, so no JADX GUI is involved and a loaded APK stays warm between sessions. Its 23 tools return classes, decompiled sources with size-capped outlines, methods, fields, smali, cross-references and callees read from a dex-derived index, type hierarchies and overrides, exported and deep-link components, the manifest and resource files, plus a whole-APK sweep for framework sink call sites grouped by impact category. - Type: Integration - Targets: App - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The repository has a single commit, dated 2026-08-20, and no releases or tags. Its GitHub description still calls it a pure-Java MCP server; README explains that the MCP layer moved to Python after concurrent tool calls hung the Java SDK's transport. Unlike JADX-AI-MCP, it uses no JADX GUI plugin. - Building needs Java 17+ (README says it is built and run on 21) and Maven 3.6+ for the Spring Boot daemon jar; the MCP layer needs Python 3.10+ with the pinned mcp 1.27.2 and httpx 0.27.2. The MCP client launches mcp_server/jadx_mcp.py, which starts the daemon on first use. The daemon binds 127.0.0.1:8765 with a 24 GB default heap and keeps one APK loaded by default; README puts a large APK at about 26 GB. - Input is an APK the analyst supplies. List and source tools are capped by default to bound response size, and README says the sink sweep is blind to reflection and to wrappers that rename the operation. The committed test fixture misc/DivaApplication.apk is the DIVA deliberately vulnerable training app; tests needing a larger production APK skip without it, and README reports 92 run and 4 skipped. - No license file: README only notes that the JADX library is Apache-2.0, so the server's own code states no reuse terms. README frames the tool for defensive security analysis and demonstrates it with Claude. ##### Primary sources 1. 2. 3. 4. 5. #### usb-rea > Python CLI and stdio MCP server for inferring the USB protocol of a device whose only control software is a vendor app. While the user clicks through the app, it captures traffic with usbmon or USBPcap, takes a label for each action, diffs the packets per action and infers message layouts: constant bytes, rolling counters, scaled 8- to 32-bit values, lookup tables, packed bit fields and sum, XOR or CRC checksums. It also decodes device replies, handshakes with session tokens and image streams sent to device screens, links each inferred field to Wireshark frame numbers in a report, and generates a pyusb driver and a Wireshark Lua dissector. - Type: Integration - Targets: Protocol - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-02 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10+, with pyusb and the MCP SDK as dependencies; version 0.7.7 (released 2026-11-01) is on PyPI. Live capture needs Linux usbmon with dumpcap or tshark, or USBPcap on Windows; offline analysis reads pcap or pcapng files whose actions are marked with timestamps or listed in order with a pause between clicks. The user supplies the device and its vendor app, and the README says the tool only analyzes traffic of devices the user owns. - **Limits:** The README marks the project alpha and lists limits per feature, among them one-byte modes, unsigned 32-bit readings, handshake tokens that must be copied verbatim and image streams of at least three frames. Sending packets to hardware through the replay command or MCP tool requires explicit confirmation. - **Testing evidence:** CI runs pytest on Python 3.10, 3.12 and 3.13, including tshark checks of the generated dissectors. docs/VALIDATION.md uses synthetic devices, captures synthesized from liquidctl's Kraken X and Hydro H100i Platinum drivers and rivalcfg's Rival 100 driver as ground truth, and two Wireshark sample captures downloaded on demand; one user-shared ASUS TUF Gaming LC III LCD capture is stored trimmed, with its image data zeroed. Emulated-gadget tests and real-hardware case studies remain open roadmap items. - **License:** MIT per LICENSE and pyproject.toml. - **Attribution:** The README expands the name as “Reverse Engineer any USB gadget”. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### IDA NO MCP > IDA Pro exporter that turns an analyzed binary into plain files for AI coding tools such as Cursor or Claude Code instead of serving it over MCP. It writes each decompiled function as a .c file, or as .asm when decompilation fails, under a header listing its name, address, callers and callees, along with the string, import and export tables, 1 MB hexdump chunks of every segment and logs of fallbacks, failures and skipped library functions. It ships as an IDA plugin (Export for AI, Ctrl-Shift-E) for small and medium files and as a Rust command-line binary for large or batch exports, which can skip IDA's auto-analysis. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The plugin, oldpython/INP.py, goes into IDA's plugins directory (%APPDATA%\Hex-Rays\IDA Pro\plugins on Windows, .idapro/plugins under the home directory on Linux and macOS). The Rust binary needs a local IDA Pro 9.x, whose non-redistributable libida and libidalib libraries it links at run time, plus LLVM/Clang for bindgen; it must be built natively on each platform, with an idalib crate version that matches the IDA release, such as idalib 0.9.0 for IDA 9.3sp1. - **Limits:** The Chinese README says the in-IDA plugin can hang on files of 100 MB or more, which the standalone binary's --skip-analysis option avoids. The repository has no releases, and the reviewed main commit dates from 2026-07-26. - **License:** The repository has no license file and GitHub detects no license. ##### Primary sources 1. 2. 3. #### ida-mcp-rs > Headless MCP server written in Rust that drives IDA Pro through idalib, so agents such as Claude Code, Codex CLI, Gemini CLI or Cursor can open and analyze binaries without the IDA GUI. Apple targets are single tool calls, including universal Mach-O slice selection, dSYM/DWARF loading and dyld_shared_cache module loading; a 28-tool lean profile sits beside the full tool set, run_script executes IDAPython and returns JSON, and editing tools such as rename, comments, patches and type application each take exactly one address or exact symbol name. save_idb writes checkpoints, and crashed or wedged IDA workers are replaced automatically. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs a released IDA Pro 9.5 with a valid license on the same host architecture, a Hex-Rays decompiler for the target processor for pseudocode tools and working IDAPython for run_script; IDA's first-launch setup, including license acceptance, must be completed by the user. Server versions follow IDA versions (v9.5.x for IDA 9.5, with Homebrew casks for 9.2 to 9.4), and the IDA 9.5 beta runtime is not compatible with the stable server. - **Prerequisites:** Installs through Homebrew, Scoop, Nix or release archives for macOS, Linux and Windows on ARM64 and x86_64; the binary loads IDA's libida and libidalib at run time from standard install paths or IDADIR and library-path variables. Release at review: v9.5.0, published 2026-11-01 and validated with IDA 9.5.261026 on macOS, Linux and Windows ARM64. - **License:** MIT per LICENSE. ##### Primary sources 1. 2. 3. #### ida-multi-mcp > MCP server that lets an agent analyze several IDA Pro databases at once through one endpoint. Each database with its plugin registers itself when opened and headless idalib sessions can be added, and a router exposes up to 76 tools for triage, decompilation and disassembly, cross-references and call graphs, search, types, renaming, comments and patching, plus analysis-wait gating so agents can wait for IDA's auto-analysis to settle; its IDA tool implementations come from the ida-pro-mcp project. Function-similarity search compares functions within or across binaries using name-independent instruction MinHash, API, string and constant anchors and control-flow shape, with optional local neural recall, and nothing is uploaded. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs Python 3.11 or later and IDA Pro 8.5 or later (9.1 or later recommended); IDA 9.0 SP0 (build 240925) is not supported. The package must be installed for both the terminal's Python and IDA's Python, and headless idalib sessions need IDA Pro, because IDA Home and IDA Free do not ship idalib. The repository has no releases; pyproject.toml declares version 0.1.0, and the reviewed main commit dates from 2026-09-19. - **Limits:** The README lists limits: the router binds to localhost only and speaks only stdio, calls to the same IDA instance still run one at a time, cancellation is not forwarded to IDA, and resources need manual routing. Renames, retypes and comments stay in memory until idb_save is called. The optional neural recall downloads its model on demand. - **License:** MIT per the README and pyproject.toml; the repository has no LICENSE file. ##### Primary sources 1. 2. 3. #### x64dbg MCP (x64dbgMCP) > MCP server that connects LLM clients to the x64dbg and x32dbg debuggers through a native plugin and a Python MCP script. It exposes more than 40 tools built on the x64dbg SDK and was tested with Claude and Cursor; agents can query registers, search byte patterns in a module and drive debugging sessions. The README advises giving the model the executable's full path so it can restart a crashed or hung target through the command-execution tool, and starting from GetModuleBase so that queries use valid addresses. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs x64dbg: copy the .dp64 or .dp32 plugin into x64dbg's plugins folder, then register src/x64dbgmcp.py, which needs pip install mcp requests, as the MCP server in the client configuration. Building the plugins needs CMake and MSVC. Release at review: build1.1 (2026-03-15); the README recommends building from source for the latest features, and the reviewed main commit dates from 2026-06-05. - **License:** GPL-3.0 per LICENSE.txt. ##### Primary sources 1. 2. 3. 4. #### IDASQL > SQL interface to IDA Pro databases that exposes a binary's analysis as more than 30 live virtual tables for agents and scripts. The tables cover functions, segments, names, imports, cross-references, basic blocks, instructions, strings, types, decompilation and annotations, and part of the database can be edited through them. It runs as a standalone CLI that can open raw binaries through idalib, as a plugin in IDA's command-line dropdown, as an HTTP REST or MCP server, or through a skills plugin for Claude Code, GitHub Copilot CLI and Codex, and it can work across several databases at once. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Needs IDA Pro with its directory on PATH and the idasql release artifact built for the installed IDA version (ida92, ida93 or ida94); plugin binaries are SDK-version-specific. The HCLI-compatible plugin archive covers Windows x86-64, Linux x86-64 and macOS ARM64, with separate ARM64 archives for IDA 9.3 and 9.4. Building from source needs IDA SDK 9.0 or later. Release at review: v0.0.19, published 2026-10-10. - **Scope:** The MCP server serves SSE on a local port and is compiled in by default (-DIDASQL_WITH_MCP=ON); the agent skills live in the separate idasql-skills repository. Deep-link features need IDA 9.4. - **License:** Licensed under the Human-Origin Source License v1.0, a source-available license derived in structure from MPL 2.0 that is not OSI-approved: it allows using, building and redistributing unmodified copies, including commercially, but forbids shipping modified versions outside upstream contributions and using the code as an implementation source without the author's written permission. ##### Primary sources 1. 2. 3. #### Exoproc > Exoproc exposes Windows x64 process inspection and instrumentation to agents through a CLI and MCP server. It enumerates processes, reads and scans memory, installs function detours, redirects thread contexts and compiles C snippets for execution in a target process. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Live process instrumentation requires native Windows x64. - **Prerequisites:** The Node.js route requires Node.js 18 or newer; the README also describes Bun and a standalone executable. - **License:** MIT License. ##### Primary sources 1. #### OpenOCD SPI Dump Plugin > OpenOCD SPI Dump Plugin guides an agent through extracting SPI flash or EEPROM contents using a target MCU's SWD/JTAG debug connection. It supplies MCU register maps, a RAM-resident C reader, linker and OpenOCD Tcl templates, and a workflow for JEDEC identification and dump checking. - Type: Integration - Targets: Firmware - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - OpenOCD, an ARM GNU toolchain, and netcat are required. - A working SWD/JTAG probe connection and an MCU connected to SPI flash or EEPROM are required. - The maximum dump chunk size remains to be parameterized. - MIT license. ##### Primary sources 1. 2. #### dos-mcp > dos-mcp connects AI agents to DOS programs running in js-dos for interactive reverse engineering. Its MCP tools send keyboard and mouse input, capture frames, exchange files with the guest and read or search emulated memory; the documentation shows a save-format comparison workflow using Ultima Underworld. - Type: Integration - Targets: Binary · Game - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Node.js 22.13 or newer is required; Puppeteer installs a browser dependency. - **Prerequisites:** A DOS program or bundle is needed as input. - **Limits:** Save-state snapshot and restore are missing; breakpoints and stepping are only proposed. - **License:** MIT License. ##### Primary sources 1. #### x64dbg MCP > x64dbg MCP gives agents debugger control over Windows binaries through a native x64dbg plugin and a C# stdio MCP server. The plugin serves local HTTP requests to x64dbg's bridge API, while MCP tools expose disassembly, memory and register access, modules, execution control, and breakpoints. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Windows, Visual Studio 2022, CMake 3.20 or newer, .NET 10 SDK, and a built x64dbg checkout. - **Scope:** The plugin's HTTP endpoint binds to localhost and grants control over the debugged process. - **License:** GPL-3.0 license. ##### Primary sources 1. #### adb-mcp > adb-mcp gives agents structured Android Debug Bridge tools for investigating app behavior on a device. It can launch packages, inspect the UI hierarchy, capture logcat records and screenshots, retrieve files, and set up port forwarding. Its documentation shows a command sequence for investigating an in-app action through UI interaction and logs. - Type: Integration - Targets: App - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10 or newer, Android platform-tools adb, and an MCP client. - **Prerequisites:** An Android device or emulator is needed for device operations. - **Limits:** The general run_shell tool is disabled unless explicitly enabled. - **License:** MIT license. ##### Primary sources 1. #### website-to-cli > website-to-cli is an agent skill for deriving terminal clients from captured website traffic. Its scripts record a HAR and filter requests to identify endpoint methods, paths, parameters, payload shapes and authentication headers. The skill then uses a Bun CLI template to build a client. The repository includes clients for crates.io and Hacker News search. - Type: Integration - Targets: Website - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Bun is required for the scripts and CLI template. - **Prerequisites:** Playwright is required for browser capture, or a HAR with response content can be exported from browser DevTools. - **License:** MIT license. ##### Primary sources 1. #### reverse-workbench-skill > reverse-workbench-skill is a multi-agent-harness skill bundle that routes investigations to workflows for APKs, native binaries, firmware, frontend JavaScript, and network traffic. Its documented paths include Ghidra headless exports, binary diffing, and evidence recording, alongside broader security-analysis skills and helper scripts. - Type: Integration - Targets: App · Binary · Firmware · Website - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A supported agent client is required; the README lists pi, Codex CLI, DSH, and Claude Code. - **Prerequisites:** JDK, Node.js 22.12+, and Python 3.x are listed as prerequisites for the corresponding toolchains. - **Attribution:** MIT license; the LICENSE retains attribution for the original reverse-skill methodology. ##### Primary sources 1. #### MindNode MCP Server > MindNode MCP Server connects agents to MindNode Next mind maps on macOS. Its reader decodes the app's SQLite library, protobuf snapshots, Apple LZ4 compression and CRDT operations into Markdown outlines; other MCP tools return previews or create maps through MindNode's Markdown importer. - Type: Integration - Targets: App - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** macOS with MindNode 2024+ and Node.js 24 or later. - **Limits:** The author checked the format on MindNode 2026.4.4; heavily edited text may decode incorrectly. - **License:** MIT license. ##### Primary sources 1. 2. #### OGhidra > OGhidra is an AI integration for analyzing binaries with Ghidra through natural language. It supports function analysis, automated renaming, malware pattern detection, and either an MCP or PyGhidra backend. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Python 3.12 or later and Ghidra; version 12.0.3 is recommended. - Java 21 is required to build the Ghidra 12.0.3 extension. - Configure a local or external AI provider; the MCP backend requires a running Ghidra client, while PyGhidra requires a valid Ghidra project or a binary to import. - BSD 3-Clause with a commercial license alternative, per LICENSE. ##### Primary sources 1. #### aiDAPal > aiDAPal is an IDA Pro plugin that uses a locally hosted language model trained for Hex-Rays pseudocode to assist with code analysis. It presents generated changes for acceptance before updating the pseudocode. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - IDA Pro with Hex-Rays is required. - Ollama must be configured with the downloaded model weights and modelfile. - The plugin requires the Python requests package; its default configuration connects to a local Ollama service. - The repository has no license file. ##### Primary sources 1. #### x64dbg MCP Server Plugin > An MCP server plugin for x64dbg and x32dbg that lets external applications and AI agents control debugging through HTTP. It provides tools for execution, memory, registers, breakpoints, and disassembly, along with debugger context resources and workflow prompts. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires a 64-bit Windows 10 or 11 host and x64dbg or x32dbg build 2023 or later. - Building requires CMake 3.15 or later, Visual Studio 2022 with the C++ Desktop Development workload, vcpkg, and Git. - Debugging operations require the debugger to be paused; memory and register writes are disabled by default. - License: MIT. ##### Primary sources 1. #### JEB-MCP > JEB-MCP is an MCP server and JEB Pro script that lets MCP clients inspect and rename elements of Android apps in JEB. Its documented commands include reading decompiled code, examining classes and methods, and renaming them. - Type: Integration - Targets: App - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - JEB Pro with the project script started in its GUI. - Python 3.11 or later and uv. - An MCP client configured to connect to the server. - The repository has no license file. ##### Primary sources 1. #### re-shell > re-shell is a Nix flake development environment that provides Claude Code with reverse engineering tools and workflows. Its skills select guidance for Windows binaries, Android packages, and web captures based on the files being analyzed. - Type: Integration - Targets: App · Binary · Protocol · Website - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Nix with the nix-command and flakes experimental features enabled. - Claude Code for the file-specific skills and workflows. - The repository has no license file. ##### Primary sources 1. #### ghidra-rpc > ghidra-rpc is a CLI integration that lets AI coding assistants use a persistent Ghidra session for binary analysis. It returns structured JSON for tasks such as decompilation, symbol annotation, type recovery, patching, and binary version comparison. - Type: Integration - Targets: Binary - Category: Independent agent workflows - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Ghidra 11+, Python 3.11+, Java 17+, and uv. - An AI coding assistant must be able to run shell commands to drive a session. - The repository has no license file. ##### Primary sources 1. #### r0idamcp > r0idamcp is a single-file MCP server that connects IDA Pro to an MCP-capable assistant for automated reverse engineering. Its tools expose functions, strings, decompilation, cross-references, comments, and renaming through an SSE connection. - Type: Integration - Targets: Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - IDA Pro is required; version 8.3 or later is recommended. - Install FastMCP with pip into the Python environment used by IDA Pro. - Use an MCP client that can connect to an SSE server, and allow access to the configured server port. - License: MIT. ##### Primary sources 1. #### SOMCP > SOMCP is an Android MCP server for analyzing and modifying native SO libraries. It exposes ELF analysis, disassembly, patching, and optional dynamic analysis tools to MCP clients. - Type: Integration - Targets: App · Binary - Category: Independent MCP integrations - Relationship: Independent agent integration - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Requires Android 8.0 or later. - Emulation in official release APKs requires a 64-bit device; Frida features require a separately installed Frida server or gadget on a rooted device. - The repository declares the AGPL-3.0 license. ##### Primary sources 1. ### Related collections (32) #### Awesome Reverse Engineering > A task-oriented reverse-engineering resource list by REA's maintainer, useful for broader tools and foundations. - Type: Collection - Targets: App · Binary · Firmware · Game · Protocol · Website - Category: Related resource lists - Relationship: REA maintainer companion list - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Individual tools retain their own requirements and licenses. ##### Primary sources 1. #### Awesome REA Cases > A bilingual collection of REA and other AI-assisted reverse engineering cases, with source links and explicit distinctions between reported and reproduced outcomes. - Type: Collection - Targets: App · Binary · Firmware · Game · Protocol · Website - Category: Related resource lists - Relationship: Community REA learning resource - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A discovery index; review each case's original source, redistribution rights, and evidence status before reproducing it. ##### Primary sources 1. 2. #### awesome-rea (yibie): verification-focused projects and practice reports > Organizes AI-assisted game decompilation, native ports, static recompilation and tooling around stated acceptance checks, alongside a separate track of practitioner write-ups and discussions. Useful for finding primary reports and comparing how projects define correctness. - Type: Collection - Targets: Binary · Game - Category: Related resource lists - Relationship: Community REA learning resource - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Project entries describe acceptance mechanisms; the separate discussion track does not require public code or an acceptance test. - The reviewed snapshot has an intentionally empty console/firmware category. - Collection summaries can lag primary repositories, including platform support, progress and license scope; follow the linked project sources before relying on a claim. - The collection LICENSE declares CC0 1.0 Universal. Linked projects and source articles retain their own rights and license conditions. - An independent community collection. ##### Primary sources 1. 2. 3. 4. 5. #### Reversed with AI > A moderated website directory of AI-assisted reverse-engineering projects across games, firmware, file formats, APIs and protocols, apps and legacy software. Each entry links to its primary source and records the author-reported model, tools, time, cost and outcome, with four checks for public source, reproduction steps, real-hardware testing and third-party confirmation. - Type: Collection - Targets: App · Binary · Firmware · Game · Protocol - Category: Related resource lists - Relationship: Community REA learning resource - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed as a live website on 2026-10-18, when the homepage reported 180 projects, 100 marked Works, 12 guides and 166 tools, and the sitemap listed 180 project pages. The site has no pinned revision or public source repository, so entries, counts and labels can change after this review. - Entries record target, model, tools, time, cost, outcome (Works, Partial or Research), a 1–5 human-effort scale and four reproducibility checks. The About page says figures are reported by authors, not measured by the site, and unknown fields are marked Not reported; a Works label is the author’s claim. A Reproducible badge needs Works plus public source and repro steps, with real-hardware or third-party confirmation for firmware and devices. - The policy lists interoperability, preservation, modding that does not bypass DRM or anti-cheat, legacy-software recovery, format, protocol and API documentation, the user’s own devices, CTFs and defensive malware analysis without live samples. It declines DRM, licence-check and anti-cheat bypasses, online cheats, leaked source, live malware samples and weaponised exploits. The site says it hosts no binaries or code and accepts takedown requests. - The maintainer, smyaseen (@whyamas on X), reviews every submission; sponsored placements are labelled, and the site says sponsors do not affect listings or order. Its guides include a third-party REA setup guide updated 2026-10-14, but the directory covers many tools beyond REA and is not an official REA resource. The reviewed pages show a copyright notice and no reuse license for directory content. ##### Primary sources 1. 2. 3. #### Awesome Malware Analysis > A long-running single-README list of malware analysis tools and resources, grouped into 17 top-level sections covering open-source threat intelligence, detection and classification, online scanners and sandboxes, document and shellcode analysis, deobfuscation, debugging and reverse engineering, network, memory forensics, Windows artifacts, plus books and other references. Each entry is a name linked to an external tool or resource with a short description. The repository also keeps a Simplified Chinese translation of the list. - Type: Collection - Targets: Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, last committed 2026-05-30, links roughly 428 entries across 17 top-level sections; it is a list of pointers, and one tool can appear under several sections. - Entries give a name, an external link and a one-line description, and state no license, platform or maintenance status. Links point to varied destinations including project pages, vendors and online services. - A Malware Collection section links out to external malware corpora, sample feeds and honeypots; the list itself hosts no samples, and following those links means handling live malware, which requires an isolated environment and appropriate authorization. - The list text is licensed CC BY 4.0; linked tools and resources keep their own licenses and terms. An independent discovery list. ##### Primary sources 1. 2. #### Awesome Connected Things Security > A single-README list of security-research references for IoT, embedded, industrial and automotive systems, organized into sections on hardware attacks, wireless protocols (BLE, Zigbee/Z-Wave, LoRa, Matter/Thread, cellular, NFC/RFID, Wi-Fi, USB), firmware security including extraction, static and dynamic analysis and secure boot, network and web protocols, cloud backends, mobile apps, and industrial and automotive topics. Each entry links out to an external tool, talk, paper, write-up or course with a short note. The README reports 900+ resources. - Type: Collection - Targets: Firmware · Protocol - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README, last committed 2026-10-16, links roughly 979 entries and states 900+ resources; it is a list of pointers, and one entry can fit several sections. - Entries give a name, an external link and a short note, and state no license, platform or maintenance status. - The list is oriented toward security research and exploitation, with sections such as hardware attacks, memory extraction, side-channel and fault injection, firmware extraction and secure-boot bypasses. Hardware and radio work needs physical access, appropriate equipment and authorization. - The list text is released under CC0-1.0; linked tools and resources keep their own licenses and terms. An independent discovery list. ##### Primary sources 1. 2. #### Awesome CAN Bus > A single-README list of CAN bus tools, hardware and resources for automotive and embedded work, grouped into sections for reverse-engineering tools, test equipment and simulators, higher-layer protocols (OBD-II, UDS, ISO-TP, J1939, J2534), general and Linux utilities, CAN database formats (DBC, KCD) with converters, and hardware for ARM, Arduino, ESP32, single-board computers and FPGA cores. Each entry links out to an external project or resource with a short description. - Type: Collection - Targets: Firmware · Protocol - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README, last committed 2026-08-07, links roughly 260 entries across its sections; it is a list of pointers, and one project can appear under several sections. - Entries give a name, an external link and a short description, and state no license, platform or maintenance status. - CAN bus analysis and the listed hardware need physical access to a vehicle or bus and appropriate interface hardware; the list covers the CAN protocol and higher-layer automotive protocols as its subject. - The list text is released under CC0-1.0; linked projects and resources keep their own licenses and terms. An independent discovery list. ##### Primary sources 1. 2. #### Awesome CAN ID > A single-README list that gathers links to CAN message identifier and payload decodings in one place, grouped by vehicle make and model under about 30 car brands and brand groups plus BMW, Ducati and KTM motorcycles. Its links lead to DBC files, decoding spreadsheets, wiki pages, sniffing notes and small libraries maintained elsewhere, after a Common section of general databases such as comma.ai’s opendbc and the OpenGarages CAN ID references. - Type: Collection - Targets: Protocol - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The README, last changed by a merge on 2026-08-12, holds 148 links under 57 headings, the Common section and make, model and brand-group headings; the Acura, Lotus, Peugeot, DS, SAAB, Porsche and Seat headings are still empty. About 107 links go to GitHub and the rest to Google spreadsheets, wikis, forums and blog posts, several of them in Russian; two already point to Web Archive copies. - Entries give only the make or model, a link and a short note such as a model year, ECU or bus name. They state no license, verification status or coverage. Applying the decodings means reading traffic on a vehicle bus with suitable interface hardware. - Repository CI runs only awesome-lint. The list text is dedicated under CC0-1.0; linked databases, documents and code keep their own licenses and terms. Its footnotes point to the same maintainer’s CAN bus and LIN bus tool lists. An independent discovery list. ##### Primary sources 1. 2. 3. 4. #### Awesome REA: Reverse Engineer Anything with AI (AIshihzong) > An unofficial, bilingual awesome list of what AI agents have reverse-engineered and rebuilt, tagged by whether each case's own sources show that REA was used. It gathers REA's official resources and showcases; community cases in games, apps, hardware and protocols, and security evaluations; the wider wave of AI reverse engineering and clean-room rebuilds without confirmed REA; plugins, guides and research, related MCP tools, other lists and press; and a section on legal questions and controversy. - Type: Collection - Targets: App · Binary · Game · Protocol - Category: Related resource lists - Relationship: Community REA learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Started 2026-10-13, with 50 commits on six days through 2026-10-26. At the commit of that day the English README, mirrored in Simplified Chinese, has about 110 one-line entries, with separate pages that index projects by the app they replace, check each "built with REA" claim, list new additions and collect X posts and press. The README says figures were checked on 2026-10-21 and partly refreshed on 2026-10-26, and warns that numbers move weekly. - Tags separate cases whose README, author's post or official showcase says REA was used (REA) from AI reverse engineering with other or unnamed tools (AI-RE), clean-room rewrites without reverse-engineering evidence (Rebuild) and unverified claims (Claim?). Claim checks are the maintainer's reading of public sources; the claim page says X posts could not be opened when it was checked. A short evidence section summarises two third-party controlled comparisons of REA, rea-lab and leanrea. - It links this collection among its other lists, and it names other REA case trackers such as awesome-REA-cases. A daily workflow searches GitHub and posts candidates to an issue, but entries are added by hand, and a validator checks entries against the rules stated in the list's CONTRIBUTING.md. - The README calls the list unofficial. It excludes mirrors, pure forks and projects mainly aimed at bypassing licensing, copying paid features or distributing copyrighted assets, and accepts takedown requests. The list is released under CC0-1.0. ##### Primary sources 1. 2. 3. 4. 5. 6. #### AI Rebuilds > A website and GitHub list of 81 projects that rebuild existing software or games without the original source: AI-built clean-room apps such as the ArtCraft suite, software rewritten with coding agents, AI-assisted game decompilations, game engine reimplementations, human-led decompilations and ports, clean-room classics such as Wine and ReactOS, and tools for rebuilders. Each entry says what it rebuilds and carries a method label and an AI-involvement label, and the site can be searched, filtered and sorted by stars or recent activity. A separate guide describes a clean-room rebuild workflow with REA. - Type: Collection - Targets: App · Binary · Game - Category: Related resource lists - Relationship: Community REA learning resource - Sources reviewed: 2026-11-02 - Added to the catalog: 2026-11-04 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** At commit 8092b23, data/projects.json (list updated 2026-10-29, GitHub figures refreshed 2026-11-02) holds 81 projects in seven categories and generates both the README and ai-rebuilds.com. - **Scope:** Method labels are clean-room, reimplementation, decompilation, recompilation, port, rewrite or tool. AI labels (built, assisted, none or unknown) follow each project's own description, and 49 entries are labelled with no AI involvement. A weekly workflow refreshes stars, last-push dates, archive status and licences from the GitHub API and checks links. Entries may not distribute the original's code, binaries, ROMs or assets; the site hosts no software and takes fix and removal requests. - **Attribution:** REA is listed first among 13 tools, and only the DX-Ball entry is described as using it. The site's third-party guide “Rebuild something with REA” covers installing rea-agents, choosing REA tools by input type, a two-agent clean-room split and checks against the original; its Node.js minimums (22.19+, 24.11+ or 26+) are older than the 22.23.4+, 24.22.1+ or 26.12.1+ that REA's README now requires. - **License:** MIT for the code and the list; the LICENSE excludes original games, their code and assets. Descriptions are the site's own, and the lists it drew entries from are credited, among them CC BY-SA 4.0 and CC0 lists. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### awesome-game-decompilations > A single-README list of about 480 game decompilation, recompilation and disassembly projects, grouped by console from the NES and Game Boy to the Xbox 360, PC and mobile, with a large uncategorised section. Each entry is a game title linked to its project, mostly on GitHub, and entries with AI involvement are marked with a warning emoji under the maintainer’s disclosure policy. - Type: Collection - Targets: Game - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, committed 2026-10-12, links 481 entries: 214 under 19 console and platform headings and 267 in an Uncategorised section kept for works in progress, while the table of contents and console index are marked under construction. One game can appear under several platforms. - Entries give only a title and a link, mostly to GitHub with a few on GitLab, Codeberg and SourceHut. They state no project type, completion or matching status, original-file requirement or license, and the list mixes decompilations, disassemblies, static recompilations and occasional reimplementations. - The README’s AI disclosure allows projects with AI involvement and marks them with ⚠️; 10 entries carried the mark at review. - The repository holds only README.md, with no license file or contribution guide, so the list states no reuse terms; linked projects and the games they reconstruct keep their own rights. An independent discovery list. ##### Primary sources 1. #### Awesome Decomp Games > A generated, rated index of public game reconstruction projects: decompilations, disassemblies, static recompilations, source ports, engine remakes and browser ports. A daily job merges several upstream lists and registries with GitHub and decomp.dev metadata, drops dead links and rebuilds the README and website from data files. Useful for discovery; its scores are automated heuristics, not reviews. - Type: Collection - Targets: Game - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-20 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, generated 2026-10-16, reports 2,118 projects covering 1,829 games, with sections for 646 decompilations, 520 static recompilations, 230 source ports, 206 engine remakes, 107 disassemblies, 53 browser ports, tools, mods and 347 inactive entries. - Each entry's 1–5 playability, completeness, activity and popularity sub-scores are computed by scripts/build.py from GitHub metadata, decomp.dev progress and description keywords. Projects their source list flags as AI-generated are marked ⚠️ and lose 0.2. - Entries are seeded from the listed upstream collections and registries plus data/additions.json and data/overrides.json. A scheduled GitHub Actions job runs daily at 03:17 UTC to refresh metadata, check links and browser-play URLs, and commit the regenerated files, so summaries can still lag the linked projects. - The list states that it hosts no ROMs, ISOs, BIOS files or game assets, and its contribution rules refuse links to them and repositories that ship game data; most listed projects need files from the user's own copy. Some browser entries are labeled as playing instantly without the user's files. The list does not document each site's rights basis. - The list and data are released under CC0 1.0 and the scripts and website code under MIT; linked projects and game screenshots keep their own rights. Two REA showcase repositories appear among the entries. ##### Primary sources 1. 2. 3. 4. 5. 6. #### awesome-unofficial-pc-ports > A single-README guide to unofficial PC ports of console games built from decompilations or recompilations and chosen for easy installation by players. Its 76 game entries, grouped under Nintendo, PlayStation, Xbox, SEGA, Indie and J2ME, each recommend a port with short setup notes and often link the underlying decompilation and alternative ports; a Utilities section adds two recompilation launchers. - Type: Collection - Targets: Game - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, committed 2026-10-15, has 78 collapsible entries: 43 Nintendo, 12 PlayStation, 14 Xbox, 5 SEGA, 1 indie and 1 J2ME game, plus 2 launcher utilities. Its stated criteria are console games ported to PC through decompilation or recompilation that offer an easy install path, such as a launcher or drag-and-drop; a star marks the most user-friendly option for each game. - Entries are written for players: a recommended port, a line or two of setup notes and, for some games, the underlying decompilation, alternative ports or tutorial videos. They state no matching, completion or license status, and the list also carries projects outside its stated criteria, such as Severed Chains, which it calls a reverse-engineered native recreation, and a port of the PC game Cave Story+. - Most entries tell players to supply their own ROM, disc image, ISO, game dump or XBLA package. The Ratchet & Clank: Clone Home entry also links a third-party archive.org copy of the recovered original J2ME build. - The README promotes Quiver Launcher, a separate catalog website and launcher, and says the list is kept up in spare time with updates that can take months. The repository holds only README.md and an MIT license (copyright 2023 Sebastrion); linked ports, original games and their assets keep their own rights. An independent discovery list. ##### Primary sources 1. 2. #### awesome-decompilation > A short, link-only reading list on decompiling machine code, last updated in 2023. Its 45 links cover foundational theses, compiler and program-analysis books, decompiler products and projects, pipeline topics from intermediate representations to type, control-flow and identifier recovery, early neural-decompilation papers and binary-to-source matching. - Type: Collection - Targets: Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Not maintained as a current index: the reviewed master commit of 2023-03-05 is the newest in the repository and added the December 2022 preprint Beyond the C (arXiv 2212.08950). The AI-based section therefore stops at six neural-decompilation papers and projects, and later work, including LLM-based decompilation, is absent. - Entries are bare links under 13 headings, with no annotations, dates, status or license notes. They point to paper and thesis PDFs, vendor product pages, GitHub repositories and online-store book pages, and some PDFs are third-party mirrors. - The scope is native-code decompilation theory and tooling. Its six projects are Hex-Rays, Ghidra’s decompiler, JEB, RetDec, rev.ng-c and jsdec, and its eight intermediate representations include LLVM IR, VEX, BAP, REIL, ESIL, Binary Ninja’s LLIL and VTIL. It is a reading list, not an index of game decompilations or reconstruction projects. - The repository holds only README.md, with no license file or contribution guide, and GitHub detects no license, so the list states no reuse terms. Linked papers, books and tools keep their own rights, and some listed decompilers are commercial products. An independent reading list. ##### Primary sources 1. #### Remade > The source repository of remade.wiki, a community-curated directory of open-source reimplementations of closed-source software, mostly creative, productivity and engineering applications. Each listing is a YAML record naming the original software, languages, platforms, license and self-reported status, compatibility and limitations, and the directory also tracks requests for software nobody has reimplemented yet. - Type: Collection - Targets: App - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A young directory: the repository was created on 2026-10-09, and its history reached 308 commits by the reviewed commit of 2026-10-19. Its catalog files hold 123 project records, 13 supporting tools, 2 suites and 379 Project Requests for software with no listed reimplementation yet; remade.wiki is built from these files. - Listings target closed-source originals, mostly desktop and web applications, with Adobe, Autodesk and Microsoft products frequent among them. By category there are 53 creative, 37 productivity and 22 engineering records, plus 5 operating-systems, 3 developer-tools, 2 other and 1 games record. Status and compatibility are self-reported: 78 records are experimental, 26 alpha, 13 beta, 5 stable and 1 planned, and 107 claim partial compatibility. - POLICY.md requires independently authored code without leaked or unauthorized source, binaries or assets, excludes forks, ports, launchers and mods of the original, and leaves clean-room claims to each project’s authors; Remade states it does not audit provenance or legality. Only one record mentions a clean-room process. - The repository’s MIT license covers the directory’s code and data; listed projects keep their own licenses, from MIT and Apache-2.0 to GPL and AGPL, with one recorded as Unlicensed. The project’s own 2026-10-17 documentary audit of 119 entries left unreachable repositories and license conflicts unresolved and disclaims software, legal or compatibility certification. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Reverse Engineering resources (wtsxDev) > A single-README awesome list, started in January 2017 and maintained under the KaliTut name, of 139 reverse-engineering links in 16 sections: books, courses, practice targets, hex editors, binary-format tools, disassemblers, binary analysis, bytecode analysis, import reconstruction, dynamic analysis, debugging, Mac decryption, document analysis, scripting, Android and YARA. Entries are mostly a tool or resource name with its link, a few with a one-line usage note, and lean towards Windows and macOS tooling and malware analysis. - Type: Collection - Targets: App · Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit b254985 (2019-03-07), still the default-branch head; all 26 commits date from 2017–2019, so the list predates most current tools and any LLM-assisted workflow. 24 of its 147 unique URLs gave no response, a 404 or a 503, among them every tuts4you download link, the Apple man-page links, Crackmes.de, malwr.com and the CodePlex z3 page. - Entries state no license, platform, maturity or maintenance status, so each tool must be checked at its own source; several, such as IDA Pro, 010 Editor and Binary Ninja, are commercial. Books mostly use amzn.to short links, and the header image and five closing links point to book lists on kalitut.com. - The Practice section places crackme and CTF sites next to public malware-sample repositories with only a warning to be careful with malware, and the Mac Decrypt section names tools without describing their use. - A package.json and .travis.yml set up remark-lint checks for list order, duplicate links and dead links on Node.js 8 under Travis CI. GitHub detects no license, the repository has no license file and the package.json license field is empty, so the list states no reuse terms; linked tools and books keep their own. ##### Primary sources 1. 2. 3. #### Awesome Android Reverse Engineering > An awesome list of Android reverse-engineering training, tools and resources started in 2023 by James Stevenson, with 92 one-line entries, 16 of them starred as great and up to date. It covers courses, videos and books; static analysis and deobfuscation, networking and Frida-based instrumentation, decompilers and malware analysis tools; documentation and case studies; CTFs and crackmes; obfuscation and anti-reversing; and a short firmware and kernel section. - Type: Collection - Targets: App - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 0ade43d (2025-07-08). 51 of 58 commits date from 2023; a March 2025 rewrite reorganized the list and added the obfuscation and firmware sections, and the July 2025 commit removed the Cloud API section while its contents-menu entry remains. - Entries give a link and a one-line summary with no license, version or maintenance notes, and some summaries are loose; AFLSmart, for example, is described as a firmware-image fuzzer, while its own README presents an input-structure-aware greybox fuzzer. 8 of 90 unique URLs gave no response, a 404 or a 530: five linked GitHub repositories no longer exist, four of them (the ATDF, Paranoid, libhooker and Android kernel-exploits entries) added in the March 2025 rewrite, and the Houseparty case study, the Flare-On page and AndroidXref did not load. - Six entries are the maintainer's own tools and one his blog post. Burp Suite, IDA Pro, JEB and DexGuard are commercial, the Documentation section links the APKMirror and APKPure download sites, and tools for bypassing app controls, dumping memory and kernel exploitation appear as listed. - LICENSE is the MIT License (2023, James Stevenson), although the README points to a LICENSE.md that does not exist; placeholder changelog and to-do files from the repository template remain under .github. Linked tools, books and APKs keep their own terms. An independent discovery list. ##### Primary sources 1. 2. 3. 4. #### Awesome Frida > An awesome list of libraries, scripts, tools, talks and articles built on or about Frida, the dynamic instrumentation toolkit, started by David Weinstein in May 2016. Its 82 entries fall into libraries (about half of them NowSecure Node.js modules), script collections and projects, talks and papers, tools powered by Frida such as r2frida, objection, friTap and Fridump, videos, blog posts and community links, most with a one-line summary. - Type: Collection - Targets: App · Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit e20da3b (2026-04-10). 43 of 68 commits date from 2016–2017, most talks, videos and posts are from 2015–2017, and after the April 2023 addition of RoboDroid the only change is the April 2026 addition of rekit. Entries do not say which Frida version they target; frida-load is marked deprecated and the Lobotomy entries are struck through. - 13 of 110 unique URLs gave no response or a 404, including the OSDC, ZeroNights and RMLL event pages and a three-part tutorial series, and three talk PDFs are linked as relative files that are not in the repository. Of the 57 GitHub repositories linked, 4 are archived, 2 no longer exist and 13 have not been pushed to since 2019. The README asks contributors to flag listings that are unmaintained or have had no commits for two to three years. - Several listed tools dump process memory, decrypt protected apps or log TLS keys, and two posts cover detecting Frida. - The LICENSE file is CC0 1.0. The contribution guide, adapted from the general awesome-list guidelines, refers to a code of conduct and a list-creation guide that are not in the repository. Linked projects keep their own licenses. An independent discovery list. ##### Primary sources 1. 2. 3. #### Awesome Ghidra > An awesome list of Ghidra scripts, plugins, extensions, learning materials and related services, kept by the Allsafe GitHub organization since December 2019. Its 49 entries comprise 36 scripts and extensions, from malware-analysis and crypto-constant finders to Go, JNI, EVM and EFI helpers, Python and Jupyter bridges, P-code emulation and patch-diff correlators; 10 books, talks and courses; and three related projects such as r2ghidra-dec and Ghidraaas, each with a one-line summary. - Type: Collection - Targets: Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 9265b2f (2026-06-18). 42 of 53 commits date from 2019–2021; after that gap the maintainers merged four contributor pull requests in June 2026, adding entries such as the printf-inliner plugin, 0xdea's scripts, IDAObjcTypes and GhidrAI. Entries name no Ghidra versions, GhidrAI is the only AI-assisted entry, and no MCP server is listed. - Entries give a link and a one-line summary with no license or maintenance information. Of the 42 GitHub repositories linked, 1 is archived and 17 have not been pushed to since 2021, so each project's Ghidra compatibility must be checked at its source; only the OOAnalyzer plugin path returned a 404. - Five entries are the maintaining organization's own scripts and tools. The Materials section includes a Japanese-language practical guide, the NSA's GhidraClass course material in the Ghidra repository, conference talks and The Ghidra Book. - GitHub detects no license and the repository has no license file or contribution guide, so the list states no reuse terms; linked projects keep their own licenses. ##### Primary sources 1. #### PRE-list > A table-based reading list of 71 research papers on automatic protocol reverse engineering for network protocols, from the Protocol Informatics project (2004) to NetPlier (2021). Built from three surveys and extended since, it compares each method by approach, by input (network traces or execution traces) and output (message formats, state machines or other artifacts), and by the text, binary or hybrid protocols it was evaluated on, with full references and a short table of the few papers that released code. - Type: Collection - Targets: Protocol - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README was last updated on 2024-05-22, when NetPlier and NEMETYL were added; the other changes date from November 2020 to May 2021. Its 71 papers span 2004–2021, so later protocol reverse-engineering work is not covered. - 40 of the 71 overview rows still read “Please review” instead of describing the approach, several input/output rows are empty, and 29 rows of the tested-protocols table name no protocol. The tables summarize what each paper reports. - The README states that most papers do not provide their code; its source-code table lists eight projects, one only through a Web Archive copy of the Protocol Informatics page. The remaining entries are papers, with PDF links where the maintainer found one. - CSVtoREADME.py generates the README tables from tools.csv, contributions are requested as additions to tools.ods, and two further spreadsheets keep categorisations from the Duchêne et al. and Sija et al. surveys. - LICENSE is CC0-1.0, while CSVtoREADME.py carries a GPL-3.0-or-later header; the linked papers keep their publishers' terms. An independent reading list. ##### Primary sources 1. 2. 3. 4. 5. #### awesome-reverse-engineering (alphaSeclab) > Large reverse-engineering link list, auto-exported in 2019 in English and Chinese, with abridged and full README versions. The full English README lists about 3,600 open-source tools and 2,300 posts and videos, grouped under Windows, Linux, Apple platforms and Android, and under tool sections for IDA, Ghidra, x64dbg, OllyDbg, WinDbg, radare2, Cuckoo, Binary Ninja and dynamic binary instrumentation. Tool rows carry a star count, language and upstream description captured at export time. - Type: Collection - Targets: App · Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The latest master commit dates from 2019-12-31; GitHub reports a later push in 2021, but master holds no newer commit and the list has not been updated since. Its star counts, update ages and links reflect that export, so many may be out of date. - Readme_en.md and the Chinese Readme.md are abridged pages; the English one has 675 tool rows and 684 post rows. Readme_full_en.md and Readme_full.md hold the complete list, with 3,619 tool rows and 2,310 dated post rows in English. Post rows give a month, a source site and a title, and many point to Chinese forums such as Kanxue and Anquanke. - The README says the contents are auto-exported by the maintainers' system. Rows are list entries: they state no license, maintenance status or verification. - No license file is present and GitHub detects none, so the list states no reuse terms; linked projects and posts keep their own rights. An independent discovery list. ##### Primary sources 1. 2. 3. 4. 5. #### awesome-mobile-security > A single-README list of Android and iOS application security resources, about 245 links in all, divided by platform into blogs, papers and how-tos, books, courses, tools, deliberately vulnerable lab apps, talks and miscellany. Android tools are further split into static analysis, dynamic analysis and online APK analyzers, and reverse-engineering entries such as smali/baksmali, radare2, Cutter, Bytecode Viewer, Frida and Objection sit alongside pentesting guides and vulnerability write-ups. - Type: Collection - Targets: App - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, last changed 2021-01-20, has 168 Android and 78 iOS list entries, a few of them repeated. It has not changed since, so listed versions and services date from that time; for example, it names Magisk v20.2. - Entries give a name and link, sometimes with a short note, and state no license, maintenance status, platform requirement or test result. The list mixes open-source projects, commercial and online scanning services, books, courses and conference talks, and includes rooting and jailbreak tools, so check each resource's own terms and use it only on devices and apps you are authorized to test. - The repository holds only README.md and has no license file, so the list states no reuse terms; its GitHub description says the references and tools belong to their respective owners. ##### Primary sources 1. #### Awesome Executable Packing > A single-README list of resources on executable packing, meaning the bundling, compression, encryption, mutation, protection or virtualization of PE, ELF and other executables, including Android apps, and on detecting and unpacking packed files. About 770 entries are grouped into documentation, dated scientific papers, sample datasets, packers sorted by era from before 2000 to after 2010, and tools for packer identification, unpacking and binary analysis. - Type: Collection - Targets: App · Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, committed 2026-10-10, has 768 list rows: 94 documentation links and 328 scientific publications under Literature, 37 datasets, 190 packers (90 after 2010, 41 from 2000 to 2010 and 59 before 2000) and 119 tools. All but one publication give a month and year; Literature rows carry emoji type markers and 110 publications carry a star, neither of which the README explains. One documentation row links to the list itself. - Rows give a name, a link and usually a one-line description, with no license, maintenance or platform fields, and many packers and tools are specific to Windows PE files. Packer rows point to vendor sites, SourceForge, GitHub projects, blog analyses and 30 Internet Archive copies of old pages or download archives. - The Datasets section lists public malware repositories and feeds next to packed and benign PE and ELF sample sets and benchmark datasets such as EMBER and SOREL-20M. Samples obtained through them can be live malicious software and fall under each provider's access terms. - CC0-1.0 for the list; CONTRIBUTING.md asks for alphabetically sorted rows and one commit per suggestion. Linked papers, packers, tools and datasets keep their own licenses. An independent discovery list. ##### Primary sources 1. 2. 3. #### Awesome AI Reverse Engineering > A single-README, Chinese-language list of AI-assisted reverse-engineering projects, grouped into JavaScript reversing, binary and native analysis, Android and iOS security, and browser automation and traffic analysis. Its entries are mostly MCP servers, agent skills for Claude, Cursor and Codex, and IDE plugins that connect large language models to tools such as IDA Pro, Ghidra, Binary Ninja, JADX and Frida. Each row is a project name, a link and a one-line Chinese blurb. - Type: Collection - Targets: App · Binary · Website - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, from the commit dated 2026-09-29, lists 35 projects across four sections: 11 under JavaScript reversing, 9 under binary and native analysis, 9 under Android and iOS security, and 6 under browser automation and traffic analysis. The list carries a last-updated 2026-04 badge. - Each entry gives only a name, a link to a third-party repository and a short Chinese description, with no stated completion, accuracy or maintenance status. The list mixes MCP servers, agent skills and IDE plugins, and several entries are dual-use — anti-bot/WAF traffic evasion, anti-detection browsers, and APK ad or bloat removal with repackaging — so each linked project must be reviewed at its own source for scope, rights and lawful, authorized use. - The list links out and bundles no tools or target files of its own; the GhidraMCP server and the SimoneAvogadro Android reverse-engineering skill it points to are already in this catalog. Linked projects and the software they analyze keep their own licenses. - The README shows an MIT license badge, but the repository contains only README.md with no LICENSE file, and GitHub detects no license, so the list itself states no clear reuse terms. An independent discovery list. ##### Primary sources 1. #### Interactive IDA Plugin List > A sortable, filterable list of 618 plugins, loaders, processor modules and scripts for Hex-Rays' IDA Pro, published as a GitHub Pages table with a static copy generated into the README. Each entry links to its project, almost always on GitHub, with a short description and, where recorded, its language (C++ or Python), category tags such as decompiler, deobfuscation, loader, debug or integration, and the date the project was last updated. The list grew out of onethawt's idaplugins-list of about 200 plugins. - Type: Collection - Targets: Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit, of 2024-11-19, refreshed every last-updated date and holds 618 entries in data.js, mirrored in the README. Those dates record each project's latest activity at refresh time, from 2006 to 2024 with 136 in 2024. - Category tags cover 313 entries; the most common are integration (97), decompiler (63), development (51), loader (42) and debug (39). data.js also notes an IDA version for 385 entries, the highest being 8.4, but the table does not show it, and no entry is marked for IDA 9 or later, so compatibility must be checked at each plugin's source. - The list itself is a static page that needs only a browser; tools/gen_readme.py regenerates the README from data.js and depends on demjson. Listed plugins need the user's own IDA installation, and the list records no license, edition or install requirements for them. - LICENSE is MIT, and lib/DEPENDENCIES.md lists the bundled Tabulator 5.1.8, moment.js and jQuery 3.6.0 files as MIT; listed plugins keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Awesome RE-MCP > A single-README list, written in July 2025, of 28 MCP servers for reverse-engineering tools, grouped into disassemblers and decompilers (IDA Pro, Ghidra, Binary Ninja and others), debuggers, static and dynamic analysis, network analysis, Android and security testing, with a one-line note per entry. It also names tools the author found without an MCP server, links four talks and guides, and points to starting material for writing new servers. - Type: Collection - Targets: App · Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - All seven commits were made on 2025-07-26 and the list has not changed since, so its entries, star counts and status remarks are a July 2025 snapshot. Some of its gap lists no longer hold: for example, it reports no WinDbg MCP server. - Rows give a name, link and short description without language, transport, maintenance status or license, although the contribution guidelines ask submitters for implementation status and transport. One debugger row links a PulseMCP directory page rather than a project. - The network and security-testing entries, such as a collection wrapping SQLMap, Nmap and other scanners, are dual-use tools. The list itself has no tests or verification of its entries. - The README says the list is released under the MIT license, but the repository has no license file and GitHub detects none. An independent discovery list. ##### Primary sources 1. 2. 3. #### RE list (extremecoders-re) > A single-README list of 71 open-source reverse-engineering tools with a focus on binary analysis, kept as one alphabetical list from Amoco to X86isa. Each entry gives the tool's name, a link and a one- to three-sentence description; the entries span binary analysis frameworks, lifters to LLVM and other intermediate representations, symbolic execution and emulation engines, dynamic instrumentation, whole-system and virtual-machine introspection platforms, decompilers, debugger front ends and deobfuscation tools. - Type: Collection - Targets: Binary - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, last changed on 2024-04-16 when Cannoli was added, links 71 entries in one alphabetical list without categories; the repository's 56 commits since October 2017 mostly add one tool at a time. These are list rows. - Entries give only a name, a link and a short description: 56 point to GitHub and 15 to project, university or vendor pages, such as Intel's Pin page and Tetrane's REVEN Free Edition page rather than source repositories. They state no maintenance status, supported platforms, license or date added. - The repository holds only README.md, with no license file or contribution guide, so the list states no reuse terms; linked tools keep their own licenses. An independent discovery list. ##### Primary sources 1. #### awesome-te > A public-domain directory, started in June 2026, of hacking projects for Teenage Engineering devices: custom firmware, reverse-engineering notes and protocol documentation, tools, hardware mods, teardown and recovery guides and community hubs for the OP-1, OP-Z, OP-XY, TP-7, SP-1 Stem Player, EP series, Pocket Operators and other gear. One-line entries are grouped by device and task, each with a maintainer-assigned active, dormant or archived marker, and the scope rule admits only released, TE-specific projects. - Type: Collection - Targets: Firmware · Protocol - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, committed 2026-10-20 and marked as last reviewed that day, has 195 status-marked rows under 11 device sections and a cross-device section, some of them bundling several links: 136 marked active, 56 dormant and 3 archived. Under the contribution guide the marker reflects activity in the past 12 months; the weekly lychee workflow only checks that links resolve. - Entries mix open-source projects, commercial apps and forum, wiki and repair pages, ranging from SysEx, file-transfer and file-format documentation to Ghidra Blackfin support, and include a few AI tools such as an SP-1 reference packaged as a Claude agent skill and an MCP server for the OP-1 field. Several firmware and flashing entries warn that they erase stored data or can brick a device. - A few rows point to unofficial mirrors of OP-1 and OP-1 field firmware and to an OP-1 firmware decryptor; the list itself recommends Teenage Engineering's official downloads. Device firmware keeps its vendor's terms, and each linked project keeps its own license. - The list and its contributions are dedicated to the public domain under CC0 1.0. An independent discovery list. ##### Primary sources 1. 2. 3. 4. #### Awesome UEFI Security > A single-README awesome list of UEFI and BIOS security material, which its maintainer describes as a personal and not comprehensive collection. It links UEFI, PI and ACPI specifications, EDK II development resources, firmware analysis tools such as UEFITool, efiXplorer, CHIPSEC and UEFI plugins for Ghidra and Binary Ninja, SMM-themed CTF challenges, analyses of bootkits found in the wild, vulnerability write-ups, conference talks, blog posts, papers and training courses. - Type: Collection - Targets: Firmware - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README was last changed by a pull request merged on 2025-09-04 that fixed the UEFITool link; the last addition, a 2025 arXiv paper, was committed on 2025-02-01. It holds about 230 linked entries in ten sections, including roughly 35 tools, 57 talks, 71 blog posts and 14 papers. - Most tool entries have no description, and no entry states maintenance status, supported firmware, platform or license. The list itself contains no firmware images, SDKs or tools. - Several sections cover offensive material, including bootkit and SMM backdoor repositories, exploit code and a Secure Boot bypass project. - CC0-1.0 for the list; linked works keep their own licenses. CI runs awesome-lint on pull requests. ##### Primary sources 1. 2. 3. #### Firmware-Analysis-Papers > A single-README reading list of 28 academic security papers on firmware and embedded-system analysis, grouped by year from 2013 to 2021. It covers rehosting and emulation, firmware fuzzing, symbolic execution, Bluetooth and baseband analysis and bug detection in Linux-based and bare-metal firmware. Each entry is a title linked to a PDF or publisher page, with its venue such as USENIX Security, NDSS, IEEE S&P or CCS. - Type: Collection - Targets: Firmware - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed README, last changed 2021-08-30, lists 28 papers: 10 from 2021, 7 from 2020, 4 from 2019, one from 2018 and 6 under “2017 and Before”, the oldest from 2013. The list has not been updated since, so later work such as Fuzzware (USENIX Security 2022) is absent. - Entries give only a title, a link and a venue label, with no summaries, code, artifact or citation details. Most links go to PDFs on conference, author or arXiv sites; the rest go to an IEEE Xplore page, ResearchGate, or ACM Digital Library URLs carrying session tokens, which may stop working. Year labels can differ from publication years: Firmadyne is labeled NDSS 2017, matching its link's 2017 upload folder. - The repository holds only README.md and no license file, so the list states no reuse terms; the papers keep their authors' and publishers' rights. An independent reading list. ##### Primary sources 1. #### OpenDeviceDB > OpenDeviceDB indexes devices with existing firmware or protocol reverse-engineering work and links back to source projects. Its website lists installation routes and remaining vendor dependencies, while importers aggregate existing databases and an MCP server lets agents query device records. - Type: Collection - Targets: Firmware · Protocol - Category: Related resource lists - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Using the local website, importers or MCP server requires the repository's npm workflow. - **Scope:** Some device entries retain non-free vendor components or require vendor cloud services. - **License:** Code is AGPL-3.0-or-later; data is CC BY-SA 4.0. ##### Primary sources 1. 2. #### Malware Analysis & CTI Reports > Malware Analysis & CTI Reports collects ten PDF investigations of malware, security tools and binaries with disputed detections. The author describes static inspection with Detect It Easy, strings and imports, followed by manual disassembly or decompilation in Ghidra or radare2. - Type: Collection - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** Reports are PDF files; the repository does not include live malware samples. - **License:** No licence file in the repository. ##### Primary sources 1. ### References and learning (83) #### Installation and client setup > Reviewed setup plans, client registration, provider prerequisites and scoped readiness checks. - Type: Documentation - Targets: App · Binary · Firmware · Game · Website - Category: Official REA: core and setup - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supported Node.js and npm. - Setup previews client configuration changes; native engines have separate prerequisites. ##### Primary sources 1. #### CLI and Evidence > CLI workflows for saving Evidence and projecting smaller views from completed analysis. - Type: Documentation - Targets: App · Binary · Firmware · Game · Website - Category: Official REA: core and setup - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Installed REA CLI or an explicitly pinned package runner. - CLI processes are separate; retain result files for later operations. ##### Primary sources 1. #### MCP contracts and generated catalog > Canonical tool contracts, provider discovery and Evidence semantics for integration authors. - Type: Documentation - Targets: App · Binary · Firmware · Game · Website - Category: Official REA: core and setup - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A compatible MCP client for live use. - Discover the live catalog before relying on tools documented on main. ##### Primary sources 1. #### Native binary investigation > Locate a function, inspect instructions and pseudocode, and follow references with a selected native provider. - Type: Documentation - Targets: Binary · Game - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A target binary and a configured supported provider such as Ghidra, Hopper or IDA. - Host, architecture and provider support are scoped separately; pseudocode is not original source. ##### Primary sources 1. #### Cross-layer JavaScript application workflows > Trace features and compare authenticated JavaScript application graphs while preserving static-analysis limits. - Type: Documentation - Targets: App · Website - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Evidence from analyze_javascript_application or supported runtime reconciliation. - No native engine is required for the static JavaScript path; keep the complete parent Evidence. ##### Primary sources 1. #### Static Android APK analysis > Inspect Android package identity, classes, methods and references through REA's JADX integration. - Type: Documentation - Targets: App - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Full JDK 17 or newer and caller-supplied jadx-headless-mcp 0.7.1 with the documented digest check. - Linux requires a procps-compatible ps for provider process ownership. ##### Primary sources 1. #### Managed-code analysis > Read PE/CLI metadata and CIL, compare managed members and inspect declared native boundaries without loading the assembly. - Type: Documentation - Targets: App - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A supported PE/CLI assembly; no native engine is required for metadata/CIL inspection. - NativeAOT, IL2CPP and packaged single-file deployments have different boundaries. ##### Primary sources 1. #### Historical web network captures > Inspect saved web captures offline; recorded URLs are not fetched and no proxy is started. - Type: Documentation - Targets: App · Protocol · Website - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A supported existing capture and an explicit format selection. - PCAP/TShark workflows are separate and have different host/tool requirements. ##### Primary sources 1. #### Firmware analysis > Inspect firmware regions with Binwalk and explicitly extract with Unblob, retaining tool and artifact identity. - Type: Documentation - Targets: Firmware - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Caller-supplied Binwalk 3.1.x for inspection; Unblob 26.6.x for extraction. - The documented verification scope is Linux x64; extraction needs a new caller-selected output directory. ##### Primary sources 1. #### Recorded packet capture inspection > Select TShark fields, display filters and decode-as rules over an existing network, USB or Bluetooth capture, and look up installed field names. It does not capture traffic, open an interface or control a device. - Type: Documentation - Targets: Protocol - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Caller-supplied TShark 4.x on Linux with util-linux prlimit; macOS and Windows hosts are refused before inspection. Listed in the rea-agents 6.5.0 release notes. - Dissector output describes the selected recording, not verified device behavior. Upstream fixtures are generated Ethernet/UDP/DNS and Bluetooth HCI PCAPs and do not cover PCAPNG, USB, BLE ATT or physical capture. ##### Primary sources 1. 2. #### Packet capture summaries > Summarize a saved pcap or pcapng file’s endpoints, DNS questions and addresses, TLS SNI, protocol stacks and HTTP URIs into paged Evidence views. It does not capture traffic or fetch recorded targets. - Type: Documentation - Targets: Protocol - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Caller-supplied Wireshark 4.x tshark and capinfos. Capture inspection needs Linux with util-linux prlimit or Windows Job Objects; macOS reports a capability gap. Listed in the rea-agents 6.5.0 release notes. - Upstream’s current verification used Linux, Node 24.18.0 and Wireshark 4.0.17; actual Windows execution is unverified. Summaries do not establish decrypted payloads, process identity or the absence of unrecorded traffic. ##### Primary sources 1. 2. #### Recorded signal decoding > Run caller-chosen sigrok protocol decoders, such as UART or I2C, over an existing logic-signal recording and keep annotation text with sample ranges. It does not acquire samples or communicate with hardware. - Type: Documentation - Targets: Firmware · Protocol - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Caller-supplied sigrok-cli 0.7.2 with libsigrokdecode on Linux, plus util-linux prlimit; macOS and Windows are refused. Listed in the rea-agents 6.5.0 release notes. - The caller supplies decoder stacks, channel names and settings such as baud rate. Upstream’s fixture is a synthesized 9600-baud UART VCD and does not cover other formats, decoders or physical acquisition. ##### Primary sources 1. 2. #### Browser observation guide > Follow a user-triggered export request in the supplied Notes browser example and connect it to the downloaded result. - Type: Documentation - Targets: Website - Category: Official REA: investigation guides - Relationship: Official REA guide - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A user-owned Chrome-family browser, loopback CDP connection and explicitly allowed origins. - The recorded upstream example used a separate controller to click. ##### Primary sources 1. #### JavaScript and Electron: follow a CSV export > A source-owned Notes fixture teaches the renderer, preload, IPC and CSV path with linked analysis evidence. - Type: Documentation - Targets: App - Category: Official REA: investigation guides - Relationship: Official REA guide - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Supported Node.js and REA; no native engine is required for this static fixture. - The fixture is source-owned teaching material, not an installed Electron distribution. ##### Primary sources 1. #### rea-playbook > An Electron practice target, Evidence extractor and MCP probe; offline fixture mode is distinguished from real REA analysis. - Type: Learning resource - Targets: App - Category: Community REA labs - Relationship: Community REA learning resource - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - README pins the real-analysis path to rea-agents 6.3.0 and lists supported Node.js versions. - The offline demo reads bundled results without running REA. ##### Primary sources 1. #### rea-lab > A Windows REA/Ghidra lab with seeded challenges, published studies, upstream contributions and recorded limitations. - Type: Research - Targets: Binary - Category: Community REA labs - Relationship: Community REA learning resource - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The documented environment uses Windows 11, REA 6.4.0 and Ghidra 12.1.4. - Study results are author-reported and task/model-specific. - Code and documentation use different licenses; inspect the relevant repository notices. ##### Primary sources 1. #### Flutter build identification > Identifies a Flutter APK’s Dart snapshot hash, per-ABI library digests and engine build provenance, then inspects one ABI’s AOT snapshot sections, through REA’s pure-parsing CLI and MCP tools. The string-pool output is a bounded byte-pattern projection of package and SDK URIs, not deserialized Dart classes or recovered source. - Type: Documentation - Targets: App - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed on main as rea-agents 6.7.0, which declares Node ^22.19.0, ^24.11.0 or 26+. identify-flutter-build and inspect-dart-aot (MCP identify_flutter_build and inspect_dart_aot) parse a caller-supplied APK’s libapp.so and libflutter.so without an engine, external tool, execution or network lookup. Inputs are copied into an owned read-only snapshot, with documented bounds such as 2 GiB per APK and 256 MiB per library. - REA performs no hash-to-SDK lookup; mapping a snapshot hash to a Dart release needs an external dataset such as reFlutter’s. Complete structural coverage currently requires the FullAOT kind of the supported Dart 2.14 snapshot layout, and other kinds are kept with partial coverage. Typed class and function recovery needs an SDK-specific parser, and class-like tokens include incidental matches. - The documented verifier runs both tools through the compiled CLI and stdio MCP on the Flutter Gallery 2.9.2 release APK against a pinned expectations file: one agreeing snapshot hash on all three ABIs, engine labels and URI counts. A plain aapt2-built APK checks negative detection. The guide reports the Gallery workflow and 147 focused tests passing on macOS 14.8.9 x86-64 and Windows 11 x64 guests. - In merged PR #1582, an independent reviewer reports that hashes, ELF sections and package lists matched readelf/strings checks on three F-Droid apps, PocketDhamma, Flutter McSweepy and cone, on pre-merge heads, with a non-Flutter control not detected; the thread records fixes for gaps found. These checks cover build identity and structure. REA declares MIT; analysed APKs keep their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Static HarmonyOS package inventory > Inventories HarmonyOS HAP, HSP and App Pack files through REA’s hardened ZIP reader and projects an execution-free application graph: component paths, IDs and hashes, Stage/FA packaging hints, runtime-family hints and path-based native-bridge hypotheses. Every claim rests on path presence; manifests, Ark bytecode, resources and signatures are not decoded or verified. - Type: Documentation - Targets: App - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed on main as rea-agents 6.7.0, which declares Node ^22.19.0, ^24.11.0 or 26+. No HarmonyOS SDK, toolchain or engine is needed: inspect-artifact produces the inventory and project-harmony-application-graph (MCP project_harmony_application_graph) projects it, with CLI and MCP sharing one workflow. .hap, .hsp and ZIP-verified root .app inputs are recognized; .har shared libraries are deferred because the suffix also names HTTP Archive JSON. - Outputs are path-presence claims: Stage is inferred only from module.json and FA only from config.json, App Pack children are listed without recursive inventory, encrypted or unavailable entries make coverage partial, and N-API bridge entries are hypotheses. Manifest semantics, Ark bytecode contents and versions, resource resolution, signing verification and observed native boundaries stay listed as limitations, and inventories that cannot be authenticated fail closed. - The verification lane downloads a SHA-256-pinned harmony-next-pipeline 1.0.1 HAP from an MIT-licensed source repository into an ignored directory and checks inventory authenticity, projection determinism, Stage path hints, exact component sets, complete coverage and CLI/MCP parity. The fixture’s compiler/SDK versions and reproducible build are not established, and the lane does not complete the pinned-toolchain acceptance in roadmap issue #1431. - REA declares MIT. Analysed packages keep their own licenses, and the guide says the fixture’s bundled component licenses were not independently audited; the downloaded artifact is not redistributed. Merged PR #1447 introduced this increment. ##### Primary sources 1. 2. 3. 4. #### MIPS ELF analysis through Ghidra > Documents REA’s Ghidra lane for MIPS ELF executables, relocatable objects and MIPS16 shared images, including a pinned 32-bit language for recordless legacy firmware executables that Ghidra would otherwise import as 64-bit. Admission is bounded by declared header and ABI-record facts, and verification compares source-owned fixtures with independent readelf output rather than executing or rehosting firmware. - Type: Documentation - Targets: Binary · Firmware - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Needs a caller-installed Ghidra and compatible JDK on a supported Linux or macOS host; Windows Ghidra P0 does not admit MIPS, and Hopper/IDA gain no MIPS support. The lane does not execute MIPS code or rehost firmware. The standard profile admits ELF32 executables and relocatable objects declaring o32 and MIPS32r2; MIPS16 shared images have a separate bounded profile. ELF64, n32/n64, microMIPS, machine variants, FP64, NAN2008 and PSP PRX are refused. - Merged PR #1898, for issue #1620, admits recordless legacy ELF32 executables with EF_MIPS_ARCH_32 or 32R2, an unspecified ABI field and an inspected absence of ABI-flags records. It pins MIPS::32:default and checks the language Ghidra reports after import. o32 is recorded as an analysis assumption, not a declared fact, and floating-point ABI semantics stay unverified. - Optional real-provider lanes need caller-supplied Clang with MIPS targets, LLD, GNU readelf or MIPS cross-binutils, and Ghidra. They build source-owned fixtures in both byte orders without executing them, comparing instruction bytes, symbols, languages and relocations with independent readelf facts. The guide states that pseudocode presence and decoding agreement do not establish runtime, delay-slot or complete floating-point semantics. - The issue author reports gating a local patch on four real MIPS32 LE firmware ELFs whose function entries matched separate 32-bit Ghidra exports, and 400 of 5,250 functions lost on one image under auto-selection; those files are not public. A PR reviewer tested header-edited OpenWrt kernels and BusyBox builds with Capstone cross-checks and found no unedited public recordless file. - REA declares MIT. Ghidra, compilers, binutils and analysed firmware keep their own terms, and the firmware behind the author’s results is not supplied. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### PSP static ELF analysis through Ghidra > Documents REA’s bounded Ghidra profile for static PSP ELF executables, which leaves Allegrex instructions, PSP loading and calling conventions to a caller-installed ghidra-allegrex extension while reusing REA’s CLI, MCP, Evidence and snapshot workflows. It admits one PSPSDK header and ABI declaration on Linux x64 and verifies selected static facts on a self-built fixture, not commercial games or PRX modules. - Type: Documentation - Targets: Binary · Game - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The initial profile runs on a Linux x64 host and admits little-endian ELF32 executables with the PSPSDK declaration e_flags 0x10a23001 and an inspected version-0 ABI-flags record matching the documented single-float Allegrex declarations. PRX, relocatable or shared images, PBP/ISO/CSO containers, emulation and live overlays are out of scope; missing or different declarations are refused, and file names do not identify a target. - Install a compatible ghidra-allegrex extension inside the selected Ghidra distribution; REA never downloads, installs, rebuilds or vendors it, and fingerprints its files before launch. The published compatibility pairing is Ghidra 12.1.3, extension v21.4, PSPDEV v20261001 and JDK 21. Missing prerequisites return PSP_EXTENSION_UNAVAILABLE without fallback. - Verification uses the real MIPS verifier’s PSP mode with caller-supplied PSPDEV tools. A maintained fixture built from tests/conformance/psp is analysed without execution and checked against PSP GNU tool observations: known functions, a direct call, an immediate, BITREV, a global word, snapshot reopening and an A-B-A target switch. Merged PR #1599 reports a passing real-Ghidra run on an earlier contribution head and says the final head was not freshly revalidated by that run. - These are selected static facts; the extension does not fully model VFPU prefix effects. No commercial game data is used or reconstructed, and issue #1330 remains open. REA declares MIT; ghidra-allegrex, Ghidra, PSPDEV and analysed executables keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### NativeAOT metadata recovery with Ghidra > Recovers .NET 8 NativeAOT metadata from x64 PE executables during REA’s Ghidra analysis: MethodTable relationships, virtual slots and frozen strings from RTR 9.1 data, through a built-in read-only parser or an optional headless adapter that annotates the Ghidra database. Generated names, inferred prototypes and recovered native pseudocode stay separate from the unknown original C# names, fields and source. - Type: Documentation - Targets: Binary - Category: Official REA: investigation guides - Relationship: Official REA documentation - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed on main as rea-agents 6.7.0, which declares Node ^22.19.0, ^24.11.0 or 26+. Bring your own Ghidra and JDK; the guide’s Windows check used Ghidra 12.1.4 and JDK 21. The built-in parser handles x64 PE32+ with .NET 8 RTR 9.1 metadata and needs a unique RTR header and exactly one DEHYDRATED_DATA row; other RTR versions and PE architectures are reported as unsupported or partial. Ordinary PE/CLI or ReadyToRun assemblies belong to REA’s managed-code tools instead. - The optional adapter is built from a clean pinned checkout of Washi1337/ghidra-nativeaot with existing git, javac and jar; REA records the JAR’s SHA-256, copies it and rechecks the digest before loading, and JARs run inside Ghidra, so supply a trusted build. It annotates within an ephemeral Program transaction and never changes the original executable. It is unavailable on Windows Ghidra P0, where database tools do not see rehydrated bytes and slot targets come from the parser report. - Outputs include MethodTable addresses, base types, interfaces, virtual slots and frozen strings, within documented local limits such as 128 MiB of captured PE bytes and 4 MiB of report JSON; rows beyond the report budget are omitted with partial coverage. Type identification uses upstream heuristics and prototypes remain inferences. Pseudocode is recovered native logic, not original C# source, and original class/member names and custom field layouts stay unknown. - Verification uses benign source-built .NET 8.0.22 fixtures with independent compiler/linker-symbol and directory-byte oracles, plus stripped and negative inputs; fixtures are never executed, and building them needs .NET SDK 8.0.416 and platform NativeAOT tools. The real MCP lane runs only on Linux x64 with the adapter. Windows-host behavior was checked manually once on Windows 11 x64 without the JAR against the fixture oracle and linker map; no CI lane repeats that check. - REA declares MIT. The parser’s hydration semantics are adapted from Washi1337/ghidra-nativeaot (MIT, with its notice shipped under licenses/) and cross-checked against .NET’s MethodTable.h. Analysed executables keep their own licenses. Merged PR #748 introduced the integration and issue #744 records the request and its closure. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### REA & AI RE Tools Guide (unofficial) > An unofficial, independently run guide to installing REA and connecting it to coding agents, in 32 pages: install paths for npx, npm and Bun including Windows, MCP setup for Claude Code and Desktop, Codex, Cursor, Windsurf and Gemini CLI, a config generator for 24 clients, Ghidra, IDA and JADX provider setup, and troubleshooting pages that match exact error text to upstream REA issues. Several pages record the author's own runs, such as Android APK analysis through headless JADX on rea-agents 6.5.0 and a Claude Code setup re-test on 6.8.0. The site also compares REA with Ghidra, IDA and other reverse-engineering MCP servers and documents look-alike REA copies. - Type: Learning resource - Targets: App · Binary · Website - Category: Community REA labs - Relationship: Community REA learning resource - Sources reviewed: 2026-11-02 - Added to the catalog: 2026-11-04 - Original resource: - Catalog page: ##### Requirements & limits - **Scope:** Reviewed as a live website on 2026-11-02, when its sitemap listed 32 pages. There is no public source repository or pinned revision; each page dates the check of the commands it restates (2026-10-13 to 2026-10-27 on the reviewed pages). The home page named rea-agents 6.8.0 and Node.js 22.23.4+, 24.22.1+ or 26.12.1+, matching npm and REA's README at review. - **Testing evidence:** Tested pages state their platform and versions: Android APK analysis on Debian 13 with rea-agents 6.5.0, JDK 21 and jadx-headless-mcp 0.7.1 on an F-Droid APK, and Claude Code setup re-run on rea-agents 6.8.0. The Gemini CLI page scanned REA's tool schemas on 6.5.0 and 6.7.0 but sent no request to Gemini, and the Windows page draws on REA's documentation and issue reports. - **Attribution:** Every page calls the site an independent community guide not affiliated with the REA project and names rea.tools and morluto/rea as authoritative; its fake-copies page lists only morluto/rea, rea.tools and the rea-agents npm package as official. The pages carry no ads or affiliate links and load Cloudflare Web Analytics. - **License:** The pages state no license for the guide's own text. REA is MIT; commercial engines it can drive, such as IDA Pro and Hopper, need their own licenses. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### OpenSecurityTraining2 > Free self-paced security courses with learning paths for reverse engineering, firmware and systems foundations. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Browser access; choose classes according to their published prerequisites and lab requirements. ##### Primary sources 1. #### pwn.college: Reverse Engineering > Hands-on reverse-engineering module covering functions, data access, static tools and dynamic tools with hosted exercises. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Catalog page: ##### Requirements & limits - Browser access and the platform's account/environment setup for interactive challenges. ##### Primary sources 1. #### Reverse Engineering for Beginners > Dennis Yurichev's free book on understanding compiled programs and assembly, available in multiple languages. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Catalog page: ##### Requirements & limits - A browser or PDF reader; use the toolchains relevant to the exercises being followed. ##### Primary sources 1. #### The Official Radare2 Book > Official practical reference for radare2 analysis, disassembly, scripting, debugging and related plugins. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-15 - Added to the catalog: 2026-10-16 - Original resource: - Catalog page: ##### Requirements & limits - Upstream lists radare2 5.8.x as the minimum and recommends a current release for following the examples. ##### Primary sources 1. #### LLM4Decompile (EMNLP 2024) > Research on direct binary decompilation and refinement of Ghidra output with language models. Evaluates re-executability on HumanEval and ExeBench; useful for distinguishing readable output from functional recovery. - Type: Research - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Catalog page: ##### Requirements & limits - EMNLP 2024 paper. Results are author-reported for the evaluated models and benchmarks. ##### Primary sources 1. 2. #### DecompileBench (Findings of ACL 2025) > A benchmark combining functions from real programs, runtime-aware validation, and LLM-assisted assessment of decompiled-code usability. Helps separate functional correctness from perceived understandability when comparing decompilers. - Type: Research - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Catalog page: ##### Requirements & limits - Findings of ACL 2025 paper. LLM-as-judge assessments and runtime correctness measure different properties. ##### Primary sources 1. 2. #### ReSym (CCS 2024) > Combines language models and program analysis to recover variable and user-defined data-structure symbols from stripped binaries. The authors provide training, inference, evaluation, and posterior-reasoning artifacts. - Type: Research - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - CCS 2024 paper with author-provided artifacts. ##### Primary sources 1. 2. #### Finding Jingle Town: Debugging an N64 Game without Symbols > A walkthrough from the Snowboard Kids 2 decompilation project on attaching gdb-multiarch to the Ares emulator while the matching build still cannot carry debug information. It breaks on a function by its ELF symbol name and reads one structure byte by hand to test whether that byte selects the level overlay. A short method note on checking decompilation hypotheses at runtime, not a reconstruction result. - Type: Learning resource - Targets: Game - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Catalog page: ##### Requirements & limits - The post, dated 23 December 2025, asks one question: how Snowboard Kids 2 picks the level overlay on level entry. It breaks on a function that indexes 16 overlays and reads the candidate byte for Sunny Mountain, Turtle Island and Jingle Town (0, 1 and 2). Other levels and the code that sets the index are not traced. - Following it needs a Snowboard Kids 2 N64 ROM, original or rebuilt by the decompilation (the post treats them as byte-identical), and the decompilation's build/snowboardkids2.elf for function names. The post does not cover obtaining or building either. - Tools are gdb-multiarch set to mips:4000 and Ares with debugging enabled, connected through Ares's GDB remote support; an SSH reverse tunnel is optional when GDB runs on another host, as on the author's x86 Ubuntu server. The post explains that adding -g would shift sections in the absolute-address build and usually stop it booting, so structure fields are read by manual pointer arithmetic. - Results are the author's observations from one debugging session. The post calls the workflow painfully manual and reports gdbgui did not work with the setup. Its generated names have since changed: at reviewed commit 7600c79, symbol_addrs.txt names 0x8003D560 initRace and 0x800AFE8C gGameSessionContext, and the footnoted src/3E160.c is no longer in the tree. - The post describes manual debugging. The decompilation repository has no license file at the reviewed commit, and the game ROM and its content keep their own rights. ##### Primary sources 1. 2. 3. #### JPCERT/CC: APK analysis and API probing on attack servers > JPCERT/CC’s 15 October 2026 blog post on the infrastructure behind a series of unauthorized-access incidents in Japan. It reports that the attackers used AI for known-vulnerability scanning and API attacks, and that attack servers held APKs, jadx- and Blutter-related files, APK-extraction directories and an SSRF test script used to probe app APIs. It is a defender’s account of observed attacker tooling with mitigation advice, not a published AI-assisted analysis method or reproducible workflow. - Type: Learning resource - Targets: App - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original resource: - Catalog page: ##### Requirements & limits - The reviewed source is the Japanese-language JPCERT/CC Eyes post dated 15 October 2026; no English version was found at the corresponding URL during review. It follows JPCERT/CC’s 8 October alert about personal-data leaks reported by several organizations in Japan, and describes three investigated servers, one of which it states is not directly related to these attacks. - The post states that JPCERT/CC confirmed AI use for scanning and API attacks, but it does not name the AI system or tooling or explain how AI was applied. The roles of the SSRF script and some files are described as likely rather than confirmed. Findings are illustrated with partial file listings and one script; no samples, logs, prompts or timelines are published. - Appendix A describes Blutter as an open-source tool for analyzing the Dart AOT-compiled code in Flutter apps, and cites third-party write-ups that combine Frida, Blutter, LIEF and Capstone to recover embedded keys and request-signing logic. These are referenced examples, not JPCERT/CC’s own reproduction. - Recommended mitigations are to keep API signing keys and long-lived credentials out of apps, to authenticate and authorize users on the server rather than rely on in-app signing or obfuscation, to rate-limit and monitor API use, and to restrict SSRF-prone URL fetches and re-validate redirect destinations. The post also lists three attacker IP indicators. - The post names jadx and Blutter but no other analysis tools. ##### Primary sources 1. #### Reverse Engineering (mytechnotalent) > A free, English lesson index by mytechnotalent that grows almost daily: 490 numbered lessons, most of which have learners write small programs and then debug and patch ("hack") them, across x86, x64, 32/64-bit ARM, RISC-V and AVR. Early courses start from number systems, registers, memory and the stack; later ones cover microcontroller firmware on Raspberry Pi Pico/Pico 2, STM32F401, ESP32-C3, ATmega328P and micro:bit boards, plus Windows, Go, Rust and WebAssembly programs. The README is a table of links; the lesson text lives in a GitBook and in the author's other repositories and PDF books. - Type: Learning resource - Targets: Binary · Firmware - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - At reviewed commit 8ae661a (pushed 2026-10-18) the README lists 490 numbered lessons in 26 courses and headlines a dated "Today's Tutorial" (Lesson 329, 18 October 2026); the default branch has received commits on most recent days. Lesson 1 describes the x86 course as starting from the basic concepts of malware reverse engineering and working up to an entry-level look at assembly, while later courses assume that grounding. The Reverse Engineering Data course (lessons 461–490) is statistics and machine-learning notebooks, not binary analysis. - No third-party target files are needed: most courses follow a write, debug, then patch pattern on programs the learner builds from the lessons. The embedded courses need physical boards (Raspberry Pi Pico and Pico 2/RP2350, STM32F401CCU6, ESP32-C3, ATmega328P, micro:bit), and the RISC-V course says it lists everything to purchase. The repository root also keeps Fritzing schematics and a few Windows MASM/Visual Studio example projects with their Debug builds. - Toolchains are set out in the linked material rather than the README, which mentions GDB in the x86 course, a Linux install lesson and PlatformIO for the ESP32-C3. Most of lessons 1–203 point to the "Reverse Engineering For Everyone!" GitBook by @mytechnotalent (built by @0xInfection); later lessons point to PDF books and lesson files in the author's separate repositories, which move independently. - The README's "Reverse Engineering Assistant" (REA) link is the author's own mytechnotalent/rea tool. The repository is Apache-2.0; linked books and repositories carry their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. #### Z0FCourse Reverse Engineering > A free English course by Z0F on reverse engineering 64-bit Windows programs, which its README pitches as taking learners from beginner to intermediate. Markdown lessons move from number systems, x64 registers, memory layout and calling conventions to x64dbg and Ghidra, then reverse small samples and an author-written DLL, recovering a Player class and calling the DLL's exports from a program of one's own. The unfinished later chapters introduce Windows internals and reverse ntdll's generic-table functions. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit ee4b070 (2026-07-25). Most lessons were written in 2019–2020, and the table of contents marks Chapter 7 (Windows) and Chapter 8 (Generic Table) as work in progress; the .NET and other-architecture material promised by the setup and Before You Begin pages is not in the tree. Later commits are small fixes, formatting, refreshed PDF copies and new links. The README points to two TryHackMe rooms as an interactive version of chapters 1–6. - Chapter 1 lists a good understanding of C/C++, object-oriented programming and pointers as prerequisites and highly recommends prior x86/x64 assembly. The course needs a 64-bit Windows system, a virtual machine being optional until the malware material; setup names the Microsoft Visual C++ Redistributable, x64dbg (with the optional xAnalyzer plugin) and dnSpy or ILSpy as required, with Ghidra and Visual Studio highly recommended. - The target programs are the author's own and ship with their source in FilesNeeded: the Chapter 6 DLL with two host programs and debug symbols, plus a sample malware program and dropper for a chapter not yet written, which FilesNeeded marks as use-at-your-own-risk. Chapter 8 instead analyzes Windows's own ntdll.dll, which is not included. PDF copies of the chapters are also committed, and the README warns they may lag the Markdown lessons. - The repository's License.md is the AGPL-3.0 text; the FAQ adds that downloading is allowed for personal use only and defers redistribution and teaching use to the license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### OWASP Mobile Application Security Testing Guide (MASTG) > OWASP’s open manual for Android and iOS app security testing and reverse engineering, published at mas.owasp.org. Chapters on platform internals, test setup and app tampering and reverse engineering sit beside modular, individually referenced tests, techniques, tool pages, knowledge articles, best practices and runnable demos, all mapped to MASVS controls and MASWE weaknesses. OWASP’s UnCrackable crackme apps serve as practice targets and examples. - Type: Learning resource - Targets: App - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-09-30 master commit. The latest release, v2.0.0 of 2026-06-30, is described as completing the refactor into modular, machine-readable components and as the first stable release of that framework, while CITATION.cff still names version 1.5.0 of 2022. The pin holds 92 v1 tests and 200 atomic tests, 167 techniques, 135 tool pages, 157 demos, 141 knowledge articles and 74 best practices. - Reading needs only a browser; OWASP’s separate mas-website workflow builds the site. Following the techniques needs a Windows, Linux or macOS host with the tools each page names, such as the Android SDK platform tools, plus test devices or emulators. The guide recommends a rooted Android test device or jailbroken iOS device for dynamic analysis, warns against using a personal device, and describes fallbacks for testers without one. - The UnCrackable apps for Android and iOS are OWASP’s own reverse-engineering challenges, used as examples throughout the guide. Sample-app pages describe third-party apps, and tool pages describe external software; both keep their own terms. Demo results are written up from the guide’s sample code, not from tests of production apps. - The repository is licensed CC BY-SA 4.0, so adapted text needs attribution and the same license. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### The Decompilation Wiki > Community wiki explaining how decompilers work, from disassembly, lifting and control-flow recovery to type recovery, control-flow structuring, quality evaluation and neural decompilation, citing the research behind each technique. It also keeps directories of decompilers, plugins, blogs and talks, pages on applied research such as symbol recovery, code similarity and vulnerability discovery, and a table of about 240 game reconstruction projects by original platform. - Type: Learning resource - Targets: Binary · Game - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-10-15 main commit, from which a workflow builds the site with MkDocs Material and publishes it to GitHub Pages; reading needs only a browser. The README calls the wiki early in development: it has about 30 pages, several of them short, and the neural-decompilation page was last changed in September 2024. - Listings are compiled from contributions. The decompiler directory’s 23 rows note open-source, inactive, plugin and educational status, and the program-reconstruction table lists 241 games, 39 marked completed. Cited papers are gathered in a linked Google Sheets list kept outside the repository. - Changes arrive as GitHub pull requests: listing additions should give a description link, tags and a source link, while content changes to research areas need a citation or a reasoned argument. Local previews use Python and MkDocs. - The repository is BSD-2-Clause; linked papers, tools and projects keep their own terms. The wiki was started by Zion Leonahenahe Basque and is maintained with community contributions. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Frontkick vs Rikugan: a CREBench agent comparison > Matthieu Breuil’s Synacktiv article explains tool-calling and code-executing agent designs and describes Frontkick, a CodeAct agent that runs generated Python inside Binary Ninja. It compares Frontkick with the open-source Rikugan plugin on two CREBench cryptographic binary tasks, then attributes most of Frontkick’s advantage to a prompt that listed installed Python libraries rather than to its architecture. It is a small evaluation write-up with per-run results, not a released tool or a general benchmark finding. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original resource: - Catalog page: ##### Requirements & limits - The article on Synacktiv’s publications site is dated 13/10/2026. It describes Frontkick as a CodeAct agent that executes generated Python against Binary Ninja’s API, with a recipe-retrieval corpus, a single-level subagent and truncation of older turns; no download, repository or license for Frontkick is linked. Rikugan is an MIT-licensed community agent plugin for IDA Pro and Binary Ninja built on schema-validated tools, while Vector 35’s closed-source Sidekick was excluded because its internals are not accessible. - The comparison used Claude Sonnet 5.5 with CREBench’s AES-128-CBC and ChaCha20 cases in the hardcode_plain/O0 setting, supplied as stripped binaries, with four runs per case for each agent and a 1M-token budget. Each run had to identify the algorithm and key and reimplement decryption to recover the flag. The article does not state the Binary Ninja, Rikugan or Frontkick versions or publish the run transcripts it inspected. - In the published run table Frontkick fully solves six of eight runs and Rikugan none; the means are about 86 versus 31 out of 100 and about 0.60M versus 0.95M tokens, which the article summarizes as roughly half the tokens and nearly three times the score. On AES-128-CBC, Rikugan repeatedly tried a Python crypto package that was not installed and fell back to a manual implementation, whereas Frontkick’s prompt listed the installed libraries. The author therefore calls the outcome a draw driven by prompt design, and proposes a rerun with aligned prompts. - Two tasks, one model and eight runs per agent cannot support general conclusions about either agent, about tool-calling versus code-executing designs, or about other CREBench settings. ##### Primary sources 1. 2. 3. 4. #### FLARE Learning Hub > Free English reverse-engineering and malware-analysis modules from Mandiant's FLARE team, published as Google Docs, with lab binaries, IDA databases and scripts kept in this repository. The Malware Analysis Crash Course builds from x86 basics to reading Windows API use through assembly-patching exercises and labs with worked solutions; the other modules introduce WinDbg Time Travel Debugging for malware triage and provide a reference to how Go 1.24 programs look in Windows executables. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - At reviewed commit ebd4e3a (2026-03-31), the repository, first committed on 2026-03-19, holds three modules: Malware Analysis Crash Course (nine chapters, five labs, hacking exercises and flash quizzes), An Introduction to Time Travel Debugging (a demo, one triage lab and a JavaScript automation reference) and The Go Reverse Engineering Reference. Module text lives in web-published Google Docs that change outside the repository. The README promises refinements and new modules, but no commits followed 31 March by the review date. - The crash course is the entry point: it assumes Windows command-line use, Boolean logic, two's complement, basic programming and networking. The TTD module assumes basic x86 Windows reversing and WinDbg. The Go reference assumes x86 reversing and Go, and is restricted to Windows AMD64 executables built with Go 1.24.0. - The README says all modules support only Intel x86-64 environments and strongly recommends an isolated, snapshot-capable FLARE-VM virtual machine. The crash course uses IDA and FakeNet, and its exercises ship with IDA database files; the TTD module uses WinDbg, which includes TTD, and ttd.exe. Lab and demo binaries, databases and scripts are FLARE-made and come as password-protected archives. The README warns that some behave like malware and may be flagged, so they belong only in that VM; one TTD demo trace is a separate Google Drive download. - The repository is Apache-2.0; the Google Docs reviewed carry no separate license statement. The project does not accept contributions and takes errata by email. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Nintendo Switch Reverse Engineering > Notes begun by dekuNukem in 2017 and extended by contributors on how the Joy-Con, Pro Controller and parts of the Switch console and dock work, worked out from teardowns, logic-analyzer captures and packet logs. Markdown files cover the Joy-Con board test points and rail-connector pinout, the wired serial handshake with its CRC-8 checksum, Bluetooth HID input and output reports with 32 documented subcommands, the USB HID commands of the Pro Controller and charging grip, the SPI flash memory map with stick and 6-axis calibration, IMU conversion formulas and rumble encoding tables. The repository also keeps STM32 test firmware that plays the console or a Joy-Con on the rail, a Wireshark dissector for the Bluetooth traffic, and the captures behind the notes. - Type: Learning resource - Targets: Firmware · Protocol - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit b354f21 (2026-08-21). Of 277 commits, 228 date from 2017 and most others from 2018–2021; the 2026 changes document the console's sanity checks on stick calibration. The notes describe the original Joy-Con and Pro Controller, listing controller firmware 3.89 as the latest, and several fields remain marked unknown, so newer firmware and controllers need separate checking. - Following the notes needs one's own controller. The wired-protocol work involves opening a Joy-Con and connecting its rail connector, which uses 1.8 V logic, to a logic analyzer or microcontroller; the Bluetooth and USB notes assume a host that can exchange raw HID reports, and their sample C code uses hidapi-style calls. No controller or dock firmware is included: the README says a dock firmware dump was made but is not posted. - The joycon_reader and joycon_spoofer projects target an STM32F072 and were generated with STM32CubeMX for Keil MDK-ARM; their build outputs are committed alongside the sources. The nxbt dissector has to be compiled as a plugin within a Wireshark source build, a Lua script dissects Bluetooth traffic captured over USB, and small Python scripts parse captures and compute the serial checksum. The .logicdata captures need logic-analyzer software that reads that format. - The Bluetooth notes also document SPI flash write and sector-erase and firmware-update commands, with warnings about erasing whole sectors; the field meanings come from the contributors' own captures and tests. - GitHub detects no license and the repository has no license file, so the notes state no reuse terms; a datasheets folder holds copies of third-party chip datasheets, and the Lua dissector says it is provided with no license. The README credits the many contributors. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Android App Reverse Engineering 101 > Maddie Stone's free English workshop introducing static reverse engineering of Android apps, published as GitHub Pages. Its chapters cover app components and entry points, Dalvik bytecode and smali, decompiling DEX with jadx, finding and reading JNI native libraries in Ghidra, and string deobfuscation. Seven exercises with written solutions apply this to triaging malware samples and spotting command-execution flaws in pre-installed apps. - Type: Learning resource - Targets: App · Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 17f9eeb, the last default-branch commit (2020-04-29); most pages date from 2019 and the material is not being extended. The introduction says the workshop covers static analysis only and does not teach app development, malware analysis or vulnerability hunting themselves; the conclusion points to Frida and dynamic analysis as next steps. - Exercises are designed for the author's Ubuntu 18.04 64-bit VM image, offered for VirtualBox and VMware from Google Drive, with jadx and Ghidra installed. The exercise APKs (apps triaged as possible malware and two pre-installed vendor apps, each named with a SHA-256 digest in most exercises) exist only inside that VM; the repository holds Markdown pages and images and no APKs. - The native-library chapter assumes some ARM assembly, pointing to outside tutorials, and says every exercise library also has an x86 build. The pages were last updated in 2020, so their screenshots may not match current jadx and Ghidra releases. - The repository has no license file, so reuse terms for the text are not stated; the pages credit the Android robot logo to Google under CC BY 3.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### Reverse Engineering iOS Applications > Ivan Rodriguez's free English course (version 1.1) on reverse engineering iOS applications, aimed at beginners in iOS app security. Five Markdown modules cover setting up a jailbroken test device, decrypting App Store apps for analysis, static analysis of an IPA's files, frameworks, Objective-C classes and ARM binary in Hopper or Ghidra, runtime analysis with Cycript and Frida, and binary patching in Hopper. Exercises use CoinZa, a deliberately insecure Objective-C app the author built from vulnerability classes he reports finding in production App Store apps. - Type: Learning resource - Targets: App · Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 183873a (2024-04-17). The course was written mainly in 2019; commits since mid-2020 are a few small wording and command fixes. Device instructions cover iOS 10 through 12, and many setup tools are from that period, so they may not work on current devices. The introduction excludes jailbreaking, iOS exploitation, tweak development, backend API testing and in-depth ARM assembly. - The prerequisites page lists no mandatory knowledge but recommends a Mac (Xcode has no Windows alternative), basic Objective-C, Swift, JavaScript, HTML, SSH/SCP and man-in-the-middle concepts, and an ARM disassembler such as Ghidra, IDA or Hopper's trial. A jailbroken iPhone/iPad/iPod on iOS 10 or later is needed only for the decryption module and the Cycript and Frida exercises. - No third-party app is needed for the exercises: the author ships CoinZa as an already-decrypted IPA, plus an EPUB of the course, in the companion repository RE-iOS-Apps-Extras-Github. The README says its vulnerabilities come from production apps but are reproduced in CoinZa instead of being published against those apps, and the closing page asks readers to report vulnerabilities responsibly. - There is no separate license file; the README carries an MIT-style permission notice (Copyright 2019 Ivan Rodriguez) and an at-your-own-risk disclaimer; the closing page asks people who reuse the material to credit the author. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### tiny-dec > Zhuo Zhang's small educational decompiler for 32-bit RISC-V (RV32I) ELF files, written in Python to teach how decompilation works rather than to compete with production decompilers. Its 19 deliberately separate stages run from ELF loading, decoding and p-code lifting through SSA, stack, type, variable and range recovery to control-flow structuring and C output, and the CLI can stop at any stage to print that stage's intermediate result. The README also offers a Claude Code plugin whose AI tutor walks learners through the stages with quizzes and exercises. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 4f5f1e0 (2026-05-27), the repository's only commit; the package is version 0.1.0, and the repository's test and lint workflows passed on that commit. The README calls it a teaching tool, not a production decompiler: it handles RV32I only, and unresolved expressions stay in the output as raw<...> rather than being guessed. A live demo site at tiny-dec.zzhang.xyz shows the stages. - Input is an RV32I ELF file. The repository commits 13 C test programs and 39 RV32I builds of them (-O0 and -O2, PIE and non-PIE) under tests/fixtures, so no outside binaries are needed. Rebuilding them or compiling one's own C code needs clang, lld and LLVM with RISC-V support, installed locally or through the included Docker development image. - Requires Python 3.12+ and Poetry, and the loader leaves ELF parsing to pwntools; the README lists Ubuntu/Debian system packages, and a devcontainer is included. The AI tutor needs Claude Code and installs as a plugin from the repository's marketplace manifest; its skill files hold one lesson guide per pipeline stage. - MIT license (Copyright 2026 Zhuo Zhang). The 500-test count and the example outputs are the author's. The tutor is an AI teaching aid. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Reverse Engineering Reading List > A short reading list, compiled by One Thawt mostly in 2015–2016, of about 58 links to reverse-engineering tools, books, papers, talks and blog posts, kept in a README and a separate malware-analysis page. Sections run from disassemblers and debuggers, beginner talks and classic books through data-structure recovery papers, instruction-set references, iOS, Android and Windows material, unpacking, deobfuscation and protocol inference from network traces. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit a1ee767 (2023-05-02). 46 of 53 commits date from 2015–2016; the last added entries are x64dbg (2017), Binary Ninja (2018) and Ghidra (2019), and the 2023 commit merged a 2018 pull request that removed a dead link. The list therefore predates most current tools and research. - Most entries are a bare link, some followed by a quoted publisher or project description, and there are no notes on difficulty, platform or currency. Many point to 2010–2016 posts and PDFs on personal or project sites, and the README suggests archive.org for links that are down. Six of the 59 unique URLs in the two files gave no response, a 404 or a sign-in page, and the TIE and HyperV entries link to unrelated documents (an iOS 6 security talk and an IR-synthesis slide deck). - Books link to Amazon store pages, and IDA Pro, Binary Ninja and Hopper are commercial products. The Windows section also links older write-ups on kernel-protection bypasses. - GitHub detects no license and the repository has no license file, so the list states no reuse terms; linked works keep their own rights. The author offers copies of unavailable documents on request through a personal contact page. ##### Primary sources 1. 2. #### Decomp Academy > A free, English, in-browser course in matching decompilation maintained by Jack Price-Burns: learners read a function's target assembly, write C, and the original console compiler grades the result byte for byte. Lessons build from reading registers and arithmetic through control flow, structs, floating point, the ABI, globals, optimizer behaviour and 64-bit integers, then finish with functions adapted from open-source decompilation projects. The curriculum now spans GameCube PowerPC, Game Boy Advance Thumb and Nintendo 64 MIPS courses, and the frontend source is on GitHub. - Type: Learning resource - Targets: Binary · Game - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at frontend commit a21f9d0 (2026-09-23); the repository was first published in June 2026 and has had commits most months since. The README still describes a single GameCube course of 258 lessons, but the reviewed curriculum and the live site list 755 lessons in three courses: GameCube (263), Game Boy Advance (251) and Nintendo 64 (241), each in four tiers from warm-up to real functions. - Lessons run in the browser at decomp-academy.dev and the README says no signup is needed to start; an account stores progress. Grading compiles the learner's C with the original compilers and diffs it using objdiff: Metrowerks CodeWarrior GC/2.0 for GameCube and SGI IDO 5.3 for Nintendo 64 on the hosted backend, a separate AGPL-3.0 repository that the README says runs the CodeWarrior compilers under wibo, and agbcc built to WebAssembly in the browser for Game Boy Advance. - No game files are needed: the later lessons adapt functions from open-source decompilation projects the README credits (Star Fox Adventures, Pikmin 2, Metroid Prime, Mario Party 4), and targets are generated server-side from each lesson's reference C. This repository contains no compiler, and the backend README says it commits only wibo, not MWCC; for local development the README expects Node 18+ and a sibling Star Fox Adventures decompilation checkout that supplies MWCC and binutils, while .env.example says a fresh clone uses the hosted compile API by default. - The frontend is AGPL-3.0, which also covers modified versions run as a network service. A CLAUDE.md lesson-authoring guide for Claude Code is committed. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### OWASP Firmware Security Testing Methodology (FSTM) > A free English methodology, maintained by Aaron Guzman and published on GitBook, for security testing and reverse engineering embedded-device firmware. It is organized as nine stages: information gathering, obtaining firmware, analyzing the image, extracting the filesystem, static analysis of its contents, emulation, dynamic testing, runtime analysis and binary exploitation, with example commands for tools such as binwalk, unblob, FACT, EMBA, Firmwalker, QEMU and Ghidra. An October 2025 revision added C/C++ static-analysis tools, SBOM generation and a mapping to the OWASP IoT Security Verification Standard (ISVS). - Type: Learning resource - Targets: Firmware - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at default-branch commit ec666e8 (2025-10-05). Most of the text dates from 2019–2020, with a 2022 EMBA/EMBArk update and an October 2025 revision that refreshed tool references, removed commercial ones and added the SAST, SBOM and ISVS sections; the published GitBook includes those additions. A feature branch adding ISVS requirement mappings by stage (June 2026) was not merged at review, and a shorter 2020 Chinese translation sits on the separate zhong-wen-fstm branch. - Its stated audience is security researchers, software developers, consultants, hobbyists and information-security professionals. It is a single long reference page of procedures and commands rather than a paced course, and it points to the OWASP IoT Security Testing Guide for hardware, wireless, network and user-interface tests outside firmware. - Following it needs the firmware image or the physical device under an authorized assessment; the methodology tells testers to choose acquisition methods by project objectives and rules of engagement and to follow local laws. Some stages assume hardware debug access and a chip programmer. Tools mostly run on Linux; the README links a preconfigured EmbedOS Ubuntu VM from 2020 and, for practice, deliberately vulnerable firmware such as OWASP IoTGoat, DVRF and DVID. - Licensed CC BY-SA 4.0 (License.md). ##### Primary sources 1. 2. 3. 4. 5. #### Emproof workshop: Firmware Reverse Engineering > Slides and 14 self-contained exercises from Emproof's firmware reverse-engineering workshop at ScapyCon Automotive 2025, designed by Tim Blazytko for a technical audience with little security experience. The firmware and binary tasks move from reading ELF metadata with binutils and first steps in Ghidra or Binary Ninja, through unpacking two embedded-Linux CTF images with binwalk, to bare-metal analysis: identifying the microcontroller, toolchain and memory map of a model car's firmware ELF, and rebasing a raw STM32F103 flash dump with segments taken from the datasheet. Other tasks decrypt strings statically in a Mirai sample and trace a hardcoded AES key back to its data section. - Type: Learning resource - Targets: Binary · Firmware - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-01 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit, from 2025-09-25, ends a 14-commit history that began on 2025-09-21. It holds slides.pdf and 14 tasks, each a task.md with step-by-step questions next to a samples folder; no model solutions are included, and the two embedded-Linux tasks link an external write-up. - The README says most samples target ARMv7 (Thumb/ARM32) or AArch64, and many come with C source. A Kali Linux-based Docker image fixed to linux/arm64, emulated on x86_64 hosts, supplies binutils, binwalk, John the Ripper and armhf runtime libraries; on first use docker_run.sh installs QEMU binfmt handlers on the host through a privileged container. Ghidra and Binary Ninja Free are installed on the host, and because Binary Ninja Free lacks AArch64 support, many tasks also ship an .armv7 build. - Bare-metal tasks expect the analyst to consult the microcontroller's datasheet or reference manual; the STM32F103 task names the flash, SRAM, peripheral and system-control-space ranges to define before re-analysis. Several further tasks are crackme-style license, keygen and anti-patching exercises on the workshop's own binaries. - The workshop materials are GPL-2.0, but the README excludes three sample folders from that license and provides them for analysis and education only, without redistribution: the two embedded-Linux images, which the tasks attribute to WORMCON CTF 2021, and a Mirai botnet binary that its task describes as active malware not to be executed, stored in a password-protected archive. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### iOS App Reverse Engineering > Freely published 2015 book by snakeninny and hangcom on reverse engineering iOS apps, distributed in its repository as a 442-page English PDF. Its four parts cover the iOS filesystem and file types; OS X and on-device tools such as class-dump, Theos, Reveal, IDA, Cycript and LLDB with debugserver; an Objective-C and ARM assembly methodology for locating the code behind a feature; and four worked practices that locate the relevant code in Notes, Mail, WeChat and Messages and then extend those apps with tweaks. - Type: Learning resource - Targets: App - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A historical resource: the repository has not changed since 2015-09-17 and holds only the README, an MIT LICENSE and the PDF. The book states that its examples were done on an iPhone 5 with iOS 8.1, and its tooling chapters date from the Xcode 6 and Cydia Substrate era, so tools, file locations and app internals described there may no longer match current iOS releases. - Reading needs only a PDF reader. The practices assume an OS X host with the tools the book names and a jailbroken test device, and they examine Apple's bundled apps and WeChat as installed on that device. - The cover credits the English translation to Ziqi Wu, 0xBBC, tianqing and Fei Cheng, and the preface warns that the book may contain errors and inaccuracies. The README invites readers who find it useful to buy the paid ebook edition. - MIT license, copyright 2015 snakeninny; the apps examined in the practices keep their owners' rights. ##### Primary sources 1. 2. 3. #### Frida Snippets > A single large README that collects hand-written Frida instrumentation examples, grouped into Native, Android and iOS sections, for observing how a running app behaves. The examples show patterns such as attaching interceptors, enumerating loaded modules and classes, describing class members, tracing method arguments and return values, printing backtraces, logging SQLite queries and I/O, and scanning or dumping process memory. A scripts directory adds helper code, including Python generators that emit hook stubs from a decompiler and a frida-server install script, plus editor snippets for Sublime and Vim. - Type: Learning resource - Targets: App - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - A reference collection, not an installable package: the content is the README and the scripts directory at the reviewed commit (last pushed 2024-11-29). The snippets assume a current Frida and are written for its JavaScript API with some ObjC and Java bridge calls; running any of them needs a separate, matching Frida install, which the repository does not pin. - Examples run against an app the analyst controls: Android snippets expect a device or emulator with a frida-server (the bundled install_frida_server.sh pushes one over ADB), and the iOS notes assume a jailbroken device. Scripts are standalone and uneven in quality, with several explicitly marked work-in-progress (WIP) files, and one JEB plugin that copies a generated hook to the clipboard needs JEB and xclip. - The target app comes from the user; the repository ships only example code and one demonstration GIF, no app binaries. It is intended for instrumenting software the analyst is authorized to analyze. - No license file is present and GitHub detects no license, so the examples carry no granted reuse terms and default to all rights reserved by the author. ##### Primary sources 1. 2. 3. 4. 5. #### iOSRE: iOS Reverse Engineering reference > A community-maintained reference on iOS reverse engineering started by kpwn, built from a wiki, a curated index of public technical papers and talks, and a few environment-setup scripts. The wiki pages introduce iOS internals such as the Mach-O executable format, the XNU kernel and IOKit, the boot chain and a history of platform mitigations, while the README states the project is an early, ongoing effort and several pages remain stubs. The repository hosts notes and external links rather than any Apple firmware, device images or app binaries. - Type: Learning resource - Targets: App · Binary · Firmware - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 20aff77 on the master branch; the repository was last pushed on 2018-06-30 and has not been updated since, so its iOS 8/9-era material is historical and does not track current iOS versions. The README calls the effort new and ongoing, and several wiki pages on topics such as auditing the XNU kernel, the boot ROM, the sandbox and userland subjects are still marked TODO. - The repository ships documentation and links, not target files: resources/papers/README.md is an index that links to publicly published papers and talks rather than hosting the PDFs, and no Apple firmware images, device keys or app binaries are committed. Working through the material assumes the reader supplies their own research device and Apple or third-party tooling, which the repository does not provide. - The setup scripts under resources/scripts target macOS with Xcode command-line tools and download third-party software at runtime, including Homebrew, ldid, Theos, Reveal, Hopper and class-dump, while a separate Install XPwn script builds tools on Linux through apt; each stays under its own license. - The README warns that files in the resources folder are mostly user-contributed and may be malicious and advises checking them before running; the project reports no testing or verified results. - LICENSE.txt is the author's Modified Anyone But Richard M Stallman (MABRMS) license, which GitHub cannot classify (NOASSERTION) and which permits broad reuse with the warranty disclaimer in that file; individual files may state otherwise, and the linked papers and tools keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### linux-re-101 > Michal Malik’s single-README reading list for Linux reverse engineering, with about 230 links and book titles that run from quick references on system calls, ELF and processor ABIs through 101 and 201 tiers on program start-up, linking and relocations. Later sections gather material on packers and obfuscation, anti-debugging, ELF infection, kernel modules and rootkits, exploitation, crackmes, radare2 walkthroughs, detection tools and books. It is a lightly annotated link list last changed in January 2022, useful as a background syllabus rather than a maintained course. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit f858da0, dated 2022-01-16, contains a single file, README.md, which calls the list a work in progress. It holds 231 bullet entries under 15 headings; the largest are Linux kernel, rootkits and LKM development (40), 101 (22) and viruses and infection techniques (20), and several articles appear in more than one section. - Entries give a title and a link, sometimes marked Optional or followed by a short remark; beyond the 101 and 201 headings they state no level, prerequisites or exercises. 148 of the 229 URLs use plain HTTP, and most dated links point to posts from 2008–2017. - The material centres on Linux ELF binaries on x86, x86-64, ARM, ARM64 and MIPS, and the hands-on section mostly uses radare2, with GDB, IDA and LIEF references elsewhere. The repository supplies no labs, sample binaries or setup; crackme and challenge links lead to external archives, and readers need a Linux system plus whatever tools each linked article names. - The packer, anti-debugging, infection, rootkit and exploitation sections link offensive write-ups, rootkit source repositories and external virus collections alongside detection material; linked code and samples are third-party material with their own risks and terms. - GitHub detects no license and the repository has no license file, so the list states no reuse terms; linked articles, books and code keep their own rights. An independent learning list. ##### Primary sources 1. #### Frida Labs > Eleven Android challenge apps with step-by-step write-ups for learning Frida instrumentation, progressing from setting up frida-server and hooking a Java method through calling static methods, changing fields, creating instances and hooking constructors to hooking, calling and patching native functions. The author presents them as beginner-to-intermediate exercises rather than hard CTF challenges: each app hides a flag, but the stated goal is learning Frida’s common APIs and being able to read scripts written by others. - Type: Learning resource - Targets: App - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2026-02-22 main commit, which adds Frida 17 workarounds to the native-hooking write-ups for challenges 0x8 to 0xB; the first write-up deploys frida-server 16.1.4. There are no releases, and the README says new challenges will be added over time. - Each challenge is a prebuilt APK committed by the author, with package names such as com.ad2001.frida0x1; the apps’ source code is not in the repository, and the solutions are Markdown write-ups with screenshots. They assume a rooted Android device or emulator, adb, frida-tools from pip and a frida-server build matching the device architecture, with jadx for the Java code and Ghidra for the native libraries; the 0xB write-up shows instruction patches for both x86 and ARM64 builds. - Flags and solution scripts are published next to each APK, so the set works as guided practice rather than an assessment. The README points to learnfrida.info and Frida CodeShare for further material. - MIT license for the repository; Frida, jadx, Ghidra and the Android tools keep their own terms. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### osx & ios re 101 > A single-README reading list for macOS (OS X) and iOS reverse engineering, kept by Michal Malik from 2015 to 2019 and labelled a work in progress. Its 98 entries in nine sections run from must-read blogs and Mach-O, ABI and system-call references through Mach-O basics, malware, anti-debugging and obfuscation write-ups, kernel, sandbox and jailbreak research, kernel-extension development and kernel debugging, and forensics and monitoring material, to crackmes and six books. Entries are bare links or titles, mostly with no annotation. - Type: Learning resource - Targets: App · Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed commit, from 2019-12-19 and the latest, closes a history of 69 commits that began on 2015-07-13. Most linked material targets OS X 10.x and iOS 8–10 era internals, such as El Capitan kernels and iOS 9 and 10 jailbreak analyses, and the list predates current macOS and iOS releases and Apple silicon Macs. A December 2019 commit replaced some broken and outdated links. - No target files are supplied or needed by the list itself; the linked tutorials and crackmes bring their own samples, and the books are listed by title only. Following the material assumes a Mac or iOS device and the tools each article uses, such as LLDB, Hopper, and VMware Fusion or VirtualBox for kernel debugging. - The list mixes analysis tutorials with malware infection, rootkit, privilege-escalation and jailbreak write-ups. The repository contains only README.md and no license file, so the list states no reuse terms, and linked works keep their own rights. ##### Primary sources 1. 2. 3. #### AndroidReverse101 > A Chinese-language Android reverse-engineering course by Evil0ctal, planned as 100 daily lessons. It starts from number systems, ARM assembly, the Dalvik/ART runtime and APK loading, then covers APK and DEX structure, Smali editing and repackaging, Frida and Xposed hooking, JNI and native-library analysis, traffic analysis, obfuscation and app hardening, with commands and code for tools such as jadx, apktool, readelf, GDB/LLDB, Frida and Burp Suite. A Crackmes folder adds copies of OWASP's UnCrackable and r2pay practice apps, and a community Indonesian translation follows the published lessons. - Type: Learning resource - Targets: App - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 9b72d20 (2025-12-31), the merge of a community Indonesian translation; the Chinese lessons and crackmes were committed between 22 and 25 February 2025, and there are no releases. The README outlines 100 days in three phases, but the tree holds 44 lessons (Days 1–41, 60, 70 and 100), and the Indonesian translation covers the same 44, many in shortened form. - No outside target files are needed to begin: the Day 20 lesson supplies crackme source for learners to compile, and the Crackmes folder commits five practice APKs, UnCrackable-Level1.apk, UnCrackable-Level2.apk, UnCrackable-Level3.apk, r2pay-v0.9.apk and r2pay-v1.0.apk, whose Git blobs are identical to the crackmes in OWASP's MASTG repository. Only Level 1 has a written walkthrough; the README's Crackme 2 link points to a file that is not in the tree. - Lessons assume a desktop host with adb and an Android device, and name tools including jadx, apktool, baksmali, readelf, GDB/LLDB, IDA Pro, Ghidra, Frida with frida-server on the device, Burp Suite and Wireshark; the Xposed lesson starts from a device rooted with Magisk. - Many phase-two lessons and the Day 70 and Day 100 exercises are framed around modifying third-party apps, including defeating licence, paid-feature, root-detection, certificate-pinning and anti-debugging checks. The README and lessons carry no note on legal use or authorization. - The repository is MIT-licensed (copyright 2025 Evil0ctal); the crackmes come from OWASP's CC BY-SA 4.0 MASTG repository, and the tools named keep their own terms. The lessons mention AI as a reverse-engineering subject. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. #### Ghidra Snippets > A single-page collection of 30 commented Python examples for scripting Ghidra, grouped by task: projects, programs, functions and cross-references, basic blocks, instructions, stack variables, decompiler output, comments, P-code emulation and dumps, call graphs and program slices. It starts from the Flat Program, Flat Decompiler and Flat Debugger APIs, then shows where a task needs Ghidra's fuller API; most snippets include an example of their output. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Everything is in one README, with no script files or releases. The last change, on 2023-07-19, fixed a typo; the one before, on 2022-11-09, added Flat API notes for Ghidra 10.2. Version remarks range from Ghidra 9.1 and 9.2.2 to 10.2, so names and behavior in current Ghidra releases may differ; the README points to Ghidra's built-in API help and to the ghidra.re online docs, which it says may not be up to date. - The examples run in Ghidra's Python scripting environment, which the README calls the Jython console, against a program the user has loaded. Plotting a function AST also needs GraphViz's dot plus networkx and pydot importable from Jython, and the README notes that Python modules with native code do not work there. Compatibility with PyGhidra or Python 3 is not stated. - Released under CC0 1.0. The README calls the snippets a verbose mashup with more than one way to do each task and invites pull requests. ##### Primary sources 1. 2. 3. #### Frida Boot: a beginner binary instrumentation workshop > A beginner workshop by leonjza on binary instrumentation with Frida, served as offline pages from a Docker container that has gdb with GEF and frida-tools preinstalled. Three chapters move from a small Linux C program, LD_PRELOAD hooks and how library calls resolve through the PLT and GOT, to Frida’s Interceptor for reading arguments and changing return values, NativeFunction for calling a program’s own functions, Python injector tools, RPC exports, TypeScript agents, frida-server and frida-gadget. It deliberately leaves out Frida’s mobile-app uses, and every exercise targets sample programs shipped with the workshop. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed master commit dates from 2021-04-28, with no releases or tags; the prebuilt leonjza/frida-boot image on Docker Hub (tag latest, amd64 only) was last updated the same day. The README links a YouTube recording of the workshop and keeps a PDF of the slides in slides/. - Needs a host with Docker. docker.sh pulls or builds the image and starts it with the SYS_PTRACE capability, serving the course at localhost:9999 and mounting a local code folder into the container. The Dockerfile builds on Debian bullseye-slim and downloads frida-server and frida-gadget 12.9.4 for linux-x86_64, but installs frida-tools, GEF and the frida-agent-example project unpinned, so a fresh build will not reproduce the 2021 tool versions. - Exercises compile and instrument the workshop’s own C samples in software/: a random sleep loop, a fake_sleep LD_PRELOAD library and a PIN-check program whose test_pin function the lessons call directly from Frida, with numbered JavaScript, TypeScript and Python snippets for each step. No third-party target binaries are included or needed; the material covers x86_64 Linux user-space processes. - The repository has no license file and GitHub detects none; the bundled docsify scripts and themes keep their own licenses, and Frida, GEF and the base image are fetched under theirs. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. #### Embedded Hacking (mytechnotalent) > A free English course by mytechnotalent on developing, debugging and reverse engineering firmware for the Raspberry Pi Pico 2 (RP2350, Arm Cortex-M33). A fourteen-week syllabus with slides, Markdown notebooks and a 40-chapter PDF textbook follows a write, debug, then hack pattern from hello-world through variables, data types, constants, operators, conditionals, structures and functions, using GDB with OpenOCD and Ghidra, with Binary Ninja and IDA versions of the notebooks from week 4; an I2C LCD, GPS, LoRa radio, servo and IR remote supply the exercises. Graded CTFs, story-driven classified-brief challenges and a secure-boot custom bootloader ship as author-built binaries alongside their source. - Type: Learning resource - Targets: Firmware - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at commit 76fa253 (2026-10-19). The repository dates from October 2023, but its current history restarts with an initial commit on 2026-10-07 and has received commits almost daily since; there are no releases. Weeks 1–7 and 9–11 have slides and notebooks; Week 8 is a midterm built on CTF-02, Weeks 12–13 list only topics, and the two Week 14 final projects are scenario descriptions with no linked files. A supplemental section, which the README places beyond the course, links Rust, Arm-assembly and RISC-V-assembly tutorials, drivers and IoT CTF projects in the author's other repositories. - The README expects intermediate C including pointers, bare-metal assembly basics, a working model of registers and the stack, command-line use and breadboarding. Hardware is a Raspberry Pi Pico 2 with a Raspberry Pi Debug Probe and the listed parts, among them LEDs, a push button, a 1602 I2C LCD, a DHT11 sensor, an SG90 servo, a VS1838B IR receiver with an NEC remote, a u-blox NEO-6M GPS module, two REYAX RYLR998 LoRa modules and an FT232RL USB-serial adapter; Fritzing and wiring diagrams are in hardware/. - Setup is native on Windows x64, Apple-silicon macOS and Linux x64: the VS Code Raspberry Pi Pico extension installs the Pico SDK, Arm GNU Toolchain, picotool and OpenOCD, builds use CMake and Ninja, and the course adds Ghidra with JDK 21, a serial terminal and a licensed Binary Ninja Personal; the IDA notebook variants additionally assume IDA. Root flash and debug-server scripts wrap flashing and the debug server. - No third-party firmware is needed: the exercises target programs the author wrote, and the repository commits their source with build outputs (ELF, BIN, UF2, HEX, disassembly and map files), two Binary Ninja databases, CTF-02's static libraries (its auth module, an mbedTLS subset and the Argon2 reference implementation), the RP2350 SVD file and the custom bootloader's signed images. datasheets/ holds copies of the RP2350 datasheet, the Pico C/C++ SDK book, Arm's Cortex-M33 Technical Reference Manual, the Armv8-M Architecture Reference Manual, AAPCS32 and Application Note 132, which keep their publishers' terms. - Apache-2.0 for the repository. The README's legal disclaimer limits use to educational, research and defensive work on devices the user owns or is explicitly authorized to test. A bundled OpenCode skill only enforces the author's C coding standard. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### Reverse-Engineering a Bluetooth-Enabled Radar Detector > Write-up of how the author decoded the Bluetooth RFCOMM protocol of a Cobra iRAD 900 radar detector so that a Raspberry Pi 3 could receive alerts without the iOS or Android app. Traffic was logged on a jailbroken iPhone with BTServer and filtered in Wireshark; the README then documents the detector's half-second status payload and the 9-byte reply whose ACK byte must echo the detector's sequence byte, and replays recorded responses to the initial settings sync instead of decoding it. A short beginner's case study on RFCOMM traffic analysis with a rough proof-of-concept script, not a maintained client. - Type: Learning resource - Targets: Protocol - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Written in 2017 and last expanded on 2017-07-06; the latest commit, from January 2025, only updates the contact email. It covers one detector model. The alert-type values are only partly identified because the author had no radar gun, the initial sync is replayed rather than decoded, and the README expects the replay data would need re-recording after app settings change. - Following the method needs a Cobra iRAD 900 used with its vendor app and a way to log the phone's Bluetooth traffic; the author used BTServer logging on a jailbroken iPhone 5 and Wireshark. The repository commits the author's three .pklg captures, the Wireshark XML export (data.xml) and the processed packetData.dat; no app or device firmware is included. - radar.py is a self-described extremely rough proof of concept that talks RFCOMM through PyBluez, with the author's detector address and service UUID hard-coded; its setup notes install the Python 2 python-bluez package. parseData.py converts data.xml into packetData.dat, which radar.py loads with pickle, so treat that file as executable input. - MIT License. Cobra's detector, app and trademarks keep their own rights. ##### Primary sources 1. 2. 3. 4. 5. #### Link Pi ENCx encoders (unofficial documentation) > A single-README notebook, kept since 2021 by an owner with no ties to the vendor, on the internals of LinkPi ENC-series video encoders and the TBS 2603SE, which share one firmware line; the author's first units use the F3520D board with a HiSilicon Hi3520DV400. It covers the Linux system and PHP web interface, undocumented features and internal pages, intercom and tally interfaces, default accounts and network services with hardening steps, HiSilicon media-pipeline diagnostics, board pinouts including the UART, firmware recovery, and translated release notes for firmware updates from 2020 to 2026. - Type: Learning resource - Targets: Firmware - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - The reviewed main commit, of 2026-07-13, added release notes for firmware 5.2.0 (build 20260531). Findings come from the author's and contributors' own devices; several sections are marked outdated, the release notes are machine-translated from Chinese, and the README says TinyENC1 appears to ship different firmware that the author has not examined. - The procedures need the reader's own encoder and shell access to it. Firmware upgrade and full-flash packages come only from LinkPi's official download pages; none are committed. The repository's only other file is v4l2-ctl, a prebuilt ARM uClibc build of the V4L2 control utility added in 2021 without source or a license notice. - The README lists the vendor's default credentials and exposed services as a security warning, says LinkPi did not answer the author's reports, and gives hardening steps. A 2026 update credits AI for in-progress LD_PRELOAD timestamp hooks. - There is no license file, so the notes state no reuse terms; LinkPi firmware, software and documentation keep the vendor's rights. ##### Primary sources 1. 2. 3. #### Supplementary AST-Based Deobfuscation Materials > Companion code for the ReverseJS blog's 2022 series on deobfuscating JavaScript by manipulating abstract syntax trees with Babel. Each folder pairs a small obfuscated sample with a deobfuscator script and its output, covering string concealing (escape sequences, concatenation, string arrays and string encryption), constant folding including JSFuck-style code, substitution of constant variables, bracket-to-dot property access, dead-code removal, proxy functions and sequence expressions. The README presents them as short learning examples rather than a production deobfuscator. - Type: Learning resource - Targets: Website - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the 2023-10-20 master commit, whose last change bumped @babel/traverse to 7.23.2. The blog lists seven posts in the series from May and June 2022, and folders such as Proxy Functions and Sequence Expressions have no matching post; the README warns that code not published on the blog is outdated and experimental, may be inaccurate or buggy, will likely not be updated and should not be used in a production deobfuscator. - Needs Node.js and npm install: package.json declares @babel/core and js-beautify, and the lockfile resolves @babel/parser, @babel/traverse and @babel/generator 7.23.x. Each script is run with node from its folder against the bundled sample. The String Encryption example also imports chrome-remote-interface-extra, which package.json does not list. - The samples are short, author-written obfuscations, so applying the techniques to other code needs the analyst's own inputs and checking. The VM-evaluation proxy-function example and the String Encryption example run code from the sample through Node's vm module, which Node.js documents as not a security mechanism. The author's later blog post reports CVE-2023-45133, an arbitrary-code-execution flaw in @babel/traverse before 7.23.2; the reviewed lockfile already resolves 7.23.2. - There are no tests or CI (the npm test script is a placeholder); expected outputs are committed beside each sample. - MIT (LICENSE), although package.json keeps npm's default ISC field. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. #### MCP Reversing Dataset (mrexodia) > Three worked examples by mrexodia of a language model reverse-engineering crackme binaries in IDA Pro through his IDA Pro MCP server. Each folder holds the input binary, a README giving its origin, the prompt and the model, the agent's own report and the exported session transcript, so readers can follow every tool call, rename, retype and comment the agent made on the database. The tasks cover a small Linux password check, an obfuscated Linux flag checker and a Windows crackme that, according to the agent's report, routes its checks through vectored exception handling. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Three tasks, committed between 2025-03-28 and 2025-04-14 and unchanged since. Each folder's README gives the input, the prompt and the model, next to the agent's report.md and an exported task-history.md transcript; crackme03 adds the agent's solve.py and a launcher that runs the ELF through WSL. All three runs used Claude 3.7 Sonnet in Roo Cline or Roo Code with the author's IDA Pro MCP server. - The repository bundles the three challenge binaries it analyzes: VEHMeme.exe, a Windows crackme the README credits to Brit and xenocidewiki from an earlier CTF; crackme03.elf, compiled with GCC 11.4.0 on Ubuntu 22.04 from a NoraCodes crackmes source file; and transformed.elf, described as a modified version of babush's mcp-job-security obfuscation project. They are small CTF-style samples rather than commercial software, but the repository states no redistribution terms for them. - Following a run needs IDA Pro, which is commercial, the IDA Pro MCP server and an MCP client. The prompts ask the model to rename, retype and comment the database and write a report, and the crackme03 prompt forbids brute forcing. The transcripts are single, unscored runs: the crackme03 report records a password confirmed by running the binary, the mcp-job-security report names the flag it extracted, and the VEHMeme report explains the exception-based check without stating a flag. These are author-published results. - There is no license file, so reuse terms for the transcripts and reports are unstated; the README welcomes contributions, but only the original three tasks exist. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. #### ICSim (Instrument Cluster Simulator) > OpenGarages' Instrument Cluster Simulator for practising CAN bus reverse engineering on a Linux virtual CAN interface instead of a car. One SDL window draws a dashboard whose speedometer, turn signals and door-lock indicators react to the CAN frames it sniffs, while a separate controls program turns gamepad or keyboard input into those frames and replays a recorded sample of generic CAN traffic as background noise. In training mode the arbitration IDs and byte positions behind each signal are randomized from a seed shared by both programs, and the highest difficulty level adds further random data to the target messages, so learners have to find the relevant messages themselves. - Type: Learning resource - Targets: Protocol - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Reviewed at the master head of 2025-09-18, which merged a fix for canvas glitches; the changes before it, from December 2023 and January 2024, added the Meson build and cleaned up compiler warnings. There are no tags or releases, tests or CI. The default signal layout is generic, and -m bmw switches some signals to IDs that the source labels for a BMW X1. - Runs on Linux with SocketCAN: the README creates a vcan0 virtual interface by loading the can and vcan kernel modules with sudo, and setup_vcan.sh repeats those commands. Building needs SDL2, SDL2_image and can-utils, which Meson checks for through candump; controls launches canplayer to replay data/sample-can.log and reads data files from ./data/. The README suggests an Xbox-style gamepad, and the source also maps keyboard keys; its troubleshooting notes cover SDL header paths and one Arch Linux report that needed sdl2_gfx. - The repository commits lib.o, a prebuilt x86-64 ELF object for can-utils' lib.c that both the Makefile and Meson link into icsim; the README says to rebuild it from can-utils when it does not link on another architecture. It also ships data/sample-can.log, a recorded log of generic CAN traffic used as background noise, plus PNG, SVG and layered-image artwork; it includes no vehicle firmware or software. - The exercise is to sniff the simulated bus, for example with candump, and infer which IDs and bytes drive each gauge; the controls usage text calls disabling the background traffic with -X cheating for that practice. Difficulty runs from 0 to 2, with 1 as the default, and only level 2 adds random bytes. - GPL-3.0 (LICENSE; meson.build declares GPL-3). lib.c keeps the Volkswagen Group Electronic Research copyright from can-utils, offered under BSD-style terms or GPL-2.0. ##### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. #### CNNPRE (IEEE Access 2023) > Research code and data for CNNPRE, a message-type identification method for protocol reverse engineering by Javad Garshasbi and Mehdi Teimouri, published in IEEE Access in 2023. A single Colab notebook turns each message's padded bit string into a resized grayscale image, extracts features with an ImageNet-pretrained ResNet50 as transfer learning, adds message direction and length-group encodings, reduces the features with UMAP and clusters messages with agglomerative clustering and HDBSCAN, scoring each clustering against labelled message types. Preprocessed message datasets for twelve protocols, from ARP and DNS to SMTP and GSM, accompany the notebook. - Type: Research - Targets: Protocol - Category: Protocol analysis tools - Relationship: Learning resource - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - Paper: Javad Garshasbi and Mehdi Teimouri, “CNNPRE: A CNN-Based Protocol Reverse Engineering Method,” IEEE Access, vol. 11, pp. 116255–116268, 2023, DOI 10.1109/ACCESS.2023.3325391; Crossref lists it under CC BY-NC-ND 4.0. The repository was reviewed at its 2026-01-13 head, a README update; the notebook last changed on 2023-07-06, and there are no releases. - The only code is cnnpre.ipynb, written for Google Colab. It pip-installs umap-learn and hdbscan, apt-installs TeX Live and pandoc for a PDF export, and otherwise relies on Colab's preinstalled TensorFlow, scikit-learn, OpenCV, pandas and yellowbrick without pinned versions. It downloads ImageNet ResNet50 weights, reads one hard-coded CSV (GSM5000-hex.csv) with a message count that must be edited for other datasets, and its last cells mount Google Drive to convert the notebook. There is no package, command-line tool or test. - Inputs are message-level CSVs with direction, labelled message type and each message as hex and bit strings. Data/ holds preprocessed CSVs for ARP, DHCP, DNS, FTP, GSM, HTTP, ICMP, NBNS, NTP, POP, SMTP and Syslog, PCAP/ holds the GSM capture 44CON-gsm-uplink-downlink-sim-example.pcap, and the README names the public WRCCDC 2021 regional competition captures as the other source. No PCAP-to-CSV preprocessing script is included, so a new protocol needs its own conversion, and the notebook's evaluation metrics need ground-truth message types. - The notebook covers message-type clustering only, not field, semantic or state-machine inference. Its results labelled K-Means take the cluster count from a K-means elbow search but cluster with agglomerative clustering, and the saved outputs show one GSM run. Accuracy figures are the paper's. - GitHub detects no license and the repository has no license file, so the code and preprocessed datasets state no reuse terms; the paper's license covers the article, not the repository, and the captures keep their sources' terms. ##### Primary sources 1. 2. 3. 4. 5. #### RPISEC Malware Analysis course (CSCI 4976) > Materials from the student-run Malware Analysis course that RPISEC taught at Rensselaer Polytechnic Institute in Fall 2015, built around the book Practical Malware Analysis. Twelve lectures run from basic static and dynamic analysis, x86 and IDA through Windows internals, malware behavior, data encoding, covert launching, anti-disassembly, anti-VM and anti-debugging, and packing and unpacking to the Windows kernel and rootkit techniques, with ten labs and four projects that include runtime process manipulation, unpacking automation and an APT sample analysis. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The course expected working C/C++ and some assembly experience, and students read the matching book chapters before each lecture. It used a Windows 7 32-bit analysis VM, which is not distributed; the v1.0_release (2016-01-14) packages installers for the free tools used, such as IDA Free, OllyDbg, WinDbg, the Sysinternals Suite, PEiD, Regshot and Wireshark. - **Limits:** Most lab and project samples are real malware, stored in ZIP archives encrypted with the password infected; the README says to keep them inside a proper analysis environment. Lectures were not recorded, and slides covering book material are outlines. - **License:** The repository has no license file and GitHub detects no license; the reviewed master commit dates from 2017-05-11. ##### Primary sources 1. 2. 3. 4. #### Corkami pics > Collection of posters and diagrams that dissect file formats byte by byte, published as PNG and PDF images. The binary posters cover executables (ELF, DOS COM and EXE, NE, LE, PE, Mach-O and fat Mach-O, Java class, Dalvik DEX, Python bytecode, SWF, GameCube/Wii DOL and Switch NRO) along with image, video, archive, document, sound and serialization formats, x86 and x64 opcode charts and Dalvik, JVM and .NET opcode tables. The more detailed 101 series explains PE, ELF, Mach-O, ZIP, Java class, PDF, COM and WAV files and includes Inkscape sources and proof-of-concept files. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Images and PDFs to view in a browser or image viewer; nothing needs installing. The repository has no releases, and the reviewed master commit dates from 2024-02-18. - **Scope:** Besides the file-format posters, the repository holds general posters, tracings and outlines that are not about file formats. - **License:** The repository has no license file and GitHub detects no license, so reuse terms are not stated. ##### Primary sources 1. 2. 3. #### Practical Malware Analysis > No Starch Press book, published in February 2012, that teaches hands-on malware analysis from basic static and dynamic techniques in virtual machines through x86 disassembly with IDA Pro, debugging with OllyDbg and kernel debugging with WinDbg. Later chapters cover malicious Windows programs, covert launching, data encoding, network signatures, anti-disassembly, anti-debugging and anti-VM techniques, unpacking, shellcode, C++ and 64-bit malware, and hands-on labs with solutions have readers dissect malware samples. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-05 - Added to the catalog: 2026-11-06 - Original resource: - Catalog page: ##### Requirements & limits - **Prerequisites:** An 800-page book, sold in print with a free ebook or as a PDF, Mobi and ePub ebook. Chapter 12, the detailed table of contents and the index are free PDFs, and an errata PDF is posted. - **Prerequisites:** Following the book needs a safe virtual analysis environment, which it teaches readers to set up, and the analysis tools it covers, such as IDA Pro, OllyDbg and WinDbg. - **Limits:** The publisher's “Download the labs” link leads to a GitHub repository offering the lab binaries as a self-extracting archive or a password-protected 7-Zip file. Its README warns that the binaries contain malicious code that should not be installed or run without first setting up a safe environment, and that, like real malware, some may crash, leak memory or behave unexpectedly. - **Limits:** The labs target Windows XP: many work on newer Windows but some do not, and a separate archive holds labs rebuilt for Windows 7 whose results differ from the book's answers. ##### Primary sources 1. 2. #### Windows Malware Analysis training, volume 1 (malware_training_vol1) > Slides and exercises for a Windows malware analysis training that builds an understanding of common malware techniques through programming, reverse engineering and Windows internals, and shows how analysis tools are used for particular goals. Module 1 covers compilation, the PE format, processes, WoW64, shellcode and PE loaders; module 2 introduces malware missions and tactics, hooking, persistence and banking trojans; module 3 introduces evasion and self-defence and fingerprinting, with obfuscation, anti-hooking, deobfuscation and kernel-mode components planned. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Aimed at people who already know the basics of programming and reverse engineering and want to enter Windows malware analysis. Slides are in slides/ and exercises in exercises/. - **Limits:** The README marks the material as a work in progress: several topics still lack slides or exercises. The reviewed main commit dates from 2024-07-01. - **License:** Published under the Creative Commons Attribution 4.0 license, per the README; the repository has no license file. ##### Primary sources 1. 2. 3. #### esp-idf-injection-ng > esp-idf-injection-ng documents an investigation of ESP-IDF's compiled libnet80211.a frame-type check. The author traces why symbol overrides fail in v5 and later, then supplies an objcopy patch, demonstration firmware and captures for transmitting additional 802.11 management frames through esp_wifi_80211_tx. - Type: Research - Targets: Binary - Category: Native analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** An ESP-IDF installation and ESP32 hardware are needed for the demonstrated patch and firmware. - **Testing evidence:** The author tested ESP-IDF v6.1-dev on classic ESP32; other listed versions and chips are conditional. - **Limits:** The patch changes the local ESP-IDF archive globally and affects builds using it. - **License:** MIT License. ##### Primary sources 1. 2. #### RE-Workstation > RE-Workstation is a Chinese reference library for reverse-engineering workflows and related security research. Its topic pages cover native binaries, APKs, firmware, JavaScript, patch diffing and malware analysis, with indexes, evidence templates and pattern references for locating relevant methods. - Type: Learning resource - Targets: App · Binary · Firmware · Website - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The full directory, including SKILL.md, CATALOG.md, knowledge/ and references/, is needed for agent-skill use. - **Scope:** Analysis tools are supplied by the host environment. - **License:** Original and newly organized content is GPL-3.0-only; third-party content retains its own terms. ##### Primary sources 1. 2. #### Walksnail Ascent VRX UART Protocol > Walksnail Ascent VRX UART Protocol documents serial control messages for Walksnail video receivers and supplies a C reference transmitter with an STM32 example. It specifies framing, payload checksums, remote keys, channel selection and status queries, while recording contradictions and unknown reply layouts. - Type: Documentation - Targets: Protocol - Category: Protocol analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Walksnail VRX and a controller with a compatible UART interface for hardware use. - **Limits:** The library limits payloads to 64 bytes; baud rate, electrical levels and pinout need hardware confirmation. - **Testing evidence:** TX examples are tested against supplied documentation; RX telemetry layout and device behavior remain unresolved. - **License:** MIT license. ##### Primary sources 1. 2. #### T2 platform research > T2 platform research maps Apple T2 firmware, hardware and Linux-facing interfaces using static analysis, hardware observations and driver comparisons. Its chapters cover Secure Enclave services, boot and recovery, graphics, audio, sensors, storage and other subsystems. Machine-readable findings and board indexes connect claims to their evidence, with Python reference code for selected message formats. - Type: Research - Targets: Firmware · Protocol - Category: Firmware tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The main firmware inventory covers bridgeOS 23P6068 across 16 production configurations. - **Scope:** Most host observations concern MacBookPro16,1 / J152fAP; other board and firmware claims have separate scope. - **Limits:** The reference code does not provide a driver or fingerprint service. - **License:** MIT license. ##### Primary sources 1. 2. #### Glaurung Models > Glaurung Models contains tokenizer and model experiments for executable analysis. Its documented 64K BPE tokenizer encodes compiled PE and ELF bytes using Latin-1, with x86 and ARM64 training coverage; an accompanying analysis compares learned SSE and AVX instruction patterns across two tokenizers. - Type: Research - Targets: Binary - Category: Native analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The documented tokenizer workflow uses the tokenizers and transformers Python packages and Latin-1 conversion of binary bytes. - **Testing evidence:** The document reports an average of 2.849 bytes per token for the 64K tokenizer. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### CrackMes > CrackMes is a set of walkthroughs for purpose-built crackme binaries from crackmes.one. The supplied Linux x86-64 examples identify ELF executables, inspect program disassembly, use breakpoints and runtime observations, and explain how candidate input is checked. - Type: Learning resource - Targets: Binary - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The covered examples use Linux x86-64 crackme binaries obtained separately from crackmes.one. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### Binary BPE Tokenizer for Executable Analysis > Binary BPE Tokenizer for Executable Analysis studies byte-pair encoding of ELF, PE, Mach-O and APK files for transformer-based binary analysis. The repository provides paper sources, 4K to 64K tokenizer vocabularies, Python evaluation scripts and a sample archive. The author reports 2.89 bytes per token for the 64K vocabulary. - Type: Research - Targets: App · Binary - Category: Native analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Python 3.10+ with uv; TeX Live 2023+ is required to compile the paper. - **Prerequisites:** Rust 1.70+ is optional for retraining the tokenizer from scratch. - **License:** No licence file in the repository. ##### Primary sources 1. #### Assassin's Creed III online service docs > Assassin's Creed III online service docs record method IDs and request and response fields for the PC game's online services. The files cover RMC services such as online saves and account management, alongside notes on P2P Duplicated Objects over PRUDP. - Type: Documentation - Targets: Game · Protocol - Category: Protocol analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** Scope is Assassin's Creed III PC online services. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### AC4 docs > AC4 docs records online service interfaces for the PC version of Assassin's Creed IV Black Flag. Its RMC documents list method IDs and request and response types, while the repository also contains HTTP API specifications for service revival work. - Type: Documentation - Targets: Game · Protocol - Category: Protocol analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** Scope is the PC online services of Assassin's Creed IV Black Flag. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### eRepublik API Documentation > eRepublik API Documentation maps endpoints observed in the browser-based strategy game's web client. Its reference pages cover authentication cookies and requests for travel, battles, economy, social features and other game functions, with HTTP methods and example parameters. - Type: Documentation - Targets: Game · Website - Category: Website analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Most documented endpoints require authentication. - **Limits:** The source warns that undocumented endpoints may change or stop working. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### Garmin Strength Workout API > Garmin Strength Workout API documents payloads for creating strength workouts through Garmin Connect's undocumented API. Its reference describes repeat groups, exercise and rest steps, conditions, weights and exercise identifiers, with JSON examples plus a small builder and validator. - Type: Documentation - Targets: Protocol · Website - Category: Website analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Garmin Connect OAuth tokens are required to call the workout endpoint. - **Limits:** The source warns that the undocumented API may change. - **License:** MIT License. ##### Primary sources 1. 2. #### Substack API Reference (Unofficial) > Substack API Reference documents the web app's undocumented JSON API using curl probes and captured browser requests. It records read and write endpoints, authentication and request bodies, and supplies an OpenAPI 3.1 specification with curl and TypeScript examples. The author reports 129 verified endpoints from 14 capture rounds. - Type: Documentation - Targets: Protocol · Website - Category: Website analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Substack session cookie is needed for authenticated endpoints. - **Limits:** The internal API can change; entries distinguish author-tested, reported, inferred, dead and gated endpoints. - **License:** MIT License. ##### Primary sources 1. 2. #### hyperscan-homebrew > hyperscan-homebrew documents Mattel HyperScan hardware behavior for homebrew and emulation work. Its notes cover SPG290 PPU registers, RFID reader signaling, controller I²C behavior, SPU audio and S+Core 7 compiler failures, drawing on MAME experiments and hardware captures where available. - Type: Documentation - Targets: Protocol - Category: Firmware tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The documented work concerns Mattel HyperScan and its Sunplus S+Core 7/SPG290 hardware. - **Testing evidence:** The notes use MAME as the working reference platform; hardware captures were available for some comparisons. - **License:** MIT license. ##### Primary sources 1. 2. #### Локальный аудиостриминг на Яндекс.Станцию > Local audio streaming on Yandex Station is a technical guide to the device’s Glagol WebSocket control channel and its HTTP audio-stream behavior. It documents radio_play, token acquisition, message formats and MP3 CBR stream requirements, including an exact Content-Length. - Type: Documentation - Targets: Protocol - Category: Protocol analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** A Yandex Station on the local network and an account Session_id to obtain a short-lived Glagol token. - **Prerequisites:** An HTTP server serving MP3 CBR with an exact Content-Length. - **Testing evidence:** The author tested a first-generation Yandex Station; other Quasar models were not tested. - **License:** Documentation text is CC BY 4.0; code snippets are MIT. ##### Primary sources 1. 2. #### Hacking the Xbox — 日本語訳 > Hacking the Xbox — 日本語訳 publishes a Japanese translation of a book on Xbox reverse engineering. The repository includes translated introductory material and chapters 1–6 with figures; later chapters and appendices remain pending. - Type: Learning resource - Targets: Firmware - Category: Learning resources - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** Japanese reading ability. - **Limits:** Chapters 7–13 and appendices A–F are not started; earlier sections remain under review. - **License:** Book-derived text, images and translations: CC BY-NC-SA 1.0; scripts and site configuration: MIT. ##### Primary sources 1. 2. #### Spelunking > Spelunking studies Apple apps, private frameworks and system services with Swift and Objective-C probes. It inventories runtime classes, symbols, notifications and MediaRemote state, while publishing target-specific writeups and raw captures for Messages, Phone, MediaRemote and UserNotifications. - Type: Research - Targets: App · Binary - Category: Native analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Prerequisites:** The package requires macOS 26 or later and Swift 6.2 or later. - **Limits:** Individual probes may require specific OS builds, private frameworks, TCC permissions or SIP settings. - **License:** No licence file in the repository. ##### Primary sources 1. 2. 3. #### whatsapp-docs > whatsapp-docs records findings from static decompilation of the WhatsApp Android APK, covering app internals and communication formats. Its reports describe linked-device pairing, Noise transport, reporting stanzas, media upload and other client flows, with findings distinguished from inferences. - Type: Documentation - Targets: App · Protocol - Category: Android tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Scope:** The reports use WhatsApp Android APK version 2.26.41.6 for the listed topics. - **Limits:** The analysis is static; server-side ML behavior is inferred from client-collected metrics. - **License:** No licence file in the repository. ##### Primary sources 1. 2. #### RtG-Format > RtG-Format documents the observed save and construction format of the Roblox game Road To Gramby's. Its references and experiments cover build structures, part identifiers, connections, properties, encoding and compression, with supporting CLI and browser preview tools. - Type: Documentation - Targets: Game - Category: Game analysis tools - Relationship: Learning resource - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original resource: - Primary source: - Catalog page: ##### Requirements & limits - **Limits:** The project states that reverse engineering is ongoing and some field meanings and behavior remain uncertain. - **License:** GPL-3.0 license. ##### Primary sources 1. ## Research papers (235) ### LLM4Decompile: Decompiling Binary Code with Large Language Models > Trains language models for assembly-to-C decompilation and for refining Ghidra pseudocode, evaluating whether recovered functions can be recompiled and executed correctly. - Authors: Hanzhuo Tan; Qi Luo; Jing Li; Yuqun Zhang - Venue: EMNLP 2024 - Status: Conference paper - Publication / posting date: November 2024 - Date source: ACL proceedings publication month - First arXiv submission: March 8, 2024 - arXiv: 2403.05286 - Reviewed arXiv version: v3 - DOI: 10.18653/v1/2024.emnlp-main.203 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The paper limits its experiments to C on x86 and function-level benchmarks. Re-executability on sampled tests does not establish whole-program equivalence or recovery of the original source. Later repository releases are separate from the 2024 paper. #### Why it fits this collection Direct evidence for LLM decompilation and a concrete baseline for evaluating agent-generated or refined pseudocode. #### Publication and review notes Publication date is the conference month; the first arXiv submission date is listed separately. #### Primary sources 1. 2. 3. 4. 5. ### DecompileBench: A Comprehensive Benchmark for Evaluating Decompilers in Real-World Scenarios > Evaluates traditional and LLM-based decompilers using functions from real programs, runtime behavioral checks, and an LLM-assisted assessment of analyst-facing code understandability. - Authors: Zeyu Gao; Yuxin Cui; Hao Wang; Siliang Qin; Yuanda Wang; Zhang Bolun; Chao Zhang - Venue: Findings of ACL 2025 - Status: Conference paper - Publication / posting date: July 2025 - Date source: ACL proceedings publication month - First arXiv submission: May 16, 2025 - arXiv: 2505.11340 - Reviewed arXiv version: v1 - DOI: 10.18653/v1/2025.findings-acl.1194 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The evaluated corpus has 23,400 functions from 130 programs. Fuzzing-based checks have finite coverage, and understandability scores depend partly on an LLM judge. The artifact warns that rebuilt OSS-Fuzz projects can differ from the paper's versions. #### Why it fits this collection Helps readers separate readable decompiler output from behaviorally faithful output when choosing or evaluating reverse-engineering tools. #### Publication and review notes The published ACL record and PDF use 'Zhang Bolun'; the arXiv record uses 'Bolun Zhang'. The paper's Jennieett/DecompileBench link now redirects to vul337/DecompileBench. This is distinct from Tan et al.'s Decompile-Bench (arXiv:2505.12668). #### Primary sources 1. 2. 3. 4. 5. ### DIRE: A Neural Approach to Decompiled Identifier Naming > Combines lexical and structural information from decompiler output to predict meaningful variable names, with a training and evaluation corpus derived from compiled C projects. - Authors: Jeremy Lacomis; Pengcheng Yin; Edward J. Schwartz; Miltiadis Allamanis; Claire Le Goues; Graham Neubig; Bogdan Vasilescu - Venue: ASE 2019 - Status: Conference paper - Publication / posting date: November 2019 - Date source: Publisher-deposited Crossref print-publication month; the 11–15 November 2019 conference dates are not used to assert a publication day. - First arXiv submission: September 19, 2019 - arXiv: 1909.09029 - Reviewed arXiv version: v2 - DOI: 10.1109/ASE.2019.00064 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations This is learned identifier naming, not complete source reconstruction or an autonomous agent. Its reported results concern an x86-64 C corpus and depend on decompiler output. The original author repository is deprecated and points to a successor. #### Why it fits this collection A foundational reference for the renaming step frequently delegated to reverse-engineering assistants. #### Publication and review notes IEEE/ACM ASE 2019 proceedings, pages 628–639; the DOI resolves to IEEE Xplore document 8952404. The publisher-deposited and arXiv titles use 'Naming'; the ASE program and original code repository use the variant 'Renaming'. Both refer to this paper. Crossref lists 'Edward Schwartz'; the paper's own 'Edward J. Schwartz' is retained. Code URL is the verified original author artifact, explicitly deprecated. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Augmenting Decompiler Output with Learned Variable Names and Types > Introduces DIRTY, a Transformer model that recommends variable names and types from decompiled code and layout information, together with the DIRT corpus for training and evaluation. - Authors: Qibin Chen; Jeremy Lacomis; Edward J. Schwartz; Claire Le Goues; Graham Neubig; Bogdan Vasilescu - Venue: USENIX Security 2022 - Status: Conference paper - Publication / posting date: August 2022 - Date source: USENIX proceedings BibTeX publication month - First arXiv submission: August 13, 2021 - arXiv: 2108.06363 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The original pipeline is built around C programs and Hex-Rays output. Predicted names and types are learned hypotheses, not guaranteed original symbols. The published paper is from 2022, although its arXiv preprint first appeared in 2021. #### Why it fits this collection Extends name recovery to types, making it directly relevant to assessing semantic annotations added by binary-analysis assistants. #### Publication and review notes Year and publication month come from the final USENIX conference record; the arXiv date is not substituted for publication. #### Primary sources 1. 2. 3. 4. 5. ### ReSym: Harnessing LLMs to Recover Variable and Data Structure Symbols from Stripped Binaries > Combines two fine-tuned language models with Prolog-based cross-function reasoning to infer local-variable symbols and user-defined data structures from stripped-binary decompilation. - Authors: Danning Xie; Zhuo Zhang; Nan Jiang; Xiangzhe Xu; Lin Tan; Xiangyu Zhang - Venue: ACM CCS 2024 - Status: Conference paper - Publication / posting date: December 2, 2024 - Date source: ACM-deposited Crossref print-publication date; the October 14–18 CCS 2024 conference week is not used as the publication date. - DOI: 10.1145/3658644.3670340 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The method depends on underlying decompilation and learned predictions over C/C++ data. Cross-checking reduces conflicting predictions but does not prove that recovered names or layouts match the unavailable source. The public artifact includes models, processed data, and evaluation code. #### Why it fits this collection A concrete hybrid approach for grounding LLM-generated reverse-engineering annotations in program analysis. #### Publication and review notes ACM metadata records print publication on 2024-12-02 and online publication on 2024-12-09, pages 4554–4568. The author-hosted published PDF identifies the event as CCS ’24, held October 14–18, 2024 in Salt Lake City. The DOI, title, six authors and venue agree with the publisher record and the official author artifact. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### CrackMeBench: Binary Reverse Engineering for Agents > Evaluates agents on executable-checked CrackMe tasks: infer validation logic from binaries and submit an accepted input or artifact, while recording tool use, time, and scoring attempts. - Authors: Isaac David; Arthur Gervais - Venue: arXiv - Status: Preprint - Publication / posting date: May 11, 2026 - Date source: arXiv v1 submission - First arXiv submission: May 11, 2026 - arXiv: 2605.10597 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The v0 study uses 12 generated tasks and eight public calibration tasks, Linux x86-64 ELF binaries, a shell interface, and a five-minute budget. Its compact educational tasks do not establish performance on large applications. No paper-linked public artifact URL was verified. #### Why it fits this collection Directly measures whether an autonomous reverse-engineering workflow produces a verifiably accepted result. #### Publication and review notes No conference venue is stated in the reviewed arXiv record. Tool repositories cited in its bibliography are not treated as the paper's own code. #### Primary sources 1. 2. ### CREBench: Evaluating Large Language Models in Cryptographic Binary Reverse Engineering > Benchmarks cryptographic binary reverse engineering across algorithm recognition, key or IV extraction, wrapper reconstruction, and flag recovery using 432 controlled challenges. - Authors: Baicheng Chen; Yu Wang; Ziheng Zhou; Xiangru Liu; Juanru Li; Yilei Chen; Tianxing He - Venue: COLM 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: Publication year from the official COLM 2026 OpenReview record and its BibTeX; no finer publication date is asserted. - First arXiv submission: April 4, 2026 - arXiv: 2604.03750 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The corpus combines 48 algorithms, three insecure key-use scenarios, and three difficulty levels. It excludes professional-grade obfuscators such as Tigress and O-LLVM; results should not be generalized to heavily protected arbitrary binaries. #### Why it fits this collection Provides a focused, decomposed test of cryptographic behavior recovery, with a verified official implementation. #### Publication and review notes The COLM 2026 OpenReview record has the same title, seven authors and abstract as arXiv v2 (2026-08-06), whose header reads 'Published as a conference paper at COLM 2026' and which the official project calls its camera-ready version. OpenReview’s 2026-07-08 publication timestamp coincides with the project’s acceptance announcement and is not used as a publication date; the October 6–9, 2026 conference and its Poster Session 5 listing are event details. The repository BibTeX still cites arXiv. This is unrelated to the creativity-evaluation paper also named CreBench. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### The Next Challenge for Agentic Cybersecurity: A Realistic, Contamination-Free Reverse Engineering Benchmark > Introduces SRE-Bench, with privately authored programs and protected binary variants, to study agent recovery of program semantics while reducing training-data contamination. - Authors: Jeremy Spence; Nicholas Assaderaghi; Feng Xiao; Jinhao Zhu; Nikil Ravi; Xiangyu Qi; Matthew Jagielski; Raluca Ada Popa; Eric Wallace; Guannan Wei; Yangruibo Ding; Zhuo Zhang - Venue: arXiv - Status: Preprint - Publication / posting date: August 11, 2026 - Date source: arXiv v1 submission; summary and author list use revised v2 - First arXiv submission: August 11, 2026 - arXiv: 2608.11469 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The revised study reports 19 programs, 262 binary instances, and 1,572 graded tasks. Binaries and task instances are not publicly released; access is through an evaluation service. Its contamination-control claim is the authors' methodology, not an independent guarantee. #### Why it fits this collection Adds realistic-scale and contamination-aware evaluation context for agent-assisted reverse engineering without mislabeling a private corpus as open data. #### Publication and review notes Use the 12-author v2 list, revised 2026-10-01, rather than the older eight-author v1 search snippets. No conference venue or own public code repository was verified. AgentRE-Bench GitHub links in the bibliography refer to another benchmark. #### Primary sources 1. 2. ### Humans vs. Machines: A Comparison With AI Agents in Software Reverse Engineering > Compares human and LLM-agent understanding and navigation on the same static reverse-engineering challenges, then studies how binary representations consume context windows. - Authors: Samuele Doria; Stefano De Rosa; Ruoyu Wang; Zion Leonahenahe Basque; Eleonora Losiouk; Simone Aonzo - Venue: arXiv - Status: Preprint - Publication / posting date: October 10, 2026 - Date source: arXiv v1 submission - First arXiv submission: October 10, 2026 - arXiv: 2610.14960 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2610.14960 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Understanding is graded on two compact challenges; the separate 4,000-binary study measures context capacity, not task-solving accuracy. The interface is static IDA/MCP without dynamic execution, and prior exposure to challenge source remains an acknowledged validity threat. #### Why it fits this collection Informs tool-interface design, selective retrieval, and persistent analysis state for reverse-engineering agents. #### Publication and review notes The original source review did not verify a conference venue or paper-specific public code link. On 2026-10-20, the official arXiv history still listed only v1. Although its abstract page labels the DOI as pending, DataCite reports the matching title and six authors as findable, registered on 2026-10-14. This is an identifier correction, not a new paper version or expanded experimental verification. #### Primary sources 1. 2. 3. ### Design2Code: Benchmarking Multimodal Code Generation for Automated Front-End Engineering > Evaluates reconstruction of frontend code from webpage screenshots using real-world reference pages, visual-element and layout metrics, and human assessment. - Authors: Chenglei Si; Yanzhe Zhang; Ryan Li; Zhengyuan Yang; Ruibo Liu; Diyi Yang - Venue: NAACL 2025 - Status: Conference paper - Publication / posting date: April 2025 - Date source: ACL proceedings publication month - First arXiv submission: March 5, 2024 - arXiv: 2403.03163 - Reviewed arXiv version: v3 - DOI: 10.18653/v1/2025.naacl-long.199 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations This is visual website reconstruction, not binary decompilation or recovery of backend behavior and interactive workflows. The main benchmark contains 484 webpages with placeholder images; code and data have separate licensing terms. #### Why it fits this collection Directly supports the collection's screenshot-to-website reconstruction scope while keeping visual fidelity separate from behavioral equivalence. #### Publication and review notes Use the final NAACL 2025 title and six-author list. arXiv v1 (2024-03-05) and the project page’s BibTeX use the earlier title “Design2Code: How Far Are We From Automating Front-End Engineering?” and list five authors without Ryan Li; v2 and the reviewed v3 match the final title and authors. SALT-NLP/Design2Code hosts the project website, whereas NoviScl/Design2Code is the verified research-code repository. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Interaction2Code: Benchmarking MLLM-based Interactive Webpage Code Generation from Interactive Prototyping > Benchmarks reconstruction of interactive webpages from screenshots before and after an interaction. The final study covers 127 webpages and 374 interactions, comparing rendered appearance, automated interaction checks, and human usability judgments. - Authors: Jingyu Xiao; Yuxuan Wan; Yintong Huo; Zixin Wang; Xinyi Xu; Wenxuan Wang; Zhiyao Xu; Yuhang Wang; Michael R. Lyu - Venue: ASE 2025 - Status: Conference paper - Publication / posting date: November 16, 2025 - Date source: Publisher-deposited Crossref print-publication date; this also matches the conference start date. - First arXiv submission: November 5, 2024 - arXiv: 2411.03292 - Reviewed arXiv version: v3 - DOI: 10.1109/ASE63991.2025.00028 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The inputs specify individual interaction transitions, not autonomous exploration of a complete site. Its tests do not establish long-workflow, server-side, or original-source equivalence; a detectable interaction is not necessarily usable. #### Why it fits this collection Extends screenshot reconstruction with concrete behavioral checks, helping distinguish visual similarity from usable interaction. #### Publication and review notes Uses the final nine-author title and author list. The 2026 arXiv v3 revision is separate from the 2025 conference publication; the earlier preprint used a different title, five authors, and a smaller benchmark. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### IWR-Bench: Can LVLMs reconstruct interactive webpage from a user interaction video? > Tests reconstruction of interactive webpages from user-interaction videos and supplied static assets. Its 113 tasks replay annotated action sequences to assess visual fidelity and functional behavior across observed page states. - Authors: Yang Chen; Minghao Liu; Yufan Shen; Yunwen Li; Tianyuan Huang; Xinyu Fang; Tianyu Zheng; Wenxuan Huang; Cheng Yang; Daocheng Fu; Jianbiao Mei; Rong Wu; Licheng Wen; Xuemeng Yang; Song Mao; Qunshu Lin; Zhi Yu; Yongliang Shen; Yu Qiao; Botian Shi - Venue: ICLR 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: Publication year stated by the official ICLR proceedings; no finer publication date is asserted. - First arXiv submission: September 29, 2025 - arXiv: 2509.24709 - Reviewed arXiv version: v3 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The required output is one HTML file; the paper explicitly instructs models to mock implied backend logic with static JavaScript data. Trajectory coverage and model-based judgments do not prove complete website or backend equivalence. #### Why it fits this collection Provides a direct behavioral reconstruction benchmark beyond static screenshots while making the frontend/backend boundary explicit. #### Publication and review notes Authors and order follow the published PDF: 20 authors. The proceedings landing page orders some middle authors differently; arXiv v3 and the project page list 21, additionally including Yunfei Zhao. The 2025 preprint date is separate from ICLR 2026 publication. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Dashboard2Code: Evaluating Multimodal Models on Reconstructing Interactive Dashboards > Evaluates agents that actively explore a running dashboard and reconstruct its appearance and interaction logic. DashboardMimic provides 180 Plotly+Dash examples, with code-semantic analysis and dynamic interaction tests for the generated implementations. - Authors: Tianhao Niu; Ziyu Han; Qiguang Chen; Shiqi Zhou; Baocai Shan; Hengjie Fang; Qingfu Zhu; Wanxiang Che - Venue: ACL 2026 - Status: Conference paper - Publication / posting date: July 2026 - Date source: ACL proceedings publication month. - First arXiv submission: July 6, 2026 - arXiv: 2607.04727 - Reviewed arXiv version: v1 - DOI: 10.18653/v1/2026.acl-long.1750 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Limited to Plotly+Dash dashboards, including model-augmented examples. Some settings expose DOM information and evaluation uses model judges. This is not a general backend-recovery benchmark. The linked dataset requires accepting access conditions and sharing contact information. #### Why it fits this collection Directly studies reconstruction through active observation, including callbacks and state dependencies rather than screenshot appearance alone. #### Publication and review notes The paper links the public code repository directly. Only the public dataset access notice was inspected; gated files were not accessed. Publication metadata follows the final ACL record. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### WebUIBench: A Comprehensive Benchmark for Evaluating Multimodal Large Language Models in WebUI-to-Code > Diagnoses webpage-to-code capability through visual perception, HTML programming, image-to-HTML understanding, and screenshot reconstruction tasks. It separates underlying skills using question-answer pairs derived from real websites. - Authors: Zhiyu Lin; Zhengda Zhou; Zhiyuan Zhao; Tianrui Wan; Yilun Ma; Junyu Gao; Xuelong Li - Venue: Findings of ACL 2025 - Status: Conference paper - Publication / posting date: July 2025 - Date source: ACL proceedings publication month. - First arXiv submission: June 9, 2025 - arXiv: 2506.07818 - Reviewed arXiv version: v1 - DOI: 10.18653/v1/2025.findings-acl.815 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations Primarily evaluates visual and HTML reconstruction skills. The paper includes a preliminary interaction study, not a full workflow or backend-equivalence benchmark. The official repository currently exposes README and images but not the evaluation scripts described in its instructions. #### Why it fits this collection Adds diagnostic evidence for screenshot-based website reconstruction, complementary to end-to-end Design2Code evaluation. #### Publication and review notes The published ACL record supplies the bibliography; repository citation fields remain placeholders and the dataset card displays a different arXiv identifier. The author-linked repository is retained as a project link, not advertised as a runnable code release. #### Primary sources 1. 2. 3. 4. 5. ### GameReplica: A Benchmark for Black-Box Visual Game Replication by Vision-Language Agents > Evaluates whether vision-language agents can infer hidden game rules through screenshots and active interaction, then build runnable single-file HTML replicas across 125 tasks from 25 web games, each with five difficulty levels. - Authors: Boyu Qiao; Zixin Tang; Xiaoshuai Hao; Wenbo Li - Venue: arXiv - Status: Preprint - Publication / posting date: September 15, 2026 - Date source: arXiv v1 submission history - First arXiv submission: September 15, 2026 - arXiv: 2609.22308 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2609.22308 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The tasks cover rule-driven web puzzles and board games, not native or commercial game reconstruction. Rule, implementation, and visual scores use LLM judges and do not prove behavioral equivalence. The official site provides demos; a benchmark-code repository was not verified. #### Why it fits this collection Directly evaluates active black-box specification recovery and executable game reconstruction, filling the bibliography’s game-replication gap. #### Publication and review notes The official project page marks the work as under review. arXiv reports the v1 submission on 2026-09-15 and displays its arXiv DOI as pending registration. The project link is a showcase with demos, not a verified release of the full evaluation framework. #### Primary sources 1. 2. 3. ### Reverse Engineering Mobile Application User Interfaces with REMAUI (T) > Reconstructs native Android UI code from screenshots or design bitmaps using OCR, computer vision, and layout heuristics; evaluates visual similarity and view hierarchies on 488 screenshots from over 100 Android and iOS applications. - Authors: Tuan Anh Nguyen; Christoph Csallner - Venue: ASE 2015 - Status: Conference paper - Publication / posting date: November 2015 - Date source: IEEE/Crossref proceedings publication month and author bibliography; conference dates 9–13 November 2015 - DOI: 10.1109/ASE.2015.32 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The output is Android UI code; iOS screenshots are inputs, not evidence of native iOS output. Original logic and backend behavior are not recovered, and multi-screen transitions were future work. OCR/layout heuristics can misidentify content. The linked REMAUI v2 repository has older dependencies and is not the exact verified 2015 artifact. #### Why it fits this collection Adds foundational native mobile-interface reconstruction research alongside the existing binary and website papers. #### Publication and review notes IEEE and Crossref include the technical-paper marker “(T)” in the title; the author PDF omits it. The January 2016 IEEE indexing date differs from the November 2015 publication. Pixel to App explicitly identifies the linked repository as REMAUI v2. #### Primary sources 1. 2. 3. 4. 5. 6. ### SPRITE: From Static Mockups to Engine-Ready Game UI > Transforms game-interface screenshots into editable engine assets through hierarchical YAML, visual grounding, asset extraction, and Unity UXML/USS synthesis, with evaluation on a curated game-UI benchmark and review by three senior UI/UX designers. - Authors: Yunshu Bai; RuiHao Li; Hao Zhang; Chien Her Lim; Ming Yan; Mengtian Li - Venue: CHI EA 2026 (poster/extended abstract) - Status: Conference paper - Publication / posting date: April 13, 2026 - Date source: Crossref publisher-deposited online publication date - First arXiv submission: March 18, 2026 - arXiv: 2604.18591 - Reviewed arXiv version: v1 - DOI: 10.1145/3772363.3798742 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The generated interactions cover basic hover, toggle, and click behavior. Complex temporal and drag-and-drop logic remain outside scope, and translucent overlap or ambiguous diegetic layouts can fail. This is game-UI prototyping, not complete gameplay reconstruction; the official page still labels code as coming soon. #### Why it fits this collection Adds game-specific screenshot-to-engine reconstruction while distinguishing visual and structural recovery from full game behavior. #### Publication and review notes Published as a CHI 2026 poster/extended abstract. The publisher title has “SPRITE:From” and “GameUI”; arXiv and the project page normalize these spaces. arXiv/Hugging Face report a March 18 first submission despite the 2604 identifier; the April 13 publication date is independently verified in Crossref. No implementation link is verified. #### Primary sources 1. 2. 3. 4. ### RevengeBench: Reverse Engineering Code-Space Policies from Behavioral Experiments > Tests whether agents can recover executable decision policies from behavioral traces and self-designed opponent probes, using 75 synthetic policies across five game arenas and measuring held-out action agreement and downstream competitive value. - Authors: Babak Rahmani; Sebastian Dziadzio; Joschka Strüber; Sergio Hernández-Gutiérrez; Matthias Bethge - Venue: arXiv - Status: Preprint - Publication / posting date: June 24, 2026 - Date source: arXiv v1 submission history; the non-archival AIWILD workshop acceptance does not create a separate publication date. - First arXiv submission: June 24, 2026 - arXiv: 2606.26094 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2606.26094 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-16 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The targets are fixed synthetic policies, not full games or adaptive adversaries. Agreement on finitely evaluated states does not uniquely identify source code, and some arenas have substantial variance. The public package omits some paper-only plotting and ablation suites; reproduction also needs CodeClash, a container runtime, and model access. #### Why it fits this collection Provides a game-domain benchmark for agent-assisted behavioral reverse engineering and active experimental design. #### Publication and review notes Accepted to the non-archival Second Workshop on Agents in the Wild (AIWILD) at ICML 2026: its OpenReview record was published on 2026-05-23 and is linked from the ICML page for the July 11, 2026 workshop. The workshop call states a non-archival policy, so this entry keeps the arXiv preprint and first-submission date. The repository and an author’s publication page also report the acceptance. The artifact is official. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### pix2code: Generating Code from a Graphical User Interface Screenshot > Learns screenshot-to-DSL generation for native Android XML, iOS Storyboards and web HTML/CSS interfaces, then compiles the DSL into platform UI code. - Authors: Tony Beltramelli - Venue: EICS 2018 - Status: Conference paper - Publication / posting date: June 19, 2018 - Date source: ACM-deposited Crossref proceedings metadata: online and print publication on 19 June 2018; arXiv first submitted 22 May 2017. - First arXiv submission: May 22, 2017 - arXiv: 1705.07962 - Reviewed arXiv version: v2 - DOI: 10.1145/3220134.3220135 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses synthetic screenshot/code pairs: 1,500 training and 250 test instances per platform. Reported accuracy concerns DSL tokens, not complete apps or behavior. Text labels are ignored; platform datasets train separate models using the same architecture. The task covers layout, components and relationships, not application logic or backend recovery. The repository describes an educational research prototype; its older dependencies were not runtime-tested. #### Why it fits this collection Adds an early learned screenshot-to-code approach spanning native mobile and web UI reconstruction. #### Publication and review notes The published EICS 2018 proceedings article follows the 2017 arXiv release; this record reviews arXiv v2 dated 19 September 2017. The linked author repository is the implementation identified by that version, reviewed at a current pinned commit. It contains compiler code and split dataset archives; the actual LICENSE declares Apache 2.0, while the README license badge has a stale filename. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Machine Learning-Based Prototyping of Graphical User Interfaces for Mobile Apps > ReDraw turns screenshots or design mock-ups into native Android GUI prototypes by detecting components, classifying widget types with a CNN, and assembling a plausible view hierarchy with a data-driven nearest-neighbor method. - Authors: Kevin Moran; Carlos Bernal-Cárdenas; Michael Curcio; Richard Bonett; Denys Poshyvanyk - Venue: IEEE Transactions on Software Engineering - Status: Journal article - Publication / posting date: February 2020 - Date source: Publisher-deposited print issue date in Crossref (2020-02-01), represented at month precision. - First arXiv submission: February 7, 2018 - arXiv: 1802.02312 - Reviewed arXiv version: v2 - DOI: 10.1109/TSE.2018.2844788 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The implementation covers 15 Android component classes and one screen at a time; multiple screens require manual combination, and hierarchy construction is tied to the mined screen size. Evaluation concerns appearance and view hierarchy, not recovery of original app logic or backends. Screenshots and reconstructed mock-ups served as proxies for real design artifacts. #### Why it fits this collection Adds a data-driven foundation for recovering native widget types and plausible structure from pixels, complementing the existing REMAUI entry. #### Publication and review notes IEEE TSE 46(2), pages 196–221, February 2020. The author-hosted accepted manuscript and arXiv v2 are dated 2018; ESEC/FSE 2018 was a journal-first presentation, not the journal publication. Crossref creation on 2018-06-07 is a deposit date, not an independently verified online publication date. The author project page describes a rewritten implementation as forthcoming in Winter 2020; no original code repository was verified. The separately archived ReDraw dataset is dated 2019-01-02 (Zenodo 2530277). #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### DeclarUI: Bridging Design and Development with Automated Declarative UI Code Generation > Combines visual component extraction, multimodal models, page-transition graphs and iterative checks to reconstruct multi-page mobile UI code from designs or screenshots, evaluated with React Native, Flutter and ArkUI. - Authors: Ting Zhou; Yanjie Zhao; Xinyi Hou; Xiaoyu Sun; Kai Chen; Haoyu Wang - Venue: Proceedings of the ACM on Software Engineering (FSE 2025) - Status: Journal article - Publication / posting date: June 19, 2025 - Date source: ACM-deposited Crossref metadata gives 19 June 2025 for online and print publication; the author PDF labels the issue July 2025. - First arXiv submission: September 18, 2024 - arXiv: 2409.11667 - Reviewed arXiv version: v1 - DOI: 10.1145/3715726 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations People review and correct the inferred navigation graph. Evaluation covers 50 five-page UI sets; transition coverage and compilation do not establish full business-logic or backend recovery. Framework results vary, and visual metrics imperfectly reflect perceived fidelity. Public scripts and data are available, but no project-level license was found at the reviewed commit. #### Why it fits this collection Extends app-interface reconstruction from isolated screens to mobile UI projects with explicit navigation. #### Publication and review notes This is a PACMSE journal article, volume 2, FSE issue, pages 219–241 (article FSE011), not an unpublished preprint. Its published title adds DeclarUI to the 2024 arXiv title. The author-hosted 23-page article is the main reviewed text; arXiv v1 was also checked. The linked repository is the paper-named artifact, reviewed at a pinned commit. #### Primary sources 1. 2. 3. 4. ### ProgramBench: Can Language Models Rebuild Programs From Scratch? > Evaluates black-box program reconstruction across 200 tasks: agents query an executable and read its documentation, then independently implement a codebase whose behavior is checked by generated tests. - Authors: John Yang; Kilian Lieret; Jeffrey Ma; Parth Thakkar; Dmitrii Pedchenko; Sten Sootla; Emily McMilin; Pengcheng Yin; Rui Hou; Gabriel Synnaeve; Diyi Yang; Ofir Press - Venue: NeurIPS 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: The official NeurIPS 2026 poster listing verifies conference acceptance; no proceedings publication date is asserted. - First arXiv submission: May 5, 2026 - arXiv: 2605.03546 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2605.03546 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Binary inspection, decompilation, and internet access are forbidden during inference. Passing finite tests does not prove complete behavioral equivalence or recovery of the original source. Later live-leaderboard runs are separate from the reviewed arXiv results. #### Why it fits this collection Provides an executable benchmark for recovering software behavior through experiments, complementing benchmarks that permit static binary analysis. #### Publication and review notes NeurIPS lists a December 2026 poster; this records acceptance, not proceedings publication. The July 2026 DL4C oral was a separate non-archival workshop appearance. The DOI identifies the arXiv preprint. The pinned harness is version 1.2.5 under MIT; its generated-test dataset preserves per-task attribution and upstream license terms, including copyleft obligations for derivative portions. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ### Decompile-Bench: Million-Scale Binary-Source Function Pairs for Real-World Binary Decompilation > Introduces two million C/C++ binary-source function pairs using a Compile-Trace-Filter pipeline, with an evaluation suite spanning translated HumanEval/MBPP tasks and recent GitHub functions. - Authors: Hanzhuo Tan; Xiaolong Tian; Hanrui Qi; Jiaming Liu; Zuchen Gao; Siyi Wang; Qi Luo; Jing Li; Yuqun Zhang - Venue: NeurIPS 2025 Datasets and Benchmarks - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: Publication year in the official NeurIPS proceedings and publisher-deposited Crossref metadata; no finer publication date is asserted. - First arXiv submission: May 19, 2025 - arXiv: 2505.12668 - Reviewed arXiv version: v2 - DOI: 10.52202/085713-0177 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations This is function-level decompilation. Re-execution tests cover HumanEval/MBPP; GitHub2025 provides no unit tests. Inlining can prevent one-to-one source correspondence, and the fine-tuning study uses 10% of the corpus. These results do not establish whole-program recovery. #### Why it fits this collection Adds a training corpus and evaluation artifact for LLM decompilation, distinct from Gao et al.’s existing DecompileBench entry. #### Publication and review notes Author order follows the final PDF, which puts Zuchen Gao before Siyi Wang; the proceedings landing page and Crossref reverse them. arXiv v2 was revised on 2025-10-19. The artifact is the decompile-bench subdirectory of the existing LLM4Decompile repository. Code has an MIT license; the dataset declares CC0-1.0, while model weights have separate terms. These declarations do not replace source-project license review. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### Fuzzware: Using Precise MMIO Modeling for Effective Firmware Fuzzing > Rehosts monolithic ARM Cortex-M firmware for fuzzing, using locally scoped symbolic execution to model memory-mapped I/O accesses and focus input mutations on values relevant to firmware logic. - Authors: Tobias Scharnowski; Nils Bars; Moritz Schloegel; Eric Gustafson; Marius Muench; Giovanni Vigna; Christopher Kruegel; Thorsten Holz; Ali Abbasi - Venue: USENIX Security 2022 - Status: Conference paper - Publication / posting date: August 2022 - Date source: Publication month in the official USENIX proceedings citation; no exact publication day is asserted. - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The Cortex-M3/M4 artifact requires memory-map configuration and does not automatically model DMA. Abstracting hardware can produce crashes that are impossible on the physical device. This is an analysis environment, not original-source recovery or faithful full-device reconstruction. #### Why it fits this collection Shows how firmware logic can be exercised without its original hardware by reconstructing enough of the execution environment for dynamic analysis. #### Publication and review notes The official proceedings give pages 1239–1256 and nine authors. No paper DOI or arXiv identifier was verified. Zenodo DOI 10.5281/zenodo.6499215 identifies the software artifact, not this paper. The artifact appendix names the sec22-ae-accepted release and declares Apache-2.0 for code and data; third-party components retain their own terms. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### FirmAE: Towards Large-Scale Emulation of IoT Firmware for Dynamic Analysis > Extends Firmadyne with empirically derived interventions for boot, networking, NVRAM, kernel behavior, and other runtime failures, enabling Linux router and IP-camera firmware web services to run for dynamic analysis. - Authors: Mingeun Kim; Dongkwan Kim; Eunsoo Kim; Suryeon Kim; Yeongjin Jang; Yongdae Kim - Venue: ACSAC 2020 - Status: Conference paper - Publication / posting date: December 7, 2020 - Date source: ACM-deposited Crossref print-publication date; the online-publication date is recorded separately in metadata notes. - DOI: 10.1145/3427228.3427294 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Arbitration deliberately changes execution and targets functioning web interfaces, not identical physical-device behavior. The evaluation covers ARM little-endian and MIPS little-/big-endian firmware from routers and IP cameras; heuristics may fail on unseen devices or configurations. It reuses firmware binaries rather than recovering their source. #### Why it fits this collection Provides a concrete firmware-rehosting method and evaluation for restoring analyzable network-service behavior when exact hardware emulation is unavailable. #### Publication and review notes ACM metadata records print publication on 2020-12-07 and online publication on 2020-12-08, pages 733–745. The six-author paper is separate from later repository updates. The pinned artifact README documents Ubuntu 20.04 and privileged run modes. Its MIT license does not license vendor firmware images or all dependencies. #### Primary sources 1. 2. 3. 4. 5. 6. ### NEMESYS: Network Message Syntax Reverse Engineering by Analysis of the Intrinsic Structure of Individual Messages > Infers approximate field boundaries within individual binary-protocol messages from changes in bit congruence, and introduces Format Match Score to compare inferred segmentation with known protocol dissectors. - Authors: Stephan Kleber; Henning Kopp; Frank Kargl - Venue: 12th USENIX Workshop on Offensive Technologies (WOOT 18) - Status: Conference paper - Publication / posting date: August 2018 - Date source: The official USENIX BibTeX entry identifies August 2018 for the WOOT 18 workshop publication. - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Requires plaintext payloads. Evaluation covers DNS, DHCP and NTP with protocol-tuned parameters. Single-byte fields are not inferred; zero-filled fields, character sequences and pseudo-random values can cause errors. FMS needs known field boundaries for validation. The output is approximate segmentation, not field semantics, a state machine or complete application/device behavior. #### Why it fits this collection Provides a foundational method for reconstructing wire-message structure from observed traffic. #### Publication and review notes The official USENIX citation verifies this workshop paper; no DOI or arXiv identifier was verified. The linked author repository now integrates NEMESYS with later NEMETYL and 2022 methods. Its README identifies it as experimental and its LICENSE declares MIT. #### Primary sources 1. 2. 3. 4. 5. ### NetPlier: Probabilistic Network Protocol Reverse Engineering from Message Traces > Uses multiple sequence alignment and probabilistic keyword-field inference to cluster network messages by type, evaluated across ten protocols with downstream format and state-machine analysis. - Authors: Yapeng Ye; Zhuo Zhang; Fei Wang; Xiangyu Zhang; Dongyan Xu - Venue: NDSS 2021 - Status: Conference paper - Publication / posting date: 2021 (exact date not verified) - Date source: Publisher-deposited Crossref metadata supplies publication year 2021; the publisher PDF separately identifies the 21–25 February 2021 symposium. - DOI: 10.14722/ndss.2021.24531 - Sources reviewed: 2026-10-16 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Requires unencrypted traces and cannot recover unseen message types. Larger alignments, sub-byte keywords and one-way traffic can reduce accuracy. Format/FSM inference is downstream evaluation rather than the main contribution; state semantics in a case study were manually annotated. These models do not establish complete application/device reconstruction. #### Why it fits this collection Connects observed application/device traffic to message-type models needed for protocol reconstruction. #### Publication and review notes The publisher paper cites netplier-tool/NetPlier, which now redirects to yapengye/NetPlier. The pinned GPLv3 artifact implements keyword inference and clustering evaluation; its core retains TODOs for iteration and format inference. #### Primary sources 1. 2. 3. 4. 5. 6. ### ProgramDistill: From Interactive Web Apps to Verifiable Reference-Guided SWE Tasks > Evaluates recovery of web-app behavior from a live reference with hidden source. It provides 4,063 feature-restoration tasks across 26 applications and a separate 12-application reconstruction setting, scored by replaying dependent browser workflows. - Authors: Jeonghye Kim; Minseon Kim; Young Jin Kim; Matheus Pereira; Marc-Alexandre Côté; Alessandro Sordoni; Xingdi Yuan; Zhengyan Shi - Venue: arXiv - Status: Preprint - Publication / posting date: September 16, 2026 - Date source: arXiv v1 submission history; the earlier author blog date is separate. - First arXiv submission: September 16, 2026 - arXiv: 2609.18805 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2609.18805 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Tests cover finite, model-mined behaviors in self-contained apps, including SaaS clones. Persistence failures can be detected through replayed workflows, but passing does not establish all backend or database invariants. Evaluated agents receive structured browser observations without screenshots; visual fidelity is not measured. Public verifiers and reference solutions are not a contamination-resistant test set. #### Why it fits this collection Directly studies reference-guided behavioral reconstruction beyond screenshot-to-HTML, including dependent state changes and fresh verification of submitted implementations. #### Publication and review notes The DOI resolves and DataCite records registration on 2026-09-17, despite arXiv’s stale pending banner. Separately, the paper was accepted to the non-archival Workshop on Interpreting Agent Behavior (IAB) at NeurIPS 2026, scheduled for December 12, 2026; its OpenReview record was published on 2026-10-04. That record and the workshop listing put Xingdi Yuan before Alessandro Sordoni; the authors here follow arXiv v1. The public release contains executable benchmark packages, not the mining, task-generation or orchestration pipeline. ProgramDistill-authored artifacts declare MIT; included applications and assets retain upstream terms. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### Vision2Web: A Hierarchical Benchmark for Visual Website Development with Agent Verification > Benchmarks website development from visual prototypes and written requirements across 100 static-page, 66 interactive-frontend and 27 full-stack tasks, combining workflow-based functional checks with model-judged visual comparison. - Authors: Zehai He; Wenyi Hong; Zhen Yang; Ziyang Pan; Mingdao Liu; Xiaotao Gu; Jie Tang - Venue: ICML 2026 - Status: Conference paper - Publication / posting date: September 29, 2026 - Date source: Publication date stated for PMLR volume 306; the July 6–11 conference dates are not used as the publication date. - First arXiv submission: March 27, 2026 - arXiv: 2603.26648 - Reviewed arXiv version: v3 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The full-stack tier is specification-driven, not reconstruction solely by exploring a live website. Workflows test state management and CRUD outcomes, but finite agent judgments do not establish exact backend or durable-database equivalence. The current public evaluator maintains a browser session within each workflow and permits local business-API checks; this is not a universal persistence proof. #### Why it fits this collection A useful comparison for evaluating interactive and stateful website reconstruction, while separating written-specification development from behavior-only inference. #### Publication and review notes The final PMLR paper has seven authors and pages 41393–41415; arXiv v3 is dated 2026-07-20. Current artifact evaluation differs from the paper configuration. Licensing signals conflict: README text says CC-BY-NC-SA-4.0, Hugging Face metadata says Apache-2.0, the project page says CC BY-SA 4.0, and setup.py lists MIT while the repository has no LICENSE file. No uniform artifact license is asserted. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### From UI Design Image to GUI Skeleton: A Neural Machine Translator to Bootstrap Mobile GUI Implementation > UI2code translates a mobile UI image into an Android component hierarchy and layout skeleton using a neural encoder-decoder. The paper evaluates structural prediction and a small developer study of implementing layouts from generated skeletons. - Authors: Chunyang Chen; Ting Su; Guozhu Meng; Zhenchang Xing; Yang Liu - Venue: ICSE 2018 - Status: Conference paper - Publication / posting date: May 27, 2018 - Date source: Publisher-deposited Crossref publication date for the ICSE proceedings article. - DOI: 10.1145/3180155.3180240 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The output covers component types and hierarchy from a single image; detailed styling and text require developer work. Structural token accuracy and an eight-participant study on five screenshots do not establish complete visual fidelity, navigation, app logic or backend recovery. The main split is screenshot-based; a separate evaluation on 1,208 images from 20 unseen apps provides limited generalization evidence. #### Why it fits this collection A native-app reconstruction foundation that explicitly generates and evaluates GUI structure from visual observations, beyond locating interface elements. #### Publication and review notes The author-hosted PDF prints 10.1145/3180155.3180222, which identifies another paper; the DOI here follows publisher-deposited metadata for this title, pages 665–676. The artifact README lists 29,887 screenshots, while the paper reports 185,277 image/skeleton pairs. The pinned legacy Torch/Lua repository has no license file. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Tycho: Active Abstraction with Programmatic World Models for ARC-AGI-3 > Tycho constructs editable Python models of game state, transitions, rendering and outcomes from action/observation histories in unfamiliar ARC-AGI-3 games. It checks model predictions against recorded transitions and can use, repair or bypass these models during planning. - Authors: Jens Lehmann; Andrei Aioanei; Sahar Vahdati - Venue: arXiv - Status: Preprint - Publication / posting date: July 30, 2026 - Date source: First public arXiv submission date; version v1 was reviewed. - First arXiv submission: July 30, 2026 - arXiv: 2607.28287 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2607.28287 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses one stochastic run per configuration on 25 public games and 183 levels; five games informed harness development. Models may abstain on cells or accept bounded rendering variants. Transition replay and game scores do not establish complete engine reconstruction, correct objectives, unseen-state fidelity, unseen-game generalization or run-to-run reliability; the agent can bypass modeling. #### Why it fits this collection Studies executable reconstruction of observed game dynamics and checks model fidelity separately from task success, providing a bounded behavioral reconstruction case. #### Publication and review notes The arXiv posting date is July 30; the manuscript header and software release use July 29. DataCite confirms the arXiv DOI is registered and findable. The pinned author artifact is Apache-2.0 and includes source, prompts, paper configurations and compact evaluation evidence; ARC environment terms are separate. Python >=3.12, model/ARC access and a Docker or Finch sandbox are documented requirements. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### WorldCoder, a Model-Based LLM Agent: Building World Models by Writing Code and Interacting with the Environment > WorldCoder learns executable Python transition and reward models from environment interactions and natural-language goals. It refines code against recorded experiences and an optimistic planning constraint, studying transfer and task solving in Sokoban, MiniGrid and ALFWorld. - Authors: Hao Tang; Darren Key; Kevin Ellis - Venue: NeurIPS 2024 - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: The NeurIPS proceedings and publisher-deposited Crossref record identify 2024; no publication month or day is asserted. - First arXiv submission: February 19, 2024 - arXiv: 2402.12275 - DOI: 10.52202/079017-2243 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Assumes deterministic dynamics and symbolic, discrete states rather than recovering a game from arbitrary pixels or binaries. Consistency with observed transitions and successful planning do not establish complete engine equivalence or correctness on every unseen state. Evaluation concerns bounded environment models and planning, not original source or asset recovery. #### Why it fits this collection A foundation for agent-assisted reconstruction of observed game behavior as executable code, with explicit consistency checks instead of a visual-only similarity claim. #### Publication and review notes The final NeurIPS paper, pages 70148–70212. The MIT author repository is a partial experiment artifact: its pinned environment registry exposes MiniGrid only, despite the README’s Sokoban example and broader paper experiments. The README warns about NumPy 2 incompatibility and older Gymnasium/MiniGrid dependencies. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### UI2App: Benchmarking Visual Interaction Inference in Executable Web Application Generation > UI2App evaluates runnable React/TypeScript applications generated from 600 screenshots across 95 web applications. It separates build executability, visual fidelity and screenshot-implied interaction behavior, including cross-route state, using a reference interaction taxonomy and public evaluation pipeline. - Authors: Grace Man Chen; Litao Guo; Yifan Wu; Yiyu Chen; Yenchi Tseng; Sicheng Liu; Yuyu Luo; Ying-Cong Chen - Venue: arXiv - Status: Preprint - Publication / posting date: July 7, 2026 - Date source: First arXiv submission date. The reviewed v2 was submitted on 2026-10-04; it is not a separately verified conference publication. - First arXiv submission: July 7, 2026 - arXiv: 2607.06306 - Reviewed arXiv version: v2 - DOI: 10.48550/arXiv.2607.06306 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Static screenshots underdetermine behavior; the rubric accepts multiple valid implementations rather than proving equivalence to the original application or backend. Auto IIS judges generated source and screenshots without tool execution; human runtime validation covers a 45-application subset. Cross-route state is not necessarily durable persistence across reloads or sessions. Main results use one generation per application-model pair, with repeated runs on a subset. #### Why it fits this collection Tests reconstruction from observed web interfaces while distinguishing visual copying from inferred interaction logic; its explicit behavior ambiguity makes it a bounded complement to trace-guided reconstruction benchmarks. #### Publication and review notes Use v2’s 95 applications and 600 screenshots, not v1’s 45/327 counts. The arXiv DOI is registered. Public code is MIT; the dataset and reference annotations are CC BY 4.0, with upstream code and third-party asset rights separate. The documented pipeline needs Python 3.10+, Node/npm, pnpm, Chromium, Tesseract and model access; Auto IIS additionally needs an authenticated Codex CLI. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### JsDeObsBench: Measuring and Benchmarking LLMs for JavaScript Deobfuscation > Builds an execution-verifiable JavaScript deobfuscation benchmark by applying seven JavaScript-Obfuscator transformations to Project CodeNet programs with test cases, then scores LLM and tool outputs for syntax, execution, code simplification and similarity to the original code. - Authors: Guoqiang Chen; Xin Jin; Zhiqiang Lin - Venue: ACM CCS 2025 - Status: Conference paper - Publication / posting date: November 19, 2025 - Date source: ACM-deposited Crossref print-publication date; the October 13–17 CCS 2025 conference week is not used as the publication date. - First arXiv submission: June 25, 2025 - arXiv: 2506.20170 - Reviewed arXiv version: v1 - DOI: 10.1145/3719027.3744871 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations On average, LLM outputs passed execution checks 60.93% of the time, against 83% for the two existing deobfuscator baselines. All samples come from a single obfuscator applied to moderate-length competitive-programming solutions. The 4,515 obfuscated malware samples have no test cases and are compared only through behavior traces. #### Why it fits this collection Adds a measurable, execution-checked benchmark for LLM-assisted JavaScript deobfuscation, a common step in recovering website behavior from shipped scripts. #### Publication and review notes ACM-deposited Crossref metadata records print publication on 2025-11-19 and online publication on 2025-11-22, pages 36–50. The reviewed text is arXiv v1, which carries the CCS 2025 header. The paper links the code repository and the jsdeobf.github.io leaderboard. At the pinned commit the repository contains the CodeNet-derived obfuscated datasets, evaluators and scripts, but no malware samples or license file. #### Primary sources 1. 2. 3. 4. 5. 6. ### CASCADE: LLM-powered JavaScript Deobfuscator at Google > Uses Gemini to locate the prelude functions that Obfuscator.IO inserts for string obfuscation, then applies constant-propagation and inlining passes in the JSIR compiler IR to restore string literals and API names deterministically. - Authors: Shan Jiang; Pranoy Kovuri; David Tao; Zhixun Tan - Venue: ICSE-SEIP 2026 - Status: Conference paper - Publication / posting date: April 12, 2026 - Date source: ACM-deposited Crossref print-publication date, which matches the ICSE 2026 start date; the online-publication date is recorded separately in metadata notes. - First arXiv submission: July 23, 2025 - arXiv: 2507.17691 - Reviewed arXiv version: v2 - DOI: 10.1145/3786583.3786873 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The method addresses Obfuscator.IO string obfuscation; control-flow flattening, other obfuscators and an agent-based design are future work. Evaluation obfuscates 3,000 programs from the ETH 150k JavaScript dataset with four Obfuscator.IO presets and measures prelude detection, recovered literals and run time, not functional equivalence. Production deployment and scan volume are author-reported, and production pre-filtering uses a proprietary YARA rule. #### Why it fits this collection Shows how an LLM can be confined to locating obfuscation helpers while a compiler IR performs the rewrites, a practical pattern for website deobfuscation. #### Publication and review notes ACM-deposited Crossref metadata records print publication on 2026-04-12 and online publication on 2026-07-11, pages 292–302. The publisher title writes 'LLM-powered'; the arXiv record capitalizes 'Powered'. The reviewed text is arXiv v2, which carries the ICSE-SEIP '26 header. The paper says its prompt templates and JSIR are open-sourced at google/jsir. At the pinned commit that Apache-2.0 repository contains JSIR with prelude-extraction and dynamic constant-propagation code, but no prompt-template, Gemini pipeline or evaluation-set files were found; the paper prints its prelude-detection prompt in Figure 5 and lists an open-source CASCADE release as future work. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Divide-and-Conquer: Generating UI Code from Screenshots > Recursively divides a webpage screenshot along visual separation lines, has a multimodal model generate HTML/CSS for each leaf segment, and assembles child code upward into the full page; evaluated with GPT-4o, Gemini and Claude models and a small developer study. - Authors: Yuxuan Wan; Chaozheng Wang; Yi Dong; Wenxuan Wang; Shuqing Li; Yintong Huo; Michael Lyu - Venue: Proceedings of the ACM on Software Engineering (FSE 2025) - Status: Journal article - Publication / posting date: June 19, 2025 - Date source: ACM-deposited Crossref metadata gives 19 June 2025 for online and print publication; the article text labels the issue July 2025. - First arXiv submission: June 24, 2024 - arXiv: 2406.16386 - Reviewed arXiv version: v3 - DOI: 10.1145/3729364 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations It reconstructs static visual layout as HTML/CSS, not interaction, JavaScript behavior or backend logic. Test pages are self-contained snapshots with images replaced by placeholders; the main evaluation samples 111 of 348 top-ranked sites, adds 80 harder GitHub Pages pages, and the usefulness study has four participants. Segmentation uses manually set thresholds, and assembly can still misarrange elements. #### Why it fits this collection A segment-wise method for rebuilding website layout from screenshots, complementing the benchmark-oriented website papers. #### Publication and review notes This is a PACMSE journal article, volume 2, FSE issue, pages 2099–2122 (article FSE094). Its published title replaces the arXiv title 'Automatically Generating UI Code from Screenshot: A Divide-and-Conquer-Based Approach'. Author names follow the article text, which prints 'Michael Lyu', as does Crossref; the arXiv record lists 'Michael R. Lyu'. The ACM Digital Library copy could not be retrieved during review; the reviewed text is the 24-page ACM-format arXiv v3. The paper-linked repository has no license file at the pinned commit; the full dataset is hosted separately on Hugging Face without a dataset card. #### Primary sources 1. 2. 3. 4. 5. ### ScreenCoder: Advancing Visual-to-Code Generation for Front-End Automation via Modular Multimodal Agents > Splits screenshot-to-code generation among grounding, planning and generation agents that label UI regions, build a hierarchical layout tree and write HTML/CSS. The pipeline also produces the Screen-10K training pairs used for supervised and reinforcement fine-tuning, and the paper introduces the 1,000-page ScreenBench. - Authors: Yilei Jiang; Yaozhi Zheng; Yuxuan Wan; Jiaming Han; Qunzhong Wang; Michael R. Lyu; Xiangyu Yue - Venue: EMNLP 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: The official EMNLP 2026 detailed program lists a main-conference poster, verifying acceptance; no proceedings publication date is asserted. - First arXiv submission: July 30, 2025 - arXiv: 2507.22827 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Output is static HTML/CSS layout; interaction, JavaScript behavior and backend logic are not reconstructed. Results are visual-similarity scores (CLIP and OCR-matched text blocks) on ScreenBench and Design2Code, which do not establish code-level or functional equivalence. The released pipeline calls a hosted model API, Doubao by default. The reviewed text is arXiv v2; the accepted EMNLP version may differ. #### Why it fits this collection Represents staged, agent-based screenshot-to-code reconstruction for websites, separating visual grounding and layout planning from code synthesis. #### Publication and review notes The official EMNLP 2026 detailed program lists paper 7281-MAIN as a poster on 2026-10-26; this records acceptance, not proceedings publication. The arXiv v2 comment 'ScreenCoder-v2' is a version label, not a venue, and an earlier ICLR 2026 submission was withdrawn. The abstract-linked repository is Apache-2.0 at the pinned commit and bundles UIED, LLaMA-Factory and VLM-R1 code with their own license files. ScreenBench is published on Hugging Face under Apache-2.0. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### SK2Decompile: LLM-based Two-Phase Binary Decompilation from Skeleton to Skin > Splits LLM decompilation into two phases: a Structure Recovery model turns decompiler pseudocode into an identifier-free IR that keeps control flow and data structures, trained with compiler-based RL rewards, and an Identifier Naming model then restores names under a semantic-similarity reward. The authors report a 21.6% average re-executability gain over GPT-5-mini on HumanEval and a 29.4% average R2I improvement over Idioms on GitHub2025. - Authors: Hanzhuo Tan; Weihao Li; Xiaolong Tian; Siyi Wang; Jiaming Liu; Jing Li; Yuqun Zhang - Venue: ICLR 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: Publication year stated by the official ICLR proceedings; no finer publication date is asserted. - First arXiv submission: September 26, 2025 - arXiv: 2509.22114 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Training and main evaluation use function-level C compiled for x86-64 Linux with GCC and Clang at -O0 to -O3, with IDA Pro pseudocode as model input. Re-executability is measured only on HumanEval and MBPP; ExeBench and GitHub2025 use R2I readability and a GPT-5-mini judge. Appendix experiments extend to BringUpBench projects, macOS arm64 and Windows MSVC builds, and Obfuscator-LLVM, but the models are trained on C only and the paper expects them to degrade on features without C equivalents, such as C++ templates. #### Why it fits this collection Adds a recent LLM decompiler that separates structural correctness from identifier recovery, extending the LLM4Decompile line of work. #### Publication and review notes Authors follow the proceedings PDF; the proceedings landing page writes the first author's given name as 'hanzhuo'. OpenReview lists the paper as an ICLR 2026 Poster. The September 2025 arXiv v1 is separate from ICLR 2026 publication, and the 32-page proceedings version adds appendix experiments. Code is the sk2decompile directory of the LLM4Decompile repository. License signals differ by source: the repository LICENSE is MIT, both 6.7B model cards are tagged MIT, and the repository also carries a DeepSeek LICENSE-MODEL; both models are initialized from LLM4Decompile-6.7B. No single license is asserted. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### Automatic Wireless Protocol Reverse Engineering > Infers message formats of proprietary wireless protocols from demodulated physical-layer captures: it aligns messages by preamble and sync word, then uses RSSI and dedicated engines to label length, address, sequence-number and checksum fields, optionally using known addresses or field positions. - Authors: Johannes Pohl; Andreas Noack - Venue: 13th USENIX Workshop on Offensive Technologies (WOOT 19) - Status: Conference paper - Publication / posting date: August 2019 - Date source: The official USENIX BibTeX entry identifies August 2019 for the WOOT 19 workshop publication. - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Only message formats are inferred: preamble, sync, length, address, sequence number and checksum. State-machine inference and payload fields, such as an on/off bit, are out of scope. The method assumes length-efficient binary messages with one preamble and sync word each. Accuracy is measured on 8 generated protocols; 3 real smart-home captures (EnOcean, Homematic BidCoS and an eQ-3 protocol used by RWE Smarthome) serve for performance tests, which the authors call a limited test set. #### Why it fits this collection Extends protocol inference from network-message traces to physical-layer wireless captures, with the field-labeling method implemented in a public analysis tool. #### Publication and review notes The official USENIX page, its BibTeX entry and the final PDF verify this workshop paper; no DOI or arXiv identifier was verified. The final PDF uses the WOOT 19 underscore path, and the conference/woot19 form returns 404. The PDF carries an Artifact Evaluated 'Passed' badge. The paper names Universal Radio Hacker as its implementation, and the URH README links its automatic field inference to this paper. At the pinned commit the GPL-3.0 repository is archived, its inference code is in src/urh/awre, and the latest release is v2.10.0. URH's WOOT 18 tool paper is a separate publication. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Generating Code World Models with Large Language Models Guided by Monte Carlo Tree Search > GIF-MCTS generates executable Python transition and reward models from natural-language environment descriptions and offline state-transition trajectories, using prediction feedback to generate, improve and repair code. CWMB evaluates 18 reinforcement-learning environments and downstream planning; a separate experiment uses a simplified Read to Fight Monsters grid world. - Authors: Nicola Dainese; Matteo Merler; Minttu Alakuijala; Pekka Marttinen - Venue: NeurIPS 2024 - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: The final NeurIPS proceedings and publisher-deposited Crossref record identify 2024. No publication month or day is asserted; conference event dates are not substituted for publication dates. - First arXiv submission: May 24, 2024 - arXiv: 2405.15383 - DOI: 10.52202/079017-1933 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Assumes deterministic, fully observable dynamics and sufficiently detailed descriptions; this is not recovery from pixels or binaries alone. Accuracy uses the replay transitions supplied during synthesis, alongside planning-return evaluation, rather than proving correctness on all unseen states or full-engine equivalence. RTFM fixes the manual across episodes and keeps monsters stationary. CWMB also includes non-game control and physics tasks; some planning returns are unavailable and complex continuous-state models remain difficult. #### Why it fits this collection Shows how documented rules and observed transitions in game-like environments can become executable behavior models with test feedback. It complements game reconstruction without claiming recovery of original engines, graphics or assets. #### Publication and review notes Reviewed the final proceedings paper, pages 60429–60474. Its WorldCoder baseline follows the first arXiv version, not later revisions. The Apache-2.0 repository provides prompts, replay-buffer files and evaluation scripts; bundled RTFM carries CC BY-NC 4.0. The pinned evaluator balances reward classes, grants partial credit over next-state components, skips terminal next-state checks, and accepts nonempty valid-action subsets for RTFM; continuous states use 1e-5 relative/absolute tolerance. The planning script defaults to two episodes, while the paper reports ten. Reproduction needs the Linux-oriented Conda/Python 3.10 environment, Gymnasium/MuJoCo and model access. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ### The Closer You Look, The More You Learn: A Grey-box Approach to Protocol State Machine Learning > StateInspector learns protocol Mealy machines by combining active message queries with snapshots of runtime memory, without requiring the target’s source code. It identifies candidate state-defining heap locations and uses taint and concolic analysis to merge states, evaluated by the authors on TLS 1.2 and WPA/2 implementations. - Authors: Chris McMahon Stone; Sam L. Thomas; Mathy Vanhoef; James Henderson; Nicolas Bailluet; Tom Chothia - Venue: ACM CCS 2022 - Status: Conference paper - Publication / posting date: November 7, 2022 - Date source: The ACM-deposited Crossref record gives November 7, 2022 for both online and print publication; this date is not inferred solely from the conference schedule. - DOI: 10.1145/3548606.3559365 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Assumes a finite Mealy-machine abstraction, a known input alphabet that can reach the relevant states, and state-defining memory on the heap exercised by bootstrap queries. State merging depends on configured search-depth and symbolic look-ahead bounds. Missing inputs or state stored elsewhere can leave behavior unmodeled; malformed harness messages, response abstraction and timeouts can create misleading transitions. Learned models and bounded checks do not establish full implementation equivalence, recover unknown message formats or reconstruct an application’s source code. #### Why it fits this collection Provides a concrete method for reconstructing communication-state behavior from executable protocol implementations and testing deviations from expected flows, complementing message-format inference. #### Publication and review notes Reviewed the author-hosted 19-page copy; ACM-deposited metadata lists proceedings pages 2265–2278. Public code documents a dated Linux setup with Python 2, OpenJDK 14, Maven, per-protocol input/reset harnesses and target-specific ptrace hooks. The taint path requires Triton and IDA Pro/Wine; omitting it can prevent termination on counters. No project-wide license was found in the inspected repository; component licenses and proprietary-tool rights remain separate. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### HALucinator: Firmware Re-hosting Through Abstraction Layer Emulation > HALucinator rehosts monolithic ARM Cortex-M firmware by identifying hardware-abstraction-library functions and replacing them with authored Python handlers and peripheral models. LibMatch locates library interfaces; the QEMU/Avatar2 implementation supports interactive I/O, while the paper-associated HAL-fuzz variant uses AFL-Unicorn for fuzzing. - Authors: Abraham A Clements; Eric Gustafson; Tobias Scharnowski; Paul Grosen; David Fritz; Christopher Kruegel; Giovanni Vigna; Saurabh Bagchi; Mathias Payer - Venue: USENIX Security 2020 - Status: Conference paper - Publication / posting date: August 2020 - Date source: The official USENIX proceedings citation gives August 2020. Month precision is retained; the conference’s event dates are not substituted for a publication day. - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations LibMatch requires an available HAL/library and a sufficiently similar compilation environment; compiler variation and inlining limit matching. Rehosting also needs a QEMU-supported architecture, firmware memory layout, interception addresses and authored handlers/models. Unmodeled direct hardware accesses may return zero or ignore writes, and simplified timing and peripheral behavior do not establish hardware equivalence. The authors’ rehosting and fuzzing demonstrations are not universal firmware coverage, complete device reconstruction or original-source recovery. #### Why it fits this collection Shows how binary library identification and explicit environment models can reconstruct enough of an embedded execution environment to analyze existing firmware, with the abstraction boundary made visible. #### Publication and review notes Reviewed the final USENIX paper, pages 1201–1218; no DOI or arXiv identifier is asserted. The paper-linked embedded-sec/halucinator repository carries GPLv3, while the separate ucsb-seclab/hal-fuzz implementation carries Apache-2.0; these licenses are not interchangeable. The original README describes a lightly tested Ubuntu 16.04/18.04 and Python 3 environment with Avatar2, QEMU and GDB, and points to a newer project separately. Reproduction needs firmware images, compatible HAL/SDK inputs and configuration; vendor firmware, dependencies and SDK rights remain separate. HAL-fuzz uses simplified handlers and deterministic timers rather than wall-clock equivalence. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ### User-Space Dependency-Aware Rehosting for Linux-Based Firmware Binaries > FIRMWELL reconstructs the execution environment of Linux firmware services by running their initialization processes, locating blocking dependencies and repairing missing system-level behavior. It combines containerized QEMU-user emulation with a QEMU-system fallback, using process traces and binary analysis to recover resources needed by the target service. - Authors: Chuan Qin; Cen Zhang; Yaowen Zheng; Puzhuo Liu; Jian Zhang; Yeting Li; Weidong Zhang; Yang Liu; Limin Sun - Venue: NDSS 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: The Internet Society’s Crossref deposit and the official NDSS paper identify publication year 2026. No finer publication date is asserted from the conference event dates. - DOI: 10.14722/ndss.2026.230249 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The evaluation concerns selected network services, not complete device or hardware equivalence. HTTP acceptance uses configured response-status and error-content checks; other services need their own criteria. Coverage depends on unpacking, supported architectures, initialization heuristics and peripheral models. Symbolic path explosion, solver timeouts and complex peripheral checks remain failure modes. The paper’s recovery strategy avoids patching target binaries; successful service interaction does not establish recovery of original source code or every device function. #### Why it fits this collection A concrete method for reconstructing the dependencies around shipped firmware binaries, complementing HAL-level and full-system rehosting research. #### Publication and review notes The nine-author order follows the official paper. Crossref agrees on the DOI but repeats Jian Zhang as a tenth author row. Its appendix lists 1 CPU core, 4 GiB RAM and 100 GiB disk per task, and describes the full firmware corpus as private. The pinned repository declares GPLv3; vendor firmware and dependencies retain separate terms. Its Docker-in-Docker workflow uses an elevated-privilege outer container, and the authors recommend VM isolation; the current inner-container privilege flag defaults off. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Target-Centric Firmware Rehosting with Penguin > Penguin rehosts embedded Linux firmware from an extracted filesystem by deriving an editable configuration of emulation transformations, such as file changes, pseudofiles, NVRAM values and network interfaces, from static analysis. Dynamic-analysis plugins expose failures so the configuration can be refined for each target, and a minimizer identifies which transformations a working rehosting needs. - Authors: Andrew Fasano; Zachary Estrada; Luke Craig; Ben Levy; Jordan McLeod; Jacques Becker; Caden Kline; Elysia Witham; Cole DiLorenzo; Ali Bobi; Dinko Dermendzhiev; Tim Leek; Wil Robertson - Venue: Workshop on Binary Analysis Research (BAR) 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: The Internet Society’s Crossref deposit gives publication year 2025. The PDF footer names the 28 February 2025 workshop; no finer publication date is asserted from the event date. - DOI: 10.14722/bar.2025.23010 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Targets embedded Linux firmware through whole-system emulation with kernel replacement, as in Firmadyne and FirmAE; the implementation covers x86, ARM and MIPS and relies on the Linux syscall ABI. In the FirmAE comparison, success means a process binds port 80 or 443; a non-empty HTTP response is a stricter check, and the authors note neither shows full functionality. The 75% gain over FirmAE is author-reported on their own corpus of 13,649 images from vendor websites. Refinement still needs an analyst, and nondeterministic runs were repeated up to ten times. It builds an analysis environment, not a faithful device reproduction or source recovery. #### Why it fits this collection Makes firmware rehosting an explicit, shareable per-target configuration refined from runtime evidence, a reproducible way to rebuild an analyzable execution environment without the original hardware. #### Publication and review notes BAR 2025 is a workshop co-located with NDSS Symposium 2025, not the NDSS main track. The 13-author order and the name ‘Wil Robertson’ follow the PDF and the Internet Society’s Crossref deposit; the NDSS paper and program pages list ‘William Robertson’ and place Caden Kline after Cole DiLorenzo. The DOI resolves directly to the PDF, whose footer gives ISBN 979-8-9919276-4-2; no page range was verified. The conclusion says 13,650 images where the abstract and appendix say 13,649. The PDF’s availability section points to rehosting/penguin but names no evaluated release; the curated tool record reviews v3.1.21 (2026-10-06), which postdates the paper. The repository is GPL-2.0-or-later at the pinned commit, and the paper does not describe its firmware corpus as released. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Fingerprinting and analysis of Bluetooth devices with automata learning > Learns Mealy-machine models of Bluetooth Low Energy implementations on physical peripherals by active automata learning. An nRF52840 central running SweynTooth-derived firmware sends abstract BLE inputs, with error handling, repeated queries and caching for lost packets and non-deterministic replies. The authors learn connection-procedure models of six devices and legacy-pairing models of three, and use model differences to fingerprint their SoCs. - Authors: Andrea Pferscher; Bernhard K. Aichernig - Venue: Formal Methods in System Design - Status: Journal article - Publication / posting date: August 2022 - Date source: Springer-deposited Crossref metadata and the article page give the August 2022 issue date of volume 61, issue 1, represented at month precision; the 22 May 2023 online publication is recorded in metadata notes. - First arXiv submission: November 29, 2022 - arXiv: 2211.16074 - Reviewed arXiv version: v2 - DOI: 10.1007/s10703-023-00425-y - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Models are bounded by the chosen abstract alphabet and cover only connection and legacy pairing; message formats are not inferred, and secure pairing is left to future work. Equivalence was approximated with a small number of conformance tests per state, so models are hypotheses, not proofs. One SoC was learnable only with reduced alphabets, two were learned from an already-connected state, and some pairing runs needed manual hard resets. The fingerprinting sequence holds only for the tested SoCs. Apart from one crashing input sequence, the authors report no security vulnerabilities in the learned models. #### Why it fits this collection Reconstructs the protocol-state behavior of closed BLE implementations through black-box interaction with real devices, showing how learned state machines expose implementation differences and deviations from the specification. #### Publication and review notes Formal Methods in System Design 61(1), pages 35–62, published online on 22 May 2023 as an open-access CC BY 4.0 article. It extends the authors’ FM 2021 paper ‘Fingerprinting Bluetooth Low Energy Devices via Active Automata Learning’ (LNCS 13047, pages 524–542, DOI 10.1007/978-3-030-90870-6_28). The ble-learning README, linked from AALpy’s applications list, names this article ‘Identification and Analysis of Bluetooth Devices via Automata Learning’, unlike the published title. Springer’s PDF could not be fetched automatically, so its full-text page and arXiv v2, the accepted manuscript, were reviewed. The study used Python 3.9.0, AALpy 1.0.1 and a modified Scapy 2.4.4; the repository, pinned at a 2025 commit, now requires aalpy>=1.1.7 and scapy>=2.4.5. It needs an nRF52840 dongle or development kit flashed with the supplied SweynTooth-derived firmware, and pairing also needs Linux with SweynTooth’s BlueZ-based Security Manager module. The repository has no license file. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### Web2Code: A Large-scale Webpage-to-Code Dataset and Evaluation Framework for Multimodal LLMs > Studies screenshot-to-HTML reconstruction through instruction tuning and two evaluation benchmarks. Web2Code combines generated webpages, refined WebSight and pix2code image/code pairs, and WebSRC-derived question answering. Models produce HTML from a webpage image and instruction; rendered output is compared visually, while a separate benchmark measures screenshot understanding. - Authors: Sukmin Yun; Haokun Lin; Rusiru Thushara; Mohammad Qazim Bhat; Yongxin Wang; Zutao Jiang; Mingkai Deng; Jinhong Wang; Tianhua Tao; Junbo Li; Haonan Li; Preslav Nakov; Timothy Baldwin; Zhengzhong Liu; Eric P. Xing; Xiaodan Liang; Zhiqiang Shen - Venue: NeurIPS 2024 Datasets and Benchmarks - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: The official NeurIPS proceedings and publisher-deposited Crossref metadata identify publication year 2024; Crossref provides no finer publication date. The first arXiv submission date is recorded separately. - First arXiv submission: June 28, 2024 - arXiv: 2406.20098 - Reviewed arXiv version: v2 - DOI: 10.52202/079017-3560 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses 1,198 screenshots and 5,990 yes/no questions. WCGB grades rendered images with GPT-4V; its User Interface and Interactivity category measures element appearance, not executed click paths, persistent state or backend behavior. Synthetic and refined examples do not establish coverage of arbitrary real web applications, original-source equivalence or code quality. The paper reports contact-information issues in 2.7% of a 1,000-item privacy sample, so a blanket claim that the data is free of such information is unsupported. #### Why it fits this collection A foundational visual reconstruction dataset and evaluation method, useful for distinguishing screenshot fidelity from the behavioral guarantees of later website-reconstruction benchmarks. #### Publication and review notes Published in NeurIPS volume 37, pages 112134–112157; full author names follow the proceedings PDF. The repository still cites the preprint; reviewed arXiv v2 is dated 2024-11-17. The LLaVA-based training subtree carries Apache-2.0. Dataset licensing is inconsistent: the GitHub README and dataset-card frontmatter say MIT, while the same card’s body says CC BY 4.0 with research-only/non-commercial wording. The training metadata requires Python >=3.8 and pins PyTorch 2.0.1; evaluation needs browser rendering and an external vision-model API. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ### DeGPT: Optimizing Decompiler Output with LLM > Refines existing C-like decompiler output through three coordinated roles that select, propose and check changes. It simplifies structures, adds comments and renames variables; Micro Snippet Semantic Calculation compares simulated symbol values and calls before accepting structural changes. The authors evaluate readability and naming on 620 functions from four codebases, with separate stripped and non-stripped variants. - Authors: Peiwei Hu; Ruigang Liang; Kai Chen - Venue: NDSS 2024 - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: The official NDSS paper and the publisher’s Crossref deposit establish publication year 2024. The conference dates and DOI registration date do not establish a publication day. - DOI: 10.14722/ndss.2024.24401 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The reported 24.4% reduction is a Halstead-effort proxy on non-stripped output, not a measured reduction in human effort. The 62.9% comment result is the average non-trivial share among manually judged correct comments. MSSC is an intraprocedural heuristic: calls are abstracted and loops become branches; parsing, aliasing and path growth remain limitations. Its 80-case manual audit reports 84% accuracy and 85% recall, including three harmful changes missed. This supports assisted pseudocode comprehension, not guaranteed binary equivalence, recompilable whole programs or original-source recovery. #### Why it fits this collection A concrete LLM-assisted reverse-engineering method combining readability edits with an explicitly evaluated semantic-change filter. #### Publication and review notes The publisher and PDF agree on the title, three-author order and DOI; no arXiv identifier or proceedings page range was verified. The September 2024 artifact snapshot is later than the paper, has no release tag, and declares no project license. Its README requires manually installed cinspector, openai==1.28.1, tiktoken==0.2.0 and python-levenshtein, without a DeGPT Python minimum. Current code reads model, API key and endpoint from config.ini, differing from the README’s chat.py setup example; it uses Unix-style SIGALRM timeouts. The separately pinned cinspector dependency declares WTFPL and tree-sitter==0.20.4; this does not license DeGPT or its third-party samples. The paper primarily used gpt-3.5-turbo at temperature 0.2 and Ghidra 10.2.3. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### BinPRE: Enhancing Field Inference in Binary Analysis Based Protocol Reverse Engineering > Infers protocol-message field boundaries and semantics from instrumented server binaries and input messages. BinPRE groups bytes by the instruction operators that process them, applies detectors for field types and functions, then refines results across similar messages. On eight protocols with 50 messages each, the authors report average field perfection of 0.73 and type/function F1 scores of 0.74/0.81. - Authors: Jiayi Jiang; Xiyuan Zhang; Chengcheng Wan; Haoyi Chen; Haiying Sun; Ting Su - Venue: ACM CCS 2024 - Status: Conference paper - Publication / posting date: December 2, 2024 - Date source: The publisher’s Crossref deposit records published/print publication on 2024-12-02 and a separate publisher publication-history assertion on 2024-12-09. This record uses the published/print date; the October 14–18 CCS meeting dates and the September arXiv submission are separate. - First arXiv submission: September 3, 2024 - arXiv: 2409.01994 - Reviewed arXiv version: v1 - DOI: 10.1145/3658644.3690299 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations This is field inference, not recovery of a protocol state machine or complete endpoint behavior. It requires an accessible, instrumentable implementation and runtime message processing; passive captures alone are insufficient. Perfection counts exactly segmented fields against all true fields, not fully recovered protocols. The detector library covers five semantic types and six functions. Byte-level taint cannot accurately resolve bit flags, and unexercised behavior is not established. Ground truth uses Wireshark dissectors and specifications; three binary-analysis baselines were author reimplementations. Reported fuzzing improvements are a downstream evaluation, not proof of implementation equivalence. #### Why it fits this collection Adds recent executable-assisted protocol field and semantic inference, complementing the collection’s traffic-based syntax inference and protocol-state learning research. #### Publication and review notes The author’s publication page links the CCS-formatted paper, the 17-page arXiv v1 and the artifact. Six-author order, DOI and proceedings pages match Crossref. The reviewed artifact snapshot is dated 2024-10-25 and declares no project-level license. Its README specifies Ubuntu 20.04, Python 3.8 and Intel Pin 3.28; the workflow runs a server and client and requires protocol/thread selection. The reviewed tree supplies a Modbus example, not a complete eight-protocol benchmark package; additional servers, captures and evaluation ground truth need separate setup. The README’s Docker example uses a privileged container, and the Dockerfile fetches a named branch rather than the reviewed commit. Public availability does not grant rights to bundled binaries or dependencies. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ### BinaryInferno: A Semantic-Driven Approach to Field Inference for Binary Message Formats > Infers partial binary-message formats from static message samples without instrumenting an executable. Specialized detectors recognize floats, timestamps, lengths, entropy boundaries and serialization patterns; a graph-based integration step reconciles their descriptions. Across samples from ten protocols, the authors report top-level field-boundary precision of 0.69, recall of 0.73 and false-positive rate of 0.04 for the 1,000-message setting without analyst priors. - Authors: Jared Chandler; Adam Wick; Kathleen Fisher - Venue: NDSS 2023 - Status: Conference paper - Publication / posting date: 2023 (exact date not verified) - Date source: The official NDSS paper and publisher-deposited Crossref metadata establish publication year 2023. Crossref supplies no publication month or day; the conference dates and DOI registration date are not substituted. - DOI: 10.14722/ndss.2023.23131 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Assumes error-free, uncompressed, unencrypted, byte-aligned data and infers common fields or payload regions beginning at consistent offsets. It leaves optional/union fields and unsupported serialization patterns unresolved; sample diversity matters. The 26 encapsulated-payload test sets were pre-grouped using ground-truth message types, not discovered automatically. Ground truth merges adjacent fields that are constant across the sample; empty inference results are excluded from reported averages where stated. BI+ additionally uses supplied endianness and capture-time ranges. These are field-boundary results, not complete semantic recovery, protocol-state inference or behavioral equivalence. #### Why it fits this collection Provides trace-only semantic field inference that complements executable-assisted analysis and protocol-state learning, with explicit assumptions and evaluated false-positive behavior. #### Publication and review notes Three-author order, title and DOI agree across the publisher, paper and Crossref. No arXiv identifier or proceedings page range was verified; the PDF has 18 pages. The paper’s project URL leads to the author’s Tufts page, which links the repository. The reviewed 2023-05-02 snapshot has GPL-3.0-or-later code headers and a GPLv3 LICENSE; third-party trace provenance and rights require separate checking. README prerequisites are Python 3, sklearn, scipy and parallel, without pinned dependency versions; the pattern-search launcher also uses timeout and hardcodes 30 parallel jobs. Input is one hexadecimal message per line; timestamp search accepts a supplied time range. The actual entry file is binaryinferno/blackboard.py, despite the README’s basic-command blackboard.by typo. A dataset directory is present, but its README remains a placeholder. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### ICEPRE: ICS Protocol Reverse Engineering via Data-Driven Concolic Execution > Infers message-field boundaries by following concrete message-guided paths through binary protocol parsers, then symbolically replaying them to extract byte-level data flow. It merges bytes using value-preserving operations and similar processing traces. For the 1,000-message datasets of four public ICS protocols, the authors report average boundary F1 of 0.76 and field perfection of 0.67. - Authors: Yibo Qu; Dongliang Fang; Zhen Wang; Jiaxing Cheng; Shuaizong Si; Yongle Chen; Limin Sun - Venue: Proceedings of the ACM on Software Engineering (ISSTA 2025) - Status: Journal article - Publication / posting date: June 22, 2025 - Date source: The ACM article page and publisher-deposited Crossref metadata agree on publication on 2025-06-22. The ISSTA presentation date is not substituted for this journal publication date. - DOI: 10.1145/3728982 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-17 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Recovers message syntax, not field semantics, protocol state machines or endpoint equivalence. It needs the binary, loader configuration and correctly identified initialization, input and parsing functions; manual filtering remains necessary, especially without symbols. Encrypted protocols and bit-level fields are unsupported, and ignored or only copied bytes can be merged incorrectly. Perfection measures fields with both boundaries correct. Quantitative tests use four public protocols with 50- and 1,000-message sets; separate proprietary studies cover three protocols in five firmware targets, with interaction checks on three devices and manually established ground truth. Those checks do not demonstrate complete device behavior. #### Why it fits this collection Adds firmware-assisted protocol format inference using concolic analysis, complementing live-server instrumentation and traffic-only field inference. #### Publication and review notes The publisher identifies article ISSTA105 and licenses the paper under CC BY 4.0; its Data Availability section links the repository. The reviewed 2025-04-16 code snapshot has no project-level license declaration. Python 3 dependencies use compatible-release bounds, including angr~=9.2.100, Netzob~=2.0.0 and scapy~=2.5.0; the paper describes Ghidra 11.0.3 for function analysis. The repository includes public-protocol configurations and a Modbus capture, but no firmware images; target binaries and libraries need separate provision. The paper specifies trace-similarity threshold 0.9, while released InferSyntax.py uses 99 on a 100-point scale. Its batch evaluator excludes abnormal traces from aggregate metrics. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ### Lifting Network Protocol Implementation to Precise Format Specification with Security Applications > NetLifter statically lifts source-available C protocol parsers into BNF-style message grammars and first-order constraints between packet fields. It analyzes annotated LLVM bitcode using abstract format graphs, localized path-sensitive analysis, unfolding and reordering. The resulting field boundaries, constraints and names can support packet generation and parser construction. - Authors: Qingkai Shi; Junyang Shao; Yapeng Ye; Mingwei Zheng; Xiangyu Zhang - Venue: ACM CCS 2023 - Status: Conference paper - Publication / posting date: November 15, 2023 - Date source: ACM’s Crossref deposit records published/print publication on 2023-11-15 and a separate online/publication-history date of 2023-11-21. This entry uses the published/print date, not the November 26–30 conference dates. - First arXiv submission: May 19, 2023 - arXiv: 2305.11781 - Reviewed arXiv version: v1 - DOI: 10.1145/3576915.3616614 - Sources reviewed: 2026-10-17 - Added to the catalog: 2026-10-18 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Requires source/LLVM IR and packet-buffer/length annotations; it is not closed-binary or traffic-only recovery. The paper targets common top-down C parsers and does not support C++, inline assembly or libraries without available code. Pointer/loop analysis remains approximate; checksum fields can be identified while some checksum constraints are omitted, and fields ignored by an implementation may be missed. Precision/recall was manually checked on ten selected protocols. The reported fuzzing evaluation used three-hour runs repeated twenty times and bypassed checksum checks. It infers formats, not protocol state machines or proof of implementation equivalence. #### Why it fits this collection Adds source-to-format inference with cross-field constraints, complementing traffic-based and binary-assisted protocol reconstruction research. #### Publication and review notes The final author PDF and Crossref establish the five-author order, CCS 2023 DOI and pages. The 19-page arXiv v1 retains an old CCS 2022 submission template and placeholder DOI; publication identity follows the final 15-page paper. The repository calls its prototype Popeye and warns of rough edges. Its reviewed 2025-04-21 snapshot declares AGPL-3.0-or-later in source headers. CMake requires 3.10+, LLVM 12.x and Z3>=4.8.12; README recommends LLVM 12.0.1 and the author’s modified Z3 4.8.12-popeye branch. Vectorized IR is unsupported: README documents -fno-vectorize and -fno-slp-vectorize, and recommends debug information and removal of optimization flags for field naming. Dependencies and target code retain separate terms. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ### UIOrchestra: Generating High-Fidelity Code from UI Designs with a Multi-agent System > UIOrchestra converts static mobile UI designs into React/CSS through layout-description, code-generation and rendered-image comparison agents. Its APPUI benchmark contains 1,101 human-refined code/rendering pairs based on screenshots from 165 apps across 12 categories. The reference code is reconstructed for evaluation, rather than recovered original application source. - Authors: Chuhuai Yue; Jiajun Chai; Yufei Zhang; Zixiang Ding; Xihao Liang; Peixin Wang; Shihai Chen; Wang Yixuan; Yanping Wang; Guojun Yin; Wei Lin - Venue: Findings of EMNLP 2025 - Status: Conference paper - Publication / posting date: November 2025 - Date source: The official ACL Anthology citation gives November 2025. Crossref records only the year; the November 4–9 conference dates printed in the PDF are not treated as a publication day. - DOI: 10.18653/v1/2025.findings-emnlp.150 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Tests visual, component and code similarity, not native-package execution, interaction, backend behavior or application equivalence. APPUI references are rendered reconstructions of iOS screenshots; unavailable images/icons use placeholders. A human study covers 200 samples with four annotators. The difference-analysis prompt ignores font-size/typeface differences and placeholder image content. #### Why it fits this collection Adds a mobile-oriented screenshot reconstruction method and benchmark with explicit human-built reference data; also evaluates on Design2Code-hard webpages. #### Publication and review notes Reviewed the final 14-page proceedings PDF. Its eleven-author order is retained, including Yanping Wang where ACL/Crossref metadata renders Wangyanping; Wang Yixuan is preserved as printed. No arXiv version was verified. The paper promises a code/data release, but the reviewed coauthor page has disabled code/project placeholders and no attributable release or artifact license was verified. Code/project URLs therefore remain unset. The paper is covered by ACL’s CC BY 4.0 policy. #### Primary sources 1. 2. 3. 4. ### SLaDe: A Portable Small Language Model Decompiler for Optimized Assembly > SLaDe translates function-level assembly into C with a 200M-parameter encoder–decoder model, code-specific tokenization and PsycheC type completion. It studies x86 and ARM at -O0 and -O3, combining generated candidates with input/output checks. The input is assembly text, not raw machine bytes; disassembly is outside the method. - Authors: Jordi Armengol-Estapé; Jackson Woodruff; Chris Cummins; Michael F. P. O'Boyle - Venue: IEEE/ACM CGO 2024 - Status: Conference paper - Publication / posting date: March 2, 2024 - Date source: IEEE’s Crossref deposit gives published/print date 2024-03-02. Edinburgh’s publication record instead gives 2024-02-28, also the DOI-creation date. This entry uses the publisher-deposited print date and does not infer it solely from the conference schedule. - First arXiv submission: May 21, 2023 - arXiv: 2305.12520 - Reviewed arXiv version: v3 - DOI: 10.1109/CGO57630.2024.10444788 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluation covers about 4,000 ExeBench functions and a 112-program synthesis suite. Beam size 5 selects the first candidate passing finite I/O tests; generated functions are inserted into the original calling context. Passing these tests is not whole-program or all-input equivalence. Edit similarity is a readability proxy. Longer functions, external calls and incorrect type/operator predictions remain failure modes; the model has 1,024-position source and target windows. Historical baseline comparisons have different coverage and do not establish current rankings. #### Why it fits this collection Adds type-inference-assisted neural decompilation with explicit execution-based evaluation, complementing symbol recovery and later LLM decompilation studies. #### Publication and review notes Reviewed arXiv v3 dated 2024-02-15, the accepted CGO manuscript; publication metadata establishes the final venue and pages. Paper reference 65 links the Zenodo artifact. Its separate LICENSE restricts included code/data/models to paper reproducibility and calls it nonproduction research code. Appendix prerequisites include Python 3.8, PyTorch 1.10.2, Transformers 4.22.2, PsycheC, Haskell Stack and an AArch64 GCC toolchain. BTC weights are not redistributed and ChatGPT outputs may change. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### Coda: An End-to-End Neural Program Decompiler > Coda decompiles the assembly of short functions into C in two phases. An instruction-type-aware N-ary Tree-LSTM encoder and an attention-fed AST decoder first generate a code sketch; an ensemble of neural error predictors then proposes token corrections, each kept only if recompiling the candidate does not increase its edit distance to the input assembly. On synthetic benchmarks the authors report 82% average program accuracy after correction, against 12% for a sequence-to-sequence baseline with attention. - Authors: Cheng Fu; Huili Chen; Haolan Liu; Xinyun Chen; Yuandong Tian; Farinaz Koushanfar; Jishen Zhao - Venue: NeurIPS 2019 - Status: Conference paper - Publication / posting date: 2019 (exact date not verified) - Date source: The NeurIPS proceedings page and its metadata give publication year 2019 (Advances in Neural Information Processing Systems 32). No publication day is asserted; neither the December conference dates nor the June 2019 arXiv submission is substituted. - First arXiv submission: June 28, 2019 - arXiv: 1906.12029 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Training and test programs are randomly generated from Karel commands, math.h calls and arithmetic or logical expressions, in short and long variants (average length 15 and 30), 50,000 pairs per task, compiled without optimization: clang -O0 for the main MIPS results and gcc -O0 for an x86-64 appendix that reports sketch token accuracy only, about 6% lower on average. Real-world checks are small PyTorch C++ API model-construction and Hacker's Delight loop-free programs. Program accuracy requires an exact token match with the ground-truth source, the metric under which the paper reports 0% for conventional decompilers. Error correction assumes the compiler configuration is known, and token accuracy drops for longer programs. The results show neither optimized, whole-program nor binary-equivalent decompilation, and the paper names no author implementation. #### Why it fits this collection Adds an early (2019) end-to-end neural decompiler that pairs learned code generation with compiler-checked iterative correction, predating the LLM-based decompilation papers in this section. #### Publication and review notes The sole arXiv version, v1 of 2019-06-28, is titled 'A Neural-based Program Decompiler' and lists the same seven authors; this record uses the proceedings title. NeurIPS metadata gives Advances in Neural Information Processing Systems 32, pages 3708–3719; the proceedings page lists no DOI. A footnote expands Coda as CodeAttack. The proceedings supplemental ZIP holds one appendix PDF with dataset statistics, hyper-parameters, the x86-64 table and RetDec examples. The paper cites third-party disassemblers (mipt-mips, REDasm) but no author code, data or model release. #### Primary sources 1. 2. 3. 4. 5. ### Debin: Predicting Debug Information in Stripped Binaries > Debin predicts debug information for stripped ELF binaries on x86, x64 and ARM. After lifting code to BAP-IR, an Extremely randomized Trees classifier decides which registers and memory offsets hold source-level variables. A conditional random field, solved with Nice2Predict, then jointly predicts names and types for variables and functions, and the result is written back as DWARF sections. On 300 held-out binaries per architecture, the authors report 68.8% precision and 68.3% recall for x64 names and types. - Authors: Jingxuan He; Pesho Ivanov; Petar Tsankov; Veselin Raychev; Martin Vechev - Venue: ACM CCS 2018 - Status: Conference paper - Publication / posting date: October 15, 2018 - Date source: ACM-deposited Crossref metadata gives print and online publication on 2018-10-15. That is also the first day of the October 15–19 conference; the date comes from the publisher record, not from the conference schedule. - DOI: 10.1145/3243734.3243866 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The dataset has 3,000 non-stripped executables and shared libraries per architecture from 830 Linux debug-symbol packages of C code built with default package settings, split 2,700/300 for training and testing. Accuracy evaluation assumes given function boundaries; for fully stripped inputs, BAP's ByteWeight infers them, which the paper cites as about 93% accurate. Debin predicts 17 types, and leaves struct and union contents, line numbers and formats such as PE outside the evaluation. A prediction counts only when it equals the original debug value. Models learned from compiler-generated, benign code may be less accurate on obfuscated binaries, hand-written assembly or malware. The 35-sample malware study is manual inspection of decompiled output with no accuracy figures, because the samples lack ground-truth debug information. #### Why it fits this collection Adds learned name and type prediction that works directly on stripped binaries and emits standard debug sections, complementing identifier-naming and symbol-recovery research that operates on decompiler output. #### Publication and review notes Crossref's title field holds only “Debin”; the full title follows the ETH-hosted author PDF, which carries the ACM reference format, DOI and CCS ’18 rights notice. Crossref and the PDF agree on the five-author order and pages 1667–1680. The paper names https://debin.ai as the public tool; that host did not respond on 2026-10-18. The reviewed 2022-05-20 snapshot of eth-sri/debin is Apache-2.0, links the paper and depends on Nice2Predict and BAP. Its README says the setup scripts were tested only on Ubuntu 16.04 with gcc 5.4.0; the Dockerfile pins Ubuntu 16.04, Bazel 0.19.2, OCaml 4.05.0 and BAP 1.4.0, and requirements.txt pins numpy 1.19 and scikit-learn 0.19.2. Pretrained models are a separate archive of about 923 MB from files.sri.inf.ethz.ch. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Towards LLM-Resistant Software Protection: Agent Failure Patterns in CTF Reverse Engineering > Runs Claude Code, Codex CLI and ChatGPT-5.2 Pro on 24 crackme-style challenges selected from 15 international CTF events held in 2025, and attributes their failures to stages of an Observe–Comprehend–Plan loop and to three protection effects: concealment, complication and misdirection. From the failure logs, the authors derive four recurring weaknesses (training bias, over-trust in observations, context limitation and plan persistence). They rerun both CLI agents without a decompiler and compare outcomes with in-competition solve rates. - Authors: Ryutaro Nishizaka; Yudai Fujiwara; Takuya Shimizu; Kazushi Kato; Yuichi Sugiyama - Venue: Workshop on Binary Analysis Research (BAR) 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: The Internet Society’s Crossref deposit gives publication year 2026. The PDF footer names the 27 February 2026 workshop; no finer publication date is asserted from the event date. - DOI: 10.14722/bar.2026.23058 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The study covers 24 locally solvable Linux x86-64 ELF crackmes and three commercial agents (Claude Opus 4.5 and GPT-5.1-Codex-Max in the CLI tools, and an undisclosed ChatGPT model), evaluated in December 2025 with network access; runs that consulted public write-ups were excluded. The binaries are small relative to real-world software, and malware analysis and vulnerability discovery are out of scope. Each configuration had at most three attempts with early stopping, which the authors call noisy; success means printing the correct flag or finding an accepted input. Weakness labels come from qualitative log analysis by two evaluators and describe these runs, not general properties of LLM agents. ChatGPT-5.2 Pro ran in an uncontrolled web sandbox and is excluded from the decompiler comparison. Solve rates are among teams that solved at least one challenge, unavailable for six tasks, and may include LLM-assisted teams. Training-data exposure remains a validity threat, and the paper does not publish its assembled challenge set, run logs or code. #### Why it fits this collection Links reverse-engineering agent failures to specific protection effects and analysis stages, complementing benchmarks that mainly report success rates. #### Publication and review notes BAR 2026 is a workshop co-located with NDSS Symposium 2026, not the NDSS main track. The five-author order follows the PDF, the NDSS paper and program pages, and the Internet Society’s Crossref deposit. The DOI resolves directly to the PDF, whose footer gives ISBN 978-1-970672-08-4; Crossref lists no pages, and no page range was verified. No arXiv version was found. Table I gives per-task times and weakness labels for each configuration; the per-agent counts (15, 17, 14, 14 and 19 of 24) and the decompiler comparison are author-reported. The paper names no code or data release. #### Primary sources 1. 2. 3. 4. 5. ### TypeForge: Synthesizing and Selecting Best-Fit Composite Data Types for Stripped Binaries > TypeForge recovers composite data types, including struct layouts, unions and pointer or nesting relationships, from stripped binaries. A whole-program Type Flow Graph over Ghidra’s decompiler-inferred variables propagates member offsets and sizes, cuts conflicting edges caused by casts and unions, and synthesizes candidate type declarations. An LLM only selects among these statically synthesized candidates: each is applied through the decompiler’s retype interface, and a double-elimination tournament compares the resulting pseudocode for readability. On OSPREY’s coreutils dataset the authors report F1 of 81.7% for composite-type identification, 88.2% for layout recovery and 72.1% for relationship recovery. - Authors: Yanzhong Wang; Ruigang Liang; Yilin Li; Peiwei Hu; Kai Chen; Bolun Zhang - Venue: IEEE S&P 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: IEEE Xplore and the publisher’s Crossref deposit establish publication year 2025. Both list 12 May 2025, the first day of the May 12–15 symposium, and IEEE added the article to Xplore on 16 June 2025; neither date is treated as a verified publication day. - DOI: 10.1109/SP61157.2025.00193 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-18 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Recovers member offsets, sizes and relationships, not original type or member names; relationship correctness is judged by matching layouts because names are unavailable. The main evaluation uses OSPREY’s dataset of GNU coreutils and larger Howard-dataset programs, over 10,000 functions and 11,000 composite-typed variables at O0–O3, with ground truth from debug information; the paper does not report results per architecture. In the baseline comparison, OSPREY results were supplied by its authors and its runtime is an estimate, and ReSym figures are its published results, so not every baseline was rerun. Conservative removal of conflicting edges can drop valid members, and compiler optimizations that merge or flatten members lower accuracy at higher levels. About 75% of runtime is the LLM selection stage; the default model was GPT-4o mini, with each comparison run three times. Downstream readability and vulnerability examples are case studies, not proof of semantic equivalence. #### Why it fits this collection Adds static composite-type and struct-layout recovery that feeds decompiler readability, complementing learned variable naming, data-structure symbol recovery and LLM refinement of decompiler output. #### Publication and review notes IEEE Xplore and Crossref agree on the title, six-author order and DOI; an arXiv title search found no preprint. Both list article-relative pages 1–18, whereas the repository’s BibTeX gives 2847–2864. The author-hosted PDF is the final paper, including the S&P meta-review appendix. The 2026-03-17 snapshot is a Ghidra extension tested with Ghidra 11.0.3; its Python 3.13 selection scripts pin LangChain 0.3.23 and openai 1.75.0, and their README example names gpt-4.1-mini rather than the paper’s GPT-4o mini. Ground-truth extraction needs DWARF 4 debug information. LICENSE contains BSD 3-Clause-style terms with an added requirement to cite the paper in academic work; the README badge says BSD 3-Clause and GitHub reports NOASSERTION. Evaluation.md links early-version data captured before LLM selection, notes a June 2025 identification bug fix after submission, and withholds the variable-alignment evaluation script, so the paper’s metrics cannot be recomputed from the release alone. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### Towards Automated Dynamic Analysis for Linux-based Embedded Firmware > Firmadyne crawls, extracts and emulates Linux-based firmware for network-connected commercial devices such as routers and IP cameras. It replaces the vendor kernel with pre-built, instrumented kernels for little-endian ARM and little- and big-endian MIPS, boots the extracted filesystem under QEMU full-system emulation with a userspace NVRAM library, infers the network configuration, then runs automated analyses including 60 known and 14 newly found exploits. From 23,035 images across 42 vendors, the authors extracted 9,486 and report 887 of the 1,971 network-reachable images vulnerable to at least one sampled exploit. - Authors: Daming D. Chen; Manuel Egele; Maverick Woo; David Brumley - Venue: NDSS 2016 - Status: Conference paper - Publication / posting date: 2016 (exact date not verified) - Date source: Internet Society-deposited Crossref metadata supplies only publication year 2016; the publisher PDF separately identifies the 21–24 February 2016 symposium, which is not used to assert a publication month or day. - DOI: 10.14722/ndss.2016.23415 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The work targets Linux-based firmware on little-endian ARM and little- and big-endian MIPS, which made up 90.8% of the dataset; x86, VxWorks and other real-time operating systems are outside the system. Its pre-built kernels do not load vendor out-of-tree kernel modules, so vendor kernels and modules cannot be checked, and instrumented emulation is not identical device behavior. The emulation funnel narrows sharply: of 8,591 images that initially emulated, 2,797 had a network configuration inferred and 1,971 answered ping. NVRAM semantics, interface naming and a single emulated Ethernet device on ARM are among the reported causes. WAN and LAN ports are not distinguished, so remote exploitability is not established, and results count firmware images rather than unique products and are skewed by vendor composition. FirmAE extends Firmadyne to address such emulation failures; these 2016 rates are not current emulation figures. #### Why it fits this collection Adds the full-system firmware-emulation framework, with kernel replacement and userspace NVRAM, that later rehosting research such as FirmAE builds on. #### Publication and review notes Crossref gives only the year and no pages; the PDF footer identifies NDSS ’16, 21–24 February 2016, San Diego, with ISBN 1-891562-41-X and the DOI. The DOI resolves directly to the NDSS PDF. Figures differ between sources: the paper's per-vendor appendix table totals 8,893 extracted images where its abstract and body give 9,486, and the repository README reports 846 of 1,971 (43%) vulnerable images where the paper reports 887 (45%). The 2024-07-21 snapshot of firmadyne/firmadyne is MIT-licensed, calls itself a research tool that is not production ready, and says the paper's results used pre-release toolchains, kernels and components that it lists by version or commit. Its current Dockerfile uses Ubuntu 22.04 and runs in privileged mode, and download.sh fetches pre-built kernels, console and libnvram binaries from GitHub releases. Vendor firmware images and Metasploit exploits carry their own terms. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Self-Constructed Context Decompilation with Fined-grained Alignment Enhancement > Adds two techniques to LLM decompilation of function-level x86-64 GCC assembly into C. Self-Constructed Context Decompilation (sc²dec) recompiles a model’s first compilable output and uses the resulting assembly–source pair as an in-context example for a second attempt, without fine-tuning. Fine-grained Alignment Enhancement (FAE) fine-tunes llm4decompile-6.7b with LoRA on statement-level assembly–C alignments derived from DWARF debug information. Combining both, the authors report 52.41% average re-executability on Decompile-Eval, against 48.60% for the base model. - Authors: Yunlong Feng; Dechuan Teng; Yang Xu; Honglin Mu; Xiao Xu; Libo Qin; Qingfu Zhu; Wanxiang Che - Venue: Findings of EMNLP 2024 - Status: Conference paper - Publication / posting date: November 2024 - Date source: The official ACL Anthology citation gives November 2024. Crossref records only the year; the November 12–16 conference dates printed in the PDF are not treated as a publication day. - First arXiv submission: June 25, 2024 - arXiv: 2406.17233 - Reviewed arXiv version: v2 - DOI: 10.18653/v1/2024.findings-emnlp.385 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Results are function-level re-executability on Decompile-Eval: 164 HumanEval-derived C problems compiled at O0–O3 and checked by recompilation and HumanEval test cases. Passing these tests is not whole-program or all-input equivalence, and the paper does not evaluate real-world binaries, other architectures or readability. sc²dec helps only when the first output recompiles, so low re-compilability limits its gains; the authors report 1–2% lower results when context is built at a mismatched optimization level, and clang-built contexts scored slightly below GCC. FAE used 10,000 ExeBench functions limited to the standard C library, one training epoch and a single 6.7B base model; the authors did not validate it on larger datasets or models, and it slightly lowered the 1-shot result. GPT-4 and DeepSeek baselines are API snapshots that may not be reproducible. #### Why it fits this collection Adds recompilation feedback and debug-information alignment to end-to-end LLM decompilation, complementing LLM4Decompile and execution-checked decompilation benchmarks. #### Publication and review notes The title keeps the published spelling ‘Fined-grained’. The eight-author order follows the Anthology, PDF, Crossref and arXiv. arXiv v2 (2024-10-03) is labeled EMNLP 2024 Findings; v1 was submitted on 2024-06-25. The Anthology and Crossref give pages 6603–6614. The abstract’s ‘approximately 3.90%’ gain differs from the 3.81-point gap between Table 1’s 48.60% base result and 52.41%. At the 2025-02-18 commit, the repository declares MIT, although LICENSE.txt keeps template placeholders for year and holders. It provides an evaluation script and GCC Decompile-Eval data, and links a LoRA adapter for LLM4Binary/llm4decompile-6.7b-v1.5 and a training dataset on Hugging Face, both tagged MIT; the base model and ExeBench keep their own terms. Its README results table adds readability scores and the authors’ later ReF Decompile, and its FAE-only averages differ slightly from the paper (51.07% versus 50.88%). The evaluator uses local gcc and objdump and, with --compiler, sends code to the public Compiler Explorer API. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### jTrans: Jump-Aware Transformer for Binary Code Similarity Detection > jTrans embeds binary functions for similarity search with a BERT-style Transformer. Its jump-aware representation shares parameters between a direct jump’s operand token and the positional embedding of the jump target, so control flow enters the instruction sequence without a separate graph network. The model is pre-trained with masked language modeling and jump-target prediction, then fine-tuned with a cosine triplet objective on functions compiled from the same source at different optimization levels. The paper also introduces BinaryCorp, built by compiling C/C++ packages from Arch Linux’s official repositories and the AUR with gcc and g++. - Authors: Hao Wang; Wenjie Qu; Gilad Katz; Wenyu Zhu; Zeyu Gao; Han Qiu; Jianwei Zhuge; Chao Zhang - Venue: ACM ISSTA 2022 - Status: Conference paper - Publication / posting date: July 18, 2022 - Date source: ACM’s Crossref deposit records published/print and online publication on 2022-07-18. The date comes from that publisher deposit, not from the July 18–22 conference dates. - First arXiv submission: May 25, 2022 - arXiv: 2205.12713 - Reviewed arXiv version: v1 - DOI: 10.1145/3533767.3534367 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The model is trained on a single architecture (x86, per the paper’s discussion); cross-architecture search is not evaluated. Only direct jumps are encoded, and indirect-jump targets are left out of scope. Disassembly and function extraction rely on IDA Pro 7.5, so boundary errors upstream are not measured. BinaryCorp pairs gcc/g++ builds across O0–O3 and Os, with train and test split by project; it does not cover obfuscation or other compilers, and only the vulnerability study adds clang variants. Author-reported Recall@1 at pool size 10,000 on BinaryCorp-26M averages 62.5% against 32.0% for the best baseline, and accuracy still falls as pools grow, which the authors note for larger real-world pools. The vulnerability search uses eight CVEs with ten variants each. Baselines date from 2022, and Asm2Vec and OrderMatters were reimplemented, so the comparison does not establish current rankings. Similarity ranking identifies candidate matches; it does not recover source code, names or types. #### Why it fits this collection Adds learned binary code similarity search, a reverse-engineering aid for function matching, library identification and known-vulnerability search, complementing decompilation and symbol-recovery research. #### Publication and review notes The arXiv abstract page titles the paper “jTrans: Jump-Aware Transformer for Binary Code Similarity”; its v1 PDF, the only version, carries the full ISSTA title, ACM reference format and DOI, and its comment cites ISSTA 2022. Crossref and the PDF agree on the eight-author order, the DOI, pages 1–13 and a CC BY 4.0 license. The README at the 2025-04-10 commit declares MIT and lists Linux, Python 3.8+, PyTorch 1.10+, CUDA 10.2+ and IDA Pro 7.5+ for dataset processing. Trained models, experiment files, the processed BinaryCorp and its original binaries are hosted on the authors’ lab file server outside GitHub, so their availability is separate from the repository. The released data-loading code truncates each function to 512 token positions. Packaged software in BinaryCorp retains its own licenses. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### DecLLM: LLM-Augmented Recompilable Decompilation for Enabling Programmatic Use of Decompiled Code > DecLLM repairs decompiler pseudocode that does not recompile into C that compiles and runs, so source-level tools such as CodeQL can be applied to binaries. An iterative loop feeds compiler errors to an off-the-shelf LLM, reverting illegal outputs and large deletions, then uses mismatched test outputs and AddressSanitizer reports from the rebuilt program to repair behavior, and finally fuzzes the original and rebuilt executables for divergences. With GPT-3.5 and GPT-4 the authors report 74% and 78.3% success on 300 Code Contest programs; on Coreutils and CGC binaries, 61.9–70.9% recompile and 48.1–59.0% are fully functional. - Authors: Wai Kin Wong; Daoyuan Wu; Huaijin Wang; Zongjie Li; Zhibo Liu; Shuai Wang; Qiyi Tang; Sen Nie; Shi Wu - Venue: Proceedings of the ACM on Software Engineering (ISSTA 2025) - Status: Journal article - Publication / posting date: June 22, 2025 - Date source: The ACM article page and publisher-deposited Crossref metadata agree on publication on 2025-06-22. The ISSTA presentation date is not substituted for this journal publication date. - DOI: 10.1145/3728958 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations On Code Contest, success means the repaired code compiles and the rebuilt executable passes the supplied test cases, with AFL++ fuzzing as an extra check; the Coreutils and CGC overall rates also count rebuilt binaries that malfunction or crash. This establishes compilability and test-based agreement, not semantic equivalence, which the authors note is undecidable. Results depend on IDA Pro 8.3 output, with one Ghidra 10.4 repetition, and on the API-served gpt-3.5-turbo-0613 and gpt-4-0314 snapshots with a 4,096-token limit, so programs were chosen to fit within half of it. The 300 Code Contest programs average 112.9 lines; Coreutils 9.5 and CGC binaries were compiled without stripping symbols and repaired function by function, which cannot infer undefined globals. Around 30% of hard cases still fail, mainly from decompiler address/data confusion, ill-inferred buffer sizes, long outputs that include STL code and LLM type-cast shortcuts; deviations not exercised by tests remain undetected. CodeQL analysis of Juliet samples needed manual query adaptation. #### Why it fits this collection Adds recompilability-oriented repair of decompiler output, complementing readability-oriented LLM refinement and neural decompilation research. #### Publication and review notes The ACM page and Crossref agree on the title, nine-author order, DOI, volume 2, issue ISSTA, pages 1841–1864 and the 2025-06-22 publication date (received 2025-02-27, accepted 2025-03-31); the ACM page supplies article number ISSTA081, which Crossref omits. ACM marks the article open access under CC BY-ND 4.0. No arXiv version of DecLLM was found. The related preprint arXiv:2310.06530, “Refining Decompiled C Code with Large Language Models” (DecGPT; v1 2023-10-10, v2 2023-11-28), shares eight of the nine authors, omitting Daoyuan Wu, and the recompilation goal, but its title, author list and reported results differ. The Data Availability section points only to the Google Sites artifact page. It describes DecRule’s preprocessing rules, error examples, dynamic-repair case analysis and the CWE list; no source repository, prompt package or dataset download was identified. The prototype targeted output from the commercial IDA Pro decompiler and used OpenAI model snapshots that may no longer be served. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### Neural reverse engineering of stripped binaries using augmented control flow graphs > Nero predicts names for procedures in stripped x86-64 Linux executables; it does not produce decompiled code. Static analysis reconstructs call sites, including imported API names, and augments their arguments with concrete and abstract values along control-flow paths. LSTM, Transformer and graph neural network encoders over the resulting augmented call-site graph feed a decoder that generates the name as subtokens. On a GNU-package test set the authors report 45.53 F1 for Nero-GNN, against 35.52 for an adapted DIRE and 33.66 for Debin. - Authors: Yaniv David; Uri Alon; Eran Yahav - Venue: Proceedings of the ACM on Programming Languages (OOPSLA 2020) - Status: Journal article - Publication / posting date: November 13, 2020 - Date source: ACM’s Crossref deposit gives print and online publication on 2020-11-13, and an archived copy of the ACM article page shows the same publication date. The OOPSLA conference dates and the arXiv versions are not substituted. - First arXiv submission: February 25, 2019 - arXiv: 1902.09122 - Reviewed arXiv version: v4 - DOI: 10.1145/3428293 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses 67,246 procedures from C-only GNU packages built as x86-64 Linux executables, split by package into 60,403/2,034/4,809 examples after removing C++ executables, tests, statically linked packages and duplicate package versions. Labels come from names present before stripping, and F1 is measured over name subtokens, so outputs are learned suggestions rather than recovered original symbols. Simulated API-name obfuscation, which zeroes the .dynstr section, lowers Nero-GNN to 38.83 F1; packers and heavier obfuscation are not addressed. A procedure needs at least one statically detectable call site, and inlined procedures cannot be named. Data generation relied on a licensed IDA Pro (tested with 6.95) for procedure boundaries and export, plus angr and LLVM 10, and the model code uses TensorFlow 1.13.1; no claim is made about compatibility with current tool versions. #### Why it fits this collection Adds learned procedure-name prediction for stripped binaries driven by static call-site analysis, complementing the variable-name and type-recovery papers in this section. #### Publication and review notes ACM metadata in Crossref and in an Internet Archive copy of the ACM article page give the sentence-case title, volume 4, issue OOPSLA, article 225, pages 1–28; arXiv and the paper PDF capitalise it as 'Neural Reverse Engineering of Stripped Binaries using Augmented Control Flow Graphs'. Crossref records a CC BY-NC-SA 4.0 licence for the article. arXiv has four versions, v1 of 2019-02-25 to v4 of 2020-10-16, and links the DOI; v4 serves as the PDF. The README calls the repository the official Nero-GNN implementation; the 2021-05-10 commit carries GPL-3.0. Data generation targets Ubuntu 20 with Python 3.8, LLVM 10, angr and a licensed IDA Pro (IDAPython 2.7 scripts tested with 6.95); the model uses Python 3.6 and TensorFlow 1.13.1. The README warns that regenerated representations may differ slightly from the Zenodo copies after a Python 3 port. Zenodo (concept DOI 10.5281/zenodo.4081641) hosts the binaries, procedure representations and a trained GNN model under a CC-BY-4.0 record label. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### Decompiling the Synergy: An Empirical Study of Human–LLM Teaming in Software Reverse Engineering > Studies how human analysts work with LLM assistance during static software reverse engineering. A survey of 153 practitioners informed six LLM features built into an instrumented IDA Pro plugin. Then 48 participants (24 self-reported novices and 24 experts) analyzed two CTF-style binaries, with the features enabled on one randomly assigned challenge. From graded writeups, interaction logs and surveys, the authors report 18 findings: novice understanding rose by about 98% to expert levels while experts gained little, known-algorithm functions were triaged up to 2.4× faster, and artifact recovery rose by at least 66%, alongside harmful hallucinations. - Authors: Zion Leonahenahe Basque; Samuele Doria; Ananta Soneji; Wil Gibbs; Adam Doupé; Yan Shoshitaishvili; Eleonora Losiouk; Ruoyu Wang; Simone Aonzo - Venue: NDSS 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: The Internet Society’s Crossref deposit and the official NDSS paper identify publication year 2026. The PDF footer names the 23–27 February 2026 symposium; no finer publication date is asserted from the event dates. - DOI: 10.14722/ndss.2026.240380 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations A human study of LLM-assisted analysis, not an evaluation of autonomous agents or of LLM decompilation accuracy. It uses two unobfuscated C challenges of 26 functions each, static analysis in IDA Pro only (no debuggers or symbolic execution), researcher-written prompts, and a choice of GPT-4o, GPT-4o-Mini, GPT-4-Turbo, Claude-3-5-Sonnet or Gemini-Pro. The 2024–2025 sessions retain 48 of 51 participants; expertise is self-reported, and understanding is a rubric score of writeups graded by two researchers. LLM-created artifacts were not correlated with better understanding, and three LLM users reported a nonexistent buffer overflow that an LLM had suggested; the vulnerability-finding feature was negatively correlated with understanding. Individual observations, writeups and survey responses are not released, even on request; aggregated data is available only on request. #### Why it fits this collection Measures how LLM assistance inside a decompiler changes human reverse-engineering outcomes, complementing agent-only evaluations. The paper points to DAILA, listed in the curated catalog, as the actively maintained version of its study plugin. #### Publication and review notes The nine-author order follows the PDF, the NDSS paper page and Crossref. The PDF spells ‘Adam Doupé’, while Crossref and the paper page give ‘Doupe’; the page also lists Ruoyu “Fish” Wang. The PDF footer gives ISBN 979-8-9919276-8-0 and the DOI; Crossref lists no pages, and no page range was verified. No arXiv version was found. Footnote 1 and the Open Science section link mahaloz/dec-synergy-study. Its reviewed 2026-07-22 snapshot declares BSD-2-Clause and contains both challenges (sources, binaries, IDA databases and a solver) and the study infrastructure: a pwn.college Dojo module and REaLLM, the study version of DAILA. REaLLM requires Python 3.10+, libbs 2.9.1 and dailalib 3.15.6; study functionality needs a separately licensed IDA Pro 9 installation and the user’s own OpenAI, Anthropic or Gemini API keys. The infrastructure README documents a Docker build and a dojo.patch that this snapshot does not contain. The paper reports the known-algorithm speedup as up to 2.4× in the abstract, 238% in the introduction and at least 248% for experts on four functions in Finding 7. Finding 6 calls a p = 0.4 result statistically significant, despite the paper’s α = 0.05. These figures are author-reported. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### DynPRE: Protocol Reverse Engineering via Dynamic Inference > DynPRE starts from captured client–server traces and then interacts with a live protocol server to infer message formats and types. It detects session-specific identifiers such as cookies and rewrites them on the fly so that replayed requests stay valid. It then sends byte-level probe requests whose responses serve as semantic feedback for field identification, aligns the responses, and applies a request–response mapping refinement that also recognizes message types. On 12 protocols with 10-, 100- and 1,000-message datasets, the authors report average field perfection of 0.50 and message-type V-measure of 0.94, against 0.15–0.31 perfection for Netzob, NetPlier, FieldHunter, BinaryInferno and NEMESYS. - Authors: Zhengxiong Luo; Kai Liang; Yanyang Zhao; Feifan Wu; Junze Yu; Heyuan Shi; Yu Jiang - Venue: NDSS 2024 - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: Internet Society-deposited Crossref metadata supplies only publication year 2024; the publisher PDF separately identifies the 26 February–1 March 2024 symposium, which is not used to assert a publication month or day. - DOI: 10.14722/ndss.2024.24083 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The method needs captured traces plus a reachable server that it can query repeatedly; it does not work from passive captures alone. Probing changes server state: each probe opens a new session, but protocols with global state, such as IoT device power state, can still degrade feedback. On the 1,000-message datasets an analysis averaged 259 minutes, 50,344 connection attempts and about 3.98 million exchanged messages, so slow or rate-limiting servers reduce efficiency. Encryption and authentication were disabled in the open-source evaluation setups, and encrypted traffic in the IoT case studies was decrypted with device private keys. Checksummed protocols need an added checksum-reversal step, shown only on ICMP. Format ground truth comes from tshark dissectors, and message types from manual reading of protocol documents. The five-device IoT case studies test whether generated messages trigger device behaviors, not whether specifications are complete. State-machine inference reuses existing methods and is not evaluated as a contribution. #### Why it fits this collection Adds active, server-interactive protocol inference, complementing the trace-only, binary-assisted and source-based protocol reconstruction research in this section. #### Publication and review notes The NDSS paper page lists the seven authors with affiliations and links the PDF and slides; Crossref gives the same author order and only the year 2024. The PDF footer gives the 26 February–1 March 2024 symposium in San Diego, ISBN 1-891562-93-2 and the DOI. No arXiv version was found. The paper says DynPRE is available at github.com/DynPRE/DynPRE, but the 2025-08-27 snapshot contains only a README asking readers to contact the authors by email for the code and declares no license. The paper ran the baselines from public releases, using a public re-implementation for FieldHunter. #### Primary sources 1. 2. 3. 4. 5. ### BinMetric: A Comprehensive Binary Code Analysis Benchmark for Large Language Models > BinMetric poses 1,000 questions across six binary-analysis tasks: call-site reconstruction, decompilation, signature recovery, binary code summarization, algorithm classification and assembly instruction generation. The questions come from 20 open-source C projects compiled for x86-64, stripped and processed with IDA Pro, and aligned with source code through DWARF information. The authors evaluate 12 LLMs from five model families with one-shot prompts, alongside IDA Pro’s decompiler, LLM4Decompile, BinT5 and HexT5 where those apply. - Authors: Xiuwei Shang; Guoqiang Chen; Shaoyin Cheng; Benlong Wu; Li Hu; Gangyang Li; Weiming Zhang; Nenghai Yu - Venue: IJCAI 2025 - Status: Conference paper - Publication / posting date: September 2025 - Date source: The IJCAI Organization’s Crossref deposit gives publication month September 2025. The proceedings page’s citation metadata separately gives 2025-09-16; this entry keeps the month that both sources state and does not use the August 16–22 conference dates. - First arXiv submission: May 12, 2025 - arXiv: 2505.07360 - Reviewed arXiv version: v1 - DOI: 10.24963/ijcai.2025/858 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Scores are question-level metrics on isolated snippets, not end-to-end reverse-engineering workflows or agentic tool use. Preprocessing requires IDA Pro, and all binaries are x86-64 builds with each project’s default compiler settings on Ubuntu 22.04; other architectures, optimization sweeps and obfuscation are not studied. Most tasks score text overlap with Rouge-L, BLEU, METEOR or CodeBLEU, so they do not test semantic equivalence; only assembly generation checks compilation and test-case execution, where the average execution pass rate is below 1%. Summary labels were generated by ChatGPT and then manually reviewed, and algorithm classification uses 80 snippets from a single algorithms project. Leakage screening relied on exact-match web searches. The evaluated models predate 2025 (including gpt-3.5-turbo-16k-0613 and gpt-4-0613) and ran with a maximum length of 8,192 tokens, so the rankings are historical. #### Why it fits this collection Adds a multi-task benchmark spanning binary lifting, semantic recovery, algorithm identification and assembly synthesis, complementing single-task decompilation and agent benchmarks. #### Publication and review notes The proceedings title reads “Binary Code Analysis Benchmark”; arXiv v1, the only version, is titled “A Comprehensive Binary Analysis Benchmark for Large Language Models” and is a 23-page extended version whose comment says it was to be published in IJCAI 2025. The proceedings PDF, page metadata and Crossref agree on the eight-author order, the DOI and pages 7715–7723 in the Main Track. Neither the proceedings PDF nor arXiv v1 links code, data or a leaderboard. A same-named GitHub repository describes itself as the IJCAI’25 benchmark but declares no license and is not linked from the paper. Per-task counts are 70 call-site, 250 decompilation, 250 signature, 250 summarization, 80 classification and 100 assembly-generation items. #### Primary sources 1. 2. 3. 4. 5. ### DiSCo: Towards Decompiling EVM Bytecode to Source Code using Large Language Models > DiSCo lifts Ethereum contract creation bytecode to Solidity source by prompting a frozen LLM, instead of emitting decompiler pseudocode. It abstracts control-flow paths into logic-invariant semantic units, recovers constructor logic by simulating creation bytecode captured from block execution, and infers stripped names with signature databases and a type-aware graph model. These units become natural-language descriptions plus coding specifications in the prompt. GPT-4 is the primary model; Llama 3 is also tested. - Authors: Xing Su; Hanzhong Liang; Hao Wu; Ben Niu; Fengyuan Xu; Sheng Zhong - Venue: Proceedings of the ACM on Software Engineering (FSE 2025) - Status: Journal article - Publication / posting date: June 19, 2025 - Date source: The ACM article page and publisher-deposited Crossref metadata agree on publication on 2025-06-19. The PDF footer’s July 2025 issue date and the FSE conference dates are not substituted for this publication date. - DOI: 10.1145/3729373 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations Ground truth comes from Etherscan source files: 200 highest-balance contracts for all baselines and 1,000 for automated tests; separate studies add 50 Vyper, 50 newly deployed and 149 closed-source attack contracts. Compilability (about 75% with best-of-five sampling, 46% for a single run), differential-fuzzing pass rates and embedding similarity do not establish equivalence to deployed source. Nearly half of the imitation-learning fuzzer’s transactions revert, and manual review judged about 28.5% of generated contracts semantically consistent, and 12% for Vyper inputs. The authors report timeouts or unsound analysis on contracts with many paths, and name inference remains weak. Baselines give the same LLM output from Panoramix, Ethervm and Elipmoc, mostly taken from their websites or decompiled manually; this is not a comparison of standalone decompilers. Results depend on a GPT-4 preview snapshot. Attack reproduction covers ten January 2025 incidents, four of which were reproduced. #### Why it fits this collection Extends LLM-assisted decompilation to EVM smart-contract bytecode, recovering constructor logic and identifiers and checking results by compilation and differential execution. #### Publication and review notes The six-author order follows the ACM PDF and Crossref. ACM lists article FSE103 in volume 2, issue FSE, pages 2311–2334, and licenses the paper under CC BY 4.0. No arXiv version was found. The Data Availability section points to github.com/suxnju/disco, which now redirects to b1ue3ky/disco. At the 2025-04-13 commit, that MIT-licensed repository holds dataset CSVs of contract addresses, evaluation results and user-study material, but no DiSCo implementation. Contract sources and on-chain data keep their own terms. The primary model is given as GPT-4-0315-Preview. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### StackSight: Unveiling WebAssembly through Large Language Models and Neurosymbolic Chain-of-Thought Decompilation > StackSight decompiles WebAssembly text-format functions into C++ with LLM prompting. A static analysis annotates each WAT instruction with the virtual-stack state, using symbolic notation where branches diverge; a one-shot chain-of-thought prompt then asks the model to recover variable meanings, summarize the function and write C++. With GPT-4 the share of outputs passing all benchmark tests rises from 19.7% to 36.5% on HumanEval-X and from 42.4% to 59.6% on MBXP relative to one-shot prompting; GPT-3.5 and Code Llama-7B-Instruct are also evaluated. - Authors: Weike Fang; Zhejian Zhou; Junzhou He; Weihang Wang - Venue: ICML 2024 - Status: Conference paper - Publication / posting date: July 8, 2024 - Date source: PMLR states that Volume 235 was published on 08 July 2024, and the paper page gives the same citation date. The July 21–27 conference dates and the June 2024 arXiv submission are not used as the publication date. - First arXiv submission: June 7, 2024 - arXiv: 2406.04568 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Inputs are short exercise functions from the C++ splits of HumanEval-X (161 of 164 compiled) and MBXP (773 of 974), built as Emscripten 3.1.46 side modules at -Oz with function names kept by --profiling-funcs and converted with wasm2wat 1.0.33; minified, obfuscated or whole-application WebAssembly is not evaluated. Correctness is the share of outputs that compile and pass the benchmarks' test cases after a test oracle renames functions, inserts tests and adds namespace directives, with manual pass-by-value edits. Passing these tests is not proof of equivalence with the original module. Summaries are scored by BERTScore and SBERT; the user study had 15 participants on 20 snippets per dataset. wasm2c and an earlier neural decompiler were excluded for producing no compilable output, and results depend on specific hosted model versions. #### Why it fits this collection Adds LLM-based WebAssembly decompilation guided by static stack analysis, covering the bytecode format shipped in web applications alongside the native-code decompilation papers in this section. #### Publication and review notes PMLR lists Proceedings of the 41st International Conference on Machine Learning, PMLR 235, pages 13010–13028; no DOI is given. arXiv has a single version, v1 of 2024-06-07, whose comment cites the ICML 2024 proceedings. The models are gpt-3.5-turbo-1106, gpt-4-0125-preview and Code Llama-7b-Instruct; GPT-4 was compared only with one-shot prompting, while the GPT-3.5 and Code Llama baselines also use 3-, 5- and 10-shot prompts. The appendix gives the emcc and wasm2wat commands and the prompts. The paper links third-party tools such as WABT and Emscripten but no author code, prompts repository or evaluation harness. #### Primary sources 1. 2. 3. 4. ### Idioms: A Simple and Effective Framework for Turbo-Charging Local Neural Decompilation with Well-Defined Types > Idioms fine-tunes code language models to turn Hex-Rays output for one target function into predicted original C together with definitions of the user-defined structs, unions and typedefs it uses. Input can include neighboring decompiled functions in breadth-first call-graph order, so evidence about a type scattered across callers and callees reaches the model. The authors also build Realtype, 157,163 functions from compiled open-source C repositories with full type definitions. Their CodeGemma-7b-based model passes ExeBench unit tests for 54.4% of functions versus 46.3% for LLM4Decompile and 37.5% for Nova, and scores at least 95% higher on Realtype. - Authors: Luke Dramko; Claire Le Goues; Edward J. Schwartz - Venue: NDSS 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: The official NDSS paper and the Internet Society’s Crossref deposit establish publication year 2026. The February 23–27 symposium dates are not used as a publication day. - First arXiv submission: February 6, 2025 - arXiv: 2502.04536 - Reviewed arXiv version: v2 - DOI: 10.14722/ndss.2026.240795 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations This is local, function-level neural decompilation: each prediction covers one target function and its type definitions, not a compilable whole program. Evaluation uses x86-64 Linux gcc binaries from open-source GitHub projects and ExeBench’s “real” subset; O1–O3 builds disable inlining, and keeping only functions that decompiled at every level removes 21% of the Hex-Rays and 76% of the Ghidra test sets. ExeBench unit tests are an optimistic proxy; Realtype has no tests, so dependency-graph equivalence and exact name and type matches serve as conservative proxies, and a Realtype user-defined type counts as correct only if all of its fields, 17.6 on average when counted recursively, match. The main models use proprietary Hex-Rays output and context windows of 2,048 or 4,096 tokens. Predicted names and types are statistical, not recovered originals. Pretraining leakage from GitHub remains possible, and obfuscated code and malware were not evaluated. #### Why it fits this collection Adds neural decompilation that jointly predicts code and user-defined type definitions with interprocedural context, and introduces a type-rich benchmark, complementing assembly-to-source models and type and symbol recovery research. #### Publication and review notes The NDSS page, final PDF and Crossref agree on the published title, three-author order and DOI; Crossref lists no pages. arXiv:2502.04536 v1 (2025-02-06) is titled “Idioms: Neural Decompilation With Joint Code and Type Prediction” and v2 (2025-06-17) “Idioms: Neural Decompilation With Joint Code and Type Definition Prediction”; the repository README still uses the v1 title. The paper links Zenodo version 10.5281/zenodo.15683630, while the README links its concept DOI 10.5281/zenodo.14797016; both resolve to the same open 2025-06-17 record of about 11.8 GB, including a 10.1 GB models archive, and the Zenodo metadata names no license. The 2025-12-03 repository snapshot has no license file, and GitHub detects none. Its env.yml pins Python 3.11, CUDA 12.1, transformers 4.46.3 and peft 0.17.0; training also needs unsloth on GPUs with compute capability 7.0 or greater, dataset building runs GHCC builds in Docker that can take weeks, and the main decompilation step needs IDA Pro’s Hex-Rays. ExeBench tests run in a provided Docker image. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### EnIGMA: Interactive Tools Substantially Assist LM Agents in Finding Security Vulnerabilities > EnIGMA extends SWE-agent for capture-the-flag challenges with interactive agent tools that keep a gdb debugging session or a pwntools server connection open across turns, alongside decompile and disassemble commands, an LM summarizer for long outputs, and category-specific demonstrations and guidelines. It is evaluated with four LMs on 390 challenges from NYU CTF, InterCode-CTF, Cybench and a HackTheBox set the authors collected. The paper ablates tools, summarizers and demonstrations, and analyzes solution leakage and “soliloquizing”, where the model writes its own observations instead of acting in the environment. - Authors: Talor Abramovich; Meet Udeshi; Minghao Shao; Kilian Lieret; Haoran Xi; Kimberly Milner; Sofija Jancheska; John Yang; Carlos E Jimenez; Farshad Khorrami; Prashanth Krishnamurthy; Brendan Dolan-Gavitt; Muhammad Shafique; Karthik R Narasimhan; Ramesh Karri; Ofir Press - Venue: ICML 2025 - Status: Conference paper - Publication / posting date: October 6, 2025 - Date source: PMLR states that Volume 267 was published on 06 October 2025, matching the paper page’s citation_publication_date of 2025/10/06. The 13–19 July 2025 conference dates are not used. - First arXiv submission: September 24, 2024 - arXiv: 2409.16165 - Reviewed arXiv version: v3 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The benchmarks mix cryptography, forensics, pwn, reverse engineering, web and miscellaneous tasks (104 of the 390 are reverse engineering), so aggregate solve rates such as 13.5% on NYU CTF are not reverse-engineering accuracy. The per-category table reports 17.65% on NYU CTF’s 51 reverse-engineering challenges with Claude 3.5 Sonnet. Results are pass@1 with a $3 per-instance cost cap and 2024 models (GPT-4 Turbo, GPT-4o, Claude 3.5 Sonnet and LLaMA 3.1 405B Instruct); the NYU CTF baseline comparison uses pass@5. Many challenges have public write-ups, and the authors’ leakage and soliloquy measures are heuristics; on 21 later CSAW 2024 challenges the best configurations solved 2. Solving a CTF shows a captured flag, not recovered program structure or source. #### Why it fits this collection Evaluates how interactive debugger and connection tools change agent performance on CTF tasks that include reverse engineering, complementing the reverse-engineering-specific benchmarks in this section. #### Publication and review notes The 16-author order follows the PMLR page and the arXiv record; the PMLR metadata writes ‘Carlos E Jimenez’ and ‘Karthik R Narasimhan’, while the PDF prints ‘Carlos E. Jimenez’ and ‘Karthik Narasimhan’. PMLR lists pages 246–355 and no DOI; the arXiv v3 comment reads ‘ICML 2025’. The SWE-agent README still cites the earlier arXiv title ‘EnIGMA: Enhanced Interactive Generative Model Agent for CTF Challenges’. PMLR’s software link is the moving v0.7 branch; head 084d5d1 (2025-04-28) is MIT-licensed and documents running challenges with Docker image sweagent/enigma:latest. The current main README says to use SWE-agent 0.7 while EnIGMA is updated for 1.0. The project site links trajectories (MIT); the separate benchmarks repository reformats Cybench and InterCode-CTF only and leaves their copyright with the original creators, so it does not supply the HackTheBox set. Table 9 reports the NYU-agent overall rates as 3.00 and 4.00 in the reverse order of the main text. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ### Statistical Deobfuscation of Android Applications > DeGuard reverses layout obfuscation in Android APKs, predicting original names for the fields, methods, classes and packages that ProGuard renames. Built on Soot, it represents an app as a dependency graph over program elements and keeps Android API and other unobfuscated names fixed. It then runs MAP inference with Nice2Predict on a conditional random field learned from 1,684 F-Droid apps, under constraints that keep the renamed APK semantically equivalent. On 100 held-out F-Droid apps obfuscated with ProGuard, names identical to the originals rise from 13.3% to 79.1%, and third-party library prediction reaches 91.3% precision and 91.0% recall. - Authors: Benjamin Bichsel; Veselin Raychev; Petar Tsankov; Martin Vechev - Venue: ACM CCS 2016 - Status: Conference paper - Publication / posting date: October 24, 2016 - Date source: ACM-deposited Crossref metadata gives print and online publication on 2016-10-24. That is also the first day of the October 24–28 conference; the date comes from the publisher record, not from the conference schedule. - DOI: 10.1145/2976749.2978422 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations Only layout (identifier) obfuscation is addressed. Data, control-flow and cryptographic obfuscation, custom string encryption, reflection and goto-based code reordering are not reversed, and the paper notes that most malware samples it inspected also used such techniques. The benchmark is 100 benign, open-source F-Droid apps, obfuscated by enabling ProGuard without changing its rules and scored by exact match to the original names, so semantically close names count as errors; elements that ProGuard removed are not scored. Accuracy on other obfuscators or on malware may be lower. Libraries are identified by a package-name heuristic covering 133 libraries, and the training apps may import the same libraries. The 49-family malware study gives manual examples, such as Base64 decoders and location handling, without precision figures. #### Why it fits this collection Adds learned identifier recovery for obfuscated Android packages, complementing the interface-reconstruction papers in the app section and the binary symbol-recovery research elsewhere in the bibliography. #### Publication and review notes ACM's Crossref deposit and the ETH-hosted author PDF agree on the title, four-author order and CCS ’16 DOI; Crossref gives pages 343–355. The paper and the SRI project page name http://apk-deguard.com as the public DeGuard service; on 2026-10-18 it redirected to HTTPS and then did not respond. No DeGuard source repository was found. The project page says DeGuard is built on the open-source Nice2Predict framework. #### Primary sources 1. 2. 3. 4. ### FidelityGPT: Correcting Decompilation Distortions with Retrieval Augmented Generation > FidelityGPT post-processes existing decompiler output: an LLM labels lines with six distortion types, such as non-conventional dereferencing, redundant variables and confusing control flow, and then rewrites the labeled lines. Its prompts define the distortion types and add retrieval-augmented context from a manually annotated database of distorted IDA Pro and Ghidra lines. A semantic-intensity algorithm chooses which lines to query, and a variable-dependency analysis carries redundant-variable context across 50-line chunks. On 620 function pairs, the authors report 89% detection accuracy and 83% precision, and correction fix rates of 94% (FR) and 64% (CFR) against 83% and 37% for their DeGPT runs. - Authors: Zhiping Zhou; Xiaohong Li; Ruitao Feng; Yao Zhang; Yuekang Li; Wenbu Feng; Yunqian Wang; Yuqing Li - Venue: NDSS 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: The Internet Society’s Crossref deposit and the official NDSS paper identify publication year 2026. No finer publication date is asserted from the 23–27 February 2026 symposium dates. - First arXiv submission: October 22, 2025 - arXiv: 2510.19615 - Reviewed arXiv version: v1 - DOI: 10.14722/ndss.2026.230989 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The 620 pairs are mostly -O0 IDA Pro 7.5 functions sampled from Coreutils, curl, ImageMagick, OpenSSL, PuTTY and SQLite builds in a binary-similarity dataset, across ARM-32, MIPS-32 and x86-32, plus x86-64 TheAlgorithms/C code; separate -O1–-O3 and Ghidra sets test generalization. Ground-truth labels and FR/CFR were assessed manually by the author team against the paper’s criteria. Fix rates count lines marked as fixed and are not semantic-equivalence proofs: the authors note that repaired code often cannot be recompiled or executed. Correction runs on whole functions and may degrade on long ones, and the distortion database, built from 150 IDA Pro and 91 Ghidra lines, may miss rarer anomalies. Main results use GPT-4o at temperature 0.5 and remain stochastic; DeepSeek-chat and temperature-0 runs are reported separately. Training-data exposure of the open-source projects cannot be ruled out. #### Why it fits this collection Adds LLM-based detection and correction of distortions in decompiler output, complementing DeGPT-style refinement and end-to-end LLM decompilation. #### Publication and review notes The eight-author order follows the NDSS paper page, the PDF, Crossref and arXiv v1, which carries the same DOI. The PDF footer gives ISBN 979-8-9919276-8-0; Crossref lists no pages. The paper’s reference [31] points to the authors’ repository at a 2025-09-07 commit. It has no license file; its datasets contain decompiled functions and source code from third-party projects with their own licenses. The snapshot includes the detection and correction scripts, prompt templates, both distortion databases, seven decompiled-function sets with ground truth and a detection evaluator; the -O1–-O3 and Ghidra evaluation sets were not identified in it. Its README requires manual merging of chunked detection output and states that correction must be evaluated manually using the paper’s Table I. The configuration targets an OpenAI-compatible GPT-4o endpoint at temperature 0 with pinned LangChain 0.1 and Chroma dependencies. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### Large Language Models for Code Analysis: Do LLMs Really Do Their Job? > Evaluates GPT-3.5-turbo, GPT-4, LLaMA-2-13B, Code-LLaMA-2-13B-Instruct and StarChat-Beta on explaining what de-commented JavaScript, Python and C code does, then repeats the task on JavaScript obfuscated with JavaScript Obfuscator (identifier renaming, dead-code injection, control-flow flattening and string splitting) and with Wobfuscator’s WebAssembly transformation. GPT-3.5 and GPT-4 are also asked to rewrite 100 IOCCC winning programs as readable, compilable code. Case studies apply GPT models to a botnet and a benign browser-extension repository, an Android SMS stealer decompiled with JD-GUI, and WannaCry code decompiled with RetDec. - Authors: Chongzhou Fang; Ning Miao; Shaurya Srivastav; Jialin Liu; Ruoyu Zhang; Ruijie Fang; Asmita; Ryan Tsang; Najmeh Nazari; Han Wang; Houman Homayoun - Venue: USENIX Security 2024 - Status: Conference paper - Publication / posting date: August 2024 - Date source: Publication month in the official USENIX proceedings BibTeX; the August 14–16, 2024 symposium dates are not used to assert a publication day. - First arXiv submission: October 18, 2023 - arXiv: 2310.12357 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations Ground truth is GPT-4’s own explanations after manual checking by four students; other models are scored against those texts with similarity metrics and a GPT-4 judge, which the authors say is unreliable without manual calibration. Correctness is judged at explanation level, not by recovered behavior or executable equivalence. Only JavaScript is obfuscated with generated transformations; neither GPT model deciphered the WebAssembly that Wobfuscator inserts, and the smaller models produced no meaningful explanations once obfuscation was applied. Author-reported figures include 97.4% GPT-4 accuracy on non-obfuscated code and 87% on obfuscated JavaScript; in IOCCC de-obfuscation, about 20% of GPT-3.5’s targets and 19% of GPT-4’s yielded compilable code, and only 8% and 4% produced correct results. The malware analyses are qualitative case studies on a few samples, with manual chunking for WannaCry, missed behavior when context was split, and a false alarm in the botnet repository. Models recognized code from popular repositories, so memorization is a confound. The evaluated GPT-3.5/GPT-4-era and LLaMA-2-13B-class models are dated. The study analyzes source or already-decompiled text; it does not perform binary decompilation. #### Why it fits this collection Measures how far LLM explanations survive JavaScript obfuscation and decompiler output, complementing JavaScript deobfuscation benchmarks and tools in the collection. #### Publication and review notes USENIX publishes no DOI for the paper; the arXiv identifier is recorded, and the final PDF name usenixsecurity24-fang.pdf does not use the secYY publisher profile. The USENIX page, its BibTeX and the final PDF agree on the 11-author order, the single-name author Asmita, pages 829–846 and ISBN 978-1-939133-44-1; the page also lists a prepublication PDF. arXiv v2 (2024-03-05) carries the comment “Accepted by Usenix Security 2024”. The paper names the online appendix; at the reviewed 2024-08-28 commit it holds dataset, result and case-study folders and declares no license, and its samples include third-party code that keeps its own terms. Model versions beyond family names are not specified in the paper. #### Primary sources 1. 2. 3. 4. 5. 6. ### Beyond Classification: Inferring Function Names in Stripped Binaries via Domain Adapted LLMs > SymGen infers function names for stripped binaries by generating them with a LoRA-fine-tuned Code Llama model instead of classifying over a fixed name vocabulary. Ghidra decompiles each stripped function, its own name is masked, and callee names are normalized for deduplication. Before fine-tuning, the model is domain-adapted on decompiled code paired with LLM-generated summaries of the matching source functions. On functions from 33 C projects built for x86-64, x86-32, ARM and MIPS at O0–O3, deduplicated from 2,237,915 to 495,494, the authors report average word-level F1 of 0.277 (0.380 on x86-64), plus case studies on obfuscated binaries and Linux malware. - Authors: Linxi Jiang; Xin Jin; Zhiqiang Lin - Venue: NDSS 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: The official NDSS paper and the Internet Society’s Crossref deposit establish publication year 2025. The February 24–28 symposium dates are not used as a publication day. - DOI: 10.14722/ndss.2025.240797 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Names are split into words and scored with precision, recall and F1, with SymLM’s CodeWordNet grouping similar words; predictions are descriptive guesses, not recovered original symbols. Average F1 is 0.277 and lower on MIPS (0.137) and ARM (0.262). The gains of up to 409.3%, 553.5% and 489.4% in the abstract are author-reported relative improvements over AsmDepictor; the baselines were retrained on the authors’ deduplicated dataset, where they score far below their own papers, and XFL was compared on x86-64 only. A separate model is trained for each architecture and optimization level. All binaries were built with GCC 9.4.0, inputs depend on Ghidra output, and Code Llama’s closed pretraining data leaves leakage possible. Obfuscation tests apply three default Hikari passes to 363 binaries from six projects (F1 0.271–0.303); the malware study covers 812 functions in 16 x86-64 builds (F1 0.348). #### Why it fits this collection Adds generative LLM-based function-name inference for stripped binaries with explicit deduplication, complementing classification-based function naming and variable, type and data-structure recovery research. #### Publication and review notes The NDSS page, final PDF and Crossref agree on the title, three-author order and DOI; Crossref lists no pages. The PDF marks Linxi Jiang and Xin Jin as equal-contribution first authors. SymGen is the system name and is not part of the title; an arXiv title search found no preprint. The paper links the reviewed 2025-06-05 repository snapshot, which provides Ghidra decompilation, data-processing, summary-generation, alpaca-lora-based fine-tuning, prediction and evaluation scripts, a sample dataset and a 39 MB LoRA adapter (r=8) for codellama/CodeLlama-34b-Instruct-hf; base weights are not included and keep their own terms. The paper reports about 37 hours of LoRA training on one 80 GB A100. The README uses a Python 3.9 conda environment with largely unpinned requirements, including peft installed from Git. It links Zenodo record 10.5281/zenodo.15530083 (about 7.5 GB of source projects, binaries and decompiled data; CC BY 4.0 in its metadata), whose third-party projects keep their own licenses. The README states Apache License 2.0 and LICENSE contains Apache 2.0 text after an OSU copyright header, but GitHub reports NOASSERTION. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### “Len or index or count, anything but v1”: Predicting Variable Names in Decompilation Output with Transfer Learning > VarBERT suggests variable names for IDA Hex-Rays and Ghidra decompiler output with a BERT-style model pre-trained on 5.2M human-written C functions from Debian and fine-tuned on decompiled code; it also predicts whether each variable came from the developer or was introduced by the decompiler. The authors build VarCorpus from Gentoo C and C++ packages compiled for x86-64 at O0–O3, labeling decompiled variables from debug symbols. On per-function splits of O2 binaries, top-1 accuracy is 54.43% for IDA and 54.49% for Ghidra; on an IDA-O0 subset it reaches 50.70%, against 35.94% for DIRE and 38.00% for DIRTY. - Authors: Kuntal Kumar Pal; Ati Priya Bajaj; Pratyay Banerjee; Audrey Dutcher; Mutsumi Nakamura; Zion Leonahenahe Basque; Himanshu Gupta; Saurabh Arjun Sawant; Ujjwala Anantheswaran; Yan Shoshitaishvili; Adam Doupé; Chitta Baral; Ruoyu Wang - Venue: IEEE S&P 2024 - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: IEEE’s Crossref deposit and the proceedings title establish publication year 2024. Its published-print date, 2024-05-19, is the first day of the May 19–23 symposium, and the IEEE Xplore record could not be retrieved to confirm a separate publication date, so no day is asserted. - DOI: 10.1109/SP54263.2024.00152 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Predicted names are learned suggestions scored against developer names, not recovered originals. Top-1 accuracy drops to 42.40% (IDA) and 40.49% (Ghidra) on per-binary O2 splits, and the per-binary IDA-O0 lead over DIRTY is 4.52 points. The DIRE and DIRTY comparison covers IDA at O0 only, on about 400K functions (roughly 15% of VarCorpus), because DIRE's training time was prohibitive. The method can name only variables the decompiler recovers, and labeling relies on IDA and Ghidra preserving variables when matching debug symbols. Corpora come from Linux distribution packages, mainly x86-64 with a smaller AArch64 O2 experiment, and may not represent Windows or macOS executables; deduplication removes exact duplicates only. The user study had 27 students who completed 13 function pairs. Types, structures and recompilable code are outside its scope. #### Why it fits this collection Adds transfer-learning variable-name prediction across two decompilers and four optimization levels, with a dataset that addresses train–test overlap in earlier naming benchmarks. #### Publication and review notes Crossref gives the 13 authors in this order and pages 4069–4087 of the 2024 IEEE Symposium on Security and Privacy; the DOI resolves to IEEE Xplore document 10646727, whose page could not be retrieved during review. The title follows the paper's curly quotation marks; Crossref stores straight quotes. The 19-page author-hosted PDF, linked from the repository, lacks IEEE pagination and includes the program committee's meta-review. No arXiv version was found. The paper used IDA Pro 7.6, Ghidra 10.4, PyTorch 1.9.0, Transformers 4.10.0 and FairSeq 0.10.0. The reviewed 2025-12-17 repository commit has no license file; its README lists Python 3.8+, Java 11 for Joern and Java 17+ for Ghidra 10.4, requirements.txt leaves torch and transformers unpinned, the Dockerfile (Ubuntu 22.04, Python 3.11) fetches a modified Joern from Dropbox, and the README serves the HSC and VarCorpus data, Gentoo binaries and 16 fine-tuned models from Dropbox. Inference is offered through the separate binsync/varbert_api library and the DAILA plugin. #### Primary sources 1. 2. 3. 4. 5. 6. ### WebCode2M: A Real-World Dataset for Code Generation from Webpage Designs > WebCode2M pairs about 2.56 million real-world webpage screenshots with purified HTML/CSS code and element bounding-box layout trees. Pages sampled from a Common Crawl snapshot are cleaned (scripts, metadata and hidden elements removed, styles merged into one block), rendered with Playwright, and filtered by a neural scorer trained on 10,000 annotated samples. The paper fine-tunes Pix2Struct-1.3B as the WebCoder baseline, introduces TreeBLEU to measure DOM-structure recall, and benchmarks specialized, open and commercial multimodal models on short, medium and long test subsets of 256 pages each. - Authors: Yi Gui; Zhen Li; Yao Wan; Yemin Shi; Hongyu Zhang; Bohua Chen; Yi Su; Dongping Chen; Siyuan Wu; Xing Zhou; Wenbin Jiang; Hai Jin; Xiangliang Zhang - Venue: WWW 2025 - Status: Conference paper - Publication / posting date: April 22, 2025 - Date source: The ACM article page and ACM-deposited Crossref metadata agree on publication on 2025-04-22; the April 28–May 2 conference dates are not used as the publication date. - First arXiv submission: April 9, 2024 - arXiv: 2404.06369 - Reviewed arXiv version: v2 - DOI: 10.1145/3696410.3714889 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The task is static HTML/CSS generation from a design image. Scripts are stripped during purification, so interaction, client-side behavior and backend logic are not reconstructed, and outputs are judged by visual score, CLIP similarity and TreeBLEU rather than functional equivalence. The paper reports that no evaluated model reproduces image elements accurately, and scores fall as target code grows longer. The 768 test pages were drawn from high-scoring candidates and manually inspected; the scorer is about 90% accurate, so low-quality training samples remain, and the authors warn that crawled content may still include inappropriate material. Commercial models are named only by family, and about one-third of Gemini test cases failed with recitation errors, so those comparisons are snapshots. The dataset card's CC BY 4.0 license does not clear rights in the crawled pages' code, text or images. #### Why it fits this collection Adds a large real-world design-to-code training corpus with layout trees and a structure metric, complementing the smaller real-page and synthetic website-reconstruction benchmarks in this section. #### Publication and review notes arXiv v1 (2024-04-09) was titled “VISION2UI: A Real-World Dataset with Layout for Code Generation from UI Designs”; the reviewed v2 (2025-02-22, comment “WWW'25”) carries the final title and DOI. The ACM page and Crossref list Bohua Chen before Yi Su, while arXiv v2 lists Yi Su first; this record follows the publisher order. The project page links the paper, the naturalcc code directory and the Hugging Face dataset. The reviewed dataset-card revision f53cd4a (2025-03-05) declares CC BY 4.0, says the dataset is also called Vision2UI, warns of inappropriate content and points to a purified variant; its data directory is about 1.1 TB. The naturalcc repository declares MIT. Its webcode2m README still uses earlier names: the UICoder model and the vision2ui_test set, which now redirects to webcode2m_test. The environment file pins Python 3.10, PyTorch 2.1.2 and Transformers 4.33.1. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### SoK: AI-Augmented Binary Reversing > A systematization-of-knowledge survey of machine-learning, LLM and agentic approaches to binary reversing. Version 2 collects 246 papers published since 2015, found through keyword searches of 11 security, software-engineering and AI venues plus citation snowballing, and organizes them into 22 domains by inference task: from code-boundary detection and recovery of function names, types and struct layouts to code similarity, malware and vulnerability analysis, and decompilation. Its taxonomy links conventional triage, static, dynamic and security-testing analyses to AI pipelines through the binary-derived artifacts they exchange, and it derives 12 insights and open directions such as binary-aligned ground truth and goal-driven agentic reversing. - Authors: Yujeong Kwon; Yiyue Zhang; Kexin Pei; Dokyung Song; Hyungjoon Koo - Venue: arXiv - Status: Preprint - Publication / posting date: June 16, 2026 - Date source: arXiv v1 submission; the reviewed v2 revision of 2026-09-04 does not change the first-submission date. - First arXiv submission: June 16, 2026 - arXiv: 2606.17398 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations A literature systematization with no new experiments, benchmark or tool; it classifies and summarizes reported results without reproducing them. The corpus covers papers available up to July 31, 2026, applies citation thresholds that fall from 12 for 2015–2016 papers to 2 for 2025–2026 papers, excludes methods that need source code at inference time, and leaves out Android and interpreted-language bytecode. Detailed per-stage tables draw on 88 top-venue studies rather than the full corpus. It is an arXiv preprint with no stated venue. #### Why it fits this collection Provides a structured map of ML, LLM and agent research across binary reversing tasks, helping place the collection’s binary-analysis papers and locate related work that still needs individual review. #### Publication and review notes Reviewed arXiv v2 (2026-09-04; comment “21 pages, 7 tables, 4 figures”), which lists five authors and 246 papers; this record follows the v2 author list. v1 (2026-06-16; “20 pages, 7 tables, 3 figures”) listed six authors, Yujeong Kwon, Yiyue Zhang, Shakhzod Yuldoshkhujaev, Kexin Pei, Dokyung Song and Hyungjoon Koo, and analyzed 144 papers published between 2015 and 2025. Neither version states a venue or journal reference. Footnote 1 in both versions links the companion site, an interactive JavaScript table of the surveyed papers grouped by domain with links to their publications; no source repository is linked. The site and its paper list may change after this review. #### Primary sources 1. 2. 3. 4. 5. ### Beyond the C: Retargetable Decompilation using Neural Machine Translation > BTC (Beyond The C) treats decompilation as plain-text translation from compiler-emitted x86-64 assembly to source code. It uses byte-pair-encoding tokenizers trained separately on assembly and source, and a standard fairseq transformer. Function pairs are matched through the compiler's CFI and line directives rather than language-specific parsers, compiler plugins or lifters, so the same pipeline is retrained for Go, Fortran, OCaml and C. Training sets range from about 10,000 functions for small C, Go and Fortran corpora to 2 million C functions built from Debian packages. The best model, trained on the large C set, reaches a normalized average edit distance of 0.46 on held-out functions. - Authors: Iman Hosseini; Brendan Dolan-Gavitt - Venue: Workshop on Binary Analysis Research (BAR) 2022 - Status: Conference paper - Publication / posting date: 2022 (exact date not verified) - Date source: Internet Society-deposited Crossref metadata supplies only publication year 2022; the publisher PDF separately identifies the 24 April 2022 workshop, which is not used to assert a publication month or day. - First arXiv submission: December 17, 2022 - arXiv: 2212.08950 - Reviewed arXiv version: v1 - DOI: 10.14722/bar.2022.23009 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluation covers four languages at function level and scores outputs only by normalized edit distance to the original source. No compilation, test-based or semantic-equivalence check is reported, and whole-program decompilation is not evaluated. The authors state that the method cannot guarantee semantic correctness and is not yet ready for practical use on real code: even the best score means changes to roughly half of a function's tokens. Input is compiler-produced x86-64 assembly with labels and CFI directives intact, so disassembly of stripped binaries, other architectures and compilers without such directives are outside the evaluation. Sequence-length limits exclude long functions, and the small corpora are mostly competitive-programming and small utility code. The comparison with Katz et al. cites that work's reported score on shorter snippets rather than rerunning it on the same data. #### Why it fits this collection Adds neural decompilation evaluated beyond C, in Go, Fortran and OCaml, with a language-agnostic data pipeline, complementing the C-focused neural and LLM decompilation research in this section. #### Publication and review notes The NDSS paper page lists Iman Hosseini and Brendan Dolan-Gavitt (NYU) and links the PDF and slides; Crossref gives the same two authors and only the year 2022. The PDF footer gives BAR 2022, 24 April 2022, San Diego, with ISBN 1-891562-76-2 and the DOI. arXiv v1 (2022-12-17), the only version, was posted after the workshop and links the BAR DOI. The paper's Availability section gives the figshare link for code, data and trained models. It is a private-share link: a scripted request received an HTTP 202 challenge, while a browser showed an item titled “Beyond the C - data & code”, marked as privately shared, CC BY 4.0, modified 2022-01-04, with btc.zip (18.98 GB) and additional.zip. #### Primary sources 1. 2. 3. 4. 5. 6. ### ExeBench: an ML-scale dataset of executable C functions > ExeBench is a dataset, not a decompiler. It extracts C functions from GitHub and AnghaBench, makes them compilable by locating real headers and definitions or injecting synthetic ones, and generates input/output examples from function signatures with a C++ wrapper that runs each function. After exact deduplication the authors report 4,485,817 compilable and 687,843 executable functions, of which 124,612 have rich IO that a constant or identity implementation cannot pass; the paper also describes x86 and ARM assembly at O0, Os and Ofast for each row. Decompilation studies such as SLaDe and LLM4Decompile later used it to test whether decompiled functions re-execute correctly. - Authors: Jordi Armengol-Estapé; Jackson Woodruff; Alexander Brauckmann; José Wesley de Souza Magalhães; Michael F. P. O'Boyle - Venue: ACM SIGPLAN MAPS 2022 - Status: Conference paper - Publication / posting date: June 13, 2022 - Date source: The ACM article page and ACM’s Crossref deposit both give publication on 2022-06-13, which is also the day of the MAPS ’22 symposium. The date follows the publisher’s stated publication date, not the event schedule. - DOI: 10.1145/3520312.3534867 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations IO is generated from signatures without program context: 10 pairs per function (30 across three seeds of synthetic definitions), arrays default to 32 elements, and success falls below 5% for functions with pointer–integer conversions and stays low for goto, labels and complex control flow, so executable functions skew simpler than the compilable population. Synthetic IO is produced with injected stand-in definitions rather than the functions’ real dependencies; only 4,464 functions have rich IO with real definitions. Finite IO pairs test behavior on sampled inputs, not semantic equivalence, and deduplication removes exact matches after tokenization only. Running functions with real dependencies executes untrusted code; the authors used restricted containers. The paper’s exact v1.00 data is available only on request, while the public v1.01 release has revised splits (for example 2,134 instead of 2,232 real test functions). Each function keeps its source repository’s license; ExeBench additions are MIT. #### Why it fits this collection Adds the executable C-function benchmark behind several decompilation papers in this section, so readers can check its construction, IO limits and version differences directly. #### Publication and review notes ACM metadata in Crossref and on the article page gives the sentence-case title and pages 50–59 of the Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming; the 10-page PDF capitalises it as 'ExeBench: An ML-Scale Dataset of Executable C Functions'. No arXiv version was found. The article page marks the full text world-readable, while the PDF's 2022 notice licenses publication rights to ACM. The reviewed 2022-09-15 repository commit has no LICENSE file; its README assigns each C function its source repository's license and releases IO examples and wrappers under MIT. Its helper compiles a function's assembly with the C++ wrapper using g++ -O0 and runs it as a host subprocess without its own sandbox. Hugging Face revision 093085f (2023-03-09) hosts v1.01 as zstandard JSON-lines TAR archives with no license tag in the card metadata; the v1.00 dataset jordiae/exebench_legacy requires contacting the authors. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### XFL: Naming Functions in Binaries with Extreme Multi-label Learning > XFL treats function naming in stripped binaries as extreme multi-label classification: names are split into tokens, and PfastreXML ranks which tokens from a vocabulary of frequent labels fit each function. Its DEXTER embedding combines static-analysis features built on angr’s VEX IR with call-graph and whole-binary context, and a separate language model orders predicted tokens into a name string. On 741,724 functions from 10,047 x86-64 C binaries in Debian packages, with a 1,024-label vocabulary, the authors report precision 0.835, recall 0.575 and F1 0.681, ahead of Punstrip, Debin and Nero in precision and F1. - Authors: James Patrick-Evans; Moritz Dannehl; Johannes Kinder - Venue: IEEE S&P 2023 - Status: Conference paper - Publication / posting date: May 2023 - Date source: IEEE Xplore and the publisher’s Crossref deposit both record publication in May 2023; IEEE added the article to Xplore on 21 July 2023. No publication day is asserted. - First arXiv submission: July 28, 2021 - arXiv: 2107.13404 - Reviewed arXiv version: v4 - DOI: 10.1109/SP46215.2023.10179439 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Predictions are token labels from a fixed vocabulary, ranked and optionally assembled into names; they are not recovered source names, and scoring matches tokens rather than exact names. Evaluation uses x86-64 ELF C binaries from Debian packages, built with mixed compilers and optimization settings, plus Nero’s smaller dataset; the trained model is specific to x86-64 GNU/Linux binaries. All tools receive function boundaries from symbol tables at test time, so boundary-detection errors are excluded. Many test names also occur in training; restricted to names never seen in training, F1 falls to 0.242. Obfuscated and adversarial binaries are out of scope. Debin and Dire figures on the Nero dataset are copied from the Nero paper rather than rerun. #### Why it fits this collection Adds function-name prediction for stripped binaries framed as multi-label learning over binary embeddings, complementing variable-name, type and data-structure recovery research. #### Publication and review notes IEEE Xplore and Crossref agree on the title, three-author order, DOI, pages 2375–2390 and the May 2023 date. Reviewed arXiv v4 (2022-12-12; v1 2021-07-28), whose title and authors match. The paper’s code link github.com/unibw-patch/xfl now redirects to lmu-plai/xfl. The reviewed 2025-11-30 snapshot carries GPL-3.0 in COPYING. Its README describes xfl/ as partial original source with experiment data and logs and recommends the refactored xfl-r/ for comparisons; lm/ holds the name-generation language model. The README’s BibTeX lists pages 1677–1692 and DOI 10.1109/SP46215.2023.00096, which doi.org does not resolve. XFL-R setup requires Python 3.8, TensorFlow 2.13.1, PostgreSQL 13, radare2 5.5.4 and Ghidra 10.4, a PfastreXML build compiled from source downloaded separately, and a 46.9 GB Zenodo archive of models and tables (10.5281/zenodo.10733597) whose metadata names no license; pretrained DEXTER embeddings are linked from a separate download host. The paper reports about 850 GB of RAM for DEXTER training. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### WaDec: Decompiling WebAssembly Using Large Language Model > WaDec decompiles WebAssembly text (wat) into C by fine-tuning CodeLlama-7b with LoRA on loop-level wat–C snippet pairs. Functions are ordered by dependency and sliced so that each input holds at most one loop, with nested loops replaced by markers. Prompts add declarations of called functions, previously defined local variables and offset-to-string mappings; the outputs are then reassembled, with string constants restored and variables renamed. Training data come from 51,768 the-stack-dedup and 377 TheAlgorithms/C programs compiled with Emscripten. On 3,977 C files, the authors report 3.34% code inflation, 52.11% recompilability, 43.55% re-execution and 27.15% output consistency, compared with Wasm2c and Ghidra. - Authors: Xinyu She; Yanjie Zhao; Haoyu Wang - Venue: ASE 2024 - Status: Conference paper - Publication / posting date: October 27, 2024 - Date source: ACM-deposited Crossref metadata gives print and online publication on 2024-10-27. That is also the first day of the October 27–November 1 conference; the date comes from the publisher record, not from the conference schedule. - First arXiv submission: June 17, 2024 - arXiv: 2406.11346 - Reviewed arXiv version: v3 - DOI: 10.1145/3691620.3695020 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The reported rates are author results on C programs compiled to Wasm with Emscripten. About half of the outputs recompile, fewer than half re-execute and roughly a quarter reproduce the original output, so decompiled code is generally not semantically equivalent. The 3,977-file benchmark comes from the same two sources as the training programs. Optimized builds are not evaluated: the authors neither adapted the method to nor trained it on O1/O2 code. The model also handles data structures poorly, often flattening them into separate variables or arrays. Only C sources are studied; Wasm produced from other languages or toolchains is not evaluated. Baselines are Wasm2c and Ghidra's Wasm plugin, and LLM baselines were excluded because none could decompile Wasm functions without fine-tuning. Slicing means one function may be decompiled several times, at about 0.1 to 2 seconds per prompt. #### Why it fits this collection Adds LLM decompilation of WebAssembly with recompilation and re-execution checks, complementing the native-binary decompilation research in this section and the WebAssembly tools in the catalog. #### Publication and review notes ACM's Crossref deposit gives the three-author order, pages 481–492 and publication on 2024-10-27. The reviewed arXiv v3 (2024-09-11, comment “This paper was accepted by ASE 2024”) carries the ACM reference format and DOI; v1 dates from 2024-06-17. The paper's footnote names github.com/XinyuShe/WaDec as the replication artifact, while its reference list and the README's clone command still point to an anonymous review mirror. The reviewed 2024-07-24 snapshot contains dataset-construction notebooks, an evaluation JSON file and inference and metric scripts, but no license file or declaration. The README lists only Python 3.x and Git as prerequisites. It points to the wadecc/FGW2C dataset (110,096 examples, no license declared) and the wadecc/Wat2c model, a LoRA adapter whose configuration names codellama/CodeLlama-7b-hf as its base, so the base model's own license also applies. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### SymLM: Predicting Function Names in Stripped Binaries via Context-Sensitive Execution-Aware Code Embeddings > SymLM predicts function names for stripped binaries as sets of name words. It encodes each function’s instructions with a Trex model pretrained on micro-execution traces, fuses them with embeddings of callers, internal callees and external library calls taken from Ghidra’s interprocedural CFG, and scores words from a fixed vocabulary with an MLP decoder; name preprocessing and a word-embedding module, CodeWordNet, handle abbreviations and synonyms. On 1,431,169 functions from 16,027 binaries of 27 projects across x86, x64, ARM and MIPS, O0–O3 and four Hikari obfuscations, the authors report weighted average precision 0.634, recall 0.677 and F1 0.655, plus a firmware case study. - Authors: Xin Jin; Kexin Pei; Jun Yeon Won; Zhiqiang Lin - Venue: ACM CCS 2022 - Status: Conference paper - Publication / posting date: November 7, 2022 - Date source: The ACM article page and the publisher’s Crossref deposit both give publication on 2022-11-07, which is also the first day of the November 7–11 conference; the publisher-stated date is recorded. - DOI: 10.1145/3548606.3560612 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Names are predicted as unordered word sets from a fixed training vocabulary and scored with word-level precision, recall and F1, with CodeWordNet counting semantically similar words as matches. This is not exact source-name recovery, and out-of-vocabulary words cannot be produced. Binaries were built with GCC 7.5 for Linux and split by binary within the same 27 projects. On 540 binaries from 12 unseen projects, overall performance remains lower, which the authors partly attribute to vocabulary mismatch; a later NDSS 2025 comparison on deduplicated data reports SymLM’s average F1 at 0.105. NFRE comparisons are x64-only, and NERO comparisons use NERO’s dataset. Obfuscation covers four Hikari passes, not packing or encryption. In the firmware case study, 172 of 1,061 functions in eight 32-bit ARM firmware images received partially correct names. #### Why it fits this collection Adds execution-aware, calling-context function-name prediction for stripped binaries, evaluated across architectures, optimizations and obfuscations, complementing variable-name, type and data-structure recovery research. #### Publication and review notes Crossref truncates the title to “SymLM”; the full title follows the ACM page and the author-hosted PDF, which carries the CCS ’22 header and DOI. ACM and Crossref agree on the four-author order and pages 1631–1645, and ACM marks the article free to read. An arXiv title search found no preprint. The reviewed 2025-07-06 repository snapshot is MIT-licensed and includes a vendored fairseq, dataset-generation scripts, a sample x64 dataset, training, prediction and evaluation scripts, and CodeWordNet training code. Its README sets up Python 3.8 with CUDA 11.3 PyTorch and pinned requirements such as transformers 4.16.2 and gensim 3.8.1; training needs a December 2021 Trex checkpoint and CodeWordNet models from Google Drive links, and it warns that newer Trex checkpoints may be incompatible. The full dataset is Zenodo record 8306055 (about 9.4 GB; CC BY 4.0 in its metadata), which is registered under the paper’s DOI rather than a separate dataset DOI. The paper reports 8 days of training on top of the Trex pretraining. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### Nova: Generative Language Models for Assembly Code with Hierarchical Attention and Contrastive Learning > Nova is a generative LLM for x86-64 assembly, trained from DeepSeek-Coder checkpoints on stripped, normalized gcc -O0 to -O3 assembly built from AnghaBench and The Stack. It adds hierarchical attention that builds per-instruction summaries, and contrastive objectives that keep a function's source and O0–O3 assembly close while ordering them by optimization level. Fine-tuned for decompilation, Nova-1.3B and Nova-6.7B reach 25.17% and 34.36% average Pass@1 on HumanEval-Decompile, 14.84 and 12.41 points above same-size LLM4Decompile; separately fine-tuned models report the highest average Recall@1 for O0-to-O3 binary code similarity on six real-world projects. - Authors: Nan Jiang; Chengxiao Wang; Kevin Liu; Xiangzhe Xu; Lin Tan; Xiangyu Zhang; Petr Babkin - Venue: ICLR 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: Publication year stated by the official ICLR proceedings; no finer publication date is asserted. The proceedings page's citation date of 2025-05-01 is not adopted, and the arXiv dates are not substituted. - First arXiv submission: November 22, 2023 - arXiv: 2311.13721 - Reviewed arXiv version: v7 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Decompilation is evaluated function by function on the 164 HumanEval-Decompile C problems, each compiled for x86-64 at O0–O3, by running 20 samples per function against the problems' test cases; Pass@k on these tests is neither whole-program nor equivalence evidence. Baselines other than LLM4Decompile and Nova were prompted with three-shot examples rather than fine-tuned. Similarity results cover O0 queries against O3 candidates in pools of 50–500 functions from Binutils, Curl, ImageMagick, SQLite, OpenSSL and PuTTY, after fine-tuning on BinaryCorp-3M. Decompilation fine-tuning used a 2.16M-pair sample, the README says only 50K files came from The Stack, and the paper limits Nova to x86-64 assembly and 1.3B and 6.7B models. Inputs require the paper's assembly normalization. #### Why it fits this collection Adds an assembly-specialized foundation model evaluated on both decompilation and binary code similarity, complementing the decompilation-specific LLM papers in this section. #### Publication and review notes Authors follow the proceedings, which list pages 95905–95926. arXiv has seven versions: v1 of 2023-11-22 was titled 'Nova+: Generative Language Models for Binaries' (written Nova$^+$ in the arXiv metadata) and listed six authors, without Petr Babkin; the checked later versions (v3, v5, v7) use the final title, and v7 of 2025-11-11 states ICLR 2025 publication. The repository README's abstract gives a relative decompilation gain of up to 146.54%, while the paper reports absolute percentage points. The reviewed 2026-01-04 repository commit carries a BSD 3-Clause LICENSE, and the Hugging Face cards for nova-1.3b, nova-6.7b and their -bcr decompilation variants are tagged bsd-3-clause-clear; the models start from DeepSeek-Coder checkpoints. requirements.txt pins torch 2.3.0, transformers 4.40.2, vllm 0.5.0 and deepspeed 0.14.4 for a Python 3.10 environment, and training examples use four GPUs. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### Unleashing the Power of Generative Model in Recovering Variable Names from Stripped Binary > GenNm suggests names for placeholder variables in decompiled code of stripped binaries by fine-tuning generative code models (CodeGemma-2B by default; CodeLlama-7B and a LoRA-tuned CodeLlama-34B are also tested). Queries add renamed caller code and callee signatures propagated along the call graph; a DPO-style symbol-preference optimization (SymPO) counters bias toward frequent training names, and a data-flow name-validation step chooses among candidates over iterative rounds. The authors report 5.6–11.4-point precision gains over VarBERT and ReSym on rebuilt DIRTY and VarCorpus datasets, and 22.8% precision on names unseen in training against 17.3% for the strongest baseline. - Authors: Xiangzhe Xu; Zhuo Zhang; Zian Su; Ziyang Huang; Shiwei Feng; Yapeng Ye; Nan Jiang; Danning Xie; Siyuan Cheng; Lin Tan; Xiangyu Zhang - Venue: NDSS 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: The official NDSS paper and the publisher’s Crossref deposit establish publication year 2025. The conference dates and the arXiv versions do not establish a publication day. - First arXiv submission: June 5, 2023 - arXiv: 2306.02546 - Reviewed arXiv version: v4 - DOI: 10.14722/ndss.2025.240276 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Predictions are scored against debug-symbol names by token matching with SymLM's word clusters and rules, plus a GPT-4 evaluator for context relevance and semantic accuracy; neither shows that outputs are the original identifiers, and overall split-by-binary precision is 35.8% (DIRTY) and 41.2% (VarCorpus). Precision is about 30% for projects unseen in training, and gains are smaller at -O2 and -O3. Ground truth comes from debug information in Linux binaries rebuilt from GitHub projects or Gentoo packages, with IDA Pro output in the paper's examples. GenNm needs each binary's call graph, which is why the DIRTY dataset was rebuilt; split-by-function VarCorpus results use a 15% binary sample, and the black-box GPT-3.5/GPT-4 comparison uses 1,000 sampled functions. It recovers variable names only, not types, function names or full decompiled code. #### Why it fits this collection Adds generative, call-graph-aware variable-name recovery with explicit treatment of name-frequency bias, extending the learned-naming line of work in this section. #### Publication and review notes The record uses the NDSS title and the 11 authors in the NDSS paper's order, which match Crossref; Crossref gives year 2025 without pages. The arXiv record has carried three titles. v1 of 2023-06-05, 'LmPa: Improving Decompilation by Synergy of Large Language Model and Program Analysis', listed nine authors, without Ziyang Huang and Danning Xie; its title framed the work as improving decompilation in general, although its abstract already targeted variable-name recovery. v2 of 2024-05-01 was 'Leveraging Generative Models to Recover Variable Names from Stripped Binary'. v3 of 2024-07-20 and v4 of 2024-12-09, with the 11 NDSS authors, are 'Symbol Preference Aware Generative Models for Recovering Variable Names from Stripped Binary'; the NDSS paper defers implementation details to this extended version. The paper cites the artifact as Zenodo 10.5281/zenodo.14220042, a v1.0 code snapshot under concept DOI 10.5281/zenodo.14220041 as in the README badge. The reviewed 2026-01-29 repository commit is MIT-licensed, and Zenodo record 14287032 holds a 9.8 GB CC-BY-4.0 data package with intermediate results and model checkpoints. The README asks for Ubuntu 20.04+, Python 3.10 with vllm 0.5.3.post1, at least 24 GB of GPU memory for inference and 96 GB for training. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### BinaryAI: Binary Software Composition Analysis via Intelligent Binary Source Code Matching > BinaryAI identifies which open-source C/C++ libraries a stripped binary reuses by matching its functions to source code. Ghidra decompiles each binary function to pseudo-C, and a Pythia-410M model, trained with a CLIP-style contrastive loss on about 10 million binary–source function pairs, embeds pseudo-code and source functions in one space. Candidates retrieved from a corpus of 56,342,179 source functions from 12,013 libraries are refined with link-time locality and the call graph, and a library is reported when the share of its matched functions exceeds a threshold. The authors report 22.54% recall@1 against 10.75% for CodeCMR, and library-detection precision and recall of 85.84% and 64.98% against 73.36% and 59.81% for an unnamed commercial tool. - Authors: Ling Jiang; Junwen An; Huihui Huang; Qiyi Tang; Sen Nie; Shi Wu; Yuqun Zhang - Venue: ICSE 2024 - Status: Conference paper - Publication / posting date: April 12, 2024 - Date source: ACM's Crossref deposit records print and online publication on 2024-04-12, two days before the April 14–20 ICSE 2024 conference; the conference dates and arXiv dates are not substituted for it. - First arXiv submission: January 20, 2024 - arXiv: 2401.11161 - Reviewed arXiv version: v3 - DOI: 10.1145/3597503.3639100 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Training pairs come from ArchLinux and AUR packages compiled automatically with DWARF debug information, and the corpus and test set cover C/C++ projects only. The SCA test set is 150 stripped binaries the authors compiled from 85 GitHub projects, with 1,045 reused libraries labeled manually from build files, headers and license metadata; function-level ground truth covers 15 of those binaries (23,529 pairs). The recall@1 figures combine the model's validation set with those 15 binaries. The two commercial baselines are anonymized under confidentiality agreements, and every baseline was rebuilt on the authors' 12,013-library dataset. The 112 false positives the authors examined all trace to incomplete library-dependency data. The model, training pairs, source-function corpus and labeled test set are not public, and the hosted service the paper links may run a different model and corpus from the evaluated 2024 system. Matches identify reused source; they are not a decompilation or proof that the binary is unmodified. #### Why it fits this collection Adds binary-to-source function matching and binary software composition analysis, which identify reused open-source code inside stripped binaries, complementing binary-to-binary similarity and decompilation research. #### Publication and review notes Crossref records the ICSE 2024 proceedings article, pages 1–13, and its seven-author order matches arXiv. arXiv v1 is dated 2024-01-20, v2 2024-01-23 and v3 2024-08-26; the reviewed v3 carries the ICSE '24 ACM reference format and DOI. The ACM landing page refused automated access. The abstract links binaryai.net, which now redirects to the binaryai.cn web service, and the GPL-3.0 binaryai/sdk repository is a client for that service that needs a service credential. Neither releases the model, training pairs, corpus or labeled test set. A footnote says the module is deployed in industry with a growing corpus; another says the base model went through earlier OPT and BLOOM iterations before Pythia. #### Primary sources 1. 2. 3. 4. 5. 6. ### LLM Agent-Assisted Reverse Engineering with Quantitative Readability Metrics > Uses a composite Quantitative Readability Score (QRS) to guide agents refining decompiled C. Lexical familiarity, structural simplicity and coding idioms are combined with a binary-structure similarity gate. Experiments compare refinement with and without shell access on 210 simple C binaries. - Authors: Neil Archibald; Ruben Thijssen - Venue: arXiv - Status: Preprint - Publication / posting date: June 5, 2026 - Date source: arXiv v1 submission date. - First arXiv submission: June 5, 2026 - arXiv: 2606.06838 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Structural similarity does not prove semantic equivalence. QRS both guides and evaluates refinement; human readability validation remains future work. The selected synthetic corpus limits generalization. Recovering compilable, behaviorally correct code from difficult binaries is outside the claimed contribution. #### Why it fits this collection Connects agent feedback design with the readability of recovered code. #### Publication and review notes Reviewed the v1 abstract and full HTML. No implementation artifact identified. #### Primary sources 1. 2. ### Decoupling is a Necessity: Transformation-Agnostic Decompiled Code Recovery under Optimization and Obfuscation > ReSource refines decompiled functions affected by compiler optimization and obfuscation. Its stages retrieve guidance from a Semantic Distortion Database, predict a control-flow skeleton, and refine names and formatting. Evaluation measures code similarity and retrieval of the corresponding original function from a source corpus. - Authors: Zhiping Zhou; Xiaohong Li; Ruitao Feng; Yao Zhang; Yuekang Li; Wenbu Feng - Venue: arXiv - Status: Preprint - Publication / posting date: August 28, 2026 - Date source: arXiv v1 first-submission date. - First arXiv submission: August 28, 2026 - arXiv: 2608.27889 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations Function-level similarity and retrieval are proxies; they do not establish compilability, executable equivalence or complete program recovery. Section 5.2 notes missing global context and untested custom obfuscation. The author-linked artifact page describes a simplified dataset and explicitly says the database-construction and control-flow-prediction modules are not yet available. #### Why it fits this collection Adds staged refinement of optimized and obfuscated decompiler output, with explicit limits on what retrieval-based evaluation establishes. #### Publication and review notes Title, six-author order and preprint status agree across arXiv metadata and v1 full text. The project page links an anonymous artifact that returned HTTP 403 during review. #### Primary sources 1. 2. 3. 4. 5. ### Automatically Attacking Software Reverse Engineering AI Agents > A proof of concept for indirect prompt injection against Cline/GhidraMCP binary-analysis agents. An adapted AutoDAN generates embedded strings that make the agent describe different behavior. The authors demonstrate four small C programs with Qwen3-8B and transfer the examples to GPT-OSS-120B. - Authors: Brian Crawford; Justin Phillips; Patrick McClure - Venue: ECCWS 2026 - Status: Conference paper - Publication / posting date: June 15, 2026 - Date source: Publisher and Crossref online publication date; arXiv submission is recorded separately. - First arXiv submission: May 28, 2026 - arXiv: 2605.30667 - Reviewed arXiv version: v1 - DOI: 10.34190/eccws.25.1.4597 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-19 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Four illustrative programs, each with one or two functions; no repeated-trial success rate, realistic malware corpus or defense evaluation. The reported decompiler setting truncates strings beyond 2,048 characters. These examples do not establish general reliability across models or complex binaries. #### Why it fits this collection Adds direct evidence of a trust-boundary failure in agent-assisted reverse engineering. #### Publication and review notes ECCWS proceedings, pages 199–205; Crossref labels its deposit journal-article. Author order agrees across publisher, Crossref and arXiv. No implementation or dataset is linked in the reviewed primary sources. #### Primary sources 1. 2. 3. 4. 5. ### The CodeInverter Suite: Structure- and Data-Aware Binary Decompilation with Efficient LLMs > CodeInverter studies function-level LLM decompilation using control-flow graphs and memory-to-data mappings extracted with IDA/objdump. It presents a prompt workflow, training corpus and model family, evaluated through compilation, benchmark input/output tests and edit similarity. - Authors: Peipei Liu; Jian Sun; Rongkang Sun; Li Chen; Zhaoteng Yan; Xiaoling Zhang; Dawei Wang; Dapeng Sun; Peizheng Zhang; Dan Li - Venue: ASE 2026 - Status: Conference paper - Publication / posting date: October 7, 2026 - Date source: Online and print publication date in ACM’s Crossref deposit; arXiv first submission is recorded separately. - First arXiv submission: March 10, 2025 - arXiv: 2503.07215 - Reviewed arXiv version: v3 - DOI: 10.1145/3832783.3837554 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Evaluation covers individual C functions under 32/64-bit GCC settings. Whole-program recovery, aggressive optimization and protected binaries remain limitations. The text reports one epoch (15 steps), while the pinned launch example sets one epoch and 100 warmup steps; the exact training schedule remains unresolved. #### Why it fits this collection Adds structure- and data-informed LLM decompilation with separate compilation, execution-test and similarity evidence. #### Publication and review notes The v3 title and ten-author order match ACM’s Crossref deposit. The repository README at 548e59c still cites v2/2025. Direct ACM access returned HTTP 403. Artifact snapshots are separately versioned. The training directory contains MIT and DeepSeek notices; the CIM-1.3B card declares CC BY 4.0. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ### FirmPilot: Evidence-Guided Multi-Agent Environment Recovery for IoT Firmware Rehosting > FirmPilot reconstructs QEMU execution environments through coordinated retrieval, planning, filesystem, persistent-state and network recovery. Proposed changes are applied as constrained artifact deltas, then checked by rerunning the firmware and fixed probes. - Authors: Yanbing Shen; Fan Zhang; Haitao Xu - Venue: arXiv - Status: Preprint - Publication / posting date: July 16, 2026 - Date source: arXiv first submission date; no separate publication was verified. - First arXiv submission: July 16, 2026 - arXiv: 2607.14903 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The main denominator is 10,033 obtainable LFwC images, not all 10,913 metadata records. Reachability under a 2,400-second budget is not whole-device equivalence; HTTP success can include redirects or authentication gates. Reported results use one LLM backend and fixed probes. #### Why it fits this collection Uses execution evidence to recover the missing environment needed to inspect firmware behavior. #### Publication and review notes arXiv v1 as a preprint; its baseline and corpus references are separate works. #### Primary sources 1. 2. ### FirmCure:Towards Autonomous and Adaptive Rehosting of Linux-Based Firmware > FirmCure combines static dependency analysis, iterative boot-configuration repair and runtime fault diagnosis to rehost Linux firmware in QEMU. Specialized agents apply targeted repairs and use execution feedback to recover service behavior. - Authors: Chuan Hong; Zheng Zhang; Lei Zhou; Laisong Li; Chenyifan Liu; Ze Huang; Xu Zhou; Peihong Lin - Venue: arXiv - Status: Preprint - Publication / posting date: June 23, 2026 - Date source: arXiv first submission date; no separate publication was verified. - First arXiv submission: June 23, 2026 - arXiv: 2606.24549 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evaluation covers 21 images from ten vendors and five architectures: all opened ports, but only 19 reached full service interactivity within 45 minutes. Substituting an approximate kernel cannot preserve original-kernel or dedicated-hardware vulnerabilities. LLM reasoning loops caused residual failures. These author-reported results. #### Why it fits this collection Connects binary inspection and failure diagnosis to evidence-driven firmware environment repair. #### Publication and review notes ArXiv v1 is a preprint. Open Science mentions an anonymous repository without a locatable link. A same-named GitHub repository was not bound to this paper or its authors. #### Primary sources 1. 2. ### Reactive Peripheral Modeling for Faithful Firmware Rehosting > Bluezz models peripherals as stateful event-condition-action systems, coordinating interrupts, MMIO and DMA rather than treating accesses independently. It uses these models to rehost BLE firmware and reach connected protocol states for analysis and fuzzing. - Authors: Qinying Wang; Florian Hofhammer; Eduard Vlad; Jianqiang Wang; Marcel Busch; Shouling Ji; Mathias Payer - Venue: arXiv - Status: Preprint - Publication / posting date: August 30, 2026 - Date source: arXiv first submission date; no separate publication was verified. - First arXiv submission: August 30, 2026 - arXiv: 2608.29737 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The BLE evaluation covers 18 targets, with additional limited MCU examples. Hardware specifications, behavioral rules and use-case drivers require preparation and human validation. #### Why it fits this collection Reconstructs missing peripheral semantics so firmware and protocol behavior can be inspected in emulation. #### Publication and review notes Reviewed arXiv v1 as a preprint: earlier conference submissions are not acceptance. The paper links an anonymous review artifact and describes release upon acceptance; its landing page was reachable, but implementation availability and licensing were not verified. #### Primary sources 1. 2. ### Recovering Process Variables from Industrial Network Traffic via Search-Based Optimization > PVParser recovers process-variable layouts from industrial traffic and historian records. Periodic-pattern detection locates relevant payloads; a modified Monte Carlo tree search proposes field boundaries, types and endianness, then aligns decoded sequences with observed process variables. - Authors: Chuan Sheng; Shan Jiang; Jianming Zhao; Yu Yao - Venue: CCS 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: The official CCS 2026 accepted-paper list and arXiv v2 establish acceptance; a publication date was not verified. - First arXiv submission: August 17, 2026 - arXiv: 2608.16403 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Payload localization uses SCADA-N, SWaT and WADI; field/semantic recovery uses SWaT and WADI. Recovery depends on traffic and historian observations plus recurrent, stable plaintext byte layouts. Encrypted traffic, bit-level buses and event-driven messages whose PV lists vary are outside scope. It complements protocol dissectors. #### Why it fits this collection Infers deployment-specific message fields and semantics from observed communication instead of supplied format specifications. #### Publication and review notes ArXiv v2 and the CCS 2026 accepted list name four authors; v1 listed eight. The author-supplied DOI 10.1145/3830454.3846584 did not resolve at review, and no publication date or proceedings container was verified. #### Primary sources 1. 2. 3. ### TaoD2C-Bench: Benchmarking MLLMs for Industrial UI Code Generation Beyond Visual Fidelity > TaoD2C-Bench reconstructs interfaces from design images, layer metadata and component-library documentation. It separates requirement inference from implementation, checking component choices and layout relations through source/runtime evidence alongside rendered appearance. - Authors: Chengwei Shi; Yunnong Chen; Tingting Zhou; Qiang Lu; Shiyu Yue; Xinyuan Hu; Jianfang Ru; Liuqing Chen - Venue: arXiv - Status: Preprint - Publication / posting date: October 7, 2026 - Date source: arXiv v1 submission date; no separate proceedings or journal publication was verified. - First arXiv submission: October 7, 2026 - arXiv: 2610.10374 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2610.10374 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations Eight models are evaluated on 421 designs, not the full 2,861-design collection. Results include specified retries and one output-repair attempt. The tasks assess component/layout constraints and visual fidelity, not complete application behavior; all designs come from one commercial ecosystem. #### Why it fits this collection Adds requirement-level checks for screenshot- and metadata-guided interface reconstruction. #### Publication and review notes The linked repository at d4547c4 contains evaluation JSON only; no scorer or license file was found. Paper Appendix F assigns CC BY-NC 4.0 to annotations and separate restrictive terms to platform-owned assets. #### Primary sources 1. 2. 3. 4. ### From Visual Widgets to UI Code: Efficient Tool-Grounded Generation > WidgetGen reconstructs widget screenshots as React JSX. OCR text boxes and color palettes guide whole-widget layout reasoning and optional chart generation before one terminal render; generated render/code pairs also support model fine-tuning. - Authors: Houston H. Zhang; Tao Zhang; Li Gu; Linfeng Ye; Yuanhao Yu; Xinxin Zuo; Yang Wang; Zhixiang Chi - Venue: MUCG @ ECCV 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: The official 2026 MUCG workshop program confirms inclusion; a proceedings publication date was not verified. - First arXiv submission: August 12, 2026 - arXiv: 2608.12611 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2608.12611 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The main comparison uses six models and 1,000 test widgets from one dataset. Its nine image-based metrics do not test interaction, accessibility or maintainability. The supervision experiment covers six Qwen-family checkpoints; broader UI and model-family generalization remains open. #### Why it fits this collection Studies evidence-assisted recovery of executable interface code from compact visual references. #### Publication and review notes The official MUCG 2026 program lists this paper; proceedings publication was not verified, and OpenReview required browser verification. The arXiv paper is CC BY 4.0. No dedicated implementation or weight link was found in the reviewed paper/program; Widget2Code is the separate benchmark source. #### Primary sources 1. 2. 3. ### Does It Render Everywhere? A Study of Cross-Environment Compatibility in MLLM-Generated Webpages > WebCompat evaluates screenshot-reconstructed webpages across browsers and devices. Its XCompat detector combines rendered DOM geometry, viewport metadata and screenshots to identify layout and element failures, independently of similarity to the original design. - Authors: Ziyun Guo; Jingyu Xiao; Yuqiang Sun; Yintong Huo - Venue: arXiv - Status: Preprint - Publication / posting date: August 12, 2026 - Date source: arXiv v1 submission date; no separate proceedings or journal publication was verified. - First arXiv submission: August 12, 2026 - arXiv: 2608.12518 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2608.12518 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Filtering retains 254 static pages from 480 generations, producing 2,032 comparison pairs. The held-out detector test uses 51 pages/408 pairs. Failed renders and interaction-dependent layouts are excluded; heuristic errors and subjective design intent limit generalization to dynamic sites or every environment. #### Why it fits this collection Adds cross-environment validation for reconstructed frontends beyond single-screenshot similarity. #### Publication and review notes The pinned public snapshot contains 203 empirical pages; the paper’s 51-page test split was not found. README reports no license and incomplete collection/metric packaging. Its 56 passing tests are author-reported. #### Primary sources 1. 2. 3. 4. ### UniCoder: Unified Visual-to-Code Generation via Symbolic Rewards and Reference-Guided Code Optimization > UniCoder trains a visual-to-code model for charts, SVGs and webpages. Its reinforcement-learning objective combines rendering checks, image similarity and code-derived visual attributes; low-reward training groups receive reference-code trajectories to improve exploration. - Authors: Yaozhi Zheng; Yilei Jiang; Manyuan Zhang; Yuxuan Wan; Kaituo Feng; Tianshuo Peng; Bo Zhang; Xiangyu Yue - Venue: arXiv - Status: Preprint - Publication / posting date: June 30, 2026 - Date source: arXiv v1 submission date; no separate proceedings or journal publication was verified. - First arXiv submission: June 30, 2026 - arXiv: 2606.31732 - Reviewed arXiv version: v1 - DOI: 10.48550/arXiv.2606.31732 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Experiments concern static visual reconstruction with one 8B backbone, including Design2Code and ScreenBench. Reference code is used during training; successful rendering does not prove interactive behavior. Extending the attribute extractor to new domains requires new schemas/prompts. Interactive interfaces, animation and mobile-app behavior are not evaluated. #### Why it fits this collection Explores training signals for recovering code from visual website references. #### Publication and review notes At 2844ebd, the repository releases ChartMimic/UniSVG evaluation wrappers, not model weights, full training code or datasets. Original repository code is Apache-2.0; adapted benchmarks retain their own terms. The arXiv title includes “UniCoder”; the HTML heading and software citation omit that prefix. #### Primary sources 1. 2. 3. 4. 5. 6. ### NotDec: WebAssembly Decompilation With Inter-Procedural Type Recovery > NotDec lifts WebAssembly into SSA-based IR, uses Retypd-derived type constraints and pointer/value distinctions to recover structures, and emits C. Its study separates full interprocedural analysis from a faster intraprocedural variant. - Authors: Jikai Wang; Ningyu He; Tianming Liu; Junhai Wang; Haoyu Wang - Venue: ICSE 2026 - Status: Conference paper - Publication / posting date: April 12, 2026 - Date source: Publisher-deposited print publication date; online and arXiv dates are recorded separately. - First arXiv submission: August 4, 2026 - arXiv: 2608.03286 - Reviewed arXiv version: v1 - DOI: 10.1145/3744916.3787762 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The study uses Juliet and five Howard programs at O0/O3. Howard binaries omit actual library linking and cannot be executed, so recompilation does not demonstrate behavioral equivalence. Full analysis timed out on six Howard variants at 24 hours; recompilation results cover successful decompilations. The inspected README also warns about backend syntax errors on complex statements. #### Why it fits this collection Adds a concrete WebAssembly type-recovery and decompilation study with explicit scaling and execution limits. #### Publication and review notes Publisher metadata gives print/publication 2026-04-12 and online 2026-09-11; the arXiv deposit is 2026-08-04. ACM returned HTTP 403, so publication identity uses its Crossref deposit and author HTML. The paper is CC BY-NC-ND 4.0. The linked repository README at 0399bf0 describes ongoing work; its evaluated revision and repository-wide code/data license were not established. No root LICENSE/COPYING was present in the inspected tree. #### Primary sources 1. 2. 3. 4. 5. ### Beyond Text Matching: Towards Reference-Free Evaluation for Human-Oriented Binary Reverse Engineering > BinJudgeBench collects expert judgments for function naming, binary-code summaries and decompilation refinement. BinJudge learns to select a judge configuration for each input and task, evaluating agreement with human scores rather than executable correctness. - Authors: Xiuwei Shang; Li Hu; Xiao Jiang; Jieke Shi; Junda He; Zhou Yang; Shaoyin Cheng; Guoqiang Chen; Weiming Zhang; David Lo - Venue: ASE 2026 - Status: Conference paper - Publication / posting date: October 7, 2026 - Date source: Publisher-deposited print publication date; online and arXiv dates are recorded separately. - First arXiv submission: August 7, 2026 - arXiv: 2608.07038 - Reviewed arXiv version: v1 - DOI: 10.1145/3832783.3834339 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The router uses five-fold validation on 1,233 annotated outputs. Initial annotators are three authors, with an independent industrial expert checking a subset. Human scores are subjective, and fluent unsupported answers can mislead judges. Correlation on these tasks neither proves program equivalence nor establishes that judges can replace human review. #### Why it fits this collection Provides evidence-oriented evaluation resources for interpreting names, summaries and refined pseudocode. #### Publication and review notes The arXiv abstract still says accepted, while ACM’s Crossref deposit records ASE 2026 publication on 2026-10-07. Direct ACM access returned HTTP 403. The paper-linked Zenodo concept 19247812 resolves to version 19310393, titled Artifact for BinJudge, with anonymous creator metadata and CC BY 4.0. #### Primary sources 1. 2. 3. 4. 5. ### Echo: Learning-based Matching Decompilation using Trusted Back Translation > Echo iteratively generates source and compiler configurations, recompiles candidates, and uses assembly differences to guide configuration search and code refinement. It evaluates matching on function benchmarks and selected functions from a Mirai binary. - Authors: Jun Bi; Xiangxin Fang; Aarsh Chaube; José Wesley De Souza Magalhães; Rodrigo C. O. Rocha; Michael O'Boyle - Venue: arXiv - Status: Preprint - Publication / posting date: September 16, 2026 - Date source: First arXiv submission date from the reviewed submission history; no formal publication was verified. - First arXiv submission: September 16, 2026 - arXiv: 2609.18706 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Matching means equality of normalized function assembly under evaluated compilation settings, not byte-for-byte recovery of a whole executable. Tests cover selected x86 GCC/LLVM settings and 62 Mirai functions; passing finite harness tests is not a general equivalence proof. Long optimized functions and configurations outside the searched space remain limitations. #### Why it fits this collection Adds compiler-feedback-driven matching decompilation while separating its matching criterion from test-only recovery. #### Publication and review notes Latest reviewed version is arXiv v1. The Open Science section uses the placeholder anonymous.4open.science/xxxx, so no usable author artifact, model revision or code/data license was verified. The article uses the arXiv non-exclusive distribution license. #### Primary sources 1. 2. ### When LLM Decompilers Recompile More and Preserve Less > Decompile-Diverge builds function-level behavioral comparisons from source-derived drivers and fuzzed reference inputs. The study compares reconstructed functions on the same inputs and examines divergences and missing crashes that compilation and supplied tests can miss. - Authors: Chang Liu; Edward Raff; Kristopher Micinski - Venue: arXiv - Status: Preprint - Publication / posting date: September 4, 2026 - Date source: First arXiv submission date from the reviewed submission history; no formal publication was verified. - First arXiv submission: September 4, 2026 - arXiv: 2609.05370 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The oracle requires reference source, supported inputs and buildable harnesses. It compares a finite corpus and bounded observable state; Matched does not prove all-input equivalence. Nine of 300 GitHub reference functions failed harness builds, leaving 291. Some types/functions are excluded. DeGPT-Qwen is a substituted-backend configuration, not the originally published DeGPT model. #### Why it fits this collection Offers a concrete check on what recompilation and benchmark pass rates do not establish about recovered code. #### Publication and review notes Latest reviewed version is arXiv v1, licensed CC BY 4.0. No author-linked code or dataset URL was verified in the reviewed paper and focused artifact search; availability and artifact licenses remain unverified. Reported measurements. #### Primary sources 1. 2. ### ASAP: Assembly-Source Aligned Pseudocode Refinement For Binary Decompilation > ASAP aligns assembly and source representations during training, compresses assembly features into tokens, and supplies them alongside decompiler pseudocode to an LLM refiner. Masking and an assembly-advantage objective encourage the refiner to use low-level evidence. - Authors: Yujian Zhuang; Dehong Gao; Qichao Zhang; Qijing Lai; Jiaxin Wang; Libin Yang; Xiaoyan Cai - Venue: arXiv - Status: Preprint - Publication / posting date: September 30, 2026 - Date source: First arXiv submission date from the reviewed submission history; no formal publication was verified. - First arXiv submission: September 30, 2026 - arXiv: 2610.06900 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses C adaptations of HumanEval and MBPP, x86-64 GCC 11.4 at O0–O3, and Ghidra 11.0.3 pseudocode. Re-execution means passing supplied tests, not proving equivalence. Identifier/comment recovery is not a dedicated component, and frontier-scale model training is not exhaustively evaluated. #### Why it fits this collection Adds an assembly-informed refinement approach that explicitly documents the limits of its execution-test evidence. #### Publication and review notes Both the abstract history and v1 HTML give 2026-09-30, despite the 2610 identifier prefix. The article is CC BY 4.0. No author artifact URL or code/model/data license was verified from the reviewed sources and focused search; referenced training datasets retain their own terms. #### Primary sources 1. 2. ### STILL: Recovering Lowered STL Semantics for LLM-assisted C++ Decompilation > STILL predicts function-level STL container presence from stripped control-flow graphs and turns those predictions into compact hints for LLM refinement of Ghidra output. StlBench supplies controlled labels for five container classes. - Authors: Xiaohan Wang; Kevin Leach - Venue: arXiv - Status: Preprint - Publication / posting date: August 26, 2026 - Date source: First arXiv submission date from the reviewed submission history; no formal publication was verified. - First arXiv submission: August 26, 2026 - arXiv: 2608.26408 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The interface covers map, queue, set, string and vector, not full variable types, template arguments, nesting, iterators or std::array. Experiments use g++/x86-64/libstdc++ with angr and Ghidra; transfer to other toolchains is unverified. Test-suite executability is not equivalence, and hint benefits depend on the downstream model and adaptation. #### Why it fits this collection Connects explicit container-semantic recovery with LLM-assisted C++ decompilation without claiming full type reconstruction. #### Publication and review notes Latest reviewed version is arXiv v1, under CC BY-NC-ND 4.0. The appendix describes an artifact and a planned public StlBench release but gives no verified access URL. Its code, model and dataset licensing was not established. #### Primary sources 1. 2. ### CHISEL-ing Back Source Code with AI-enabled Iterative Recovery > CHISEL refines Ghidra pseudocode using compiler diagnostics and type-aware differential fuzzing against the original function. It retains counterexamples and candidate history; existing I/O pairs are held out for evaluation rather than supplied to the recovery loop. - Authors: Varun Kohli; N Raghava; Biplab Sikdar; Dinil Mon Divakaran - Venue: SURE @ ACM CCS 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: Acceptance is reported in the author arXiv record and publications page; proceedings publication is not verified. - First arXiv submission: August 28, 2026 - arXiv: 2608.27981 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluation covers 120 selected ExeBench functions, x86-64 O0–O3, stripped/unstripped variants and a fixed Gemma4:31b model. The feedback oracle still falsely accepts candidates; finite fuzzing and held-out tests do not establish equivalence. Signature recovery and possible benchmark exposure remain limitations. #### Why it fits this collection Adds test-suite-free in-loop refinement while explicitly separating oracle acceptance from verified behavior. #### Publication and review notes Author sources report acceptance to SURE 2026; the manuscript DOI remains a placeholder, so no proceedings publication date or DOI is assigned. The paper says selection requires at least 200 tests, while the pinned README says at least 100 held-out I/O pairs; exact evaluated artifact alignment remains unresolved. The article is CC BY 4.0, but the inspected root/README did not establish a code/data license. #### Primary sources 1. 2. 3. 4. 5. ### Decaf: Improving Neural Decompilation with Automatic Feedback and Search > Decaf samples multiple candidate decompilations, recompiles them and ranks them using compiler-derived byte distance or a learned reranker. The work studies candidate selection as a way to improve neural decompilation without an iterative source-repair conversation. - Authors: Alexander Shypula; Osbert Bastani; Edward Schwartz - Venue: arXiv - Status: Preprint - Publication / posting date: May 12, 2026 - Date source: First arXiv submission date; no separate proceedings or journal publication was verified. - First arXiv submission: May 12, 2026 - arXiv: 2605.11501 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Byte matching assumes access to the reference compiler/configuration. Experiments subsample ExeBench and exclude examples Hex-Rays cannot decompile; stripped Synth is not execution-scored because call targets cannot be linked. Supplied tests can miss errors. Alternate architectures and obfuscated code are not evaluated, and Juliet results need not generalize to complex vulnerabilities. #### Why it fits this collection Provides a compiler-feedback and candidate-ranking approach with clear distinctions between matching and test-based evidence. #### Publication and review notes This May 2026 preprint is within the six-month fallback window and is explicitly under review. The pinned code root has no license file; inspected generator/test-set metadata exposes no license declaration. #### Primary sources 1. 2. 3. 4. 5. 6. ### Binary Decompilation LLM with Feedback-Driven Multi-Turn Refinement > AutoDecompiler trains function-level decompilation models to revise assembly- or pseudocode-derived outputs using compilation, execution and I/O feedback. Its reinforcement-learning design combines diagnostic feedback with rewards for valid code, tested behavior, syntax and data-flow structure. - Authors: Peipei Liu; Jian Sun; Mingzhe Xing; Yicheng Zeng; Zhaoteng Yan; Lixiao Zhang; Li Chen; Dan Li - Venue: arXiv - Status: Preprint - Publication / posting date: June 15, 2026 - Date source: First arXiv submission on 2026-06-15; the reviewed v2 revision is 2026-10-03, not a separate publication. - First arXiv submission: June 15, 2026 - arXiv: 2606.16162 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses C adaptations of HumanEval and MBPP with validation feedback; finite tests do not establish general equivalence. HumanEval also informs reward-weight selection, and base-model pretraining exposure cannot be ruled out. Refinement is context-limited, whole-program dependencies are not recovered, and unseen toolchains or protected binaries remain limitations. #### Why it fits this collection Adds reinforcement-learning-trained use of program feedback, with separately recorded first submission and latest revision. #### Publication and review notes First submitted 2026-06-15; reviewed v2 is dated 2026-10-03. The arXiv record uses the shorter catalog title, while the v2 PDF/HTML use a longer title beginning “AutoDecompiler: Reinforcement-Learning-Trained”; eight authors match. Zenodo version 23120286 lists code/data archives under CC BY 4.0. The inspected Hugging Face model has no license metadata. #### Primary sources 1. 2. 3. 4. 5. 6. ### The Evolution of Binary Decompilation in the Modern Era: A Taxonomy, Literature Review, and Future Perspectives > This survey maps traditional, dynamic, matching and neural decompilation approaches, then organizes type recovery, control-flow restructuring, naming and refinement tasks alongside evaluation metrics and benchmark choices. An accompanying repository provides the reviewed literature list. - Authors: Omar Abusabha; Sungjae Hwang - Venue: arXiv - Status: Preprint - Publication / posting date: August 25, 2026 - Date source: First arXiv submission date; no separate proceedings or journal publication was verified. - First arXiv submission: August 25, 2026 - arXiv: 2608.24955 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The search ends in December 2025 and focuses on peer-reviewed studies of C-origin binaries. Selection and categorization involve manual judgment. Reported tool capabilities reflect surveyed publications, not necessarily current implementations. It is a literature synthesis, not a newly reproduced cross-tool performance benchmark or a complete account of 2026 preprints. #### Why it fits this collection Provides a structured map for finding decompilation techniques, benchmarks and the assumptions behind their evaluation. #### Publication and review notes The manuscript says under review at ACM Computing Surveys. The paper is CC BY 4.0. The pinned repository has a README and 72-row bibliography CSV, not a decompiler implementation; no separate repository license was established. #### Primary sources 1. 2. 3. 4. 5. 6. ### SoK: Are LLMs Reliable at Source Code Recovery? A Taxonomy and Empirical Evaluation > This SoK organizes LLM-assisted source-recovery designs and separates compilation, readability, structural and behavioral metrics. Its controlled study varies architecture, compiler optimization and symbol availability, with smaller ablations for input representation, model roles and source language. - Authors: Varun Kohli; Lee Bing Cheng; Nur Hazim Ghazali; Gao Yuze; Daryl Poon; Dinil Mon Divakaran - Venue: arXiv - Status: Preprint - Publication / posting date: October 8, 2026 - Date source: First arXiv submission date; no separate proceedings or journal publication was verified. - First arXiv submission: October 8, 2026 - arXiv: 2610.11556 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The 45,000 cases are variants of 500 functions, not independent programs. Input/language ablations use 50 functions; translated language variants were produced with an LLM and checked using finite I/O tests. The study assumes a derivable call interface, is prompt-sensitive and cannot exclude ExeBench pretraining exposure. Test agreement and relocation-masked byte matching have different assumptions. #### Why it fits this collection Adds a recent evaluation taxonomy and controlled evidence for comparing source-recovery methods without collapsing distinct correctness signals. #### Publication and review notes The arXiv v1 article is CC BY 4.0. Its anonymous artifact was readable in a browser; the page shows an October 1 snapshot available until 2027-03-29, without a full Git commit. The inspected README says a fresh database cannot directly re-score shipped generation files; redrawing supplied CSV results is a separate step. Artifact licensing was not established from the inspected README/root list. #### Primary sources 1. 2. 3. 4. ### PrismaCoder: Pushing the Boundaries of Open Multimodal Code Intelligence through Decomposed Rubric Synthesis > Trains visual-code models using separate code and rendered-output rubrics for data filtering and reinforcement learning. Relevant evaluations include rebuilding webpages, charts and vector graphics from images. - Authors: Qiushi Sun; Jingyang Gong; Yang Liu; Qiaosheng Chen; Zhangyue Yin; Zixian Huang; Hanxu Hu; Jing Xiong; Fangzhi Xu; Haochen Tan; Haoli Bai; Lifeng Shang; Xiaoguang Li; Ben Kao; Qipeng Guo; Lingpeng Kong; Jiahui Gao - Venue: arXiv - Status: Preprint - Publication / posting date: October 14, 2026 - Date source: First arXiv submission; no reviewed venue publication is established. - First arXiv submission: October 14, 2026 - arXiv: 2610.20538 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2610.20538 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations Combines visual reconstruction with text-driven generation. Judge scores do not establish behavioral equivalence. Training and evaluation share some judge families; the human check uses 100 samples. Instruction n-gram filtering cannot exclude all pretraining exposure. #### Why it fits this collection Provides a recent approach to reconstruction from rendered evidence. #### Publication and review notes Work in progress. DataCite confirms the DOI despite the arXiv pending label. The project code link is pending; the dataset API returned HTTP 401 anonymously. Reviewed model inventories include 9B and 35B-A3B-SFT with MIT card metadata. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Reveree: Diagnosing LLM Reverse-Engineering Agents > Evaluates reverse-engineering agent traces through flag recovery, eight analysis milestones and action profiles. Deterministic checks and an outcome-blinded LLM judge help locate failures beyond a single solve-rate score. - Authors: Hadjer Benkraouda; Hongyu Cai; Berkay Celik; Gang Wang - Venue: arXiv - Status: Preprint - Publication / posting date: September 1, 2026 - Date source: First arXiv submission; no reviewed venue publication is established. - First arXiv submission: September 1, 2026 - arXiv: 2609.01185 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.01185 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Uses 88 public CTF challenges and nine models; all four prompting strategies are compared on four models. Evaluation fixes the D-CIPHER harness and uses one attempt per setting. One expert checks 15 traces; agreement on judged comprehension stages is 53/60. Recall and surface-perturbation probes do not eliminate contamination. #### Why it fits this collection Adds process-level evaluation for binary-analysis agents. #### Publication and review notes Reviewed arXiv v1 and registered DOI. The paper announces a release, but the reviewed manuscript does not identify a dedicated artifact URL. #### Primary sources 1. 2. 3. ### From Code to Requirements: Agentic Reverse Engineering of Business Rules at Enterprise Scale > Uses seven agents and human review to recover business requirements from source, tests, configuration and documentation. A reported enterprise migration checks extracted rules against production-defect records. - Authors: Garima Agrawal; Prasun Das; Priyanka L; Minisha N; Akshay Sarvade; Hemath Manivanan; Sravani Joshna; Prasad Kalyansundaram - Venue: arXiv - Status: Preprint - Publication / posting date: September 19, 2026 - Date source: First arXiv submission; no reviewed venue publication is established. - First arXiv submission: September 19, 2026 - arXiv: 2609.22719 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.22719 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evidence covers one enterprise Java programme and one legacy pilot. The cost comparison uses a modeled manual baseline with asymmetric accounting. Static analysis misses some runtime and external rules; coverage does not establish completeness. Confidential inputs limit independent reproduction. #### Why it fits this collection Extends application reconstruction to recovering behavioral specifications. #### Publication and review notes Reviewed the September 2026 preprint and registered DOI. No dedicated public code or dataset was verified. Reported efficiency is an author case-study result. #### Primary sources 1. 2. 3. ### SWE-Game: Can Coding Agents Build the Games We Want? > Evaluates construction, completion, repair and Godot-to-Unity porting against executable reference games. Evaluator-owned probes and input replays check gameplay behavior, while visual rubrics assess presentation separately. - Authors: Xiaoyu Chen; Lai Wei; Jin Wang; Xiangyu Zou; Ruochen Fan; Enze Luo; Mingzhe Yao; Jiahui Zhu; Yuhua Wen; Linghe Kong; Weiran Huang - Venue: arXiv - Status: Preprint - Publication / posting date: September 27, 2026 - Date source: First arXiv submission; the reviewed version is identified separately. - First arXiv submission: September 27, 2026 - arXiv: 2609.33678 - Reviewed arXiv version: v3 - DOI: 10.48550/arxiv.2609.33678 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The 247 tasks derive from 41 games. Inputs vary by task; porting receives Godot source, so this is not purely black-box reconstruction. Each model uses one framework, confounding their effects. Finite scenario checks and 100-game functional validation do not establish general gameplay equivalence. #### Why it fits this collection Adds executable checks for reference-guided game reconstruction and cross-engine behavior preservation. #### Publication and review notes First submitted September 27; reviewed v3 dated October 7. No author-linked code or dataset release was verified in the reviewed manuscript. #### Primary sources 1. 2. 3. ### MirrorCode: AI can rebuild entire programs from behavior alone > Tests reimplementation of 25 command-line programs using execute-only reference access, documentation and visible examples. Separate scoring environments compare exact outputs on visible and held-out end-to-end tests. - Authors: Tom Adamczewski; David Owen; David Rein; Florian Brand; Giles Edkins; Allen Hart; Daniel O'Connell - Venue: arXiv - Status: Preprint - Publication / posting date: June 29, 2026 - Date source: First arXiv submission; the reviewed version is identified separately. - First arXiv submission: June 29, 2026 - arXiv: 2606.30182 - Reviewed arXiv version: v2 - DOI: 10.48550/arxiv.2606.30182 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Targets are scoped, deterministic, stateless programs with text output. Test agreement is not universal equivalence or code-quality assessment. A memorization screen flags possible exposure for 17 targets. Large inference budgets and scaffold choices limit comparisons with cheaper benchmarks; three targets remain private. #### Why it fits this collection Directly evaluates sustained reconstruction from observable software behavior. #### Publication and review notes June 29 first submission, July 17 v2: a six-month-window candidate. Distinct from ProgramBench, explicitly compared in the paper. The pinned repository has an MIT root license and public harness/task definitions, excluding private tasks; target-program licensing is separate. #### Primary sources 1. 2. 3. 4. 5. ### On the Viability of Requirements Generation from Code: An Experience Report > Studies a RAG-based, human-supervised pipeline for recovering requirements and code traces from two projects. It also tests deliberate generation of unimplemented requirements and requirements smells (potential quality issues), exposing verification and labeling difficulties. - Authors: Alexander Korn; Jone Bartel; Max Unterbusch; Andreas Vogelsang - Venue: IEEE REW 2026 / AIRE - Status: Conference paper - Publication / posting date: August 2026 - Date source: IEEE-deposited Crossref proceedings month; first arXiv submission was June 24, 2026. - First arXiv submission: June 24, 2026 - arXiv: 2606.25550 - Reviewed arXiv version: v1 - DOI: 10.1109/rew72749.2026.00023 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The 188 generated requirements come from a student web application and Mattermost Desktop, using one model and PhD evaluators. Prompt choices, accumulated feedback and author-resolved labels affect validity. Findings concern this small experience study, not all code-to-requirements methods. #### Why it fits this collection Adds negative evidence and validation limits for recovering application specifications from code. #### Publication and review notes Publication identity is verified through IEEE-deposited Crossref metadata and the official AIRE program; direct IEEE access returned an empty HTTP 202 response. Fulltext review uses arXiv v1. Figshare v4 declares CC BY 4.0 and its README describes data, prompts and an implementation. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Khost: KVM-based Near Native MCU Firmware Rehosting > Extends KVM with MCU instruction handling, memory mapping and interrupt modeling to rehost firmware on ARMv8-A hosts. An MMIO monitor and firmware wrapper support peripheral interaction and coverage-guided testing. - Authors: Chunlin Wang; Yicheng Yang; Yuan Zhang; Haoyu Xiao; Yifan Zhang; Jiarun Dai - Venue: USENIX Security '26 - Status: Conference paper - Publication / posting date: August 2026 - Date source: Publication month in the official USENIX proceedings BibTeX. - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The prototype needs ARMv8-A with 32-bit compatibility and EL2 virtualization. Some coprocessor operations need added emulation, and entry-point or basic-block recovery can require manual correction. Peripheral approximations can cause false positives; evaluation covers two benchmarks and 12 firmware images, not arbitrary devices. #### Why it fits this collection Adds a concrete firmware execution-recovery substrate and its architecture constraints. #### Publication and review notes Official proceedings give August 2026, pages 573–592. Reviewed pinned README and Apache-2.0 root license; dependencies and firmware licensing are separate. The paper-linked Zenodo v1.02 metadata declares CC BY 4.0 and lists a 65.7 MB archive. #### Primary sources 1. 2. 3. 4. 5. ### RFCLLM: Evaluating LLMs' Reasoning Ability of Network Protocol State Machines > Tests reasoning over protocol state machines using 1,482 questions across 16 protocols. Four context settings distinguish RFC retrieval from reasoning over supplied transitions; tasks cover next states, conditions, predecessor states and paths. - Authors: Anqi Chen; Dan Goldwasser; Cristina Nita-Rotaru - Venue: Findings of EMNLP 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: Author arXiv record reports acceptance to Findings of EMNLP 2026; a proceedings publication date was not verified. - First arXiv submission: September 11, 2026 - arXiv: 2609.13389 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluates reasoning, not a new FSM extractor or implementation reconstruction. Gold FSMs were prepared by one author; judge agreement was checked on 50 instances by the three authors. Packet formats, error handling, configurations and real code mappings are outside scope. Results depend on context, judges and output budgets. #### Why it fits this collection Provides a bounded validation reference for using LLMs to interpret recovered or documented protocol models. #### Publication and review notes Reviewed September 11 v1. Acceptance is author-reported. The author-linked anonymous artifact exposes README, scripts and results; its UI lists access until December 16, 2026, but no full Git commit or root license was established. #### Primary sources 1. 2. 3. ### SoK: A Large-Scale Empirical Study of Emulation-Based Dynamic Analysis Research for ARM Cortex-M Firmware (Extended Version) > Organizes 24 MCU analysis tools into configuration recovery, emulation, fuzzing and diagnosis stages, then evaluates the runnable, pipeline-compatible subset on 4,571 filtered Cortex-M firmware images. Studies where recovered configurations and emulation artifacts fail to support later analysis. - Authors: Hongyuan Li; Ke Wang; Wei Zhou; Le Guan - Venue: arXiv (extended version) - Status: Preprint - Publication / posting date: September 30, 2026 - Date source: Dates this extended arXiv release. Author-reported NDSS 2027 acceptance is recorded separately and is not a 2027 publication claim. - First arXiv submission: September 30, 2026 - arXiv: 2609.38872 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Excludes tools requiring unavailable manuals, source or hardware context, so this is not a uniform execution comparison of all 24 tools. ISA identification, admission thresholds and sampled crash diagnosis involve empirical judgments; findings do not generalize to other architectures. Reported crashes are not confirmed vulnerabilities. #### Why it fits this collection Adds evidence on the practical limits of reconstructing executable environments for black-box firmware. #### Publication and review notes The arXiv comment calls this an extended version of a paper accepted to NDSS 2027; the manuscript has a placeholder DOI and no final proceedings date is assigned. Pinned framework README describes a 20-image functional check. Firmware is not redistributed; OTACap access is under NDA. No root code license was established. #### Primary sources 1. 2. 3. 4. ### Protocol Reverse Engineering via Deep Transfer Learning > Transfers field-boundary patterns from standardized protocol traces labeled by Tshark to poorly documented target protocols. A source-selection stage chooses related protocols, and a neural domain-adaptation model infers message syntax from their shared patterns. - Authors: Yanyang Zhao; Zhengxiong Luo; Wenlong Zhang; Feifan Wu; Yuanliang Chen; Fuchen Ma; Qi Xu; Heyuan Shi; Yu Jiang - Venue: Proceedings of the ACM on Software Engineering / FSE 2026 - Status: Journal article - Publication / posting date: June 30, 2026 - Date source: ACM-deposited Crossref print/online publication date; the author-hosted manuscript retains placeholder publication metadata. - DOI: 10.1145/3797124 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Recovers message syntax, not state transitions. Evaluation uses 12 protocol variants; payload noise can distort source selection, while encrypted, compressed or obfuscated traffic needs separate preprocessing. Camera experiments supplement format metrics, but the four reported issues were vendor-known and do not establish complete protocol recovery. #### Why it fits this collection Adds a transfer-learning approach to recovering undocumented message formats without parser source code. #### Publication and review notes June 2026 is a strong six-month-window supplement. Fulltext was read from the public PDF explicitly linked by coauthor Fuchen Ma; its February date and placeholder DOI are not used as final metadata. The publisher PDF previously returned 403. Crossref confirms nine authors, volume 3(FSE), pages 636–656 and CC BY 4.0 for the version of record. No author-linked implementation release or code license was verified. #### Primary sources 1. 2. 3. ### Decompiling Quantum Assembly into Structured Programs > Quelle recovers library calls, loops, functions and symbolic parameters from compiled OpenQASM. It removes routing artifacts, proposes structured reconstructions and checks them against circuit semantics, retaining gate-level fallbacks when recovery fails. - Authors: Pingchuan Ma; Zhantong Xue; Zongjie Li; Qixin Zhang; Yuxuan Du; Zhaoyu Wang; Yuguang Zhou; Shuai Wang; Xiaoqin Zhang - Venue: arXiv - Status: Preprint - Publication / posting date: October 4, 2026 - Date source: First arXiv submission; no formal proceedings publication was verified. - First arXiv submission: October 4, 2026 - arXiv: 2610.05012 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2610.05012 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Scope is quantum circuits with ideal-device semantics, not original-source identity. Dense checks use a 1e-6 tolerance; larger circuits additionally trust rewrite bookkeeping, an unchecked wide H-conjugation identity and QCEC. Dynamic circuits and timed-out checks remain unverified. Algorithm naming needs templates, and deliberate obfuscation is outside the evaluated scope. #### Why it fits this collection Adds compiler-output structure recovery with explicit correctness-check boundaries in quantum software. #### Publication and review notes Reviewed October 4 v1 and DataCite identity. The article is CC BY 4.0. No dedicated author-linked implementation or artifact release was verified from the manuscript and targeted searches. #### Primary sources 1. 2. 3. ### Stage-Supervised Latent Reasoning for Single-Shot JavaScript Deobfuscation > Uses intermediate Webcrack rewrites to supervise Coconut-style latent reasoning for JavaScript deobfuscation. Training exposes staged code transformations; inference receives obfuscated code and generates a cleaned program in one shot. - Authors: Rong Feng; Suman Saha - Venue: arXiv - Status: Preprint - Publication / posting date: September 22, 2026 - Date source: First arXiv submission; no formal proceedings publication was verified. - First arXiv submission: September 22, 2026 - arXiv: 2609.27058 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.27058 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations A work-in-progress study of one 3B backbone: 100 programs sampled from the 300 smallest benchmark inputs, split 60/20/20. Of 20 test outputs, 10 parsed and 8 matched teacher-derived outputs; the reported 80% is conditional on valid syntax. Semantic checks include manual inspection; stronger baselines and stage ablations remain future work. #### Why it fits this collection Explores how deterministic recovery stages can supervise learned code deobfuscation. #### Publication and review notes Reviewed September 22 v1, explicitly labeled WIP, with a registered arXiv DOI. Article license is CC BY 4.0. Webcrack is a cited upstream supervision tool, not this paper’s implementation release; no dedicated author code, weights or training-artifact license was verified. #### Primary sources 1. 2. 3. ### Faultless: A Program Equivalence Technique for Validating and Evaluating Neural Decompilers > Compares neural-decompiler C output with deterministic decompilation or reference functions using symbolic execution and a specialized memory model. It supports both analyst-facing validation and model evaluation without requiring the surrounding codebase. - Authors: Luke Dramko; Claire Le Goues; Edward Schwartz - Venue: arXiv - Status: Preprint - Publication / posting date: September 28, 2026 - Date source: arXiv v1 submission date; no formal publication venue was verified. - First arXiv submission: September 28, 2026 - arXiv: 2609.34089 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.34089 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Function-level checks abstract away side-effect ordering and some compiler details; configurable options further relax return, argument and type conditions. The implementation has explicit heap-related soundness limitations and requires compatible loop structure; unsupported C features and context-independent dependency assumptions also limit coverage. Failure to establish equivalence is not proof of inequivalence. Evaluations use filtered realtype and ExeBench pairs, not unrestricted whole-program equivalence. #### Why it fits this collection Adds a concrete validation method for recovered code while exposing the assumptions and unsound cases hidden by an unconditional equivalence label. #### Publication and review notes The three-author order and first-submission date follow arXiv v1. DataCite records the arXiv DOI as findable, registered on 2026-09-29, despite the abstract page’s pending-registration label. The paper is CC BY-SA 4.0. The author-linked public repository was reviewed at 059023d874f4103b5e645a9d6d6ddbdb2bbb6da0; its root license is MIT and README calls the Python/tree-sitter/Z3 implementation a proof of concept. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### A Memorization Floor for LLM Refinement of Decompiled Code > Studies whether LLM refinement of decompiled C recovers identifiers from input evidence or prior knowledge. Within-item ablations and output-matched chance baselines test naming gains on textbook and newly authored functions, including a second-model replication. - Authors: Muhammad Asjad - Venue: arXiv - Status: Preprint - Publication / posting date: September 15, 2026 - Date source: arXiv v1 submission date; the artifact deposit date is separate. - First arXiv submission: September 15, 2026 - arXiv: 2609.17236 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.17236 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The study uses 25 textbook and 20 author-written small functions, GCC/Ghidra on x86-64, and one prompt per model. Operations remain visible and the ablation also changes idiom-recognition cues, so its bounded null does not prove memorization or absence of input use. No registered hypothesis was confirmed; the correctness measure failed its discrimination gate; original T3 per-item artifacts were lost and re-executed, changing precision. Most findings use one refiner, and the later second-model extension is distinct from the initial preregistration. #### Why it fits this collection Provides controls for interpreting apparently readable or well-named recovered code and cautions against treating naming scores as semantic recovery. #### Publication and review notes Single-author arXiv v1; no formal venue was verified. DataCite confirms the arXiv DOI was registered on 2026-09-16 despite the abstract page’s pending label. The manuscript uses arXiv’s non-exclusive distribution license. The paper’s Zenodo concept DOI resolves to record 22121473, version 1.1.0, dated 2026-08-27, declaring CC BY 4.0 for a 9,639,907-byte replication ZIP. #### Primary sources 1. 2. 3. 4. 5. 6. ### The Deception Delta: Adversarial Evaluation of LLM-Based Smart Contract Bytecode Forensics > Evaluates how language models interpret raw EVM bytecode from purpose-built deceptive and control contracts. It distinguishes recognizing a hidden transfer mechanism from correctly judging its risk, using model judges alongside judge-independent checks. - Authors: Timo Schefold - Venue: ACM CCS 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: Official ACM CCS 2026 accepted-paper list confirms acceptance, not a publication date. The reviewed arXiv v2 revision is dated 2026-10-06. - First arXiv submission: September 12, 2026 - arXiv: 2609.14098 - Reviewed arXiv version: v2 - DOI: 10.48550/arxiv.2609.14098 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The main evaluation covers 22 models and 13 synthetic contracts using single-shot raw bytecode, without execution tools, source retrieval or on-chain context. Its 8,528 analyzed responses exclude refusals and pending runs. Gold labels come from one expert; some judges also belong to evaluated model families. Ground-truth checks vary across contracts, including owner/selector-only checks and no dedicated EVM tests for two injection variants. These results neither measure deployed-contract prevalence nor generalize to interactive reverse-engineering agents. #### Why it fits this collection Adds a bounded failure-mode evaluation for interpreting executable bytecode, especially the gap between describing behavior and assigning a trustworthy safety verdict. #### Publication and review notes The official CCS list confirms the single-author title; arXiv v2 corrects the September v1. The manuscript prints ACM DOI 10.1145/3830454.3846626 and future conference details, but its Crossref lookup returned 404 during review; no publisher publication date or container fields are asserted. The DOI field is the separately registered arXiv DOI. Article and Zenodo metadata declare CC BY 4.0. The concept artifact resolves to record 23164989, v1.0.2, dated 2026-10-05; its metadata describes ERRATA and a 53,006,308-byte ZIP. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Decoding What iOS Location Services Send to Apple: An LLM Is an Unreliable Analyst but a Useful Toolmaker > Compares direct LLM recovery of Apple PBCodable schemas with an AI-written Extractor checked against compiled synthetic fixtures, published descriptors and captured traffic. It shows how plausible recovered schemas can silently decode values incorrectly. - Authors: Douglas Leith - Venue: arXiv - Status: Preprint - Publication / posting date: October 15, 2026 - Date source: First arXiv submission; the reviewed version is v1, not a verified proceedings publication. - First arXiv submission: October 15, 2026 - arXiv: 2610.21597 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The direct-agent study uses 17 seeds with 7,788 field occurrences, 4,987 distinct. Apple's true schemas remain unpublished; synthetic tests share the recovered template's assumptions. Traffic comes from one jailbroken iPhone 8 on iOS 16.7.11. Matching fields in newer OS binaries does not verify their network behavior. The maintained code also documents estimated or unresolved fields. #### Why it fits this collection A concrete binary-to-protocol-schema recovery study that separates parseable output from verified interpretation. #### Publication and review notes ArXiv names Douglas Leith; the manuscript uses D.J. Leith. No repository-wide license was verified. #### Primary sources 1. 2. 3. 4. ### Recall-Oriented Precise Binary-to-Source Function Matching > BScout matches decompiled functions to a source corpus using chunked embeddings and inlining-aware training. Existing matches provide positional clues to expand candidates; LLM selection and structural filters refine the resulting correspondences. - Authors: Junlin Li; Jianjun Huang; Wei You; Bin Liang - Venue: arXiv - Status: Preprint - Publication / posting date: October 16, 2026 - Date source: First arXiv submission; the reviewed version is v1, not a verified proceedings publication. - First arXiv submission: October 16, 2026 - arXiv: 2610.23546 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations BinKit-BCSA covers 3,904 small-utility binaries; Large-10 covers larger projects only at x86-64/O2. Some anomaly thresholds come from FreeCAD in Large-10. Incomplete ground truth, sparse anchors and source-corpus coverage limit conclusions. Function chunks are encoded independently, and extra refinement trades precision and cost against recall. This is correspondence retrieval, not proof of source recovery or semantic equivalence. #### Why it fits this collection Helps identify source origins and reused components in stripped binaries, including inlined functions. #### Publication and review notes Reviewed arXiv v1 and its four-author order. The paper promises a replication package upon formal peer-reviewed publication; no dedicated public implementation or license was verified. #### Primary sources 1. 2. ### SatBleed: Security of Commoditized Communication Modules in Satellites > Studies satellite communication modules through hardware inspection, firmware reverse engineering, protocol analysis, partial rehosting and targeted testing. A component-level threat model connects recovered data flows to security boundaries. - Authors: Ulysse Planta; Julian Rederlechner; Martin Strohmeier; Mathias Fischer; Ali Abbasi - Venue: IEEE S&P 2026 - Status: Conference paper - Publication / posting date: May 18, 2026 - Date source: IEEE's Crossref publication date, corroborated by CISPA; October 5 is the later arXiv deposit. - First arXiv submission: October 5, 2026 - arXiv: 2610.06258 - Reviewed arXiv version: v1 - DOI: 10.1109/SP63933.2026.00213 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Detailed assessment covers three vendors in isolated laboratory setups, not operational satellite links. The reported 28 of 64 active missions are passively inferred as plausibly vulnerable, not actively compromised; encrypted or compressed telemetry is excluded. Manual analysis cannot establish completeness, and vendor-specific findings do not generalize to all modules. LLM use was editorial, not an evaluated reversing agent. #### Why it fits this collection Documents firmware and undocumented-protocol recovery with explicit hardware and evidence constraints. #### Publication and review notes IEEE and CISPA establish May publication; the October arXiv v1 is the reviewed full text. The pinned supplement README describes a trimmed fuzzer without case-specific oracles and STIX bundles. Working exploit payloads and the inferred mission list are withheld. No repository-wide license was verified. #### Primary sources 1. 2. 3. 4. 5. 6. ### POZZER: A Power Side Channel-guided Fuzzer for Black-Box Embedded Systems > Builds a noise-tolerant pseudo execution-flow graph from one power trace per test input, using newly observed behavior as LibAFL feedback. It explores embedded firmware without access to its binary, source or instrumentation. - Authors: Pouya Narimani; Kseniia Rogova; Addison Crump; Martin Mohl; Meng Wang; Ulysse Planta; Pansilu Pitigalaarachchi; Ali Abbasi - Venue: arXiv - Status: Preprint - Publication / posting date: September 20, 2026 - Date source: First arXiv submission; the reviewed version is v1, not a verified proceedings publication. - First arXiv submission: September 20, 2026 - arXiv: 2609.23583 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Requires physical power measurement, known input pins and setup calibration. Evaluation covers 15 targets on two Cortex-M platforms and two commercial devices; benchmark coverage is measured by later instrumented replay, not recovered directly from power traces. Results depend on seeds and hardware, and long traces reduce throughput. The graph is not a proven control-flow graph or recovered program. Real-device harnesses are withheld. #### Why it fits this collection Provides evidence-driven behavior exploration when firmware bytes and conventional tracing are unavailable. #### Publication and review notes The first submission is September 20, not the later announcement date. Reviewed the full eight-author v1 list. Open Science promises code and results after acceptance; no dedicated public artifact or license was verified. #### Primary sources 1. 2. ### Between the Commits: Process, Error, and Claim Reliability in a Wholly AI-Authored Codebase > Studies development of the Extractor reverse-engineering tool through commits, available session logs and code-provenance tracing. Taxonomies separate instruction intent, change triggers and agent claims, exposing errors corrected before commits that ordinary repository history misses. - Authors: Douglas Leith - Venue: arXiv - Status: Preprint - Publication / posting date: September 24, 2026 - Date source: First arXiv submission; the reviewed version is v1, not a verified proceedings publication. - First arXiv submission: September 24, 2026 - arXiv: 2609.29744 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations One codebase with human-directed work, no human-coded comparison. The 14.3% figure is 15 of 105 audited generation events, including test defects and stale tests, not a defect rate per source line or in shipped code. LLM scoring has sampled human calibration; transcripts are incomplete and the archive omits per-response evidence bundles. This companion study does not independently corroborate the related schema-recovery results. #### Why it fits this collection Adds provenance and claim-auditing methods for agent-built reverse-engineering tools. #### Publication and review notes The author's pinned reproducibility-archive README documents lost sessions and unreproducible response-scoring evidence. The repository exposes an archive and Git-history material. No repository-wide license was verified; the project link points to the artifact landing page. #### Primary sources 1. 2. 3. 4. ### Schema: Discovering Unknown Environments via Agentic Program Induction > Infers executable models of game state and transition rules from interaction. Agents revise these models against recorded history, search within them, and compare predicted observations with real outcomes while executing plans. - Authors: Guanning Zeng; Jiani Wang; Wenjie Ma; Shaofeng Yin; Chenyang Wang; Shichen Liu; Angjoo Kanazawa; Wode Ni; Xiuyu Li; Andrea Zanette; Haiwen Feng - Venue: arXiv - Status: Preprint - Publication / posting date: September 30, 2026 - Date source: arXiv v1 first-submission date; the July project announcement and October repository revision are separate. - First arXiv submission: September 30, 2026 - arXiv: 2609.39140 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.39140 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses 25 public ARC-AGI-3 games, 21 public DiG-bench games and MazeBench. Matching recorded transitions establishes history consistency, not original-source recovery or correctness on unseen states. RHAE measures completion and environment-action efficiency, not elapsed time or total computation. Component ablations cover ten ARC games; MazeBench compares recorded trajectories with a leaderboard median rather than a controlled human experiment. Transfer to arbitrary software or stochastic environments is not demonstrated. #### Why it fits this collection Provides a concrete observation-to-program-and-replay loop for black-box behavioral reconstruction, while distinguishing a useful predictive model from a complete game clone. #### Publication and review notes The eleven-author v1 list and title match arXiv and the current project. DataCite registered the arXiv DOI on 2026-10-01; the article uses arXiv’s non-exclusive distribution license. The author-linked MIT code was inspected at 84c075fadfe937b97a3d1ad2acb42d1233f55ffe. Benchmark engines/services retain separate requirements. The linked trace dataset README at 0a0858a9e61a68d1e83142d9e4e3d66fc779c403 describes 50 July ARC trajectories, including a mixed-model collection. No trace-data license was verified. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Agentic Reverse Engineering: From I/O to Code with Discovery Agent > Synthesizes executable programs from input/output observations using LLM-guided evolutionary search, progressively revealed examples, simple-to-complex mutations and execution-error feedback. An active variant chooses inputs and queries a hidden reference program. - Authors: Yihong Dong; Jiaru Qian; Haoran Zhang; Peixu Wang; Binhua Li; Zhi Jin; Yongbin Li; Ge Li; Xiaokang Yang; Xue Jiang - Venue: NeurIPS 2026 - Status: Conference accepted - Publication / posting date: 2026 (exact date not verified) - Date source: Official NeurIPS 2026 poster listing confirms acceptance, not a proceedings publication date. First arXiv submission was 2026-05-14; reviewed v2 was revised on 2026-10-18. - First arXiv submission: May 14, 2026 - arXiv: 2605.15334 - Reviewed arXiv version: v2 - DOI: 10.48550/arxiv.2605.15334 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations IO2CodeBench has 125 generated tasks spanning basic operations, algorithms, geometry and image-to-value mappings, normally with eight visible and fifteen held-out examples. Active exploration covers a 25% subset from each level. Multimodal results average sample pass ratios, while other levels count tasks passing every held-out example. Finite test success does not establish original-source recovery or complete equivalence; arbitrary applications and stateful services are not evaluated. #### Why it fits this collection Provides a concrete observation-to-program reconstruction workflow and separates visible-example fitting from held-out behavior checks. #### Publication and review notes The official poster and pinned repository retain the earlier title From I/O to Code with Discovery Agent; all ten authors match v2 and DataCite. The registered DOI identifies the arXiv work. The paper uses the arXiv non-exclusive license. Author-linked code was checked at ef15827ab7090bf2d227fb1eef51d91b0163339e: its README documents Python 3.10+, provider credentials, benchmark/oracle tasks and experiment runners. No repository-wide code/data license was verified in the reviewed README and root tree. #### Primary sources 1. 2. 3. 4. 5. 6. ### Locate, Then Reason: End-to-End Patch Presence Testing in Stripped Binaries > Locates patch-relevant code in stripped binaries using instruction-aligned retrieval and caller/callee context, then uses an LLM to screen candidate matches and compare patch-specific behavior with vulnerable and patched references. - Authors: Huaijin Wang; Tongda Wang; Zhibo Liu; Yue Zhang; Shuai Wang; Pengfei Hu; Jianzhong Liu; Fangtian Zhong; Shaohua Wang - Venue: arXiv - Status: Preprint - Publication / posting date: October 18, 2026 - Date source: First arXiv v1 submission; no formal venue publication was verified. - First arXiv submission: October 18, 2026 - arXiv: 2610.25071 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2610.25071 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Requires the known source patch and vulnerable/patched reference binaries; it is not source recovery or undisclosed-vulnerability discovery. Evaluation covers 62 CVEs from four C/C++ projects, 124 reference and 496 target binaries, restricted to x86-64, GCC/Clang configurations and one reported reasoning model. Balanced labels do not reproduce deployment prevalence; public patches may be in training data. Uncertain and missing-localization outcomes are reported separately, but binary metrics map them to vulnerable and negative outcomes, respectively; selected accuracy excludes both. #### Why it fits this collection Studies evidence-guided localization and semantic comparison of binary code, including the limits of decompiler-inferred types when judging small fixes. #### Publication and review notes Reviewed the nine-author v1 abstract and full text. The article uses the arXiv non-exclusive license. Its data-availability section promises code, models, data and instructions upon publication; no paper-specific public artifact or artifact license was verified in the reviewed text and focused search. Cited baseline tools are not the PatchAlign release. DataCite registered the matching arXiv DOI on 2026-10-20, despite the abstract page still saying pending. #### Primary sources 1. 2. 3. ### Semantic Validation of Packer Identification Tools: Characterization, Repair, and Downstream Impact > Uses unpacking outcomes as reference evidence to assess packer labels, normalizes heterogeneous tool results, and evaluates complementary signature/heuristic pools with static predicates derived from unpacker implementations. It traces how identification errors affect later unpacking and malware classification. - Authors: Fangtian Zhong; Zhuoyun Qian; Yili Jiang; Jiaqi Huang; Yunming Pang; Xiuzhen Cheng - Venue: arXiv - Status: Preprint - Publication / posting date: May 25, 2026 - Date source: First arXiv submission was 2026-05-25; reviewed v3 was revised on 2026-10-19. No formal publication was verified. - First arXiv submission: May 25, 2026 - arXiv: 2605.25923 - Reviewed arXiv version: v3 - DOI: 10.48550/arxiv.2605.25923 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The corpus is approximately 160,000 Windows PE samples, split into roughly 130,000 for analysis/rule construction and 30,000 for testing. Unpacker failures or partial recovery can compromise the derived reference labels. Family-identification improvements use common pooled-rule configurations, not independently validated patches to seven separate tools. Repair evaluation excludes proprietary implementations and graph/learning-based methods. Results do not establish coverage of other executable formats, all packer families or general semantic equivalence. #### Why it fits this collection Examines the reliability of packer identification as a prerequisite for recovering analyzable binary content; it is a foundation-tool evaluation rather than an agent benchmark. #### Publication and review notes October v3 while retaining the May first-submission date. Its six-author list agrees across the current abstract, versioned PDF and updated DataCite record; v2 lists seven authors and is not combined with v3. The article is CC BY-SA 4.0, which does not license malware samples or third-party tools. Reviewed sources and focused search did not establish a paper-specific public release or its license. #### Primary sources 1. 2. 3. 4. 5. ### State-Aware Generation of Deployable Websites from Visual Prototypes and Requirements > VisStateCoder links visual prototype elements, project files, interaction requirements and render evidence in a project state graph, then uses those links to generate websites and limit subsequent repairs to selected files. - Authors: Ruwei Pan; Junlei Shen; Linhao Wu; Zixiong Yang; Qisheng Zhang; Yifan Li; Tianyu Ma; Yakun Zhang; Lu Zhang; Hongyu Zhang - Venue: arXiv - Status: Preprint - Publication / posting date: October 13, 2026 - Date source: First arXiv v1 submission; no formal venue publication was verified. - First arXiv submission: October 13, 2026 - arXiv: 2610.17861 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2610.17861 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Requires visual prototypes and textual workflow requirements. The five-model Vision2Web evaluation covers up to seven-page HTML/CSS/JavaScript sites with an optional Node.js server; larger projects and React/Vue are untested. Each configuration runs once, without variance or significance estimates. Internal repair checks do not execute interaction workflows; functional scores come from separate benchmark tests. Visual judges and incomplete tests limit conclusions about behavior, maintainability and accessibility. #### Why it fits this collection Studies visual-reference website reconstruction with explicit links between reference elements, code files and repair evidence. #### Publication and review notes DataCite registered the matching arXiv DOI on 2026-10-14. The article uses the arXiv non-exclusive license. The paper states that its implementation, prompts, projects, logs and annotations are released, but an author-linked artifact and code/data license were not verified in the reviewed sources and bounded search. #### Primary sources 1. 2. 3. ### From Dead Code and Static Requirements to Working Engines: Software Revival with Coding Agents > ReviveBench evaluates repair of nonrunning software and source-unavailable implementation of bounded computational and transactional engines from open specifications, using hidden reference-based checks. It also audits grading defects that can wrongly accept or reject reconstructions. - Authors: Tianyu Liu; Dingyuan Dai; Yufan Du; Zhen Yang - Venue: arXiv - Status: Preprint - Publication / posting date: September 28, 2026 - Date source: First arXiv v1 submission; no formal venue publication was verified. - First arXiv submission: September 28, 2026 - arXiv: 2609.36161 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.36161 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Studies ten revival and thirteen bounded engine tasks; reconstruction receives public specifications and three worked examples. Most model/task cells have one or two seeds; the reconstruction matrix reports the best eligible run. Excluded infrastructure failures and differing API adapters limit comparisons. Task-level pass thresholds do not require every check to pass, and CFD passes cannot establish numerical-solver capability. Verifier audits and contamination controls do not prove general equivalence or rule out prior exposure. #### Why it fits this collection Connects software reconstruction with audits of the tests used to judge its correctness. #### Publication and review notes The four-author v1 identity matches arXiv and DataCite, which registered the arXiv DOI on 2026-09-30. The article uses the arXiv non-exclusive license. No author-linked public benchmark/verifier package or its code/data license was verified in the reviewed full text and focused search. #### Primary sources 1. 2. 3. ### IChart2Code: Benchmarking Multimodal Large Language Models for Interactive Chart Code Generation > Benchmarks reconstruction of interactive charts from a reference screenshot, local data and specified actions. Its TRAIL framework uses Developer and Inspector agents with browser interaction traces to diagnose errors and revise the HTML/JavaScript implementation. - Authors: Xu Zhang; Hongzhang Zheng; Zhili Huang; Yaoyi Wang; Ling Xu; Sheng Huang - Venue: arXiv - Status: Preprint - Publication / posting date: September 26, 2026 - Date source: First arXiv v1 submission; no formal venue publication was verified. - First arXiv submission: September 26, 2026 - arXiv: 2609.32413 - Reviewed arXiv version: v1 - DOI: 10.48550/arxiv.2609.32413 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-10-20 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Covers 377 single-file HTML/JavaScript tasks with supplied data and explicit interaction requirements. Four models are evaluated with at most one repair round. Failing the Executability gate gives zero on scored dimensions; other rubric judgments use an MLLM, with human validation on 200 Direct outputs from 100 tasks and two models. Finite interactions and judge agreement do not establish complete application equivalence or recovery of hidden data and unspecified behavior. #### Why it fits this collection Adds an execution-aware benchmark for reproducing visual charts and their specified interactive state changes. #### Publication and review notes The six-author v1 identity matches arXiv and DataCite, which registered the arXiv DOI on 2026-09-29. The article uses the arXiv non-exclusive license. No author-linked public implementation, dataset release or corresponding license was verified in the reviewed full text and focused search. #### Primary sources 1. 2. 3. ### NYU CTF Bench: A Scalable Open-Source Benchmark Dataset for Evaluating LLMs in Offensive Security > NYU CTF Bench packages 200 manually validated challenges from CSAW CTF qualifying and final rounds held between 2017 and 2023, spanning cryptography, forensics, pwn, reverse engineering, web and miscellaneous tasks, with challenge.json metadata and Docker images for server-side challenges. The paper also presents an automated framework that gives LLMs function-calling tools for shell commands, file creation, Ghidra disassembly and decompilation, flag checking and giving up. It evaluates five LLMs and compares their scores with human teams at CSAW 2022 and 2023. - Authors: Minghao Shao; Sofija Jancheska; Meet Udeshi; Brendan Dolan-Gavitt; Haoran Xi; Kimberly Milner; Boyuan Chen; Max Yin; Siddharth Garg; Prashanth Krishnamurthy; Farshad Khorrami; Ramesh Karri; Muhammad Shafique - Venue: NeurIPS 2024 Datasets and Benchmarks - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: The official NeurIPS proceedings and publisher-deposited Crossref metadata identify publication year 2024; the proceedings page’s citation_publication_date metadata reads 2024-12-16, but neither Crossref nor a publisher statement confirms that day, so only the year is recorded. The first arXiv submission date is recorded separately. - First arXiv submission: June 8, 2024 - arXiv: 2406.05590 - Reviewed arXiv version: v3 - DOI: 10.52202/079017-1832 - Sources reviewed: 2026-10-18 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Only 51 of the 200 challenges are reverse engineering (31 qualifying and 20 final), so overall solve rates are not reverse-engineering accuracy. All challenges come from one competition series, categories are imbalanced, and the remaining 367 of the initial 567 challenges, including incident-response tasks, are excluded pending validation. The baseline counts a challenge as solved if any of five attempts succeeds, within a 48-hour limit per model; no statistical tests were run. Among GPT-3.5, GPT-4, Claude 3, Mixtral and LLaMA, the best reverse-engineering rate was 9.80% (GPT-4), and the open models solved nothing. The human comparison uses competition scores from four CSAW events, and the public repository has continued to change after publication, so later runs may not match the paper’s challenge set or framework. #### Why it fits this collection Supplies a public, dockerized CTF challenge set with a reverse-engineering subset; later agent work such as EnIGMA evaluates on it. #### Publication and review notes The 13-author order follows the NeurIPS proceedings page, the PDF, arXiv and Crossref. NeurIPS volume 37 lists pages 57472–57498; arXiv v3 (2025-02-18) matches the reviewed proceedings text. The NeurIPS checklist gives the Zenodo software DOI 10.5281/zenodo.13930622 for the v20241008 benchmark release; it is an artifact identifier, not the paper DOI. The reviewed NYU_CTF_Bench snapshot (2025-09-22) is GPL-2.0, holds the 200-challenge test split and a 55-challenge development split, and is installed through the nyuctf Python package, which clones the repository; challenges need Docker. The paper’s llm_ctf_automation link now redirects to NYU-LLM-CTF/nyuctf_agents, whose reviewed 2026-07-17 snapshot is MIT-licensed and also contains the later D-CIPHER multi-agent system alongside the baseline. Challenge files keep their original authors’ terms. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### From Obfuscated to Obvious: A Comprehensive JavaScript Deobfuscation Tool for Security Analysis > JSimplifier recovers readable JavaScript from obfuscated scripts in three stages. A preprocessor normalizes malformed or mixed-encoding input; a deobfuscator combines AST-based static simplification with selective execution of obfuscated call sites in a Node.js vm context, feeding the results back into the AST; and an optional humanizer renames identifiers with an LLM, adapting HumanifyJS, then formats the output with Prettier. The authors catalog 20 obfuscation techniques in four categories and assemble MalJS (23,212 malicious scripts) and BenignJS (21,209 scripts). They report that JSimplifier processes all 44,421 samples and reduces Halstead length by 88.2% on 1,296 multi-technique JsDeObsBench samples. - Authors: Dongchao Zhou; Lingyun Ying; Huajun Chai; Dongbin Wang - Venue: NDSS 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: The Internet Society's Crossref deposit and the official NDSS paper identify publication year 2026. The PDF footer names the 23–27 February 2026 symposium; no finer publication date is asserted from the event dates. - First arXiv submission: December 16, 2025 - arXiv: 2512.14070 - Reviewed arXiv version: v1 - DOI: 10.14722/ndss.2026.242198 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The headline “100% correctness” is syntactic validity on 400 samples (100 BenignJS, 300 MalJS) checked by parser and by hand; behavioral consistency, judged with Joern CFG/DDG comparison and manual review, holds for 83 of 100 samples. The 20-technique capability test applies each technique to one representative snippet, and the static and dynamic stages alone handle 19; identifier renaming needs the LLM stage. Readability gains come from four LLMs (Claude 3.7 Sonnet, Gemini 2.5 Pro, DeepSeek-R1 and GPT-o3) scoring 60 MalJS pairs on a 0–10 scale; a separate check of GPT-4o-mini renaming on 100 samples found 12% hallucinated names, and the user study had 9 participants. The entropy comparison excludes the LLM stage. MalJS was collected with a security company and BenignJS mixes Tranco top-site scripts with 2,000 clean samples obfuscated by the authors. The authors exclude cryptographic packing, custom interpreters and time-dependent decryption, and note that ES6+ syntax may be downgraded and that vm-based execution carries escape risk. The output is readable JavaScript, not a reconstructed website. #### Why it fits this collection Adds an open-source end-to-end JavaScript deobfuscator with a large real-world evaluation set, complementing the JsDeObsBench benchmark and LLM-based deobfuscation work in recovering readable client-side code. #### Publication and review notes The four-author order follows the PDF, the NDSS paper page and Crossref. The PDF footer gives ISBN 979-8-9919276-8-0 and the DOI; Crossref lists no pages, and no page range was verified. arXiv v1 (2025-12-16) carries the same DOI in its metadata and no venue comment; the reviewed text is the NDSS final PDF. The paper links XingTuLab/JSIMPLIFIER and Zenodo artifact 10.5281/zenodo.17531662, whose DOI identifies the artifact, not the paper. At the reviewed 2025-12-17 commit the repository's LICENSE is GPL-3.0, while package.json still declares MIT; the Zenodo record states GPL-3.0-or-later. The CLI needs Node.js 20 or later, and LLM renaming needs the user's OpenAI or Gemini API key; --model=none runs the AST stages only. Per the artifact appendix, the roughly 3 GB Zenodo archive includes the MalJS malicious samples. The paper credits HumanifyJS for its renaming approach. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### CLAP: Learning Transferable Binary Code Representations with Natural Language Supervision > CLAP (Contrastive Language-Assembly Pre-training) learns assembly-function embeddings aligned with natural-language explanations. A dataset engine compiles Ubuntu C/C++ packages with GCC and Clang at O0–O3 and Os, has GPT-3.5 explain about 2.6 million matching source functions, and fine-tunes a Vicuna-13B “shadow model” on half of those explanations to label more code, yielding 195 million assembly–explanation pairs. A 110M-parameter assembly encoder, using address rebasing, a WordPiece tokenizer and jump-aware embeddings, is first pre-trained on assembly and then contrastively aligned with a text encoder. The embeddings support zero-shot classification by matching code against text prompts. On BinaryCorp-3M similarity search in pools of 10,000 functions, zero-shot CLAP reports 0.836 average recall@1 against 0.571 for fine-tuned jTrans. - Authors: Hao Wang; Zeyu Gao; Chao Zhang; Zihan Sha; Mingyang Sun; Yuchen Zhou; Wenyu Zhu; Wenju Sun; Han Qiu; Xi Xiao - Venue: ACM ISSTA 2024 - Status: Conference paper - Publication / posting date: September 11, 2024 - Date source: ACM's Crossref deposit records print and online publication on 2024-09-11; the September 16–20 ISSTA 2024 conference dates and the arXiv date are not substituted for it. - First arXiv submission: February 26, 2024 - arXiv: 2402.16928 - Reviewed arXiv version: v1 - DOI: 10.1145/3650212.3652145 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Training explanations are generated by GPT-3.5 and a fine-tuned Vicuna model from source code, not written by humans; five experts scored 50 explanations per model, mostly as acceptable. The authors name the Ubuntu-only build environment and the GPT-3.5 explanations as possible sources of bias. Functions are disassembled with IDA Pro 7.6, and functions with fewer than three basic blocks are excluded. Similarity results use BinaryCorp-3M optimization-level pairs, where baselines get a linear probe and jTrans is also fully fine-tuned while CLAP is not; crypto identification (17 algorithms, about 70K functions labeled by name and package metadata) and protocol categorization (18 types) use datasets the authors built from Ubuntu packages, where fine-tuned CLAP beats the baselines while zero-shot CLAP trails the best baseline on crypto. The malware and sorting results are single case studies. Training used 32 A100 GPUs. CLAP produces embeddings and label scores; it is not a decompiler or a malware detector. #### Why it fits this collection Adds assembly representation learning aligned with natural language, which supports zero-shot and few-shot function labeling and similarity search in binary analysis, complementing jTrans and the LLM-based decompilation and summarization records. #### Publication and review notes Crossref records the ISSTA '24 proceedings article, pages 503–515, and a CC BY-NC-SA 4.0 license; its ten-author order matches arXiv. The ACM landing page refused automated access, so publication facts follow Crossref and the reviewed text is arXiv v1 (2024-02-26), the only version, which carries the ISSTA 2024 header with a placeholder DOI. Table 1 gives zero-shot CLAP an average recall@1 of 0.836, while the introduction states 83.3%. The paper links Hustcw/CLAP. At the reviewed 2024-09-28 commit the repository has no license file and holds a case-study notebook, IDA databases and rebased assembly for a bubble sort, SHA-3 and a malware sample identified by its VirusTotal hash, prompt files, human-evaluation screenshots and an IDA processing script; it does not include training code or the 195-million-pair dataset. The README links the Hugging Face models hustcw/clap-asm and hustcw/clap-text, whose cards declare MIT and which load with trust_remote_code. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### CodeArt: Better Code Models by Attention Regularization When Symbols Are Lacking > CodeArt pre-trains a BERT-sized encoder from scratch on 26 million stripped x86-64 functions built from jTrans's BinaryCorp. Instead of relying on symbols, it uses IDA Pro control-flow graphs and a binary data-flow analysis to compute control and data dependences, then restricts self-attention with masks so a token attends only to instructions it transitively depends on or that depend on it, to tokens in its own instruction, and to a global [CLS] token; pre-training masks tokens and perturbs the dependence graph. The authors fine-tune it for binary similarity, malware family classification and type inference. They report improvements over prior models from 53% to 64% recall@1 for similarity in pools of 500, from 49% to 60% LRAP for malware families, and from 74% to 94% average F1 for type inference. - Authors: Zian Su; Xiangzhe Xu; Ziyang Huang; Zhuo Zhang; Yapeng Ye; Jianjun Huang; Xiangyu Zhang - Venue: Proceedings of the ACM on Software Engineering (FSE 2024) - Status: Journal article - Publication / posting date: July 12, 2024 - Date source: ACM's Crossref deposit records print and online publication on 2024-07-12. The July 2024 issue date in the reference format and the FSE 2024 conference dates are not substituted for it. - First arXiv submission: February 19, 2024 - arXiv: 2402.11842 - Reviewed arXiv version: v1 - DOI: 10.1145/3643752 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The model handles x86-64 only, with functions disassembled by IDA Pro and inputs capped at 512 tokens. Similarity is fine-tuned on BinaryCorp-3M and tested on six projects (Curl, Binutils, ImageMagick, SQLite, OpenSSL and PuTTY), with Coreutils for validation, against GNN, GMN, jTrans and DiEmph baselines; on PuTTY, whose functions are short, CodeArt is only comparable to DiEmph. Type inference uses the x86-64 part of StateFormer's dataset with 35 labels and compares with StateFormer's reported results rather than a rerun. Malware classification uses 5,484 VirusTotal and VirusShare samples from the 100 most frequent families, against jTrans and a re-implemented CNN. All gains are relative to these baselines and settings. CodeArt produces embeddings and task-specific predictions; it is neither a decompiler nor a malware detector. #### Why it fits this collection Adds general-purpose pre-training for stripped binary functions that uses program dependences in place of missing symbols, evaluated on similarity, type inference and malware-family tasks that support reverse engineering. #### Publication and review notes Crossref records Proceedings of the ACM on Software Engineering volume 1, issue FSE, pages 562–585, and the seven-author order matches arXiv. The ACM landing page refused automated access, so publication facts follow Crossref and the reviewed text is arXiv v1 (2024-02-19), the only version, which carries the PACMSE reference format and DOI. The abstract lists the three gains in the order similarity, type inference, malware; the contribution list and evaluation assign 49%→60% LRAP to malware family classification and 74%→94% F1 to type inference. The paper links ziansu/codeart. At the reviewed 2025-03-10 commit the repository declares MIT and its README points to an artifacts branch; README-docker.md describes a 3.8 GB Docker image with a Gradio demo and links the PurCL CodeArt-Artifacts collection on Hugging Face, whose checkpoints and datasets, including top-100 malware-family data, declare no license. The REQUIREMENTS file asks for Docker, 64 GB RAM, a 24 GB GPU and up to 100 GB of disk. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### On Benchmarking Code LLMs for Android Malware Analysis > CAMA is a framework for benchmarking how code LLMs read decompiled Android malware. Androguard decompiles each APK into Java functions, and each model returns a structured output per function: a summary, a refined function name and a 0–10 maliciousness score. Two analysis tasks build on these outputs. Malicious-function identification is scored by consistency (whether scores and names stay stable when the model is re-prompted with its own summaries) and by fidelity (how much a LightGBM malware-category classifier loses confidence when the top-scored function descriptors are removed). Malware-purpose summarization is scored by semantic relevance (BLEU, METEOR and ROUGE-L against reference app descriptions). The benchmark holds 118 APKs from 6 categories and 13 families, with 7,542,799 decompiled functions. Of the four models evaluated, StarChat-Beta has the highest maliciousness consistency (0.813, against 0.381 for CodeLlama) and narrowly the highest semantic-relevance scores, while fidelity varies widely across models and removal sizes. Renaming functions with model-suggested names raises fidelity for CodeLlama and StarChat but lowers METEOR by about 10%. - Authors: Yiling He; Hongyu She; Xingzhi Qian; Xinran Zheng; Zhuo Chen; Zhan Qin; Lorenzo Cavallaro - Venue: ISSTA Companion 2025 (LLMSC Workshop) - Status: Conference paper - Publication / posting date: June 11, 2025 - Date source: ACM's Crossref deposit gives online publication and the issued date as 2025-06-11, with a print date of 2025-06-25, the first day of the June 25–28 conference. This entry uses the publisher's online date; the arXiv dates are not substituted. - First arXiv submission: April 1, 2025 - arXiv: 2504.00694 - Reviewed arXiv version: v2 - DOI: 10.1145/3713081.3731745 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations This is an eight-page workshop paper that evaluates four open-source code LLMs: CodeLlama-7b-Instruct, StarChat-Beta and the base-size CodeT5 and PLBART, not current frontier models. CodeT5 and PLBART were fine-tuned for three epochs to produce the output fields, and their maliciousness scores come from a separate DeepSeek-R1-Distill-Llama-70B model, so score-based results do not measure those two models alone; both are also excluded from the renaming study. No function-level ground truth exists: malicious-function identification is measured indirectly through classifier confidence, and the reference app descriptions are GPT-4-generated summaries from the earlier LAMD dataset; the authors note that these surrogates can add noise and bias. The 118 samples are de-duplicated LAMD malware decompiled only with Androguard, and obfuscation is not studied separately. Fidelity scores have standard deviations close to their means, for example 0.332 ± 0.30 for CodeT5 at k = 2. The Zenodo record holds the structured model outputs (function summaries, refined names and maliciousness scores); neither it nor the LAMD record states that it contains the APK samples. CAMA does not detect malware and is not a decompiler. #### Why it fits this collection Adds a benchmark of code LLMs reading decompiled Android malware, complementing DeGuard's identifier recovery and the single Android case study in the USENIX Security 2024 code-analysis study elsewhere in the bibliography. #### Publication and review notes ACM's Crossref deposit gives the ISSTA Companion '25 proceedings, pages 153–160, a CC BY 4.0 license and the same seven authors in order; the arXiv v2 PDF prints the ACM reference and DOI. The workshop name rests on the arXiv comment and the Zenodo description, which both state acceptance to the LLMSC Workshop 2025 of the 34th ACM SIGSOFT ISSTA Companion; Crossref names only the companion proceedings. arXiv v1 is dated 2025-04-01 and v2 2025-04-23. The paper links no code repository. Its outputs are the Zenodo dataset 10.5281/zenodo.15155917 (2025-04-05, CC BY 4.0, a 710 MB CAMA.zip); that dataset DOI is not used as the paper identifier. The samples and reference descriptions come from the LAMD dataset 10.5281/zenodo.14884736, whose 2 MB archive is described as CSV sample information and logs. The ACM landing page refused automated requests, so the review relied on Crossref and the arXiv PDF. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Fool Me If You Can: On the Robustness of Binary Code Similarity Detection Models against Semantics-Preserving Transformations > The paper builds asmFooler to test whether learned binary code similarity detection (BCSD) models keep matching functions after semantics-preserving changes. From 620 baseline x86-64 ELF binaries (coreutils, binutils, PuTTY, nginx, SPEC2006 and others, built with Clang at O0–O3), it generates 9,565 variants using in-place instruction rewriting, basic-block reordering, Obfuscator-LLVM, semantic NOPs and junk code, and it adds a greedy search for dead-code sequences that make dissimilar functions look similar. Across Genius, Gemini, Asm2Vec, SAFE, Trex and BinShot, robustness depends on each model's preprocessing, architecture and features: block reordering drops BinShot's recall from 0.972 to 0.036 but lowers it by under 0.05 for the CFG-based Genius and Gemini. The false-positive attack reaches up to 100% success with 14.75 inserted instructions on average. - Authors: Jiyong Uhm; Minseok Kim; Michalis Polychronakis; Hyungjoon Koo - Venue: Proceedings of the ACM on Software Engineering (FSE 2026) - Status: Journal article - Publication / posting date: June 30, 2026 - Date source: ACM's Crossref deposit records print and online publication on 2026-06-30. The PDF footer's July 2026 publication date and the FSE 2026 conference dates are not substituted for it. - First arXiv submission: February 13, 2026 - arXiv: 2602.12681 - Reviewed arXiv version: v1 - DOI: 10.1145/3797116 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations All samples are x86-64 ELF binaries compiled by the authors from open-source packages and SPEC2006; some packages failed to compile or transform, and the in-place transformation is non-deterministic and not formally verified. The six models evaluated (Genius, Gemini, Asm2Vec, SAFE, Trex and BinShot) exclude jTrans and LLM-based similarity models, so the findings are not shown to transfer to newer or LLM-based systems. Results depend on the transformation budgets the authors set to fit each model's input limits, and semantic NOPs and junk code are inserted only at function entry. Packing, encryption, string obfuscation and commercial protectors such as VMProtect and Themida are out of scope, and adversarial training is left to future work. #### Why it fits this collection Adds a measured study of how code diversification and obfuscation mislead learned binary similarity models, which matters when reverse engineers rely on such models to match functions in transformed binaries. #### Publication and review notes Crossref records Proceedings of the ACM on Software Engineering volume 3, issue FSE, pages 1957–1980, with a CC BY 4.0 license; the PDF footer gives article FSE088. The ACM title capitalizes 'Semantics-Preserving', while arXiv writes 'Semantics-preserving'; the four-author order matches. The ACM landing page refused automated access, so publication facts follow Crossref and the reviewed text is arXiv v1 (2026-02-13), the only version, whose comment states FSE 2026 acceptance. The Data Availability section links Zenodo record 10.5281/zenodo.17116512, a software record named asmFooler (2025-09-11, CC BY 4.0) whose creator is listed as 'anonymous', with a 159 KB artifact archive and a 5 GB dataset archive. No author-identified code repository was found, and the Zenodo DOI is recorded here as an artifact identifier, not a paper identifier. #### Primary sources 1. 2. 3. 4. 5. ### Malsight: Exploring Malicious Source Code and Benign Pseudocode for Iterative Binary Malware Summarization > MALSIGHT writes natural-language summaries of stripped binary malware one function at a time. IDA Pro produces pseudocode and a call graph, and functions are summarized callees first, so each caller receives its callees' summaries as context; a sequence-labeling model also marks key API calls and strings, which drive code-search retrieval and LLM-written annotations. The summarizer, MalT5, is a 0.77B-parameter CodeT5+ model fine-tuned first on MalS, 89,609 malicious C source functions from GitHub with LLM-generated summaries refined by human reviewers, and then on annotated benign pseudocode from the Capybara dataset. The authors also introduce MalP, 500 pseudocode functions for testing, and BLEURT-sum, a fine-tuned BLEURT metric, and report that MalT5 performs comparably to much larger Code Llama models. - Authors: Haolang Lu; Hongrui Peng; Guoshun Nan; Jiaoyang Cui; Cheng Wang; Weifei Jin; Songtao Wang; Shengli Pan; Xiaofeng Tao - Venue: IEEE Transactions on Information Forensics and Security - Status: Journal article - Publication / posting date: 2025 (exact date not verified) - Date source: IEEE's Crossref deposit gives only the 2025 publication year for volume 20. The 2025-06-26 DOI-registration date and the arXiv dates are not used to assert a month or day. - First arXiv submission: June 26, 2024 - arXiv: 2406.18379 - Reviewed arXiv version: v3 - DOI: 10.1109/TIFS.2025.3583552 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Training summaries are LLM-generated and then reviewed and refined by five experts rather than written from scratch. MalP's 500 test functions come from compiling and decompiling 20 of the same GitHub malware repositories, not from wild samples, and the authors note that loose filtering may let training and test data overlap and inflate results. Quality is scored mainly with the authors' own BLEURT-sum metric. On ten real malware samples, with 79 functions also rated by three reverse engineers, BLEURT-sum was about 30% lower than on MalP, which the authors attribute to long functions: 15.8% exceed 1,000 tokens, while most training functions are under 300. The pipeline depends on IDA Pro pseudocode, and static annotation relies on online code search and a general-purpose LLM. MALSIGHT summarizes behavior; it is not a malware detector or classifier. #### Why it fits this collection Adds LLM-based summarization of stripped malware pseudocode that follows the call graph, complementing decompilation, symbol-recovery and benchmark records that include binary code summarization. #### Publication and review notes Crossref records volume 20, pages 6733–6747, and the nine-author order, which matches arXiv; it spells the title 'Malsight', while arXiv and the paper write MALSIGHT. IEEE Xplore could not be retrieved, so publication facts follow Crossref and the reviewed text is arXiv v3 (2025-06-17), whose comment states acceptance by IEEE TIFS; v1 is dated 2024-06-26 and v2 2024-11-06. The paper reports extracting close to 30K functions from 2,289 repositories before giving the 89,609-function MalS total, and calls MalT5 0.7B in its contribution list and 0.77B elsewhere. Footnote 1 promises a source-code release but gives no link. The repository lhl7/Malsight, described as 'code for Malsight', is owned by an account whose profile name matches the first author, but neither the paper nor an author page links it. At the reviewed 2025-07-24 commit it has no license file and links Apache-2.0 Hugging Face models (sequence labeling, CodeT5+ 770M, BLEURT) and datasets. #### Primary sources 1. 2. 3. 4. 5. ### Cybench: A Framework for Evaluating Cybersecurity Capabilities and Risks of Language Models > Cybench turns 40 professional-level capture-the-flag tasks from four competitions (HackTheBox Cyber Apocalypse 2024, SekaiCTF 2022–23, GlacierCTF and HKCert) into runnable agent tasks. Each task has a description, starter files, a Kali Linux container for the agent with task servers in Docker, and the time the first human team needed to solve it, from 2 minutes to 24 hours 54 minutes. Each task is also split into subtasks that grade intermediate steps. The authors evaluate eight models with a structured bash agent and compare four scaffolds for GPT-4o and Claude 3.5 Sonnet. Without subtask guidance, the best agents solved only tasks whose first human solve took at most 11 minutes, and Claude 3.5 Sonnet reached 17.5% unguided success. - Authors: Andy K. Zhang; Neil Perry; Riya Dulepet; Joey Ji; Celeste Menders; Justin W. Lin; Eliot Jones; Gashon Hussein; Samantha Liu; Donovan Jasper; Pura Peetathawatchai; Ari Glenn; Vikram Sivashankar; Daniel Zamoshchin; Leo Glikbarg; Derek Askaryar; Mike Yang; Teddy Zhang; Rishi Alluri; Nathan Tran; Rinnara Sangpisit; Polycarpos Yiorkadjis; Kenny Osele; Gautham Raghupathi; Dan Boneh; Daniel E. Ho; Percy Liang - Venue: ICLR 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: Publication year stated by the official ICLR proceedings; no finer publication date is asserted. The proceedings page's citation date of 2025-05-01 is not adopted, and the arXiv dates are not substituted. - First arXiv submission: August 15, 2024 - arXiv: 2408.08926 - Reviewed arXiv version: v4 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Only 6 of the 40 tasks are reverse engineering; the rest are cryptography (16), web (8), forensics (4), miscellaneous (4) and pwn (2), so aggregate rates are not reverse-engineering accuracy, and Cybench is not a reverse-engineering-only benchmark. In the unguided structured-bash runs, six or seven of the eight models solved the two easiest reversing tasks (first human solves in 2 and 6 minutes), and none solved the other four. Results cover 2024 models (GPT-4o, o1-preview, Claude 3 Opus, Claude 3.5 Sonnet, Gemini 1.5 Pro, Llama 3 and 3.1, Mixtral 8x22b) with the authors' scaffolds: 15 iterations unguided or 5 per subtask, short memory, no decompiler tools, one attempt in the main comparison and the best of three in the scaffold comparison. First-solve times come from competition records and are not directly comparable across competitions. The authors judge train–test overlap by model knowledge cutoffs and cannot rule it out for Claude 3.5 Sonnet. CTF tasks are short, small-codebase competition problems, and capturing a flag does not show recovered program structure. #### Why it fits this collection Adds a CTF agent benchmark with reverse-engineering tasks and subtask-level grading; EnIGMA in this section reports results on it, and it complements the reverse-engineering-specific benchmarks here. #### Publication and review notes Authors follow the byline of the proceedings PDF, which matches arXiv v4. The proceedings page metadata instead lists 25 names: it omits Polycarpos Yiorkadjis and Gautham Raghupathi, gives Haoxiang Yang, Aolin Zhang and Kenny Oseleononmen where the PDF prints Mike Yang, Teddy Zhang and Kenny Osele, and drops middle initials. The proceedings list pages 25094–25243 and no DOI. arXiv v1 is dated 2024-08-15, v2 2024-10-06, v3 2024-12-05 and v4 2025-04-12; v4 carries the comment 'ICLR 2025 Oral'. The OpenReview forum could not be retrieved past a browser check, so the oral designation rests on that comment. The proceedings abstract links anonymized Google Drive archives, while the PDF points to cybench.github.io, which links andyzorigin/cybench. At the reviewed 2026-09-24 commit the repository is Apache-2.0; runs need model API keys, Python 3.9–3.10 and Docker with the cybench/cybench image. Its task_list.txt names all 40 tasks, but the nine GlacierCTF tasks, including the reversing tasks RPGO and SOP, are not in the repository tree. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### Code is not Natural Language: Unlock the Power of Semantics-Oriented Graph Representation for Binary Code Similarity Detection > HermesSim detects binary code similarity by lifting each function to Ghidra P-code and building a semantics-oriented graph that exposes operand structure inside instructions, def-use, control-flow and effect-order relations, while dropping semantics-independent details such as which register temporarily holds a value. A gated graph neural network with a multi-head softmax aggregator embeds the graph, and functions are compared by embedding similarity. On the Dataset-1 benchmark of Marcelli et al., the authors report 48.1% RECALL@1 for x64 cross-compiler retrieval in pools of 10,000 functions, against 31.4% for a fine-tuned jTrans, with a 388K-parameter model. - Authors: Haojie He; Xingwei Lin; Ziang Weng; Ruijie Zhao; Shuitao Gan; Libo Chen; Yuede Ji; Jiashui Wang; Zhi Xue - Venue: USENIX Security 2024 - Status: Conference paper - Publication / posting date: August 2024 - Date source: Publication month in the official USENIX proceedings BibTeX; the August 14–16, 2024 symposium dates are not used to assert a publication day. - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Laboratory results reuse Dataset-1 from Marcelli et al.: 257K, 13K and 522K training, validation and test functions for x86, ARM and MIPS in 32 and 64 bits, built at O0–O3 and Os by GCC and Clang. HermesSim keeps that dataset's IDA Pro 7.3 control flow and basic-block boundaries and uses Ghidra only to disassemble and lift each block, so the results do not measure function or CFG recovery. Each setting samples 1,000 queries against pools of up to 10,000 functions, and the gains are relative to the paper's own runs of SAFE, Asm2Vec, GMN, Trex and jTrans, which supports x86 only and was compared on the x64 subset. The real-world study searches 62,605 ARM32 and MIPS32 functions from 12 RTOS firmware images of three vendors for 10 functions linked to 5 CVEs; its ground truth comes from manually examining the top 20 results of the compared methods. String, integer and external-symbol references are not encoded, only memory effects are modeled, and unresolved indirect branches leave graphs incomplete. Similarity ranks candidates for review; it does not establish equivalence or vulnerability. #### Why it fits this collection Adds learned binary code similarity search, which reverse engineers use to match functions across builds, recover library functions in stripped binaries and locate known vulnerable code, complementing decompilation and symbol-recovery research. #### Publication and review notes The USENIX page, its BibTeX entry and the final PDF agree on the nine-author order, pages 1759–1776 and ISBN 978-1-939133-44-1; the page also lists a prepublication PDF. USENIX assigns no paper DOI and no arXiv version was found. The paper links github.com/NSSL-SJTU/HermesSim. At the reviewed 2024-12-10 commit its LICENSE file is MIT for the project and reproduces MIT and Apache-2.0 notices for included Cisco Talos and DeepMind code, which is why GitHub reports no single license. The README's paper link uses /presentation/he, which redirects to the he-haojie page. Lifting calls the separate GPL-3.0 GSAT Ghidra toolkit (gsat-1.0.jar). Zenodo record 10.5281/zenodo.10369788 (CC BY 4.0), linked from the README, holds the Dataset-RTOS binaries and archives of about 17 GB, 19 GB and 5 GB with extracted features, model inputs and outputs; that DOI identifies the data, not the paper. Dataset-1 binaries come from the Cisco Talos binary_function_similarity repository. The pinned requirements target Python 3.10, PyTorch 1.13.1 with CUDA 11.6 and PyTorch Geometric 2.3.0. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### TYGR: Type Inference on Stripped Binaries using Graph Neural Networks > TYGR infers the types of stack and heap variables in stripped binaries by running an architecture-agnostic, intra-procedural data-flow analysis on angr's VEX IR and classifying each variable's data-flow graph with a graph neural network. It predicts base types, pointers and struct member layouts, covering 97.1% of the types observed in its data. The authors also build TyDa, 163,643 binaries compiled with debug information from Gentoo and Debian C packages for x86, x64, AArch64, Arm32 and MIPS at O0–O3, and deduplicate functions in the evaluated subset before splitting it. On x64 across O0–O3 they report 76.6% overall and 45.2% struct accuracy, and say TYGR beats prior work by at least 26.1% overall and 10.2% on structs. - Authors: Chang Zhu; Ziyang Li; Anton Xue; Ati Priya Bajaj; Wil Gibbs; Yibo Liu; Rajeev Alur; Tiffany Bao; Hanjun Dai; Adam Doupé; Mayur Naik; Yan Shoshitaishvili; Ruoyu Wang; Aravind Machiry - Venue: USENIX Security 2024 - Status: Conference paper - Publication / posting date: August 2024 - Date source: Publication month in the official USENIX proceedings BibTeX; the August 14–16, 2024 symposium dates are not used to assert a publication day. - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Ground truth comes from DWARF information in binaries compiled by the authors, and training and testing use TyDa-min, about 8% of TyDa's binaries, so the results do not cover wild, obfuscated or C++ code. The analysis is intra-procedural and covers stack and heap variables only, not globals; unresolved indirect jumps can leave code unexplored, and adjacent stack structs are predicted as one struct, though the authors find this rare in TyDa. Accuracy plateaus near 80% as training data grows, which the authors attribute to rare types and types that usage alone cannot distinguish. Comparisons follow each baseline's original setting: DIRTY and OSPREY on x64 only, and OSPREY through results its authors supplied for Coreutils x64-O0. Accuracy is not compared directly with Ghidra or IDA Pro. Predictions choose from a fixed set of base, pointer and struct-member types; they do not recover type names or full struct declarations. #### Why it fits this collection Adds graph-neural-network type inference over data-flow graphs and a multi-architecture type-recovery dataset, complementing decompiler-output, LLM-based and synthesis-based type recovery research. #### Publication and review notes The USENIX page, its BibTeX entry and the final PDF agree on the 14-author order, pages 4283–4300 and ISBN 978-1-939133-44-1. USENIX assigns no paper DOI and no arXiv version was found. The paper releases its artifacts at github.com/sefcom/TYGR. At the reviewed 2024-08-22 commit the repository has no license file; it ships trained MODEL_base and MODEL_struct models, and its environment pins Python 3.8, PyTorch 1.8.1 with CUDA 10.2 and angr 9.0.7491. TyDa is not in the repository: the README links two Dropbox folders, one described as Gentoo C and C++ x86-64 binaries with per-optimization JSON metadata and one with the remaining C binaries, and notes that the dataset still contains duplicate functions. #### Primary sources 1. 2. 3. 4. 5. 6. ### ShieldedCode: Learning Robust Representations for Virtual Machine Protected Code > ShieldedCode studies software protection from the defender's side: it trains code language models on pairs of C source functions and their virtualization-protected (VMP) x86-64 code so that the models can generate, compare and rank protected variants. Training pairs come from AnghaBench functions compiled at O0–O3, protected at levels L0–L3 by a commercial VMP tool, then disassembled and normalized. The model adds attention masks for dependencies within, between adjacent and across virtual instructions, contrastive objectives for functional equivalence and protection strength, and a protection-effectiveness task that ranks variants of the same source. Continual pre-training starts from CodeLlama 34B and adds The Stack to the corpus, and fine-tuning uses 2.5 million source–VM pairs. On HumanEval-compile, VM code generation reaches 26.95% Pass@1 at level L0 (GPT-4o: 22.58%) and 14.71% at L3. On BinaryCorp-VirtualAssembly similarity detection, Recall@1 for the O0+L1 setting is 0.488, against 0.333 for jTrans with a linear probe. The authors also run a manual reverse-engineering study and pattern-matching and angr attacks on the generated protection. - Authors: Mingqiao Mo; Yunlong Tan; Hao Zhang; Heng Zhang; Yangfan He - Venue: ICLR 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: Publication year stated by the official ICLR proceedings; no finer publication date is asserted. The proceedings page's citation date of 2026-04-20 is not adopted, and the arXiv date is not substituted. - First arXiv submission: January 28, 2026 - arXiv: 2601.20679 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-27 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations All data is x86-64, and every training pair is produced with one commercial VMP tool that the paper does not name, so results may not carry over to other architectures, protectors or virtual-instruction designs. Generated VM code is checked with HumanEval-compile test cases, not formal equivalence, and Pass@1 stays between 14.71% and 26.95% across protection levels. The similarity gain over jTrans holds only in the O0+L1 setting: in the other five BinaryCorp-VirtualAssembly settings the linear-probe jTrans has higher Recall@1 (for example 0.715 against 0.309 for O2+L1), and the paper's summaries of the comparison differ (a 10% gain in the abstract, 15.5 points in the introduction, competitive in the results). The ablation table reports scores for ContraBin, CLAP and CEBin that the paper says are estimated from their architectures rather than measured. Protection-strength claims rest on the authors' own attacks and manual study: 12 graduate students and 3 professional reverse engineers analyzing 20 functions for 30–45 minutes each, with 17% success on ShieldedCode output against 67% for VMProtect and 58% for Themida. ShieldedCode is not a devirtualizer or deobfuscator, and the paper links no code, models or generated training data. #### Why it fits this collection Adds protection-side research that uses learned models to generate VM-protected code and to measure how it resists reversing, complementing the BAR 2026 protection study and SRE-Bench, which measure how agents cope with protected binaries. #### Publication and review notes The ICLR proceedings page lists the five authors in this order, pages 23529–23552 and no DOI; its PDF carries the header "Published as a conference paper at ICLR 2026". arXiv has only v1, dated 2026-01-28, with the comment "Accepted to ICLR 2026". The OpenReview forum 9F9UFVcDkV returned a browser challenge to automated requests. Neither the paper nor the proceedings page links code, models or data; the reproducibility statement only says the implementation uses PyTorch and open-source libraries. A same-name GitHub repository, Clon5676/ShieldedCode, is an unrelated Unreal Engine project. The commercial tool used to build the training data is unnamed; VMProtect and Themida appear only as comparisons in the resistance study. #### Primary sources 1. 2. 3. 4. 5. ### STRIDE: Simple Type Recognition In Decompiled Executables > STRIDE predicts the names and types of variables in decompiler output without a neural model. From training decompilation with known labels, it builds a database mapping the token sequences (N-grams, with N from 2 to 60) immediately left and right of each variable occurrence to the five most frequent names or types. Variable placeholders are canonicalized, and address-like tokens and large constants are bucketed so that N-grams can match. At prediction time it looks up the longest matching N-gram on each side of every occurrence, scores the returned labels by how specific the match is, and sums the scores across the function. The prototype is about 1,000 lines of Python and runs on a CPU. On DIRT functions not seen in training, the authors report 66.4% retyping accuracy, against 52.3% for DIRTY with beam search, and 56.2% renaming accuracy, against 51.3% reported for VarBERT. Across 16 VarCorpus splits, renaming accuracy is higher than VarBERT on 11 and 1.55 points higher on average. Prediction takes 8.2 ms per function on a CPU, against 43.7 ms for VarBERT on an NVIDIA L4 GPU. - Authors: Harrison Green; Edward J. Schwartz; Claire Le Goues; Bogdan Vasilescu - Venue: arXiv - Status: Preprint - Publication / posting date: July 3, 2024 - Date source: arXiv v1 submission on 2024-07-03, the only version at review time. No later venue publication was found, so no publication date beyond the preprint is asserted. - First arXiv submission: July 3, 2024 - arXiv: 2407.02733 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations An arXiv preprint with no stated venue. STRIDE classifies by exact N-gram matches, so its predictions depend on token sequences seen in the training data: it cannot fuzzy-match or predict a name or type absent from training, and a model trained on one decompiler's token format is not expected to transfer to another. Results are reported on decompiler output from the DIRT, DIRE and VarCorpus benchmark datasets. DIRT pairs Hex-Rays output for GCC -O0 builds of GitHub projects with DWARF-derived labels, the older DIRE dataset was prepared similarly, and VarCorpus covers Gentoo packages decompiled with Hex-Rays and Ghidra at -O0 to -O3. Retyping is evaluated only on DIRT, and only x86 C/C++ code is covered. Accuracy is exact match, so near-synonyms count as errors. About 60% of DIRT test functions also appear in training, where STRIDE reaches about 99% by memorization; the not-in-train figures are the more representative ones. DIRT keeps function and global names, and removing them lowers renaming accuracy by a few points. Several baseline numbers are copied from earlier publications rather than rerun. The authors' README expects poor results on custom closed-source binaries with structures absent from training. The repository is a research prototype with no decompiler plugin or trained databases. #### Why it fits this collection Adds a non-neural, sequence-matching baseline for decompiled variable name and type recovery, complementing the transformer-based DIRTY and VarBERT records it compares against. #### Publication and review notes arXiv v1 (2024-07-03), the only version at review time; the abstract page lists no comment or journal reference, and the PDF names Carnegie Mellon University and the CMU Software Engineering Institute as affiliations. A Crossref bibliographic search and an OpenAlex search found only the arXiv preprint; DBLP's search API returned a bot check and could not be consulted. The abstract links hgarrereyn/STRIDE, reviewed at its latest commit ebaab25 (2024-07-04): MIT license, copyright 2024 Harrison Green. The README documents converters for the DIRE, DIRT and VarCorpus datasets, which are downloaded separately from Google Drive, Amazon S3 and Dropbox; the repository ships no trained N-gram databases or requirements file, and its FAQ says no decompiler plugin exists yet. The paper says the N-gram database takes a few gigabytes of memory. #### Primary sources 1. 2. 3. 4. 5. ### Exploring the Potential of LLMs for Code Deobfuscation > Studies LLMs as source-to-source deobfuscators for C functions protected with the Tigress obfuscator. Functions from ExeBench, with identifiers randomized, are obfuscated with five transformations: MBA arithmetic encoding, branch encoding, control-flow flattening, opaque predicates and argument randomization. Each model receives a whole obfuscated function and returns simplified C. DeepSeek Coder 6.7B and Code Llama 7B are fine-tuned on obfuscated–original pairs, GPT-4 is prompted, and Clang optimization at -O0 to -O3 serves as a compiler baseline. Simplification is scored with Halstead program length relative to the original and obfuscated code, syntactic correctness by compiling ExeBench wrappers and semantic correctness by ExeBench input/output samples. The fine-tuned models reduce complexity more than GPT-4 on every transformation and more than Clang except on arithmetic encoding and argument randomization, where Clang is on par. Trained on chains of up to five transformations, they keep stable scores on chains of six and seven, and the best model cuts Halstead program length by 89.21% on average in the hardest scenario. A test with randomized constants found one sample that reproduced memorized code. - Authors: David Beste; Grégoire Menguy; Hossein Hajipour; Mario Fritz; Antonio Emanuele Cinà; Sébastien Bardin; Thorsten Holz; Thorsten Eisenhofer; Lea Schönherr - Venue: DIMVA 2025 - Status: Conference paper - Publication / posting date: July 10, 2025 - Date source: Springer's Crossref deposit gives first online publication on 2025-07-10, during the July 9–11 conference; its print and issued dates give only the year. This entry uses the publisher's online date, not the conference schedule or the later CISPA repository date. - DOI: 10.1007/978-3-031-97620-9_15 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The obfuscation is Tigress (version 3.3.3 in the released scripts) applied source-to-source to single C functions. Compiled binaries, decompiler output, commercial protectors, inter-procedural obfuscation, VM-based packing and self-modifying code are not evaluated; the authors only note that decompilation can approximate C from binaries. This is source-level simplification, not binary deobfuscation or VM devirtualization. Semantic correctness is the main weakness: for single transformations the fine-tuned models preserve behavior in 50% to 94.5% of samples, mostly below GPT-4 and, except for branch encoding, below Clang, and it falls as transformation chains grow longer. Complexity scores count only samples that are both syntactically and semantically correct. Behavior is checked with ExeBench input/output samples rather than equivalence proofs, inputs are limited to a 6,144-token context, and models were fine-tuned with 8-bit quantization. Only one obfuscator is used, so generalization to other obfuscators, versions, machine code or bytecode is left open, and baselines are GPT-4 and Clang rather than dedicated deobfuscation tools. #### Why it fits this collection Adds source-level deobfuscation of protected C code with fine-tuned code LLMs, complementing the JavaScript (JsDeObsBench, CASCADE) and Android (DeGuard) deobfuscation papers and the LLM decompilation research in this section. #### Publication and review notes Springer's Crossref deposit gives the Lecture Notes in Computer Science proceedings of the 22nd DIMVA (Graz, 9–11 July 2025), pages 267–286, and the nine authors in the order of the PDF byline. The Springer landing page returned a browser challenge to automated requests, so the review used Crossref and the open-access PDF from the CISPA repository record 10.60882/cispa.32771220.v1 (CC BY 4.0, deposited 2026-06-23). That record and the CISPA publication page list "Antonio Emanuele" and "Sébastian Bardin"; the authors here follow Crossref and the PDF. An arXiv API search for Beste with deobfuscation in the title returned no record. The PDF links DavidBeste/llm-code-deobfuscation, reviewed at commit 00c9c45 (2026-02-27), which added the MIT LICENSE after publication. Its README links the dataset 10.5281/zenodo.15831457 (2025-07-10, CC BY 4.0, a 17 MB deobfuscation_dataset.zip); that dataset DOI is not used as the paper identifier. The scripts call a separately installed Tigress 3.3.3, load ExeBench from Hugging Face and query the OpenAI API for GPT-4 (gpt-4-32k-0314 in the README examples); requirements.txt pins clang 14.0 and torch 2.4.1 but lists two conflicting versions each of peft and transformers. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### Lares: LLM-driven Code Slice Semantic Search for Patch Presence Testing > Lares tests whether a known 1-day vulnerability fix is present in a target binary function without recompiling the project. Its inputs are the target binary, the project source and the patch commit diff. A patch-enhancement step adds data- and control-flow context from the source (via Tree-sitter and Joern) to patches with few changed statements. An LLM then locates the pseudocode slice in the IDA Pro decompilation of the target function that corresponds to each patch slice. Finally, matched slices are normalized into equations and checked for equivalence with the Z3 SMT solver, and the LLM judges the cases Z3 cannot model, deciding whether the function matches the pre-patch or the patched version. On 4,480 test cases from 73 CVEs in OpenSSL, FreeType, tcpdump and libxml2, compiled with GCC 9.4.0 and Clang 6 at O0–O3 for x86, x64 and ARM, the authors report an average F1 of 0.77 on x86 with Claude 3.5 Sonnet, against 0.67 for Robin and 0.68 for PS3, and F1 from 0.71 to 0.77 across five compiler–architecture settings. - Authors: Siyuan Li; Yaowen Zheng; Hong Li; Jingdong Guo; Chaopeng Dong; Chunpeng Yan; Weijie Wang; Yimo Ren; Limin Sun; Hongsong Zhu - Venue: ASE 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: Publication year from IEEE's Crossref deposit for the 2025 ASE proceedings. Its only date, 2025-11-16, is the first day of the November 16–20 conference, so no publication month or day is asserted; the arXiv date is not substituted. - First arXiv submission: November 3, 2025 - arXiv: 2511.01252 - Reviewed arXiv version: v1 - DOI: 10.1109/ASE63991.2025.00081 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Lares answers a narrow question: given a specific CVE patch diff, the project source with its history and a candidate function, is that function pre-patch or patched? It needs both the patch diff and the project source, and assumes a separate binary code similarity tool (the paper names BinaryAI as an example) has already located the candidate function. It does not find vulnerable functions, discover new vulnerabilities or diff arbitrary binaries. Its judgments rest on an LLM plus SMT reasoning over decompiler pseudocode: Z3 handles only about 21% of test cases (Z3-only verification has recall 0.221), so most decisions come from the LLM, and the authors list hallucinated comparisons, stealthy edit-type patches and repeated patch statements as failure modes. Results use IDA Pro 7.5 and a commercial model at about $0.20 per case; GPT-3.5-Turbo and DeepSeek-Coder score lower. The evaluation covers four C projects, 73 CVEs and binaries the authors compiled themselves, plus 20 vulnerabilities disclosed after October 2024 (400 cases) to check training-data contamination; firmware, other languages and real vendor builds are not evaluated. The repository has no license file, so no reuse terms are granted. #### Why it fits this collection Adds binary patch presence testing, using LLM-located slices of decompiled pseudocode, to the decompilation and binary-analysis research; it complements the curated BinDiff diffing tool rather than replacing it. #### Publication and review notes IEEE's Crossref deposit gives the 2025 40th IEEE/ACM ASE proceedings, pages 919–931, and the same ten authors in order; the DOI resolves to IEEE Xplore document 11334274. arXiv v1 (2025-11-03) is the only version and carries no venue comment, so it may differ from the IEEE version. The abstract links Siyuan-Li201/Lares; at the 2025-09-16 commit the repository has no license file, and its README gives the inputs as the binary, the project source path and the patch diff file. The repository commits IDA databases for stripped OpenSSL test builds, zipped tcpdump, FreeType and libxml2 sources and patch files, links the evaluation binaries on Google Drive, and requires an IDA Pro 7.5 path and an LLM API key in settings.py; settings.py preconfigures a third-party API relay with an author-supplied test key. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### No More Gotos: Decompilation Using Pattern-Independent Control-Flow Structuring and Semantics-Preserving Transformations > DREAM is a decompiler whose control-flow structuring recovers loops, conditionals and switch statements from a recovered control-flow graph without matching predefined region patterns. For acyclic regions it computes each node's reaching condition, then refines the resulting conditions into if-then-else and switch constructs; cyclic regions are structured as loops whose type and continuation condition are inferred. Semantics-preserving transformations first rewrite cyclic regions with multiple entries or successors into single-entry, single-successor regions, and a Boolean variable keeps a repeated test equivalent when its operands may change. On GNU coreutils the authors report no goto statements, against thousands from Hex-Rays and Phoenix, and more compact code than Hex-Rays for 72.7% of functions and than Phoenix for 98.8% in one-to-one comparisons. - Authors: Khaled Yakdan; Sebastian Eschweiler; Elmar Gerhards-Padilla; Matthew Smith - Venue: NDSS 2015 - Status: Conference paper - Publication / posting date: 2015 (exact date not verified) - Date source: Internet Society-deposited Crossref metadata supplies only publication year 2015; the publisher PDF separately identifies the 8–11 February 2015 symposium, which is not used to assert a publication month or day. - DOI: 10.14722/ndss.2015.23185 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Correctness was measured on source-level control-flow graphs: the authors extracted CFGs of the preprocessed coreutils 8.22 source with joern, restructured the 1,530 functions joern parsed (208 of 1,738 failed to parse), recompiled and passed the coreutils tests. That experiment checks the structuring algorithm, not end-to-end decompilation of binaries, variable or type recovery. Structuredness and compactness were measured on the coreutils 8.17 binaries from the Phoenix evaluation, using functions decompiled by all three tools, with line counts as the compactness metric. Phoenix was unreleased, so its output came from its authors, and the 2014 Hex-Rays v2.0.0.140605 baseline is long superseded. The malware case studies cover one sample each from ZeusP2P, SpyEye and Cridex and compare against Hex-Rays only. The authors leave open whether more compact code is always easier to understand. The paper links no implementation, and these results do not describe current decompilers. #### Why it fits this collection Adds control-flow structuring, the decompiler stage that turns a recovered control-flow graph into structured high-level code, beneath the collection's neural and LLM-based decompilation research. #### Publication and review notes Crossref gives the title, the four-author order and year 2015 with no pages; the DOI resolves to the NDSS programme page, which links the 15-page PDF and slides. The PDF footer identifies NDSS ’15, 8–11 February 2015, San Diego, and carries the DOI. Its evaluation section names a supplemental document of decompiled malware listings hosted at the University of Bonn. The paper gives no code or project link, so both stay null. #### Primary sources 1. 2. 3. ### Lifting Optimized Binaries to Canonical Compiler IR via Structure-Aware Retrieval and Iterative Verification > BRIDGE lifts stripped, optimized x86-64 and ARM64 functions, given as llvm-objdump disassembly, to LLVM IR. Its target is the unoptimized IR that a fixed clang -O0 configuration emits for the original source. Offline, it builds a retrieval database from 69,253 ExeBench functions compiled at -O0 to -O3, using LLVM pseudo-probe instrumentation to align assembly fragments with the matching -O0 IR regions. At inference it splits each function's angr-recovered control-flow graph into control-flow segments such as loops and if–else regions, retrieves the three nearest aligned assembly–IR pairs per segment from a FAISS index of Nova-1.3B embeddings, and prompts a hosted general-purpose LLM (DeepSeek-chat) to write the IR. Up to five refinement rounds then feed LLVM verifier and compiler diagnostics and unit-test failures back to the model. On HumanEval-Decompile and MBPP compiled with Clang 19 at -O0 to -O3, average re-executability is 65.2% and 65.4% on x86-64 and 45.6% and 42.1% on ARM64. The rule-based MCTOLL reaches 62.1% and 64.9% on x86-64, and the five directly prompted API LLMs reach at most 21.5%. - Authors: Xiaoao Zhu; Jie Ren; Zhiqiang Li; Jie Zheng; Zhanyong Tang; Zheng Wang - Venue: ACL 2026 - Status: Conference paper - Publication / posting date: July 2026 - Date source: The official ACL Anthology citation and BibTeX give July 2026. Crossref records only the year; the July 2–7 conference dates printed in the PDF are not treated as a publication day. - DOI: 10.18653/v1/2026.acl-long.527 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluation is function-level on short benchmark programs: HumanEval-Decompile and an MBPP subset, with inputs of 2 to 628 assembly instructions, built by the authors with one LLVM/Clang 19 toolchain on Linux. Canonical means matching one fixed clang -O0 configuration, not recovering the original source. Refinement and the re-executability metric both use the unit tests these benchmarks supply; the authors note that such test oracles are rarely available in practical reverse engineering. On x86-64 HumanEval-Decompile, re-executability falls from 65.2% to 60.8% with LLM-generated tests and to 53.5% with no tests. Output still diverges structurally from the reference: average edit similarity stays below 50%, and exact control-flow-graph matches reach 25.9% on that benchmark. The pipeline calls a hosted LLM API, as do the LLM baselines; results are geometric means of five runs and can shift as hosted models change. Forklift and LLM Compiler FTD are excluded from the baselines because the authors treat them as lifting compiler-emitted assembly text, and MCTOLL is compared only on x86-64. Other instruction sets need a rebuilt retrieval database. BRIDGE produces LLVM IR, not C source, so it is not a decompiler to C. The code repository has no license. #### Why it fits this collection Adds retrieval-guided LLM lifting of optimized machine code to compiler IR with verifier and test feedback, complementing rule-based lifters such as rev.ng and the assembly-to-C neural decompilation papers in this section. #### Publication and review notes The ACL Anthology page and BibTeX give the Proceedings of the 64th Annual Meeting of the ACL (Volume 1: Long Papers), pages 11498–11516, San Diego, published by the ACL, and the same six authors in order; the Crossref DOI record matches the title, authors and pages and gives only the year. No arXiv version was found by arXiv title and keyword searches, so no arXiv identifier is listed. In §6.1 the text gives 42.1% average re-executability for ARM64 HumanEval-Decompile, while Table 1 lists 45.6% for that benchmark and 42.1% for ARM64 MBPP; this record follows the table. The PDF's online-materials note links Azhu-c/BRIDGE-rag. At the 2026-07-06 commit the repository has no LICENSE file and GitHub reports no license. Its README recommends Python 3.10 and requires a DeepSeek API key, and the LLM wrapper defaults to the deepseek-chat model through an OpenAI-compatible client. requirements.txt pins openai 1.57.0, angr 9.2.162, torch 2.5.1 and faiss-gpu 1.7.2. The knowledge-base configuration expects ExeBench samples under ./data/exebench_samples and a local Nova-1.3b model path; neither is in the repository. Evaluation_datasets holds HumanEval-Decompile and MBPP-subset inputs for both instruction sets with BRIDGE and baseline outputs, and docs/ holds a copy of the paper. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### Polyglot: Automatic Extraction of Protocol Message Format using Dynamic Binary Analysis > Polyglot infers the format of a message that a program receives by monitoring how the program binary processes it, an approach the authors call shadowing. An execution monitor taints network input and records an instruction trace; offline analyses then find direction fields, such as length and pointer fields, from tainted memory accesses and loop conditions, separators from comparisons between tainted bytes and constants, multi-byte fixed-length fields from how instructions group input bytes, and protocol keywords from successful comparisons. It works on stripped IA-32 binaries without source code or debugging information. - Authors: Juan Caballero; Heng Yin; Zhenkai Liang; Dawn Song - Venue: ACM CCS 2007 - Status: Conference paper - Publication / posting date: October 28, 2007 - Date source: ACM’s Crossref deposit records both print and online publication on 2007-10-28. This entry uses that date, not the October 29–November 2 conference dates printed on the paper. - DOI: 10.1145/1315245.1315286 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations It extracts the format of one received message at a time and only of messages given to the analysis; messages that never appear stay unknown, and messages the program sends are not analyzed. It does not infer the protocol state machine. The evaluation covers eleven 2007-era programs implementing DNS, HTTP, IRC, ICQ and Samba, mostly Windows servers plus an ICQ client and a Linux Samba server, with one representative message per protocol, compared against Wireshark 0.99.5 dissectors. Field formats omit data types and encodings, analysis is at byte granularity so sub-byte flags are missed, and field semantics are limited to direction fields; timestamps, checksums and addresses are not identified. Message boundaries rely on assuming a synchronous protocol, unused fixed-length fields after an ICQ length field were merged into the variable-length field, and the authors state that the techniques are not fully resistant against obfuscation. #### Why it fits this collection Adds binary-analysis inference of protocol message formats from a running implementation, the line of work that the collection's BinPRE record continues, complementing its trace-based protocol research. #### Publication and review notes Crossref records the title as “Polyglot” with the lowercase subtitle “automatic extraction of protocol message format using dynamic binary analysis”, the four-author order and pages 317–329; this entry follows the capitalization printed on the paper. The 13-page ACM-formatted copy hosted on Dawn Song’s Berkeley site carries the CCS’07 copyright notice and page numbers from 317. A 15-page author version with appendices is hosted at UC Riverside and says the definitive version was published at CCS’07. The execution monitor is cited as the authors’ earlier work and is not released with the paper. The paper gives no code or project link, so both stay null. #### Primary sources 1. 2. 3. 4. ### Avatar: A Framework to Support Dynamic Security Analysis of Embedded Systems’ Firmwares > Avatar runs embedded firmware in an instrumented emulator, S²E on QEMU, while forwarding memory-mapped I/O to the real device and injecting the device's interrupts back into the emulator, so firmware that depends on undocumented peripherals can still be analyzed dynamically. The device is reached through JTAG via OpenOCD or through a small debugging stub over a serial line. Because forwarding every access over a 38400-baud serial link is very slow, about five instructions per second in one of the authors' measurements, Avatar also keeps memory that never behaves like I/O local to the emulator, migrates selected code to run natively on the device, and switches state between the two. With S²E's selective symbolic execution, the authors probe a hard-disk mask-ROM bootloader for hidden commands, an IEEE 802.15.4 sensor node for an injected overflow, and the SMS decoding routines of a GSM feature phone. - Authors: Jonas Zaddach; Luca Bruno; Aurélien Francillon; Davide Balzarotti - Venue: NDSS 2014 - Status: Conference paper - Publication / posting date: 2014 (exact date not verified) - Date source: Internet Society-deposited Crossref metadata supplies only publication year 2014; the publisher PDF separately identifies the 23–26 February 2014 symposium, which is not used to assert a publication month or day. - DOI: 10.14722/ndss.2014.23229 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Avatar needs the physical device and a working debug channel or an injectable stub; it does not model peripherals, so it is not standalone rehosting. The three case studies are all ARM devices (a hard disk with an ARM966 core, a Redwire Econotag and a Motorola C118 phone), and each needed manual work to choose hook points and code regions. Full-separation mode is too slow for time-critical code such as DRAM initialization, and the authors report that memory changed by DMA, or by code migrated to the device, is hard to keep synchronized with the emulator. The sensor-node vulnerability was artificially inserted into a demonstration program, the bootloader study confirmed documented commands rather than finding a backdoor, and the phone's GSM stack was too complex for symbolic execution: 42 subroutines were explored without an exploitable condition before state explosion. These are 2014 results on an S²E port the authors extended for ARM. #### Why it fits this collection Adds hardware-in-the-loop firmware analysis, which forwards emulator I/O to the real device, alongside the collection's emulation-based firmware rehosting research. #### Publication and review notes Crossref gives the title, the four-author order and year 2014 with no pages. The DOI’s registered target, a /ndss2014/programme/ URL ending in an encoded apostrophe, returned HTTP 404 on 2026-10-19; the working NDSS programme page links the 16-page PDF and slides. The PDF footer identifies NDSS ’14, 23–26 February 2014, San Diego, with ISBN 1-891562-35-5, but its DOI line is the placeholder “http://dx.doi.org/OETT”; the Crossref DOI is recorded here. The paper gives the framework’s location as the EURECOM project page, which now carries a deprecation notice pointing to the successor Avatar² (avatartwo/avatar2), a later, separate project. That page links the Python core, whose eurecom-s3 URL redirects to avatarone/avatar-python; the 2016-10-18 commit is Apache-2.0 (Copyright 2013–2014 Institut Eurecom) and points to separate repositories for the NDSS’14 samples, the patched S²E and OpenOCD. #### Primary sources 1. 2. 3. 4. 5. 6. ### Tupni: Automatic Reverse Engineering of Input Formats > Tupni infers an input format from an execution trace of an x86 program parsing one input, using byte-level dynamic taint tracking. It segments the input into fields from the instructions that operate on tainted bytes, finds record sequences from parsing loops, groups records into types by the code that handles them, and emits an enhanced BNF grammar with length, value and some inter-message constraints. Grammars from several inputs can be merged into a more complete specification. The evaluation covers five file formats (WMF, BMP, JPG, PNG, TIF) and five network protocols (DNS, RPC, TFTP, HTTP, FTP), and the output is used for zero-day vulnerability signature generation with ShieldGen. - Authors: Weidong Cui; Marcus Peinado; Karl Chen; Helen J. Wang; Luis Irun-Briz - Venue: ACM CCS 2008 - Status: Conference paper - Publication / posting date: October 27, 2008 - Date source: ACM’s Crossref deposit records print and online publication on 2008-10-27, and an archived copy of the ACM article page shows the same date. The CCS meeting dates are not substituted. - DOI: 10.1145/1455770.1455820 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Tupni needs the parsing program and a recorded execution trace for every input; it does not work from captured traffic or files alone. The prototype combined iDNA traces with a re-implemented Vigilante taint engine, and the traces came from Windows XP SP2 binaries such as gdi32.dll, gdiplus.dll, nslookup.exe and IIS components. Single-input accuracy uses one input per format, scored by the authors against published specifications; WMF, DNS and HTTP guided the design, compressed image data was skipped in favor of container structure, and no quantitative baseline was run because earlier tools were unavailable. All record sequences were found, with some false-positive sequences, and 889 of 1,551 PNG fields were misidentified because the program ignored repeated chunk data. Coverage depends on input diversity, constraints can be specific to the samples, byte-level taint handles fields that do not align with bytes poorly (including many encrypted or compressed formats), and formats beyond regular expressions are out of scope. Inter-message constraints were evaluated only for TFTP, and multi-input aggregation only on 150 WMF files. #### Why it fits this collection Adds a classic execution-based input-format inference method that recovers record sequences, record types and field constraints, complementing the collection’s traffic-based and binary-assisted protocol-format research. #### Publication and review notes Crossref and the archived ACM page give the five authors in this order, CCS ’08 pages 391–402, and the main title “Tupni” with subtitle “automatic reverse engineering of input formats”; the record uses the paper’s capitalization. The 12-page copy on the Microsoft Research publication page spells the fifth author “Luiz Irun-Briz”; the record follows the ACM and Crossref spelling. The paper states that the prototype has 14,000 lines of C++ and 4,100 lines of Perl outside Vigilante and iDNA, and it links no code or data; the Windows test binaries and the 150 WMF files from an internal Microsoft repository are not public artifacts. #### Primary sources 1. 2. 3. 4. 5. 6. ### Prospex: Protocol Specification Extraction > Prospex infers message formats and a protocol state machine from execution traces of a Linux server handling client sessions. Dynamic taint analysis splits each session into messages and recovers their formats; messages are then clustered into types by input-format, execution and server-impact similarity, such as the system calls, outputs and file paths a message triggers. The observed type sequences form an augmented prefix tree acceptor, which prerequisite and end-state heuristics label before Exbar computes a minimal consistent automaton. The resulting specifications are translated for the Peach fuzzer to reach later protocol states. The evaluation covers the Agobot command-and-control protocol, SMTP on Sendmail, SMB on Samba and SIP on Asterisk. - Authors: Paolo Milani Comparetti; Gilbert Wondracek; Christopher Kruegel; Engin Kirda - Venue: IEEE S&P 2009 - Status: Conference paper - Publication / posting date: May 2009 - Date source: IEEE’s Crossref deposit and an archived copy of the IEEE Xplore page give May 2009, represented at month precision. The symposium dates are not substituted for a publication day. - DOI: 10.1109/SP.2009.14 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Prospex traces one endpoint, the server, and its taint tool runs only on Linux, so only Linux server binaries were analyzed. It cannot handle encrypted traffic: TLS sessions made up the 6.5% of 31,903 Postfix sessions that the inferred SMTP specification could not parse. Training sets are small (for example 16 SMTP and 31 SMB sessions), and the inferred machines cover only behavior exercised during training; two SMB states are artifacts of limited training variety, and SMB recall against the reference automaton is 0.58. Reference state machines were built manually by the authors, and soundness was checked with 50,000 random walks per protocol; the sk-strings and beams baselines are state-machine learners, not full protocol reverse-engineering systems. The fuzzing case studies found previously known issues in an older Samba release and in Asterisk, not new vulnerabilities in the latest Samba or Windows XP SMB versions tested. #### Why it fits this collection Adds an execution-based method that extracts both message formats and protocol state machines from observed sessions, complementing the collection’s active state-machine learning and format-only protocol inference research. #### Publication and review notes Crossref and the archived IEEE Xplore page agree on the four authors, the 2009 30th IEEE Symposium on Security and Privacy proceedings, pages 110–125 and May 2009; Xplore does not mark the paper open access. The PDF is the 16-page copy on Christopher Kruegel’s UCSB site, with the same title and author order; its file metadata shows a September 2008 creation date and a 2009 IEEE PDF eXpress certification, and IEEE Xplore holds the version of record. The paper reports that its Peach statefulness extensions were integrated into Peach release 2.2 but links no Prospex code, traces or reference state machines. #### Primary sources 1. 2. 3. 4. ### SoK: Enabling Security Analyses of Embedded Systems via Rehosting > Systematizes rehosting: moving embedded firmware from its physical hardware into a virtual environment that models enough hardware behavior for dynamic analysis such as fuzzing and symbolic execution. The authors measure why whole-system emulation does not scale using 2,574 hardware configurations, 1,956 device tree blobs from Linux 5.11.4 and 618 vendor ARM Cortex SVD files. They compare corpus CPU models with QEMU support, count unique peripherals, use driver source lines as a complexity proxy, and run a Monte Carlo simulation of adding peripheral models SoC by SoC. Supporting a random 10% of the SoCs would need about 3,947 peripherals for the Linux corpus and 1,730 for the ARM Cortex corpus, against 1,083 implemented in QEMU 5.2. The paper then classifies prior systems by how they emulate, replace, symbolically model, pass through to hardware or leave each layer unmodified, describes an iterative rehosting process with fidelity evaluation, and sets out open problems. - Authors: Andrew Fasano; Tiemoko Ballo; Marius Muench; Tim Leek; Alexander Bulekov; Brendan Dolan-Gavitt; Manuel Egele; Aurélien Francillon; Long Lu; Nick Gregory; Davide Balzarotti; William Robertson - Venue: ACM ASIA CCS 2021 - Status: Conference paper - Publication / posting date: May 24, 2021 - Date source: ACM-deposited Crossref print-publication date; the online-publication date is recorded separately in metadata notes. The June 7–11 conference dates are not used. - DOI: 10.1145/3433210.3453093 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-28 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations This is a systematization with a measurement study, not a new rehosting tool. The measurements use hardware descriptions rather than firmware images: device trees cover Linux-based (Type-1) systems and SVD files cover only ARM Cortex hardware, and only architectures or vendors with ten or more samples are counted. Driver source lines are an explicitly rough proxy for the effort of modeling a peripheral, and closed-source drivers are assigned an architecture average. The conclusion that manually written hardware emulators will not scale rests on these proxies and on QEMU 5.2 and OVPsim as of early 2021. The authors note that rehosting fidelity lacks a formal definition and that no large-scale fidelity evaluations exist, so the taxonomy compares approaches qualitatively; a concurrent survey covers fidelity in more detail. #### Why it fits this collection Adds a field-defining survey of firmware rehosting, giving the collection's individual rehosting systems such as Firmadyne, FirmAE and HALucinator a shared vocabulary and taxonomy. #### Publication and review notes ACM metadata records print publication on 2021-05-24 and online publication on 2021-06-04, pages 687–701, with the twelve-author order shown here. The paper is published under CC BY 4.0. dl.acm.org refused automated requests during this review, so the 15-page ACM PDF was read from a Wayback Machine capture of its own URL. Footnote 3 links igloo-re/rehosting_sok, which now redirects to rehosting/rehosting_sok. The reviewed 2021-06-08 commit is MIT-licensed and builds an Ubuntu 20.04 Docker image with QEMU 5.2.0, generates the 1,956 DTBs and prints the data behind Tables 1–3 and the Monte Carlo results. Its SVD analysis clones the current posborne/cmsis-svd repository, and the README warns that results change slightly as that repository grows. The repository reproduces these measurements; it is not a rehosting tool. #### Primary sources 1. 2. 3. 4. 5. 6. ### Towards Automated Protocol Reverse Engineering Using Semantic Information > Infers the vocabulary of an undocumented protocol, its message types and formats, from communication traces. The approach uses contextual information embedded in the messages to improve message clustering and the identification of field boundaries; the HAL record lists contextual clustering and semantic sequence alignment as keywords. The authors motivate the work with parsers and traffic generators for network security products, and compare it with their own reimplementations of ASAP, Discoverer and ScriptGen. The first two authors are the authors of Netzob, the open-source protocol reverse-engineering framework. - Authors: Georges Bossert; Frédéric Guihéry; Guillaume Hiet - Venue: ACM ASIA CCS 2014 - Status: Conference paper - Publication / posting date: June 4, 2014 - Date source: ACM’s Crossref deposit records print and online publication on 2014-06-04. The HAL record gives the same date as the first day of the June 4–6 conference; the conference dates alone are not used as the basis. - DOI: 10.1145/2590296.2590346 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The method starts from captured traces and addresses the protocol’s vocabulary, not its grammar or state machine; contextual hints help only where such information appears in the observed messages. Baseline results come from the authors’ reimplementations of ASAP, Discoverer and ScriptGen rather than the original tools. The comparative study and its results are the authors’ 2014 evaluation. Netzob has changed substantially since 2014. #### Why it fits this collection Documents the trace-based inference approach from the authors of Netzob, already curated as a protocol-analysis tool, and complements the collection’s other traffic-based and executable-assisted format inference research. #### Publication and review notes Crossref, the archived ACM page and the HAL record agree on the three authors, the ASIA CCS ’14 proceedings and pages 51–62; the ACM metadata uses sentence case, and the record follows the capitalization in the HAL record. Crossref lists this paper under DOI 10.1145/2590296.2590346; the neighboring 10.1145/2590296.2590338 is a different paper. The HAL record has no attached file. The code link is the authors’ Netzob repository, whose AUTHORS.txt names Georges Bossert and Frédéric Guihéry; its 2023 head ships the GPL-3.0 license text. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### How far we have come: testing decompilation correctness of C decompilers > Tests whether C decompilers preserve program behavior. The authors' DecFuzzer compiles a Csmith-generated program, decompiles the executable, substitutes the decompiled function for the original in the source, recompiles, and compares the two programs' outputs; equivalence-modulo-inputs (EMI) mutation then derives further test programs from the seeds. Across four popular decompilers the authors report 1,423 inputs that trigger decompilation errors and, after manual analysis, 13 bugs in two open-source decompilers. They argue that modern decompilers are making real progress on functional correctness, while type recovery and optimization still hinder accurate output. - Authors: Zhibo Liu; Shuai Wang - Venue: ACM ISSTA 2020 - Status: Conference paper - Publication / posting date: July 18, 2020 - Date source: ACM’s Crossref deposit records print and online publication on 2020-07-18, and the ACM article page gives the same publication date. This entry uses that date, not the conference schedule. - DOI: 10.1145/3395363.3397370 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The tests use small generated programs, not real-world binaries, and a failed recompilation is recorded separately from a behavioral mismatch. In the authors' artifact, test programs are compiled as 32-bit x86 with GCC at -O0, and Csmith is restricted to a single function without arrays, structs, unions, pointers or long long types, so optimized code and richer data types are outside that configuration. The four decompilers (IDA Pro, JEB3, RetDec and Radare2's r2ghidra plugin) were tested as of 2020; the error counts and bugs describe those releases, not current ones. IDA Pro and JEB3 are commercial and not included in the artifact, which sets up only RetDec and r2ghidra. #### Why it fits this collection Adds differential testing of decompiler correctness through recompilation, complementing the collection's decompiler benchmarks, such as DecompileBench, that evaluate output on real functions. #### Publication and review notes Crossref and the ACM page give the two-author order, pages 475–487 and the title in the lowercase form used here; the conference programme and the artifact README capitalize it “How Far We Have Come: Testing Decompilation Correctness of C Decompilers”. dl.acm.org refused automated requests during this review and no other copy of the paper text was found, so the method and results above follow the abstract on the ISSTA 2020 programme page, the ACM page captured by the Wayback Machine (abstract, reference list and an Artifacts Evaluated – Functional badge) and the artifact itself. Reference [9] of the paper links monkbai/DecFuzzer. The reviewed 2020-04-23 commit is the ISSTA’20 artifact-evaluation package: it targets Ubuntu 18.04, needs MySQL for EMI mutation, a prebuilt RetDec v4.0 and Radare2 with r2ghidra, and links seed and result data on Dropbox. The repository has no license file and GitHub reports none. #### Primary sources 1. 2. 3. 4. 5. 6. ### rev.ng: A Unified Binary Analysis Framework to Recover CFGs and Function Boundaries > rev.ng lifts binaries to LLVM IR through QEMU's tiny code generator, so one front end covers every architecture QEMU supports and the output is compilable IR. On that IR the authors build architecture-independent analyses that recover a program's control-flow graph and function boundaries without symbols or debugging information. A value-range analysis (OSRA) bounds indirect jump targets such as switch tables, and further analyses handle predicated instructions, noreturn functions, tail calls and context-dependent control flow. On coreutils built for MIPS, ARM and x86-64 with GCC and clang at -O2, -O3 and -Os, its function-boundary accuracy is close to IDA Pro and better than BAP/ByteWeight and angr. - Authors: Alessandro Di Federico; Mathias Payer; Giovanni Agosta - Venue: CC 2017 - Status: Conference paper - Publication / posting date: February 5, 2017 - Date source: ACM’s Crossref deposit records both print and online publication on 2017-02-05. This entry uses that date, not the conference schedule. - DOI: 10.1145/3033019.3033028 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-29 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The evaluation measures function boundaries, not the CFG directly: the authors could not collect CFG ground truth from GCC or LLVM, so boundary accuracy (Jaccard index against ELF function symbols) is presented as a lower bound on CFG quality. It covers 105 statically linked, stripped coreutils programs for Linux on three of the architectures QEMU supports; the other architectures and dynamically linked binaries were not evaluated. The prototype misses some nested-switch jump tables on x86-64 and jump-table addresses spilled to the stack on MIPS, needs more memory than the other tools on ARM and MIPS, and does not report dead code that IDA Pro finds through prologue heuristics, which the authors treat as a design choice. Baselines are IDA Pro 6.6, BAP 0.9.9 and angr as of November 2016. The paper does not decompile to C. #### Why it fits this collection Adds lifting of machine code to compiler IR with architecture-independent CFG and function-boundary recovery, the analysis layer beneath the collection's curated rev.ng decompiler. #### Publication and review notes Crossref gives the three-author order and pages 131–141; Crossref writes the title in lowercase, and this entry follows the capitalization of the author-hosted 11-page PDF, the same length as the ACM version. The paper reports a C++ prototype of 8,011 lines built on LLVM 3.8 and QEMU 2.5.0, and its acknowledgements give https://rev.ng/ as the Free Software release. The revng/revng repository has since become the full rev.ng decompiler: at commit 57d81a3, the README describes a decompiler developed by rev.ng Labs, licensed GPLv2 as a whole with individual files under MIT. #### Primary sources 1. 2. 3. 4. 5. ### Jetset: Targeted Firmware Rehosting for Embedded Systems > Jetset rehosts firmware only as far as an analyst-chosen goal address, such as the point where a fuzzer can inject input. Given the architecture, the MMIO address range, an entry point and the goal, it symbolically executes the firmware with angr against a modified QEMU, treating peripheral reads as symbolic, cycling interrupts, and steering toward the goal with CFG distances and Tabu search. Solved constraints become C peripheral models for QEMU that replay the inferred values and interrupts so the firmware boots concretely to the goal. The authors evaluate 13 targets across x86, ARM and Motorola ColdFire, including Linux on a Raspberry Pi 2, a BeagleBoard-xM bootloader, a SEL-751 relay, a Boeing 737 CMU-900 and nine P²IM firmware, and use the CMU model with AFL to find a privilege escalation in its VRTX kernel. - Authors: Evan Johnson; Maxwell Bland; YiFei Zhu; Joshua Mason; Stephen Checkoway; Stefan Savage; Kirill Levchenko - Venue: USENIX Security 2021 - Status: Conference paper - Publication / posting date: August 2021 - Date source: The official USENIX proceedings citation gives August 2021. Month precision is retained; the August 11–13 symposium dates on the proceedings cover are not substituted for a publication day. - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations This is targeted rehosting, not full device emulation or firmware decompilation. The analyst supplies the MMIO range, entry point and goal address, and the synthesized models replay one satisfying path and then the last satisfying value for each address, so they need not match real hardware and may mishandle stateful or complex peripheral interaction after the goal. DMA is unsupported; the two targets that needed it relied on an existing QEMU device model or a manually symbolic memory region. Incomplete CFGs, for example across virtual calls or x86 task switches, weaken the distance heuristic, and the BeagleBoard-xM emulator crashed when synthesized serial data was executed as code. Fidelity checks compare against hardware or a manually built QEMU model for selected targets. The VRTX privilege escalation is described by the authors as primarily of academic interest. #### Why it fits this collection Adds symbolic-execution-based peripheral model synthesis for booting firmware to an analysis point, complementing the section’s HAL replacement, MMIO-modeling fuzzing and Linux user-space rehosting research. #### Publication and review notes The USENIX presentation page and final proceedings PDF give the seven authors in this order, the 30th USENIX Security Symposium, pages 321–338, ISBN 978-1-939133-24-3 and month August; the 19-page PDF includes a proceedings cover page. The page also links a separate prepublication PDF. No DOI or arXiv identifier was found. The paper cites jetset.aerosec.org as its open-source release, but that host did not resolve during review. The aerosec GitHub organization, whose site lists the paper, hosts aerosec/jetset with commits from the first two authors; its README says it contains the code and data to reproduce the paper’s results, except the proprietary or security-critical CMU-900 and ICS binaries. The 2024-03-21 commit is GPL-2.0, and its Makefile clones the jetset_engine, jetset_qemu and jetset_public_data repositories over SSH; GitHub does not identify a single license for the modified-QEMU repository jetset_qemu, and jetset_public_data declares none. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### BinRec: Dynamic Binary Lifting and Recompilation > BinRec lifts an executable to LLVM IR from dynamic traces instead of static disassembly, then lowers the IR back to a recovered binary, so compiler passes can optimize, harden or otherwise transform it. Tracing runs the binary under S²E, which translates the executed code through QEMU into LLVM IR; BinRec removes the emulation instrumentation, merges traces from several inputs into one program, and adds optimizations such as register de-aliasing and promotion of emulated state to locals. When the recovered binary reaches a path that was not traced, a configurable handler stops it, falls back to the original code, or lifts the new path incrementally. The authors report recovering all SPEC CINT2006 benchmarks, including C++ programs, and apply it to reoptimization, control-flow integrity, AddressSanitizer and SafeStack hardening, and partial deobfuscation of virtualization-obfuscated code. - Authors: Anil Altinay; Joseph Nash; Taddeus Kroes; Prabhu Rajasekaran; Dixin Zhou; Adrian Dabrowski; David Gens; Yeoul Na; Stijn Volckaert; Cristiano Giuffrida; Herbert Bos; Michael Franz - Venue: EuroSys 2020 - Status: Conference paper - Publication / posting date: April 15, 2020 - Date source: ACM-deposited Crossref print-publication date; the online-publication date is recorded separately in metadata notes. The April 27–30 conference dates are not used. - DOI: 10.1145/3342195.3387550 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The prototype handles only single-threaded 32-bit x86 Linux ELF binaries and does not support self-modifying code. A recovered binary supports only control-flow paths observed during lifting, so behavior on untraced inputs depends on the chosen miss handler and on input coverage. Lifting through S²E is slow, and floating-point instructions are emulated in lifted code; across the SPEC benchmarks, recovered binaries ran at a geometric-mean 0.98x the time of unoptimized inputs and 1.29x that of optimized inputs. BinRec does not map stack slots to variables. The deobfuscation case uses two small programs obfuscated with the authors' own virtualizer, not commercial obfuscators. The McSema and rev.ng comparisons reflect 2020 versions. #### Why it fits this collection Adds dynamic lifting of executables to compiler IR and recompilation back to working binaries, complementing the collection's decompilation research, which recovers source-level code rather than a rebuildable IR. #### Publication and review notes ACM metadata records print publication on 2020-04-15 and online publication on 2020-04-17, pages 1–16; Crossref lists the title as “BinRec” with the subtitle “dynamic binary lifting and recompilation”, and the twelve-author order shown here, the first three marked as equal-contribution joint first authors. The VUSec-hosted PDF is the 16-page ACM-formatted version created on 2020-03-30. The paper gives github.com/securesystemslab/BinRec, whose README (2022-11-29) now says the source is available at trailofbits/binrec-tob. The Trail of Bits commit (2022-11-22; the repository was last pushed 2023-09-18) carries an MIT license with an ONR DFARS acknowledgment and documents Ubuntu 20.04.03 or Debian 11.3, LLVM 14, Python 3.9 and s2e-env at 4bd6a45, with x86 Linux as the only supported environment. #### Primary sources 1. 2. 3. 4. 5. 6. ### Egalito: Layout-Agnostic Binary Recompilation > Egalito statically recompiles stripped x86-64 and ARM64 binaries, using the metadata that position-independent executables and libraries carry to recover a complete disassembly in which every code and data cross-reference becomes an explicit link. Its layout-agnostic intermediate representation, EIR, stays close to machine code, so regenerated output is predictable, while a higher-level view supports analysis; data-flow analyses infer jump tables, which have no metadata. Because the original layout imposes no constraints, tools can move or rewrite code freely; the authors build nine, including continuous code randomization in which Egalito transforms itself, a retpoline defense, and software emulation of Intel CET. They report recovering the compiler's jump tables in 866 of 867 executables and libraries from 172 Debian packages, all tests passing in 90 of 149 transformed packages, and a 1.7% speedup on SPEC CPU 2006. - Authors: David Williams-King; Hidenori Kobayashi; Kent Williams-King; Graham Patterson; Frank Spano; Yu Jian Wu; Junfeng Yang; Vasileios P. Kemerlis - Venue: ASPLOS 2020 - Status: Conference paper - Publication / posting date: March 9, 2020 - Date source: ACM-deposited Crossref print-publication date; the online-publication date is recorded separately in metadata notes. The March 16–20 conference dates are not used. - DOI: 10.1145/3373376.3378470 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Egalito requires position-independent code for sufficient metadata; non-PIC inputs are outside the method except where full relocations are supplied, as in the authors' Fuchsia kernel experiment. Jump-table recovery uses data-flow analysis and an adjacency heuristic, so disassembly is not guaranteed to be complete; the one failure in the Debian study was heavily nested jump tables. The authors list obfuscated code, inline assembly that embeds data in code symbols, C++ exceptions, symbol versioning, and Go or V8 binaries among unsupported cases. Package test failures are partly attributed to these features. RISC-V support was incomplete at publication. The columbia/egalito main branch has had no commits since June 2020, so no current maintenance is implied. #### Why it fits this collection Adds static whole-binary recompilation, which regenerates a working program from a recovered low-level IR without the original layout, complementing the collection's decompilation and lifting research. #### Publication and review notes ACM metadata records print publication on 2020-03-09 and online publication on 2020-03-13, pages 133–147, with the eight-author order shown here; Crossref splits the title into “Egalito” and the subtitle “Layout-Agnostic Binary Recompilation”. The Columbia-hosted PDF is the 15-page ACM-formatted version with the DOI. The paper says Egalito is released under GPL v3 at egalito.org. The columbia/egalito commit (2020-06-01; the repository was last pushed 2023-08-01) is GPL-3.0; its README describes x86_64 and aarch64 support with experimental RISC-V and builds with make and g++ on Debian-style systems. #### Primary sources 1. 2. 3. 4. 5. ### GUI ripping: reverse engineering of graphical user interfaces for testing > GUI ripping reverse engineers a test model from a running desktop application rather than from its source code or specifications. Starting from the top-level windows, a ripper opens each child window by programmatically clicking executable widgets, records every window’s widgets, properties and values, and builds a GUI forest of windows. From that forest it derives event-flow graphs, which record which events can follow one another within a component, and an integration tree of component invocations. The paper describes rippers for Microsoft Windows applications, using window handles and the Windows API, and for Java Swing applications, using Java’s AWT and Swing APIs. It applies them to WordPad, Notepad, Yahoo Messenger and four applications of the TerpOffice student office suite, with the models feeding automated test generation in the authors’ GUITAR and DART systems. - Authors: Atif Memon; Ishan Banerjee; Adithya Nagarajan - Venue: WCRE 2003 - Status: Conference paper - Publication / posting date: 2003 (exact date not verified) - Date source: IEEE Xplore gives the publication date as 2003 and the proceedings title as WCRE 2003; the Crossref deposit has no publication date. Year precision is retained, and the conference dates and the 2004 Xplore insertion date are not substituted. - DOI: 10.1109/WCRE.2003.1287256 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The targets are 2003-era desktop GUIs on Microsoft Windows and Java Swing, not mobile apps or web interfaces; the model assumes deterministic events on widgets with discrete property values and excludes timing-dependent, continuous-media or nondeterministic GUIs. The recovered model is a window, widget and event structure for test generation, not UI code or application logic, and the paper does not establish complete behavioral coverage. Ripping can miss windows and widgets: the Windows ripper misses widgets that bypass the Windows API and cannot distinguish modal from modeless windows, while the Java ripper cannot extract the Print dialog structure. In the case studies, testers added missed windows manually, taking 5 to 10 minutes per application, and identified top-level windows by hand for Windows applications. Results come from seven applications and the authors’ own test pipeline. #### Why it fits this collection Adds a classic execution-based method for recovering an application’s GUI structure and event model, complementing the section’s screenshot-to-code and app-analysis research. #### Publication and review notes IEEE Xplore and Crossref list the authors only as A. Memon, I. Banerjee and A. Nagarajan, with pages 260–269 in the 10th Working Conference on Reverse Engineering proceedings (Victoria, BC); the record uses the full names printed in the paper. The title follows IEEE’s sentence case; the paper capitalizes it as “GUI Ripping: Reverse Engineering of Graphical User Interfaces for Testing”. The PDF is the 10-page copy on Atif Memon’s University of Maryland page; IEEE Xplore holds the version of record and does not mark it open access. The paper says the GUI Ripper was made available as a downloadable tool and cites guitar.cs.umd.edu, but that host did not resolve during review. #### Primary sources 1. 2. 3. 4. ### Ramblr: Making Reassembly Great Again > Ramblr produces reassembleable disassembly: assembly recovered from a stripped binary that can be edited and assembled again with an off-the-shelf assembler. Starting from angr's CFG recovery, it classifies the contents of data regions, then decides which immediates and data values are references to code or data that must become symbols. Base-pointer reattribution handles compiler-optimized references that point outside their target object, and sanity checks let Ramblr refuse to reassemble a binary it cannot handle safely, such as one that encrypts pointers. The authors evaluate 106 GNU Coreutils programs for x86 and x86-64 and 143 DARPA Cyber Grand Challenge binaries at six optimization levels. They report that Uroboros broke 22.64% of 32-bit Coreutils binaries at -O0 and 56.61% at -O1, while Ramblr broke none, and that Ramblr reassembled over 98% of CGC binaries at every level. - Authors: Ruoyu Wang; Yan Shoshitaishvili; Antonio Bianchi; Aravind Machiry; John Grosen; Paul Grosen; Christopher Kruegel; Giovanni Vigna - Venue: NDSS 2017 - Status: Conference paper - Publication / posting date: 2017 (exact date not verified) - Date source: Internet Society-deposited Crossref metadata supplies only publication year 2017; the publisher PDF separately identifies the 26 February–1 March 2017 symposium, which is not used to assert a publication month or day. - DOI: 10.14722/ndss.2017.23225 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The prototype handles x86 and x86-64 ELF binaries produced by GCC or Clang, whose code regions contain no inline data; binaries from compilers such as MSVC, which place jump tables inline, need further work. The authors stress that static content classification is infeasible in general: Ramblr is an empirical approach that is likely to fail if, for example, a binary is linked at a base address chosen so its addresses collide with ordinary constants. The Uroboros comparison covers only 32-bit binaries and, on Coreutils, only -O0 and -O1, because Uroboros failed on 64-bit inputs and its failure rate above -O1 was not meaningful. Correctness is measured by symbolization against linker ground truth and by each program's test cases, which do not prove full equivalence. Results are from 2017 versions of angr and the evaluated toolchains. #### Why it fits this collection Adds reassembleable disassembly, the basis of static binary rewriting that emits modifiable assembly instead of patching bytes, alongside the collection's decompilation and binary-recovery research. #### Publication and review notes Crossref gives the title, the eight-author order and year 2017 with no pages; the DOI resolves to the NDSS programme page, which links the 15-page PDF and slides. The PDF footer identifies NDSS ’17, 26 February–1 March 2017, San Diego. The paper says the entire Ramblr toolchain is open source, with Ramblr included in angr as a Python analysis and other parts in the Patcherex binary-patching platform, but it gives no repository URL, version or commit. angr currently ships a Reassembler analysis (reviewed at commit ae9f578). The evaluation ran under PyPy 5.3.1 on Ubuntu Server 16.04. #### Primary sources 1. 2. 3. 4. ### Crawling Ajax-Based Web Applications through Dynamic Analysis of User Interface State Changes > Crawljax infers a state-flow graph of an Ajax web application by driving it in a real browser. It scans the DOM for candidate clickable elements, fires events on them, compares the resulting DOM against known states with configurable comparison and similarity thresholds, and records new states and the event transitions between them, backtracking by reloading and replaying paths. A concurrent variant partitions the crawl across browser instances. The Java tool uses Selenium WebDriver and plugins; one plugin writes a static mirror of the crawled states. The authors evaluate six open-source and industrial sites and measure how the number of concurrent browsers affects crawling runtime on Google AdSense. - Authors: Ali Mesbah; Arie van Deursen; Stefan Lenselink - Venue: ACM Transactions on the Web - Status: Journal article - Publication / posting date: March 2012 - Date source: ACM’s Crossref deposit gives March 2012 for print and online publication, matching the article footer’s “Publication date: March 2012”. The archived ACM page’s 01 March 2012 is read as the issue month, so month precision is retained. - DOI: 10.1145/2109205.2109208 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Crawljax recovers client-side UI states and navigation transitions, not application source code, server-side logic or a complete behavioral model. The inferred graph is one snapshot instance: click order, server-side factors and state-explosion limits such as depth, time and state caps affect what is found. With default settings it clicks each element once and missed elements that only appear after repeated clicks: 33 of 36 annotated elements were found in Pet Store, and 38 of 40 sampled clickables across four external sites. No gold standard or comparable Ajax crawler was available, so accuracy was assessed by injected elements, a manual reference model and spot checks. External sites change over time, and the concurrent study ran at Google on AdSense. The reviewed 2023 repository is a later Java 11 and Selenium 4 codebase, not the 2012 evaluation build. #### Why it fits this collection Adds a classic dynamic-analysis method for recovering a running web application’s UI state machine, complementing the section’s screenshot-, video- and code-based reconstruction research. #### Publication and review notes Crossref and the archived ACM page give the three authors, ACM Transactions on the Web volume 6, issue 1, pages 1–30; the article’s reference format gives Article 3 (March 2012), 30 pages. The text was reviewed in the 30-page author copy on Ali Mesbah’s UBC site; the ACM page holds the version of record. The article is a revised and expanded version of the authors’ ICWE 2008 paper. It describes Crawljax as Apache-licensed and available from crawljax.com. The code link is the crawljax/crawljax repository, whose largest contributor is the first author; the reviewed 2023-06-19 commit carries an Apache-2.0 LICENSE, version 5.2.4-SNAPSHOT, Java 11 and Selenium 4.9.0. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### RetroWrite: Statically Instrumenting COTS Binaries for Fuzzing and Sanitization > RetroWrite statically rewrites 64-bit position-independent Linux binaries by generating reassembleable assembly, so instrumentation can be inserted as if at compile time. Instead of heuristics, it symbolizes references from the binary's own metadata: control-flow operands, PC-relative addressing that position-independent code must use, and data relocations become assembler labels, which separates references from scalars. On this base the authors build AFL coverage instrumentation and a binary-only AddressSanitizer. They report fuzzing throughput matching compiler instrumentation and 4.5x faster than AFL's QEMU mode, with more bugs found on LAVA-M, and binary ASan that runs 3x faster than Valgrind memcheck on SPEC CPU2006 and detects 80% more bugs in their evaluation, whose coverage tests use Juliet memory-corruption cases. - Authors: Sushant Dinesh; Nathan Burow; Dongyan Xu; Mathias Payer - Venue: IEEE S&P 2020 - Status: Conference paper - Publication / posting date: May 2020 - Date source: IEEE’s Crossref deposit and the IEEE Xplore record give only May 2020 as the publication date. Xplore separately records insertion on 30 July 2020, and the May 18–21 symposium dates are not used to assert a day. - DOI: 10.1109/SP40000.2020.00009 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-30 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The method depends on position-independent code; the paper's implementation targets Linux x86-64 and uses the symbol table for function starts and sizes, so stripped binaries need function boundaries from another tool. It cannot safely rewrite C++ binaries with exception handling, because the DWARF unwind information is not symbolized, and it does not address obfuscated or adversarial binaries. Binary ASan instruments the stack only at stack-frame granularity and adds no redzones around globals, so it misses some overflows that compiler ASan catches, and it remains slower than compiler ASan. Results are from 2019–2020 tool versions on the authors' benchmarks. The repository's later aarch64 rewriter, described in a separate thesis, uses a different algorithm, and the paper's x86-64 results do not apply to it. #### Why it fits this collection Adds static binary rewriting through reassembleable assembly, which reconstructs symbolized assembly so new code can be inserted without source, complementing the collection's decompilation and binary-recovery research. #### Publication and review notes Crossref gives the four-author order, pages 1497–1511 and May 2020; IEEE Xplore, read through a Wayback Machine capture because the live page served a bot challenge, gives the same pages and month and a 30 July 2020 insertion date. The 15-page HexHive PDF is byte-identical to the nebelwelt.net copy that the repository README links; it lacks IEEE page numbers and is used as the author-hosted copy. The paper names github.com/HexHive/retrowrite and says its results can be reproduced with the repository’s Docker image. At the reviewed 2025-04-26 commit, the repository has an MIT LICENSE file, though GitHub reports no recognized license, and the README lists Python 3.6 with pyelftools and capstone. Its feature table marks stripped binaries, non-PIE binaries and C++ as unsupported for the x64 rewriter and points to a separate thesis for the aarch64 version. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Game Engine Learning from Video > Learns a rule-based forward simulator of a 2D game from gameplay video. Using a supplied sprite palette, OpenCV locates sprites in each frame; matched sprites are converted into hand-designed fact types for animation, position, relative distance, x and y velocity and camera offset. Game Engine Search then scans the frames, and whenever the current engine’s predicted next frame differs from the real one by more than a threshold, it runs a greedy search over engines that add or modify condition–effect rules or mark them as player-controlled. Engines are ranked by pixel error and rule count. Trained on one Super Mario Bros. Level 1-1 video, the learned engine predicts frames of a different player’s video more accurately than a CNN frame predictor and a previous-frame baseline, and a value-iteration agent planning with it shows no significant difference from one using the Infinite Mario engine’s native forward simulation. - Authors: Matthew Guzdial; Boyang Li; Mark O. Riedl - Venue: IJCAI 2017 - Status: Conference paper - Publication / posting date: August 2017 - Date source: The IJCAI-deposited Crossref record gives August 2017 for print publication, represented at month precision. The IJCAI proceedings page gives no publication day, and the conference dates are not substituted. - DOI: 10.24963/ijcai.2017/518 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers one level of one game: training uses a single “speedrunner” video of Super Mario Bros. Level 1-1 (1,569 frames), and testing uses an “explorer” video of the same level. Frame parsing depends on a fan-authored sprite sheet and hand-authored fact types, which the authors say makes the method less applicable to more complex domains such as real video. The learned engine is a set of search-derived rules for on-screen sprite behavior, not recovered game code or a binary; it does not represent player death or level transitions, and mechanics absent from Level 1-1 are not expected to transfer. Search can be slow at low thresholds, up to two weeks for one level on a 2013 iMac, and the reported run used a zero threshold. The CNN comparison used downscaled grayscale frames, and the gameplay comparison is indirect, through agents in the Infinite Mario engine. #### Why it fits this collection Adds a search-based method for reconstructing game rules from gameplay video, complementing the section’s neural and LLM-based world-model and code-synthesis research. #### Publication and review notes The IJCAI proceedings page and the 7-page PDF give the three authors, the IJCAI-17 main track and pages 3707–3713; the Crossref record matches the authors and DOI. The paper links no code, learned engines or parsed data, and the Super Mario Bros. footage and fan-made sprite sheet are third-party materials. #### Primary sources 1. 2. 3. ### Learning to Simulate Dynamic Environments with GameGAN > GameGAN learns an action-conditioned neural simulator of a game from recorded frames and the actions taken, without access to the game’s logic or engine. An action-conditioned LSTM dynamics engine with a stochastic latent variable predicts the next state, an optional external memory module builds an internal map so that revisited locations stay consistent, and a rendering engine decodes frames while separating static from dynamic components. Training is end-to-end with adversarial losses, including an action-conditioned discriminator, and a temporal cycle loss for memory consistency. The authors evaluate on a modified Pac-Man, a ghost-free Pac-Man-Maze and VizDoom “take cover”, training RL agents inside the learned simulators and testing them in the real games, and measure long-term consistency with a come-back-home task; a human-playable model of the official Pac-Man is shown qualitatively. - Authors: Seung Wook Kim; Yuhao Zhou; Jonah Philion; Antonio Torralba; Sanja Fidler - Venue: CVPR 2020 - Status: Conference paper - Publication / posting date: June 2020 - Date source: IEEE’s Crossref deposit and an archived copy of the IEEE Xplore page give June 2020, represented at month precision. The May 2020 arXiv submission and the conference dates are not substituted. - First arXiv submission: May 25, 2020 - arXiv: 2005.12126 - Reviewed arXiv version: v1 - DOI: 10.1109/CVPR42600.2020.00131 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations GameGAN imitates a game’s pixels and dynamics; it does not recover game code, symbolic rules, assets or an executable. Training needs large logged datasets with actions: 40K Pac-Man episodes from a high-entropy DQN agent that sees the full environment, and 10K random-policy VizDoom episodes, at 84×84 and 64×64 resolution. Quantitative results cover small grid-based Pac-Man variants and one VizDoom scenario, with an external classifier supplying game outcomes. Agents trained in the simulators can exploit modeling errors: the full model sometimes let Pac-Man pass through walls, and its Pac-Man agents scored below those of the memoryless variant, while on VizDoom the World Model baseline scored higher than GameGAN. The released code supports VizDoom training only, relies on a deprecated WorldModels data setup, and is under the non-commercial NVIDIA Source Code License; Pac-Man data and the official Pac-Man model are not included. #### Why it fits this collection Adds a neural approach to reconstructing a playable game simulator from observed frames and actions, complementing the section’s program-synthesis and black-box game-replication research. #### Publication and review notes Crossref and the archived IEEE Xplore page give the five authors, CVPR 2020 and pages 1228–1237; IEEE metadata capitalizes the title as “Learning to Simulate Dynamic Environments With GameGAN”, while the CVF open-access paper and arXiv print “with”. The 10-page CVF PDF is the Computer Vision Foundation’s open-access version; IEEE Xplore holds the version of record. arXiv has only v1, submitted 2020-05-25 with the comment “CVPR 2020”. The repository README at the reviewed 2021-11-11 commit gives BibTeX pages 1231–1240, which differ from IEEE, and its Project Page link points to an unrelated lift-splat-shoot page. The README lists Ubuntu 18.04 and Python 3.8.3, and requirements pin torch 1.4.0 and torchvision 0.5.0. LICENSE section 3.3 limits use to non-commercial research or evaluation. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Combining Functional and Automata Synthesis to Discover Causal Reactive Programs > AutumnSynth synthesizes a program in Autumn, a functional reactive language for Atari-style grid worlds, from a trace of observed frames and user actions such as clicks and arrow keys. Heuristic perception parses each frame into typed objects and tracking links them across time steps. The synthesizer then finds an update function for each observed change and searches for the event that triggers it. When no event over the observed state explains an update, automata synthesis invents latent state, such as counters or modes, using a SAT-based Sketch encoding or a faster heuristic. The authors introduce the 30-program Causal Inductive Synthesis Corpus (CISC), on which the heuristic variant synthesizes 27 programs. A slightly modified version synthesizes 21 of 27 games from the third-party EMPA grid-world corpus. - Authors: Ria Das; Joshua B. Tenenbaum; Armando Solar-Lezama; Zenna Tavares - Venue: Proceedings of the ACM on Programming Languages (POPL 2023) - Status: Journal article - Publication / posting date: January 9, 2023 - Date source: ACM’s Crossref deposit records print publication on 2023-01-09; the online-publication date of 2023-01-11, also shown on the ACM article page, is recorded separately in metadata notes. The POPL meeting dates are not substituted. - DOI: 10.1145/3571249 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-10-31 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Targets are small, fully observed grid worlds expressible in Autumn, not games with continuous physics, rich graphics or compiled code. Perception and tracking are heuristic, and because Autumn renders objects partially transparent, perception does not address occlusion. CISC input traces were constructed manually to exercise each model’s dynamics, and success means the synthesized program reproduces the given trace, not semantic equivalence to the ground truth. Heuristic runtimes range from about two minutes to 9–13 hours; the Sketch variants time out after 24 hours on several benchmarks, and EMPA runs time out after 40 hours on some games. EMPA required domain-specific changes for random events. Because most EMPA games are nondeterministic, their results were checked by manual inspection, and only the first level of each game was used. On new CISC test traces, four synthesized programs diverged from the ground truth because their training traces did not show all dynamics, and concatenating several traces recovered the ground-truth program for the three that were retested. For random events AutumnSynth detects nondeterminism but does not infer the underlying probability distributions. The method is symbolic program synthesis and does not use an LLM. #### Why it fits this collection Adds symbolic synthesis of game programs, including latent state, from observed play, complementing the section’s LLM-based code world-model and game-reconstruction research. #### Publication and review notes Crossref, the archived ACM page and the 31-page article give the four authors, Proceedings of the ACM on Programming Languages volume 7, issue POPL, Article 56, pages 1628–1658. Crossref records print publication on 2023-01-09 and online publication on 2023-01-11, and the article footer gives January 2023. The ACM article is open access under CC BY 4.0. The paper says the Autumn language and AutumnSynth were implemented in Julia but links no code or artifact. The author’s publication page links only papers. The riadas/AutumnSynth.jl repository under the first author’s account contained only a one-line README at its single 2023-03-15 commit. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### StructEval: Benchmarking LLMs' Capabilities to Generate Structural Outputs > Evaluates generation and conversion of structured outputs, including HTML, React and SVG, with separate checks for format adherence and structural correctness. - Authors: [Authors: see the paper](https://arxiv.org/abs/2505.20139) - Venue: arXiv - Status: Preprint - Publication / posting date: May 26, 2025 - Date source: Original arXiv first-submission date; reviewed preprint edition retained. - First arXiv submission: May 26, 2025 - arXiv: 2505.20139 - Reviewed arXiv version: v3 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-01 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Not a software reverse-engineering or GUI-navigation benchmark. Structured-output scores do not prove recovered source identity, backend reconstruction or behavioral equivalence; aggregate scores are not fully correct-output percentages. #### Why it fits this collection A supporting method for checking structured and rendered artifacts produced during frontend reconstruction; parseability alone does not establish correct content. #### Publication and review notes This record describes the original arXiv edition. Supporting method. #### Primary sources 1. 2. 3. ### WebWorld: The Browser as a World Model for Self-Improving Web Code > Uses typed browser interaction contracts to check progress and preserve previously verified capabilities while improving generated web code. Only accepted transitions become training examples. - Authors: [Authors: see the paper](https://arxiv.org/abs/2608.30530) - Venue: arXiv - Status: Preprint - Publication / posting date: August 31, 2026 - Date source: Original arXiv first-submission date; reviewed preprint edition retained. - First arXiv submission: August 31, 2026 - arXiv: 2608.30530 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-01 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The study concerns web-code generation and self-improvement, not recovery of original source code. Acceptance covers declared interactions and preserved capabilities, not equivalence to an arbitrary original application. Distinct from the other WebWorld web-simulator paper. #### Why it fits this collection A supporting validation method for reconstructed web interfaces: test executable behavior and regressions instead of relying on visual similarity alone. #### Publication and review notes This record describes the original arXiv edition. Supporting method. #### Primary sources 1. ### Training Language Model Agents to Find Vulnerabilities with CTF-Dojo > CTF-Dojo is an execution environment for training LLM agents on capture-the-flag tasks: 658 challenges from 50 competitions held between 2011 and 2025, taken from pwn.college's CTF Archive and containerized with Docker. Its CTF-Forge pipeline prompts DeepSeek-V3-0324 to write each challenge's Dockerfile, docker-compose file and challenge metadata; across three independent runs, 650 challenges consistently built and answered on their expected ports. Qwen3-Coder and DeepSeek-V3-0324 agents in the EnIGMA+ scaffold, capped at 40 turns, collected trajectories. Matched CTFtime writeups served as hints during collection and were removed afterwards, and ports, paths, distractor code and other runtime details were randomized per rollout. Rejection-sampling fine-tuning of Qwen3 8B, 14B and 32B on 486 flag-capturing trajectories from 274 solved challenges raises average Pass@1 on InterCode-CTF, NYU CTF Bench and Cybench by up to 11.6 points; the 32B model reaches 31.9%. - Authors: Terry Yue Zhuo; Dingmin Wang; Hantian Ding; Varun Kumar; Zijian Wang - Venue: ICML 2026 - Status: Conference paper - Publication / posting date: September 29, 2026 - Date source: PMLR states that Volume 306 was published on 29 September 2026, matching the paper page's citation_publication_date of 2026/09/29. The July 6–11 conference dates and the arXiv dates are not used. - First arXiv submission: August 25, 2025 - arXiv: 2508.18370 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The environments span general CTF categories, not reverse engineering alone: of the 658 challenges, 228 are cryptography, 163 pwn, 123 reverse engineering, 85 miscellaneous, 38 forensics and 21 web. Among the 274 challenges with successful trajectories, cryptography is the largest category (141), followed by reverse engineering (52). Benchmark gains are reported per benchmark over 323 tasks, at temperature 0 with 40 turns, not per category, so they do not measure reverse-engineering accuracy. Decontamination matched competition and challenge names and removed 3 overlapping challenges; the authors note that it cannot exclude broader similarity between tasks. Only 150 challenges (23%) matched a writeup, all trajectories come from two teacher models, and only supervised fine-tuning is studied; the authors name the static 658-challenge scale as a limit. Hashed flag checkers in the upstream archive can be wrong, and the authors report four such bugs. The repository code is CC BY-NC 4.0. It holds CTF-Forge, the metadata and writeup-matching scripts and a challenge index, but not the challenge files, which are cloned separately from pwn.college's CTF Archive and are not covered by the repository license. The reviewed tree has no trajectories or trained weights, and writeups must be collected separately. Capturing a flag does not show recovered program structure. #### Why it fits this collection Adds execution-grounded training of open-weight CTF agents on a task pool that includes reverse-engineering challenges; trajectories are collected and evaluated in EnIGMA+, an extension of the EnIGMA scaffold in this section. #### Publication and review notes The PMLR page, its BibTeX and the proceedings PDF give the same five authors in order, the booktitle 'Proceedings of the 43rd International Conference on Machine Learning', volume 306, pages 168265–168284 and no DOI. arXiv v1 is dated 2025-08-25 and v2 2025-09-23, with no comment or journal reference; v2 matches the PMLR title and headline numbers, though its training text says 7B where its tables and the PMLR text use 8B. At the reviewed 2026-01-10 commit, the LICENSE file is the CC BY-NC 4.0 text and NOTICE gives SPDX CC-BY-NC-4.0, while GitHub reports NOASSERTION. The README and NOTICE title the project 'Training Software Agents to Find Vulnerabilities with CTF-Dojo', and the README's second BibTeX entry gives the separate Cyber-Zero preprint (arXiv 2508.00910) the title 'CTF-Dojo: Training Cybersecurity Agents without Runtime'. ctf_archive.json lists 658 challenges, with 229 cryptography and 162 pwn against the paper's 228 and 163. Building environments needs a model endpoint through litellm (default deepseek-v3-0324), a clone of pwncollege/ctf-archive, whose reviewed commit has no root license file, a separately gathered writeups JSONL, and EnIGMA+ from the Cyber-Zero repository for trajectory collection. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ### Cyber-Zero: Training Cybersecurity Agents without Runtime > Cyber-Zero synthesizes training trajectories for capture-the-flag (CTF) agents from public writeups instead of running the challenges. Writeups collected from CTFtime through the CTF Archives repository are cleaned, filtered and completed with DeepSeek-V3-0324, which fills in missing metadata and extracts flags; after removing 47 challenges that overlap the evaluation benchmarks, the corpus holds 6,188 writeups for 4,610 challenges from 543 competitions in six categories, 2017–2025. Two DeepSeek-V3-0324 personas then simulate each solve: a CTF player that sees only the challenge content, and a Bash terminal that sees the writeup and flag, invents plausible command output and may inject hints, which are removed before training. Trajectories use the EnIGMA scaffold format and are kept only if they reach the exact flag, pass format checks and are judged by an LLM filter to follow the writeup's approach. Qwen3, Qwen2.5-Instruct and SWE-agent-LM models are fine-tuned on 9,464 of these trajectories and evaluated with EnIGMA+, the authors' parallel version of EnIGMA, on InterCode-CTF, NYU CTF Bench and Cybench. The fine-tuned Qwen3-32B (Cyber-Zero-32B) rises from 20.3% to 33.4% average Pass@1, the 13.1-point gain reported in the abstract. - Authors: Terry Yue Zhuo; Dingmin Wang; Hantian Ding; Varun Kumar; Zijian Wang - Venue: ICLR 2026 - Status: Conference paper - Publication / posting date: 2026 (exact date not verified) - Date source: Publication year stated by the official ICLR proceedings; no finer publication date is asserted. The proceedings page's citation date of 2026-04-20 is not adopted, and the arXiv dates are not substituted. - First arXiv submission: July 29, 2025 - arXiv: 2508.00910 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations No training trajectory was executed: command outputs are simulated by an LLM that knows the writeup and flag, and trajectories are filtered by exact flag match, format checks and an LLM judge rather than by running commands. The authors acknowledge that the corpus may contain incorrect command traces and fabricated flags, that they report no quantitative error analysis, and that the simulated traces exclude interactive tools such as gdb, Python shells and browsers. The writeups and the evaluation tasks span six general CTF categories, not reverse engineering alone; the three test benchmarks hold 323 runnable tasks, 84 of them reverse engineering, and aggregate Pass@1 is not reverse-engineering accuracy. Results are single greedy Pass@1 runs in the authors' EnIGMA+ scaffold with a 40-turn cap, on benchmark copies the authors repaired; 17 tasks could not be set up. Contamination control removed 47 overlapping challenges by manual comparison. Capturing a flag does not show recovered program structure. The repository is archived and licensed CC BY-NC 4.0, and its benchmark README states that the bundled benchmark content remains the property of its original creators. #### Why it fits this collection Adds runtime-free trajectory synthesis for training open CTF agents whose tasks include reverse engineering; it formats its data for EnIGMA, also in this section, and evaluates on InterCode-CTF, NYU CTF Bench and Cybench. #### Publication and review notes The proceedings page, its PDF and arXiv list the same five authors in order. The proceedings page lists pages 154054–154184 and no DOI. Its 131-page PDF is headed 'Published as a conference paper at ICLR 2026'; compared with arXiv v2 it adds an appendix of limitations, describes the 47-challenge contamination removal and moves Zijian Wang's affiliation to Meta Superintelligence Labs. Its abstract says Cyber-Zero-32B is comparable to frontier open-weight models, while arXiv v2 and the proceedings page abstract claim state-of-the-art results among open-weight models. arXiv v1 is dated 2025-07-29 and v2 2025-08-25; v2's comment links the repository. At the reviewed 2025-09-02 commit the GitHub repository is archived; its LICENSE is the CC BY-NC 4.0 legal code (GitHub reports NOASSERTION) and its NOTICE gives SPDX CC-BY-NC-4.0. It contains the generation, quality-filter and reformatting scripts (Python 3.8 or later, LiteLLM, with DeepSeek-V3-0324 as the default model, so runs need a model provider), the EnIGMA+ scaffold and repaired copies of the three benchmarks. The README links no released trajectory corpus or model weights. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### Binary Rewriting without Control Flow Recovery > E9Patch statically rewrites x86-64 binaries by inserting jumps to trampolines without moving any other instruction, so the original set of jump targets is preserved and control-flow recovery, symbolization and debug information are not needed. Where a five-byte jump does not fit, instruction punning, padding and successor or neighbor eviction overlap the jump with existing bytes or relocate neighboring instructions into their own trampolines; physical page grouping reduces the memory and file-size cost of scattered trampolines. Instruction locations come from a separate frontend, a basic linear disassembler in the evaluation. The authors evaluate SPEC2006, Ubuntu 16.04 system binaries, and Chrome and Firefox builds over 100 MB, and demonstrate binary repair and heap-write hardening with low fat pointers. - Authors: Gregory J. Duck; Xiang Gao; Abhik Roychoudhury - Venue: PLDI 2020 - Status: Conference paper - Publication / posting date: June 11, 2020 - Date source: ACM’s Crossref deposit records print and online publication on 2020-06-11, and an archived copy of the ACM article page shows the same date. The June 15–20 PLDI dates printed in the paper are not substituted. - DOI: 10.1145/3385412.3385972 - Sources reviewed: 2026-10-19 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations This is static binary rewriting and instrumentation, not decompilation or source recovery. It relies on the frontend’s instruction locations and sizes being correct, assumes patched code is not read as data or self-modified, and assumes the input does not already use overlapping instructions. Each tactic can fail: 1,098 of about 10.5 million patch locations were not patched, baseline coverage alone was 72.79% for jumps and 81.63% for heap writes, and non-PIE binaries are harder than PIE ones. Chrome’s mixed code and data required starting disassembly after ChromeMain, and Firefox’s code was patched in libxul.so. Reported overheads, such as about 113% for Chrome and 46% for Firefox on Dromaeo DOM benchmarks with heap-write instrumentation, were measured with the PLDI prototype, with SPEC2006 compiled by GCC in non-PIE mode; they do not describe the current release. #### Why it fits this collection Adds a control-flow-agnostic static rewriting technique for stripped x86-64 binaries, a foundation for patching and instrumenting binaries whose structure has not been recovered, complementing the section’s lifting and decompilation research. #### Publication and review notes Crossref and the archived ACM page give the three authors, the PLDI 2020 proceedings and pages 151–163; ACM metadata uses sentence case. The PDF is the 13-page author’s version on Gregory J. Duck’s NUS page, linked from the repository README, and the ACM page holds the version of record. The reviewed 2026-06-28 repository commit describes x86_64 Linux ELF executables and shared objects, GPL-3.0 with some MIT-licensed files, and states that the current version is significantly improved over the prototype evaluated in the PLDI paper, with new optimizations, improved physical page grouping and slightly higher coverage. #### Primary sources 1. 2. 3. 4. 5. 6. ### LaTCoder: Converting Webpage Design to Code with Layout-as-Thought > LaTCoder converts webpage design images to HTML/CSS by making layout an explicit intermediate step. A rule-based divider recursively finds solid-colored horizontal or vertical lines that avoid OCR-detected text, then merges small regions into grid-aligned blocks. An MLLM writes code for each block with a chain-of-thought prompt. The blocks are then assembled by absolute positioning or by the MLLM, and a reference-free verifier combining MAE and CLIP picks the better result. The paper also introduces CC-HARD, 128 complex-layout pages manually sampled from Common Crawl. - Authors: Yi Gui; Zhen Li; Zhongyi Zhang; Guohao Wang; Tianpeng Lv; Gaoyang Jiang; Yi Liu; Dongping Chen; Yao Wan; Hongyu Zhang; Wenbin Jiang; Xuanhua Shi; Hai Jin - Venue: KDD 2025 - Status: Conference paper - Publication / posting date: August 3, 2025 - Date source: ACM-deposited Crossref metadata gives 3 August 2025 for both online and print publication; this date is not inferred solely from the August 3–7 conference schedule. - First arXiv submission: August 5, 2025 - arXiv: 2508.03560 - Reviewed arXiv version: v1 - DOI: 10.1145/3711896.3737016 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Targets static HTML/CSS from a design image; JavaScript behavior, interactions, navigation and backends are outside the method, and it does not recover a site's original source. Evaluation uses Design2Code-HARD (80 pages) and CC-HARD (128 pages), scoring generated code and screenshots against references with TreeBLEU, CLIP, Visual Score and MAE. Reported gains are relative changes on small absolute scores: with DeepSeek-VL2 on CC-HARD, TreeBLEU rises from 0.09 to 0.15 (+66.67%), and CLIP falls slightly on Design2Code-HARD. The divider assumes rectangular, solid-colored separators and fixed pixel thresholds; the block-merge area was tuned on CC-HARD. Short-context models use absolute positioning only, which fixes block positions from the design. Block content can still be misplaced, and Gemini sometimes omitted blocks during assembly. Pairwise human preference (at least 60% for LaTCoder) covers GPT-4o on CC-HARD only, by majority vote of six annotators. GPT-4o, Gemini and DeepSeek-VL2 results are historical baselines, not current rankings. #### Why it fits this collection Adds layout-first, block-wise screenshot-to-code generation with explicit assembly and verification, complementing DCGen's divide-and-conquer prompting and end-to-end website reconstruction benchmarks. #### Publication and review notes Crossref and arXiv agree on the 13-author order and DOI. arXiv v1 of 2025-08-05 is the KDD-formatted paper, with comment “KDD 2025 v2”; the ACM landing page refused automated retrieval, so bibliographic details follow Crossref. The paper links examples/latcoder on the naturalcc main branch. The reviewed snapshot is main at 5f840620 (2026-06-02); the directory was added on 2025-09-25. The repository is MIT-licensed at its root; the example README also says MIT but links a LICENSE file absent from that directory, and its project-page link is malformed. The directory contains the divider, generation and assembly agents, adapted Design2Code baselines, evaluation for MAE, Visual Score, CLIP and TreeBLEU, a human-evaluation notebook, and data/CC-HARD.parquet. That file matches the byte size of the Hugging Face dataset xcodemind/CC-HARD, which has 128 image–HTML rows under a CC-BY-4.0 card. Design2Code-HARD and the DCGen baseline must be obtained separately. requirements.txt pins openai 1.55.3, google-generativeai 0.8.3 and transformers 4.45.2, but installs CLIP and DeepSeek-VL from moving main branches plus a vLLM nightly wheel. GPT-4o is called through Azure OpenAI with placeholder credentials; DeepSeek-VL2 is served through vLLM. The paper reports runs on four A800 80 GB GPUs. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ### Understanding JavaScript Event-Based Interactions > Clematis helps developers understand a JavaScript web application's runtime behavior from a recorded user session. A proxy instruments JavaScript on the fly to log DOM events, timeouts, XMLHttpRequest phases, function calls and DOM mutations. The trace is grouped into episodes, each with its triggering event, executed functions and resulting DOM changes, linked by temporal and causal edges and shown in an interactive visualization. In an industrial study with 20 developers on the Phormer photo gallery, the authors report 61% higher task accuracy and 47% less completion time than developers using their preferred tools. - Authors: Saba Alimadadi; Sheldon Sequeira; Ali Mesbah; Karthik Pattabiraman - Venue: ICSE 2014 - Status: Conference paper - Publication / posting date: May 31, 2014 - Date source: ACM-deposited Crossref metadata gives 31 May 2014 for both online and print publication, which is also the first day of ICSE 2014; the date comes from the deposit, not from the conference schedule. - DOI: 10.1145/2568225.2568268 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations A dynamic program-comprehension aid for client-side behavior exercised in one recorded session; it does not reconstruct server-side logic, generate a replacement application or establish behavioral equivalence. Code run through eval is not captured. Evaluation consists of two small controlled experiments on comprehension tasks: 16 UBC participants on a lab-built survey application against Firebug, and 20 professional developers on Phormer. The authors graded accuracy against a prewritten answer key. Overhead was measured only for one minute of Phormer activity. The 2014 prototype drives Firefox through Selenium and a WebScarab proxy; it is not shown to run on current browsers, and the comparison tools are historical. #### Why it fits this collection Adds execution-trace recovery of a web application's event, timer, request and DOM causality, complementing the collection's screenshot-, design- and video-based website reconstruction research. #### Publication and review notes Crossref establishes the four-author order, the ICSE ’14 proceedings and pages 367–377; it deposits the title in sentence case. The author-hosted PDF is an 11-page copy carrying the ICSE ’14 permission block. The extended ACM TOSEM 2016 article “Understanding JavaScript Event-Based Interactions with Clematis” (DOI 10.1145/2876441) is a separate work. The paper cites the lab page salt.ece.ubc.ca/software/clematis/, which no longer responds; its 2014-07-08 Internet Archive copy links github.com/saltlab/clematis and technical report UBC-SALT-2014-001. The reviewed repository is GPL-3.0, with master at 7b2479a0 committed on 2015-06-19 and no later pushes. README says the tool runs from Eclipse with the m2e plugin, Maven, a Jetty server and Mozilla Firefox; Chrome support was only planned. It was tested with Phormer and a downloadable survey application. pom.xml targets Java 1.6 and uses Crawljax 2.2 and Rhino 1.7R4, with open-ended ranges for Selenium (from 2.31.0) and WebScarab, so a build today may resolve different dependencies. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Is This the Same Code? A Comprehensive Study of Decompilation Techniques for WebAssembly Binaries > Measures how well existing WebAssembly decompilers recover C, with native-binary decompilers as the baseline. The same C programs are compiled with Emscripten to WebAssembly and with clang to native code, then decompiled by wasm2c, w2c2 and wasm-decompile or by Ghidra and RetDec. Correctness reuses 1,000 Csmith programs from DecFuzzer, recompiling the output and comparing its execution with the original; code-complexity metrics and AST similarity to the original source are measured on PolyBenchC and CHStone at -O0 to -O2. wasm2c passed all 1,000 correctness programs, against 649 for wasm-decompile, 818 for Ghidra and 775 for RetDec. - Authors: Wei-Cheng Wu; Yutian Yan; Hallgrimur David Egilsson; David Park; Steven Chan; Christophe Hauser; Weihang Wang - Venue: SecureComm 2024 - Status: Conference paper - Publication / posting date: September 1, 2025 - Date source: Springer’s Crossref deposit gives published-online and issued date 2025-09-01, labelled First Online, and print year 2026. The October 2024 conference dates and the 2024-11-04 arXiv submission are not substituted for this publication date. - First arXiv submission: November 4, 2024 - arXiv: 2411.02278 - Reviewed arXiv version: v1 - DOI: 10.1007/978-3-031-94448-2_6 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Correctness covers only generated single functions with local-variable arithmetic and no library calls, pointers or global state, so the wasm2c result does not establish correctness on general programs. w2c2 is excluded from the correctness test, and wasm-decompile output could be parsed for structural similarity only at -O0. Native baselines pass through DecFuzzer’s syntax rewriter, and the authors note that some Ghidra and RetDec failures may come from that evaluation step rather than the decompilers. Readability is estimated from metrics such as lines of code, nesting depth, cyclomatic and Halstead complexity, gotos and casts, not from a human study. The benchmarks are C suites compiled by the authors with one Emscripten/clang toolchain, not real-world WebAssembly modules, and tool versions are described only as the latest available at the time. #### Why it fits this collection Adds an empirical baseline for existing WebAssembly decompilers, complementing the LLM-based WebAssembly decompilation papers and native decompiler correctness testing in this section. #### Publication and review notes Crossref records the chapter in the LNICST book Security and Privacy in Communication Networks, pages 108–130, with conference information for SecureComm 2024 (the 20th edition, Dubai, 28–30 October 2024). Crossref gives no series volume number, so none is recorded. The Springer landing page refused automated requests; the description and limitations rest on the 13-page arXiv v1 manuscript, whose footer names SecureComm 2024. The paper says its benchmark and analysis framework will be open-sourced but gives no URL, and no release was found. #### Primary sources 1. 2. 3. 4. ### Revisiting Binary Code Similarity Analysis Using Interpretable Feature Engineering and Lessons Learned > Builds BinKit, a reproducible cross-compilation benchmark of 243,128 binaries and 36,256,322 functions from 51 GNU packages, covering 1,352 combinations of eight architectures, nine GCC and Clang versions, five optimization levels, and PIE, LTO, no-inline and Obfuscator-LLVM options. TikNib, an interpretable baseline over simple presemantic function features, measures how compilers, options and architectures change those features. The authors report that a few basic features approach a deep-learning tool’s accuracy, that type features push AUC above 0.99, and trace failures to IDA Pro analysis errors, compiler back-end differences and architecture-specific code. - Authors: Dongkwan Kim; Eunsoo Kim; Sang Kil Cha; Sooel Son; Yongdae Kim - Venue: IEEE Transactions on Software Engineering - Status: Journal article - Publication / posting date: April 2023 - Date source: IEEE’s Crossref deposit gives the volume 49, issue 4 print issue date as 2023-04-01, represented at month precision. The 2020-11-21 arXiv v1 date and the June 2022 acceptance note are not substituted for the journal issue date. - First arXiv submission: November 21, 2020 - arXiv: 2011.10749 - Reviewed arXiv version: v4 - DOI: 10.1109/TSE.2022.3187689 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Studies function-level, presemantic (syntactic and structural) features on Linux GNU packages compiled from source with debugging information for ground truth; semantic features, NLP-based models and whole-binary or other similarity tasks are outside the evaluation. The above-0.99 AUC uses argument and return types derived from source via Ctags and debugging information, not types recovered from stripped binaries. The state-of-the-art comparison sets TikNib’s AUC on VulSeeker’s ASE datasets against VulSeeker’s author-reported numbers rather than a re-run, and omits the original firmware images. Obfuscation covers Obfuscator-LLVM substitution, bogus control flow and flattening applied once. Experiments used IDA Pro 6.95, and the authors cannot rule out erroneous MIPS feature extraction. The results do not rank later learned or LLM-based models. #### Why it fits this collection Adds a public, reproducible benchmark and interpretable baseline for binary function matching, and documents how compiler settings and disassembler errors bias similarity results, complementing learned models such as jTrans. #### Publication and review notes IEEE TSE 49(4), pages 1661–1682; Crossref records a CC BY 4.0 license from 2023-04-01. The reviewed arXiv v4 (2022-07-07) notes acceptance in June 2022; its running header still reads November 2020, a template date rather than the publication date. The IEEE and Crossref title capitalizes “Using”, while arXiv uses “using”. At reviewed BinKit commit f6565a3 (2023-12-15, MIT), the README describes BinKit 2.0 with 371,928 binaries, 1,904 option combinations, 23 compilers and an added Ofast level, which the paper did not evaluate; its BinKit 1.0 section matches the paper’s 243,128 binaries and 1,352 combinations, counting four obfuscation options as compilers (13 in total), and was tested on Ubuntu 16.04. Paper-version datasets, feature pickles and toolchains download from Google Drive. TikNib, the analysis tool, is a separate MIT repository reviewed at 3b7c165 (2025-05-18); its README gives IDA Pro 6.95 scripts for the paper setup and separate IDA Pro 7.5 scripts. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Decompiling x86 Deep Neural Network Executables > BTD (Bin to DNN) decompiles stripped 64-bit x86 executables emitted by deep-learning compilers into model specifications: operator types, network topology, dimensions and parameters. A learned classifier labels disassembled functions as DNN operators, Intel Pin dynamic analysis chains them, and taint-reduced, trace-based symbolic execution with per-operator patterns recovers dimensions and parameter layouts. The authors rebuild recovered models in PyTorch and recompile them to compare behaviour with the original executable. - Authors: Zhibo Liu; Yuanyuan Yuan; Shuai Wang; Xiaofei Xie; Lei Ma - Venue: USENIX Security 2023 - Status: Conference paper - Publication / posting date: August 2023 - Date source: The BibTeX on the USENIX presentation page gives August 2023 for the 32nd USENIX Security Symposium proceedings. Month precision is retained; the August 9–11 symposium dates are not substituted for a publication day, and the 2022 arXiv dates belong to the extended preprint. - First arXiv submission: October 3, 2022 - arXiv: 2210.01075 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluated only on 64-bit x86 executables from TVM v0.7, v0.8 and v0.9.dev (-O0 and -O3), three Glow snapshots from 2020–2022 and NNFusion v0.2/v0.3; GPU, accelerator and other-architecture executables are discussed, not decompiled. It assumes flawless disassembly and function recovery (IDA Pro 7.5 in the paper) and known compilation provenance, and dimension/parameter patterns are hand-designed per operator: 22 of 36 ONNX operators needing such patterns are covered, excluding quantized operators such as QLinearConv. The authors report correct specifications for 59 of 65 executables from seven CV models and FastText; one TVM -O3 ResNet18 Conv layout required manual fixing with ground truth, and NNFusion compiled only its own VGG11. Recompiled behaviour is compared on 100 ImageNet images or 50 crafted FastText inputs, not proven for all inputs. Obfuscated executables were not evaluated. #### Why it fits this collection Extends decompilation beyond C/C++ programs to compiled machine-learning models, recovering a rebuildable high-level specification from optimized native code. #### Publication and review notes The USENIX presentation-page BibTeX establishes the five-author order, proceedings title, pages 7357–7374 and August 2023. arXiv v2 (2022-10-04; v1 2022-10-03) is the authors' 25-page extended version, which the 19-page final paper cites for omitted details; figures in this record follow the final paper. The paper-linked monkbai/DNN-decompiler snapshot reviewed at commit 33227a0 (2026-03-13) carries HKUST's Academic Software License, which limits use to academic or nonprofit research and directs commercial users to the institution; GitHub reports no SPDX license. README prerequisites include Ubuntu 18.04, Python 3.6.9+, PyTorch 1.9+, Intel Pin 3.14 and optionally IDA Pro 7.5, which is commercial and not included; disassembly outputs are supplied instead. The authors report more than a week of single-threaded trace logging and nearly 1 TB of storage for the full evaluation, so the artifact ships filtered traces via a Docker image and Dropbox/Zenodo archives. Zenodo dataset DOI 10.5281/zenodo.7219867 (CC BY 4.0) identifies the artifact, not the paper. The README's 63-executable evaluation covers TVM and Glow only, omitting the paper's two NNFusion builds, and reports Available, Functional and Reproduced badges. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. ### Decompiling Smart Contracts with a Large Language Model > Converts Ethereum Virtual Machine bytecode into Solidity in two stages. Static analysis first lifts the bytecode into three-address code with recovered control flow; a Llama-3.2-3B model fine-tuned with LoRA on 238,446 TAC-to-Solidity function pairs then writes each function. On 9,731 held-out functions from verified Ethereum contracts, the authors report average semantic similarity of 0.82 to the original source, with 78.3% of functions above 0.8. An ablation compares the untuned base model on 663 functions, and case studies decompile an unverified Dx Protocol contract and an exploited MEV bot. - Authors: Isaac David; Liyi Zhou; Dawn Song; Arthur Gervais; Kaihua Qin - Venue: arXiv - Status: Preprint - Publication / posting date: June 24, 2025 - Date source: arXiv v1 submission date; no later version, journal reference or proceedings publication was found. - First arXiv submission: June 24, 2025 - arXiv: 2506.19624 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The 0.82 figure is the paper’s semantic-similarity score, whose computation v1 does not specify. With normalized edit distance and token-frequency comparisons, it measures resemblance to verified source, not behavioral equivalence; v1 reports no compilation, execution or differential tests of the generated Solidity. Training and test functions come from verified contracts, so closed-source deployments appear only in case studies. Comparisons with traditional decompilers are stated in general terms; no head-to-head experiment against a named decompiler such as Elipmoc is reported. The authors show a DeFi staking function whose output lost its fixed-point arithmetic and time-based reward logic (similarity 0.52), and report weaker results on very long functions and on contracts with deep inheritance or nested control flow. #### Why it fits this collection Adds fine-tuned LLM decompilation of EVM bytecode through an explicit three-address-code stage, complementing prompt-based EVM decompilation and the native-code LLM decompilers in this section. #### Publication and review notes Reviewed arXiv v1, the only version, which has no comment, journal reference or DOI. Crossref and OpenAlex searches found no peer-reviewed version. The paper says its evaluation dataset and metrics code are publicly available but gives no URL, and it does not name the bytecode-to-TAC analysis it uses; no model weights, training data or code release was found. The project link is the service named in the paper. On 2026-10-20 its landing page described an LLM-based decompiler with pricing and API pages and linked no code or model. #### Primary sources 1. 2. 3. ### SCDBench: A Benchmark for LLM-Based Smart Contract Decompilers > Benchmarks LLM-based EVM decompilation on 600 source-verified Ethereum Solidity contracts, sampled in easy, medium and hard thirds from 772,736 unique bytecode–source pairs after near-duplicate filtering. Each task supplies EVM assembly and optional four-byte selector hints and asks for self-contained Solidity with compiler settings. Outputs are scored in four cumulative stages: format completeness, compilation, ABI recovery, and semantic consistency, where 227,383 recorded test cases for 14,553 public functions are replayed on the recompiled output. With one compiler-feedback repair call, GPT-5.3-Codex compiled 90.3% of contracts, while the best semantic results were 29.4% of functions and 42 of 600 contracts recovered perfectly, both by Claude Opus 4.7. - Authors: Kaihua Qin; Dawn Song; Arthur Gervais - Venue: arXiv - Status: Preprint - Publication / posting date: May 27, 2026 - Date source: arXiv v1 submission date; no later version, journal reference or proceedings publication was found. - First arXiv submission: May 27, 2026 - arXiv: 2605.29059 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Replay compares return data, reverts, logs and touched storage on generated inputs that reach 77.8% average code coverage; passing it is not proof of equivalence, and replay needs an Ethereum archive node. The contracts are source-verified Ethereum Solidity from compiler v0.4 to v0.8, so unverified, obfuscated, Vyper or other-chain bytecode is not covered. Three models are evaluated zero-shot through OpenRouter: Claude Opus 4.7 and GPT-5.3-Codex at high reasoning effort, and GLM-5 with and without extended thinking. Results and quoted costs describe those 2026 snapshots. Gigahorse and Heimdall-rs are scored only on selector and prototype recovery because they do not emit compilable Solidity; DiSCo and the fine-tuned decompiler of David et al. are discussed but not run. #### Why it fits this collection Adds a shared benchmark with execution-based semantic checks for smart-contract decompilers, complementing EVM decompilation papers that evaluate on separate datasets and metrics. #### Publication and review notes Reviewed arXiv v1, the only version, which is labelled a preprint and has no comment, journal reference or DOI. The paper says the benchmark dataset and evaluation artifacts, including prompts, scripts and model outputs, are provided, and its broader-impact appendix describes a released dataset, but v1 gives no URL. GitHub and Hugging Face searches found no release. Compilation and replay use solc and Foundry. #### Primary sources 1. 2. ### Rico: A Mobile App Dataset for Building Data-Driven Design Applications > Rico is a dataset of Android app designs and a runtime mining system that needs no access to or modification of app source code. Crowd workers used free Google Play apps through a web interface to a device farm, recording interaction traces. An automated crawler then replayed each trace and kept exploring, using a screenshot-and-resource-id similarity heuristic to identify new UI states. The paper reports 10,811 traces and 72,219 unique UIs from 9,772 apps in 27 categories. Each UI has a screenshot, augmented view hierarchy, explored interactions, transition animations and a 64-dimensional autoencoder layout vector. - Authors: Biplab Deka; Zifeng Huang; Chad Franzen; Joshua Hibschman; Daniel Afergan; Yang Li; Jeffrey Nichols; Ranjitha Kumar - Venue: UIST 2017 - Status: Conference paper - Publication / posting date: October 20, 2017 - Date source: ACM-deposited Crossref metadata gives 20 October 2017 for both online and print publication; this precedes the October 22–25 conference dates printed in the paper and is not inferred from them. - DOI: 10.1145/3126594.3126651 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations A dataset and collection system, not a reconstruction method: the paper proposes UI code generation and interaction modeling as possible uses but does not generate code or reconstruct apps. It records UIs and interactions reached during human sessions capped at 10 minutes, each followed by one hour of automated crawling, not complete app behavior, backend logic or source code. Multimedia, productivity and personalization categories were excluded, and only free apps were mined. Coverage was evaluated on 10 popular apps by counting unique UIs, a measure that depends on the similarity heuristic (6% false-positive and 3% false-negative rates on 1,044 labeled pairs). The demonstrated application is autoencoder-based layout similarity search with qualitative examples. The 2017 snapshot will age as apps change. #### Why it fits this collection Adds a large runtime-mined corpus of Android screenshots, view hierarchies and interaction traces that the paper proposes for UI code generation and interaction modeling, complementing the collection's screenshot-to-code app reconstruction papers. #### Publication and review notes Crossref, the paper PDF and the project's BibTeX agree on the eight-author order, UIST ’17 proceedings and DOI; Crossref supplies pages 845–854. The author-hosted PDF is the 10-page ACM-formatted paper; no arXiv version was found. The paper's link interactionmining.org/rico now redirects to the archive page, while the older rico.html path returns 404. The archive page differs from the paper: its abstract and dataset description cite more than 9.3k apps and 66k unique UIs, so the released v0.1 files should not be assumed to match the paper's 9,772 apps and 72,219 UIs. Separate downloads include screenshots with view hierarchies (6 GB), traces (6 GB), animations (214 GB), metadata, layout vectors and later semantic annotations. The linked copyright notice says screenshots may contain copyrighted work and makes downloaders accept University of Illinois terms. These disclaim warranties, require the researcher to indemnify the Rico team and university, permit sharing with associates who accept the same terms, and bind a commercial employer. No separate code release is linked. #### Primary sources 1. 2. 3. 4. 5. 6. ### Binary Code Summarization: Benchmarking ChatGPT/GPT-4 and Other Large Language Models > BinSum benchmarks LLMs on summarizing binary functions in natural language. The authors compile 44 GNU projects with GCC 7.5 for x86, x64, ARM and MIPS at -O0 to -O3, match 557,664 binary functions to developer comments as reference summaries, and present each function as raw bytes, assembly, IDA microcode or decompiled code with and without symbols. GPT-4, ChatGPT, Llama 2 and Code Llama receive prompts selected from 320 GPT-4-generated candidates, with the fine-tuned BinT5 as a baseline; outputs are scored by embedding similarity alongside BLEU, METEOR and ROUGE-L. Decompiled code is the most useful representation, and stripping symbols lowers the average similarity score from 0.449 to 0.202. - Authors: Xin Jin; Jonathan Larson; Weiwei Yang; Zhiqiang Lin - Venue: arXiv - Status: Preprint - Publication / posting date: December 15, 2023 - Date source: arXiv v1 submission date; no later version, journal reference or proceedings publication was found. - First arXiv submission: December 15, 2023 - arXiv: 2312.09601 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-02 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Reference summaries are developer comments extracted from source, which the authors note may be inconsistent with the code. Embedding similarity with all-mpnet-base-v2 and n-gram metrics measure closeness to those comments, not whether a summary is correct or useful to an analyst, and no human evaluation is reported. All binaries are open-source GNU programs built with one GCC version, and the authors note that firmware, malware and obfuscated code are not covered. Prompts were chosen on 1,000 randomly sampled functions. The results describe the June 2023 gpt-4-0613 and gpt-3.5-turbo-16k-0613 snapshots and the 7B and 13B Llama 2 and Code Llama models, so they do not rank current models. #### Why it fits this collection Adds a dedicated large-scale benchmark for natural-language summaries of binary functions, a task that appears elsewhere in the bibliography only as one part of broader binary-analysis benchmarks. #### Publication and review notes Reviewed arXiv v1, the only version, which has no comment, journal reference or DOI; a Crossref search found no peer-reviewed version. The paper says its code and dataset are released at github.com/xinjin95/BinSum, but at the reviewed commit, last pushed on 2023-12-18, that repository holds only a README whose Dataset section reads “Coming soon”. It has no license file, and its arXiv badge shows the wrong identifier 2312.02120 while linking to 2312.09601. The authors report 4,058,297,977 inference tokens, US$11,418 in model execution costs and 873 A100 GPU hours. #### Primary sources 1. 2. 3. 4. ### How Far Have We Gone in Binary Code Understanding Using Large Language Models > Benchmarks 16 code and general LLMs on function name recovery and summarization of stripped binaries. The benchmark takes 12 popular C projects built for x86-64, strips and decompiles 28 binaries with IDA Pro, aligns 81,185 functions with source through DWARF, and keeps 2,000 functions after expert review. Zero-shot LLMs are compared with SymLM, NER, BinT5 and HexT5. Code Llama 34B leads name recovery with token-level F1 of 27.59, and ChatGPT leads summarization with BLEU-4 7.37. The study also measures few-shot prompting, LoRA fine-tuning of two 7B models on GNU binaries, and a case study on a stripped open-source Linux remote-access trojan. - Authors: Xiuwei Shang; Shaoyin Cheng; Guoqiang Chen; Yanming Zhang; Li Hu; Xiao Yu; Gangyang Li; Weiming Zhang; Nenghai Yu - Venue: ICSME 2024 - Status: Conference paper - Publication / posting date: October 6, 2024 - Date source: IEEE’s Crossref deposit gives published/print and issued date 2024-10-06, which is also the first day of the conference listed there (6–11 October). This entry uses the publisher-deposited date and does not derive it from the conference schedule or the arXiv history. - First arXiv submission: April 15, 2024 - arXiv: 2404.09836 - Reviewed arXiv version: v3 - DOI: 10.1109/ICSME58944.2024.00012 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The benchmark covers x86-64 builds with each project’s default compiler and optimization settings and IDA Pro pseudocode only, so the results do not establish behavior on other architectures, optimization levels, decompilers or obfuscated code, which the authors exclude. Reference summaries were generated by ChatGPT from source and screened by three experts, and ChatGPT is also an evaluated model. BLEU-4, METEOR and Rouge-L measure overlap with those references, which the authors say may not fit binary summarization. Name recovery uses token-level precision, recall and F1 rather than exact matches. Fine-tuning used 30,000 functions from O0 x86-64 GNU builds. Results describe model versions released between mid-2023 and early 2024, including gpt-3.5-turbo-16k. #### Why it fits this collection Adds a benchmark of LLMs on two core reverse-engineering subtasks, recovering function names and summarizing decompiled functions, with comparisons against earlier learned symbol-recovery models. #### Publication and review notes Crossref establishes the nine-author order, DOI, ICSME 2024 proceedings title and pages 1–12. Reviewed arXiv v3 (2024-10-24), whose comment reads “to be published in ICSME 2024”; v1 and v2 date from 15 and 16 April 2024. The IEEE Xplore page refused automated requests. The paper gives no download link for the benchmark, fine-tuning data or prompts, and no release was found. The evaluated pseudocode depends on IDA Pro, a commercial decompiler. #### Primary sources 1. 2. 3. 4. ### Cross-Inlining Binary Function Similarity Detection > Studies binary function similarity when function inlining makes one binary function correspond to several source functions. From BinKit builds of 51 GNU projects with and without -fno-inline (9 GCC and Clang versions, O0–O3, six x86, ARM and MIPS targets; 216 combinations each), debug-line mappings label 5,621,140 cross-inlining pairs. The authors identify Leaf-, Root- and Internal-Inlining patterns, show that Gemini, SAFE and GMN lose accuracy on them, and propose CI-Detector, which trains one attributed-CFG graph neural network per pattern and aggregates their scores, reporting 81% precision and 97% recall. - Authors: Ang Jia; Ming Fan; Xi Xu; Wuxia Jin; Haijun Wang; Ting Liu - Venue: ICSE 2024 - Status: Conference paper - Publication / posting date: April 12, 2024 - Date source: ACM’s Crossref deposit records published/print and online publication on 2024-04-12. The date comes from that publisher deposit, not from the April 14–20 conference dates. - First arXiv submission: January 11, 2024 - arXiv: 2401.05739 - Reviewed arXiv version: v1 - DOI: 10.1145/3597503.3639080 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The three patterns are derived from the authors’ own matrix of 51 GNU projects, and the authors note that other compilation settings, such as non-default optimizations, or projects with different inlining conventions may not fit the learned models. Labels depend on IDA Pro and DWARF debug tools, which the authors list as threats to construct validity, and ACFGs come from IDA Pro 7.3, so disassembly errors can affect results. Precision and recall come from balanced sets of 40,000 positive and 40,000 negative test pairs with a threshold tuned for F1, not from large-pool search. Baselines are released Gemini, SAFE and GMN models plus Bingo-style inlining strategies with Asm2Vec. Obfuscated binaries and LLM-based similarity models are not evaluated. #### Why it fits this collection Adds inlining-aware function matching, complementing similarity studies that disable inlining and single-model records such as jTrans. #### Publication and review notes Crossref and the arXiv v1 PDF, the only version and marked as the ICSE 2024 camera-ready, agree on the six-author order; Crossref gives pages 1–13. The paper’s reference 16 prints the repository URL with a line break. At reviewed commit ff606dd (2026-04-20), the repository declares AGPL-3.0 in a LICENSE file added that day, about two years after publication, and earlier snapshots carried no license file. The README links two Google Drive archives built with BinKit and says the workflow reuses code from Cisco-Talos/binary_function_similarity; it requires IDA Pro, Docker and nvidia-docker. Its training step builds a NeuralNetwork/ Docker context that is absent from the reviewed tree, and no trained CI-Detector checkpoints are included. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### How Machine Learning Is Solving the Binary Function Similarity Problem > Measures binary function similarity research by re-implementing ten representative approaches from the security, programming-language and machine-learning communities in one IDA Pro-based framework, from fuzzy hashing (Catalog1, FunctionSimSearch) to graph neural network, NLP-encoder and transformer models. Two new datasets support six tasks that vary optimization, compiler, bitness and architecture, scored by AUC and ranking metrics, plus a firmware vulnerability-search case. The authors report that fuzzy hashing fails in harder cross-architecture settings, GNN-based models perform best in almost all tasks, and many recent models score similarly on common data. - Authors: Andrea Marcelli; Mariano Graziano; Xabier Ugarte-Pedrero; Yanick Fratantonio; Mohamad Mansouri; Davide Balzarotti - Venue: USENIX Security 2022 - Status: Conference paper - Publication / posting date: August 2022 - Date source: Publication month from the official USENIX BibTeX (month = aug) and the final PDF cover for the 31st USENIX Security Symposium, August 10–12, 2022; no exact publication day is asserted. - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations A 2022 comparison of the authors’ re-implementations, not of the original papers’ code or reported numbers, which the authors did not try to reproduce; CodeCMR was run by its own authors, and Trex was tested only on Dataset-2 with its authors’ model. Dynamic-analysis, symbolic-execution and other slow direct-comparison approaches were excluded by design, and LLM-based similarity models are not covered. Dataset-1 compiles seven open-source projects (ClamAV, Curl, Nmap, OpenSSL, Unrar, Z3, Zlib) with GCC and Clang for x86-64, ARM and MIPS in 32 and 64 bit at O0–O3 and Os with function inlining disabled, and drops functions under five basic blocks. Dataset-2 reuses ten GCC 7.5 projects released by the Trex authors. Feature extraction depends on IDA Pro 7.3; BinaryAI covered only part of the data because a recent Hex-Rays MIPS decompiler license was unavailable. The firmware case searches ten OpenSSL functions in two images. Obfuscated code is not evaluated, and the results are not a current ranking. #### Why it fits this collection Adds a common-framework measurement of binary function matching, which reverse engineers use to transfer labels from known functions to stripped code, complementing single-model records such as jTrans and BinaryAI. #### Publication and review notes No paper DOI or arXiv identifier was verified; the record uses the reviewed USENIX Security presentation-page and sec22-marcelli.pdf profile. The USENIX BibTeX gives the 31st USENIX Security Symposium, pages 2099–2116, USENIX Association and month August; the presentation page also links a prepublication PDF and slides. The repository README lists errata for a Section 3.2 statement on BinDiff and Diaphora cross-architecture support and for the Figure 2 captions. At reviewed commit f0da093 (2024-05-15), repository code is MIT-licensed, but the README lists GPL-3.0 (Catalog1, SAFE, IDA CodeCMR plugin), LGPL-2.1 (Gensim-based Asm2vec), Apache-2.0 (FunctionSimSearch, GGSNN/GMN) and CC BY-NC-SA 4.0 (GNN-s2v) components; compiled binaries keep their own licenses. Binaries (about 15 GB) and extracted features (about 38 GB) download from Google Drive, and generating new IDBs or features requires IDA Pro. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### PoE-World: Compositional World Modeling with Products of Programmatic Experts > PoE-World represents an Atari world model as an exponentially weighted product of many small Python programs, or programmatic experts, each synthesized by an LLM to explain one aspect of the observed dynamics; learned weights and optional synthesized hard constraints combine them. From object lists that OCAtari parses out of a demonstration of fewer than 1,000 frames, the authors learn stochastic, partially observed models of Pong and Montezuma's Revenge and use them in a planning agent, including on rearranged Pong-Alt and Montezuma's Revenge-Alt variants that have no demonstrations. - Authors: Wasu Top Piriyakulkij; Yichao Liang; Hao Tang; Adrian Weller; Marta Kryven; Kevin Ellis - Venue: NeurIPS 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: The publisher-deposited Crossref record for the NeurIPS 2025 proceedings gives 2025; no publication month or day is asserted. Neither the proceedings page's 2026-04-23 citation date nor the November–December 2025 conference dates are used as a publication date. - First arXiv submission: May 16, 2025 - arXiv: 2505.10819 - Reviewed arXiv version: v4 - DOI: 10.52202/085713-0896 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations Models consume symbolic object lists, not pixels, and OCAtari had to be patched manually for each game, so evaluation covers only Pong and Montezuma's Revenge plus two author-built variants. The learned programs approximate observed dynamics and are not the games' original code: next-observation prediction accuracy on 1,000 random test frames is 0.06 for Pong and 0.31 for Montezuma's Revenge, and object-attribute accuracy is 0.66 and 0.76. Synthesized experts build on manually written helper classes and contact functions and were generated with gpt-4o-2024-08-06. Exploration and reward learning are outside the method; agent scores use 5 seeds and at most 3k training steps after the demonstration, and the planner reached the key in 5 of 9 Montezuma's Revenge tries. #### Why it fits this collection Adds compositional program synthesis of executable game-dynamics models for non-grid Atari games, extending the code-world-model line beyond grid, text and puzzle environments. #### Publication and review notes Title, author order and DOI agree across the NeurIPS proceedings page, the Crossref deposit, the final PDF and arXiv. The proceedings metadata and Crossref give the first author as Top Piriyakulkij; this record uses Wasu Top Piriyakulkij as printed in the final PDF, on arXiv and in the repository README. The proceedings page lists pages 26609–26638 while Crossref lists 30165–30194, so no page range is recorded. arXiv v4 (2025-11-19) was reviewed. The README headline calls the paper a NeurIPS 2025 Spotlight, which the proceedings page does not state, and its arXiv badge text reads 2401.02739 while linking to 2505.10819. The MIT-licensed repository snapshot at b499fb1 (2026-02-05) targets Python 3.10, pins most dependencies, and uses MIT-licensed submodules for OpenAI API access and a patched OCAtari fork; runs need a user-supplied OpenAI API key, and the Atari environments come through Gymnasium and the Arcade Learning Environment under their own terms. The snapshot includes seed-0 learned world models for Pong and Montezuma's Revenge and a Pitfall run script that the paper does not evaluate. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ### Guided GUI Testing of Android Apps with Minimal Restart and Approximate Learning > SwiftHand generates test inputs for Android apps while learning an approximate GUI model during testing. It instruments Dalvik bytecode to read the GUI component tree and derive each screen's enabled touch, scroll, text, Back and Menu inputs; screens with the same enabled inputs are treated as equivalent states of an extended deterministic labeled transition system. The learned model steers execution toward unexplored frontier states and avoids restarts, since reinstalling an app took about 30 seconds. On 10 F-Droid apps, the authors report higher branch coverage than random and L*-based testing within the time budget, reached faster. - Authors: Wontae Choi; George Necula; Koushik Sen - Venue: OOPSLA 2013 - Status: Conference paper - Publication / posting date: October 29, 2013 - Date source: ACM-deposited Crossref metadata for the proceedings DOI gives 29 October 2013 for both online and print publication. The SIGPLAN Notices copy lists a separate print date of 12 November 2013; neither date is inferred from the SPLASH conference schedule. - DOI: 10.1145/2509136.2509552 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations A test-generation technique whose learned model is an approximate abstraction for guiding exploration, not a complete or exact GUI specification or a reimplementation of the app. States are identified only by their sets of enabled inputs and merged heuristically; tab views and similar designs caused state explosion and low coverage. The implementation rejects apps with a native main entry, works correctly only on Android 4.1 or later, and cannot handle apps that store data on remote servers, so such apps were excluded from the benchmark. Evaluation covers 10 F-Droid apps under Android 4.1.2: eight ran on emulators with a 3-hour budget and two on a Galaxy Nexus phone with 1 hour. Random testing caught up on some small apps given more time. The 2013 tool is not shown to run on current Android releases. #### Why it fits this collection Adds execution-driven inference of an Android app's GUI state model, complementing the collection's screenshot- and design-based app reconstruction papers with behavioral model recovery. #### Publication and review notes Crossref establishes the three-author order, the OOPSLA 2013 proceedings within SPLASH ’13 and pages 623–640; it deposits the title in sentence case, while this entry keeps the capitalization printed in the paper. The same article also appears in ACM SIGPLAN Notices volume 48, issue 10, pages 623–640, under DOI 10.1145/2544173.2509552; this entry uses the proceedings DOI. The author-hosted PDF is a 17-page copy created on 2013-08-11 with the proceedings DOI. The paper names github.com/wtchoi/SwiftHand. The reviewed master snapshot b2b45acd is dated 2015-01-13, with no later pushes, and README describes it as a working demo of the version submitted to OOPSLA ’13. LICENSE.txt is a three-clause BSD-style text with a 2013 copyright of The Regents of the University of California; GitHub reports no recognized SPDX license. README requires JDK 6 or 7, Maven 3, Android SDK tools including chimpchat, Scala 2.9.1 and ASMDEX revision 1665 or older. To reproduce the paper, it recommends a Nexus S emulator at API level 16, with internet access disabled through a DNS setting. dist/ contains a prebuilt jar plus instrumented APKs of the ten benchmark apps and two unmodified APKs; those third-party apps keep their own terms. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### WAFFLE: Fine-tuning Multi-Modal Model for Automated Front-End Development > WAFFLE fine-tunes multimodal LLMs to generate HTML/CSS from UI screenshots. A quarter of the decoder's attention heads use a structure-aware mask that limits each element's tokens to its parent, preceding siblings and its own earlier tokens. A contrastive objective aligns image and code embeddings over groups of four mutated WebSight-v0.1 pages. With VLM-WebSight and Moondream2 backbones, the authors report up to 9.00 pp higher HTML-Match and 0.0982 higher CW-SSIM than standard fine-tuning on WebSight-Test, plus gains on every Design2Code metric. - Authors: Shanchao Liang; Nan Jiang; Shangshu Qian; Lin Tan - Venue: ACL 2025 - Status: Conference paper - Publication / posting date: July 2025 - Date source: The official ACL Anthology record gives July 2025. Crossref records only the year; the July 27–August 1 conference dates printed in the PDF are not treated as a publication day. - First arXiv submission: October 24, 2024 - arXiv: 2410.18362 - Reviewed arXiv version: v3 - DOI: 10.18653/v1/2025.acl-long.1208 - Sources reviewed: 2026-10-20 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Generates static HTML/CSS from a single screenshot; it does not recover a site's original source, scripts, interactions, navigation or backend. HTML-Match strips styles and attributes before requiring pixel-identical renders, while CW-SSIM, CLIP and LLEM are similarity scores; the authors note that these metrics do not fully capture human judgment. Training data and the 500-page WebSight-Test are synthetic WebSight-style pages; Design2Code supplies 484 real-world pages. Only two backbones were fine-tuned, and on Design2Code the Moondream2 model trained with WAFFLE stays below GPT-4o and GPT-4o mini. The Gemini 1.5 Pro baseline answered 384 Design2Code instances. Human ranking used 50 samples per dataset and two annotators. Commercial-model prompting results are historical baselines, not current rankings. #### Why it fits this collection Adds a training method for screenshot-to-HTML website reconstruction that builds DOM hierarchy into attention, complementing the collection's screenshot-to-code benchmarks, datasets and prompting pipelines. #### Publication and review notes Publication identity follows the ACL Anthology record and PDF. Reviewed arXiv v3 of 2026-03-02 (v1 2024-10-24, v2 2025-06-24) is titled “WAFFLE: Finetuning Multi-Modal Models for Automated Front-End Development”; the repository README and model card use “WAFFLE: Multi-Modal Model for Automated Front-End Development” and cite the arXiv preprint. The paper's availability statement links lt-asset/Waffle. The reviewed 2025-05-28 snapshot is BSD-3-Clause and provides VLM-WebSight inference, Selenium/Chrome rendering, the HTML tree-attention utilities, a contrastive dataset class reading a local load_from_disk dataset, and 500 WebSight-Test PNG screenshots without reference HTML. Although README describes a training file, the snapshot has no training script, Moondream2 code, metric implementation or mutated training set; no public copy of the 231,940-pair set was found in the lt-asset Hugging Face organization. Weights are on Hugging Face as lt-asset/Waffle_VLM_WebSight (7B). The GitHub README releases them under Apache-2.0 subject to the base model's terms, while the model card declares bsd-3-clause-clear. Documented dependencies include Python 3.10.14, PyTorch 2.3.0, Transformers 4.41.1, PEFT 0.11.1 and DeepSpeed 0.14.1; the inference script expects a CUDA GPU and has placeholder paths. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ### Diffusion Models Are Real-Time Game Engines > GameNGen learns to simulate DOOM interactively with a diffusion model instead of game code. A PPO agent first plays the game in ViZDoom, and its recorded trajectories, from random to trained play, become the training data. Stable Diffusion v1.4 is then fine-tuned to predict the next frame from the last 64 frames and actions, with noise added to context frames to keep long autoregressive rollouts stable and a fine-tuned latent decoder for detail. With 4 sampling steps it runs at 20 frames per second on one TPU-v5. The authors report next-frame PSNR of 29.43 and human raters picking the real game in 58–60% of short clips. - Authors: Dani Valevski; Yaniv Leviathan; Moab Arar; Shlomi Fruchter - Venue: ICLR 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: Publication year stated by the official ICLR proceedings; no finer publication date is asserted. The proceedings page's citation date of 2025-05-01 is not adopted, and the arXiv dates are not substituted. - First arXiv submission: August 27, 2024 - arXiv: 2408.14837 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations A neural approximation trained on recorded gameplay of an existing game; it recovers no game logic, source code, assets or state representation and is not an exact simulation. The model sees just over 3 seconds of history, so state outside that window survives only through on-screen cues and learned heuristics, which can be wrong; for example, repeated shooting may spawn enemies. Locations and interactions the agent never explored are simulated poorly. Training used 128 TPU-v5e devices and 70M agent frames at 320×240, plus an environment-specific reward function. PSNR is a teacher-forced single-frame measure on 2,048 held-out trajectories from 5 levels; autoregressive rollouts diverge from ground truth after a few steps. Human evaluation used 10 raters on 1.6- and 3.2-second clips and 150 later 3-second clips; the authors say they could often spot the simulation within seconds. Only DOOM was tested, and the model cannot readily create new games. #### Why it fits this collection Adds learned, non-symbolic reconstruction of a game's interactive behavior from gameplay, contrasting with the collection's code-based world models and visual game replication research. #### Publication and review notes Authors and title follow the ICLR 2025 proceedings page and PDF, which list pages 73754–73776 and print “Published as a conference paper at ICLR 2025”; no DOI is listed. arXiv has two versions with the same title and authors: v1 of 2024-08-27 and v2 of 2025-04-24, whose comment reads “ICLR 2025”. The OpenReview forum P8pqeEkn1H could not be retrieved automatically because of a challenge page. The project page links the paper and videos but no code or weights, and no author-provided code release was found. The paper's reproducibility statement relies on open Stable Diffusion v1.4 weights, the open-source ViZDoom environment and documented training settings. Its reported 50 frames per second uses a distilled single-step model with some quality loss. #### Primary sources 1. 2. 3. 4. ### Pop Quiz! Can a Large Language Model Help With Reverse Engineering? > Tests whether OpenAI’s Codex model code-davinci-001 can answer reverse-engineering questions about C code in a zero-shot question-and-answer prompt. Programs come from templates the authors wrote, covering cybersecurity snippets and industrial-control algorithms such as PID controllers and filters, plus five single-file Linux malware samples from vx-underground. Each is presented as original or name-randomized source, or as Ghidra decompilation of gcc -O1 builds with debug information, without it, or stripped. After exploratory open-ended questions, generated true/false and short-answer questions about purpose, capabilities and key variables are graded against an answer oracle; Codex answered 72,754 of 136,260 questions correctly. - Authors: Hammond Pearce; Benjamin Tan; Prashanth Krishnamurthy; Farshad Khorrami; Ramesh Karri; Brendan Dolan-Gavitt - Venue: arXiv - Status: Preprint - Publication / posting date: February 2, 2022 - Date source: arXiv v1 submission date; no later version, journal reference or proceedings publication was found. - First arXiv submission: February 2, 2022 - arXiv: 2202.01142 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations All results come from one model, code-davinci-001, which OpenAI shut down on 2023-03-23, so they cannot be rerun against the original model and do not describe current LLMs. Accuracy is measured with a generated true/false and short-answer quiz, paired as positive and negated questions to expose answer bias, rather than with analyst tasks; the overall 53.4% led the authors to conclude that LLMs are not yet ready for zero-shot reverse engineering. Programs are small single-file C code that fits the model’s roughly 4,000-token window, compiled only at -O1; the real-malware class has five samples. The answer oracle combines the authors’ labels with capability matches from the capa tool. #### Why it fits this collection Records the earliest LLM-for-reverse-engineering evaluation in the bibliography, a baseline for the later LLM binary-analysis studies in this section. #### Publication and review notes Reviewed arXiv v1, the only version; its comment reads “18 pages, 19 figures” and links Zenodo record 10.5281/zenodo.5949075, a dataset DOI that is not used as the paper identifier. No peer-reviewed version was found in Crossref. That record (CC BY 4.0, a 692 MB codex-reverse.zip by the same six creators) holds the test framework scripts, recorded Codex responses and generated program instances. The README requires Ghidra and an OpenAI API key, and the build log lists compiled instances under experiments/malware, so the archive appears to include the malware samples. #### Primary sources 1. 2. 3. 4. 5. ### D-Helix: A Generic Decompiler Testing Framework Using Symbolic Differentiation > Tests decompilers function by function on binaries without needing source code. RECOMPILER repairs decompiled C so individual functions recompile, SYMDIFF compares symbolic models of the original binary function and the recompiled decompiled function using patched angr and PROMPT symbolic executors, and TUNER toggles decompiler heuristic rules to locate, and sometimes work around, the rule behind an inaccuracy. On Ghidra 10.0 and angr 9.2.30, 2,004 binaries and object files from coreutils, util-linux and six popular GitHub C projects yield 93K decompiled functions; the authors report 4,515 incorrectly decompiled functions, 8 reproduced known bugs, 17 previously unknown bugs and 7 bugs fixed automatically. - Authors: Muqi Zou; Arslan Khan; Ruoyu Wu; Han Gao; Antonio Bianchi; Dave (Jing) Tian - Venue: USENIX Security 2024 - Status: Conference paper - Publication / posting date: August 2024 - Date source: Publication month from the official USENIX BibTeX (month = aug) and the final PDF cover for the 33rd USENIX Security Symposium, August 14–16, 2024; no exact publication day is asserted. - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Only Ghidra and angr were tested; Hex-Rays, Binary Ninja, RetDec and LLM-based decompilers were not, and the authors estimate that supporting a decompiler with an unsupported IR would take at least 40 days of symbolic-engine work. Results are function-level symbolic equivalence checks on the authors’ 2,004 x86-64 Linux inputs, built with GCC 11.1.0 and Clang 16.0.0 at each project’s default optimization and excluding binaries over 30 MiB. Coverage is partial: RECOMPILER recompiled 72.4% of Ghidra’s and 45.0% of angr’s decompiled functions, and SYMDIFF analyzed 91.3% and 93.9% of those. Symbolic execution bounds loops, uses a two-minute default timeout, treats global variables as constants and does not parse floating-point constraints; accuracy trade-offs cause false positives, measured on 100-function samples per decompiler. TUNER automatically fixed 72 of the 443 inaccuracies it examined. A function passing the check is not proof of whole-program correctness. #### Why it fits this collection Adds automated, binary-level correctness testing for decompilers, complementing output benchmarks such as DecompileBench and qualitative studies of decompiler fidelity. #### Publication and review notes No paper DOI or arXiv identifier was verified; the record uses the reviewed USENIX Security 2024 presentation-page and usenixsecurity24-zou.pdf profile. The USENIX BibTeX gives the 33rd USENIX Security Symposium, pages 397–414, USENIX Association and month August; the presentation page also links an appendix PDF, slides and a prepublication PDF. The paper prints github.com/purseclab/Dhelix, which the GitHub API reports as not found; the code link uses purseclab/D-helix, whose README cites this paper. At reviewed commit fda23ef (2024-09-12), the repository declares BSD-3-Clause. Its README pins angr, claripy and pyvex commits for P-code and VEX variants, supplies patches for angr, claripy, PROMPT (built with clang 3.8) and Ghidra commit 15d22e8, and uses Z3 4.9.1. A dataset directory holds 2,004 compiled input files, which remain subject to their upstream projects’ licenses. #### Primary sources 1. 2. 3. 4. 5. ### Assemblage: Automatic Binary Dataset Construction for Machine Learning > Assemblage is a distributed system that crawls GitHub and vcpkg, builds C/C++ projects under many compiler configurations, and records source-to-binary mappings such as function addresses, source code, comments and PDB or DWARF debug information. Run on AWS for about a year, it produced 890k Windows PE binaries built with Visual Studio 2015–2022 across optimization levels, architectures and Debug/Release modes, plus 428k Linux ELF binaries from GCC and Clang, in 29 configurations. Case studies use the data for compiler provenance with PassTell, function similarity with a graph neural network and jTrans, and function-boundary identification comparing XDA with IDA. - Authors: Chang Liu; Rebecca Saul; Yihao Sun; Edward Raff; Maya Fuchs; Townsend Southard Pantano; James Holt; Kristopher Micinski - Venue: NeurIPS 2024 Datasets and Benchmarks - Status: Conference paper - Publication / posting date: 2024 (exact date not verified) - Date source: The official NeurIPS proceedings and publisher-deposited Crossref metadata identify publication year 2024; Crossref provides no finer publication date. The first arXiv submission date is recorded separately. - First arXiv submission: May 7, 2024 - arXiv: 2405.03991 - Reviewed arXiv version: v2 - DOI: 10.52202/079017-1871 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The binaries are builds of open-source GitHub and vcpkg projects, many of them small student projects or utilities, so they do not represent commercial, packed or obfuscated software. Assemblage does not independently scan for malware; the authors rely on GitHub’s policy against malware and plan scanning for a later version. The reported build success rate was about 30% on Windows and 7% on Linux. Public datasets include only repositories with permissive licenses, so the downloadable copy is a subset of the paper’s corpus, and repository links in the metadata tie binaries to authors’ GitHub profiles. The case studies retrain existing models under their original protocols with minimal changes; they show Windows/Linux generalization gaps, such as jTrans MRR of 0.52 on Windows against 0.83 on Linux, rather than new analysis methods. #### Why it fits this collection Adds a dataset paper for Windows PE binaries with source and debug mappings, complementing the Linux ELF function corpora used by decompilation research in this section. #### Publication and review notes Crossref and the NeurIPS proceedings page give the eight-author order, volume 37 and pages 58698–58715; Crossref records only the year. The proceedings page’s 2024-12-16 citation date also appears on another NeurIPS 2024 paper page, so year precision is kept. Reviewed arXiv v2 (2024-11-02), which carries the NeurIPS comment; v1 dates from 2024-05-07. At the reviewed f8ac584 commit (2026-08-08), the repository README says the code is MIT-licensed and the published dataset is a permissively licensed subset; pyproject.toml declares MIT, but there is no LICENSE file and GitHub detects none. The README also says the codebase was refactored in July 2026 and extended with a Rust worker, that Windows/MSVC builds sit under backend/assemblage/legacy/ and need a Windows host, and that a pre-refactor branch keeps the earlier code. The Hugging Face cards for changliu8541/Assemblage_PE, whose public copy has 91k Windows PE binaries, and Assemblage_LinuxELF declare license “other” and ask users to follow each source repository’s license. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. ### Mechanics Automatically Recognized via Interactive Observation: Jumping > Infers platform-game jump mechanics by running controlled experiments in a modified FCEUX NES emulator. A person first plays each game to a safe state; the system then repeatedly holds the jump button for 1 to 120 frames, waits 120 frames and resets, recording every sprite from the PPU sprite table. Sprites that usually touch one another are merged into characters and tracked. A hand-designed four-state jump automaton (ground, rising with and without the button, falling) is then fitted with linear support vector regression, giving per-state velocity and gravity parameters plus minimum and maximum button-hold durations. Across 48 games (about 30% of NES platformers) and 52 characters, the authors cluster the learned jumps into three styles. - Authors: Adam Summerville; Joseph C. Osborn; Christoffer Holmgård; Daniel W. Zhang - Venue: FDG 2017 - Status: Conference paper - Publication / posting date: August 14, 2017 - Date source: ACM-deposited Crossref metadata gives 14 August 2017 for both online and print publication, which is also the first day of FDG 2017; the date comes from the deposit, not from the conference schedule. - First arXiv submission: July 12, 2017 - arXiv: 1707.03865 - Reviewed arXiv version: v1 - DOI: 10.1145/3102071.3102104 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Models only vertical jumps from a standing position; horizontal movement, running jumps, double jumps and interactions with enemies or terrain are ignored, and no game code, assets or complete mechanics are recovered. The fixed automaton is assumed rather than learned, so non-physical jumps such as Castlevania's fit with systematic errors. Stair-step arcs, delayed jump starts, unusual landings and animation jitter are acknowledged problems. Each game needs human play to reach a safe state, prior knowledge that it has jumping, and a known jump button. The 48 games are not an exhaustive sample, and results are descriptive comparisons and clusters rather than tests against developer-specified parameters. #### Why it fits this collection Adds emulator-instrumented, black-box recovery of a game mechanic's parameters from controlled play, complementing the collection's code- and visuals-based game reconstruction research. #### Publication and review notes Crossref establishes the four-author order, FDG ’17 proceedings and page range 1–10; it deposits the title in sentence case with subtitle “jumping”, while this entry keeps the paper's printed capitalization. Crossref lists the second author as Joe Osborn; the paper and arXiv print Joseph C. Osborn, the form used here. arXiv has only v1 of 2017-07-12, with comment “10 pages, 12 figures. Accepted at Foundations of Digital Games 2017” and the same DOI. Its PDF is the 10-page ACM-formatted paper with the FDG ’17 reference block. Neither the paper nor arXiv links code, the modified emulator or the experiment data, and no author release was found. #### Primary sources 1. 2. 3. 4. ### Sketch2Code: Evaluating Vision-Language Models for Interactive Web Design Prototyping > Sketch2Code benchmarks vision-language models on turning rough hand-drawn wireframe sketches into HTML webpage prototypes. Crowd annotators drew 731 sketches of 484 real-world webpages from the Design2Code test set. Ten models, eight commercial and two 8B open-source, generate pages directly and in two multi-turn settings with a GPT-4o simulated user: following its feedback, or asking it clarification questions. Outputs are scored by Design2Code visual similarity and a new IoU-based layout similarity over component types such as text blocks, images, navigation bars, forms and buttons. Claude 3.5 Sonnet and GPT-4o lead single-turn layout similarity, and feedback rounds help commercial models more than question asking does. - Authors: Ryan Li; Yanzhe Zhang; Diyi Yang - Venue: NAACL 2025 - Status: Conference paper - Publication / posting date: April 2025 - Date source: The ACL Anthology record gives the proceedings month as April 2025; Crossref records only the year. The conference ran from 29 April to 4 May 2025, and no publication day is inferred. - First arXiv submission: October 21, 2024 - arXiv: 2410.16232 - Reviewed arXiv version: v1 - DOI: 10.18653/v1/2025.naacl-long.198 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - Project: - BibTeX: - Catalog page: #### Scope and limitations The generated pages are prototypes scored by visual and layout similarity to reference screenshots, not recovered source code; behavior, interactivity and code equivalence are not evaluated, and page images are replaced with a placeholder. Sketches deliberately omit most text and styling, so similarity scores are low in absolute terms, with best single-turn layout similarity around 22%. The simulated user is GPT-4o, judged faithful in 83.3% of feedback and accurate in 86.7% of answers by human annotators. Only 8B open-source models were run, and a multi-turn example needs 40,000 to 160,000 input tokens. The user study interviewed eight UI/UX experts. Results describe 2024 model versions. #### Why it fits this collection Adds sketch-based and multi-turn interactive webpage generation, complementing the screenshot- and design-based website reconstruction benchmarks in this section. #### Publication and review notes The ACL Anthology page, final PDF and Crossref establish the three-author order, DOI, NAACL 2025 Volume 1 proceedings and pages 3921–3955. Reviewed arXiv v1 (2024-10-21), the only version, commented “preprint, 9 pages”; the description follows the 35-page proceedings PDF. The paper links its code and data through the project page. At the reviewed 21dfd1d commit, SALT-NLP/Sketch2Code is MIT-licensed, pins Python packages including torch 2.4.0, transformers 4.44.1 and playwright 1.43.0, and requires OpenAI, Anthropic or Gemini API keys for the commercial models. The Hugging Face dataset card declares ODC-By, and the paper says the source webpages were collected by Design2Code under ODC-By. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### Decomperson: How Humans Decompile and What We Can Learn From It > Reframes manual reverse engineering as perfect decompilation: writing source that, compiled with the original toolchain and options, reproduces the target functions’ binary code exactly. The authors built Decomperson, a web editor that compiles, disassembles, tests and diffs each submission, and used it in Decompetition, a 24-hour Jeopardy-style competition in November 2020 with 23 unstripped challenge binaries written in C, C++, Go, Rust and Swift. Over 150 participants made more than 35,000 submissions, including over 300 perfect ones; all but one challenge was perfectly decompiled, and the recorded edit histories are analyzed to describe how humans decompile. - Authors: Kevin Burk; Fabio Pagani; Christopher Kruegel; Giovanni Vigna - Venue: USENIX Security 2022 - Status: Conference paper - Publication / posting date: August 2022 - Date source: Publication month from the official USENIX BibTeX (month = aug) and the final PDF cover for the 31st USENIX Security Symposium, August 10–12, 2022; no exact publication day is asserted. - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Participants were self-selected competitors in a single 2020 event, mostly playing solo on teams of any size, and the follow-up survey drew only 12% of registrants. The challenges are 23 small competition binaries written by the organizers, not stripped and without debug information, and Decomperson assumed the original toolchain and compilation options were known. Perfect decompilation requires matching compiler output; the authors note that it is not a traditional reverse-engineering task, does not capture skills such as triaging large binaries, and can include time spent fighting compiler idiosyncrasies. The web editor took players out of their usual tools and may have influenced timings. Participants could paste automatic-decompiler output; about 20% of C function attempts resembled tool output, mostly Hex-Rays, Ghidra or Binary Ninja. The study observes humans and does not evaluate automated decompilers or agents. #### Why it fits this collection Adds a large, programmatically analyzable record of human decompilation, complementing studies that compare human reverse engineers with LLMs and agents. #### Publication and review notes No paper DOI or arXiv identifier was verified; the record uses the USENIX Security presentation-page and sec22-burk.pdf profile. The USENIX BibTeX gives the 31st USENIX Security Symposium, pages 2765–2782, USENIX Association and month August. The paper states IRB exemption under Category 3 and that no personally identifiable information was used. Its Artifacts section links the challenges-2020, server, disassembler and data repositories and a Docker Hub builder image. The code link uses the Decomperson server, reviewed at commit 0d381d4 (2026-04-13), which carries an Apache-2.0 license whose copyright line was filled in that day; the challenges and disassembler repositories first received Apache-2.0 license files the same day. The anonymized submission data, decompetition/data at 4b339e5 (2022-06-02), is a PostgreSQL dump from a 2020-12-10 snapshot with a Docker-based serve.sh, and that repository declares no license. #### Primary sources 1. 2. 3. 4. 5. ### Unleashing the Power of LLM to Infer State Machine From the Protocol Implementation > ProtocolGPT infers protocol state machines from implementation source code with a retrieval-augmented LLM. It extracts state-machine-related code with regular expressions and a code filter, splits it into syntax-aware chunks stored in a FAISS vector store with OpenAI embeddings, and prompts GPT-4 step by step to recover states and message-triggered transitions. On six protocols in five open-source code bases (IKEv2, TLS 1.3, TLS 1.2, BGP, RTSP and L2TP), the authors report transition precision above 90%, more than 30% higher precision and 55% higher recall than baselines. Seeding AFLNet with the inferred machines raised coverage by more than 20% and found two previously unknown crash bugs in an RTSP server. - Authors: Haiyang Wei; Ligeng Chen; Zhengjie Du; Yuhan Wu; Haohui Huang; Yue Liu; Guang Cheng; Fengyuan Xu; Linzhang Wang; Bing Mao - Venue: IWQoS 2025 - Status: Conference paper - Publication / posting date: 2025 (exact date not verified) - Date source: The publisher's Crossref deposit establishes publication year 2025. Its print date of 2 July 2025 is also the first day of the July 2–4 symposium recorded in the same deposit, and IEEE Xplore could not be retrieved automatically to confirm a publication day, so no finer date is asserted. - First arXiv submission: May 1, 2024 - arXiv: 2405.00393 - Reviewed arXiv version: v4 - DOI: 10.1109/IWQoS65803.2025.11143461 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Requires source code; it does not work from binaries or traffic alone. Each implementation was chosen for explicitly defined states, and results cover only the six evaluated protocols, two of which share the s2n-tls code base. Ground truth was built manually by three experts from repository code; precision and recall count only fully correct transitions. RFCNLP had higher precision on RTSP. Results depend on GPT-4 at temperature 0.2 through a commercial API, so outputs and costs may change. The inferred machines are LLM summaries, not proofs of implementation behavior or equivalence. Fuzzing gains come from AFLNet seeds; BGP's event-driven transitions limited message-based coverage. The two crash bugs are in the feng RTSP server. #### Why it fits this collection Adds LLM-based protocol state-machine recovery from implementation source code, complementing the collection's traffic-based, binary-assisted and grey-box state inference research. #### Publication and review notes Crossref establishes the ten-author order, the IWQoS 2025 proceedings, pages 1–10 and the DOI; the IEEE title capitalizes “From”, while arXiv uses “from”. arXiv v4 of 2025-03-27 (v1 2024-05-01) has no journal reference or venue comment. Its benchmark pins strongSwan f994e0a, s2n-tls 025f3b2, openbgpd 08b59c1, feng d302a1c and openl2tp be6c288; the experiments ran GPT-4 on a 32 GB i7-12700 Ubuntu 20.04 machine. That version says source code and experimental data would be released after acceptance; neither arXiv nor the paper links a release. A GitHub repository, s1awwhy/ProtocolGPT, uses the paper title and contains Python scripts, but has no license and is not linked by the paper. The developer is reported to have confirmed the two RTSP bugs; no CVE identifiers are given. #### Primary sources 1. 2. 3. 4. 5. ### Unlocking the conversion of Web Screenshots into HTML Code with the WebSight Dataset > WebSight is a synthetic dataset of 2 million HTML documents paired with full-page screenshots for training screenshot-to-HTML models. Mistral-7B-Instruct generates website concepts, Deepseek-Coder-33B-Instruct writes each page in HTML with Tailwind CSS, images come from keyword-based stock-photo URLs, and Playwright renders the screenshots after filtering. This v0.2 release replaces the 823K-pair v0.1, which used traditional CSS and colored rectangles instead of images. The authors fine-tune an 8B vision-language model, Sightseer, on the data with DoRA and show qualitative conversions, including one from a hand-drawn sketch. - Authors: Hugo Laurençon; Léo Tronchon; Victor Sanh - Venue: arXiv - Status: Preprint - Publication / posting date: March 14, 2024 - Date source: arXiv v1 submission date; no later version, journal reference or proceedings publication was found. - First arXiv submission: March 14, 2024 - arXiv: 2403.09029 - Reviewed arXiv version: v1 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Project: - BibTeX: - Catalog page: #### Scope and limitations The websites are synthetic, LLM-generated single pages, not crawled real sites, so training on them does not establish reconstruction of real websites, their source or their behavior. Evaluation is qualitative only: no benchmark scores are reported, checkpoints were selected by manual inspection because validation loss did not track output quality, and the authors note failures on complex layouts, long text and designs unlike the training data, as well as Tailwind syntax errors. v0.2 pages load Tailwind CSS from a CDN link and images from source.unsplash.com URLs, so re-rendering depends on those external services. The base model was unreleased at the time, and the report is not peer-reviewed. #### Why it fits this collection Adds the synthetic screenshot-to-HTML training dataset that later website reconstruction work, including Design2Code and Web2Code, builds on. #### Publication and review notes Reviewed arXiv v1, the only version, a technical report with no comment, journal reference or DOI; a Crossref search found no peer-reviewed version. The project link pins the Hugging Face dataset card at revision b11f817 (last modified 2024-03-26). The card declares CC BY 4.0, asks users to follow the licenses of the source content and to disclose use when releasing trained models, documents v0.1 in detail and still marks the v0.2 split size and creation section “TO DO”. The paper does not link code or the Sightseer weights. #### Primary sources 1. 2. 3. ### Elipmoc: Advanced Decompilation of Ethereum Smart Contracts > Elipmoc decompiles Ethereum Virtual Machine bytecode into a structured three-address intermediate representation for security analyses and reverse engineering. Built as an evolution of the Datalog-based Gigahorse decompiler, it adds transactional context sensitivity, path-sensitive inference of function arguments and returns with path merging, and fully context-sensitive reconstruction of private functions. On a uniform random sample of 5,000 unique mainnet contracts first deployed between April and September 2021, the authors report fully resolved operands for 99.5% of contracts versus 62.8% for Gigahorse, 67% more unique external-call signatures than Etherscan’s Panoramix, and over 5x faster decompilation. - Authors: Neville Grech; Sifis Lagouvardos; Ilias Tsatiris; Yannis Smaragdakis - Venue: Proceedings of the ACM on Programming Languages (OOPSLA 2022) - Status: Journal article - Publication / posting date: April 29, 2022 - Date source: ACM’s Crossref deposit records published/print and online publication on 2022-04-29; the article footer gives April 2022. The OOPSLA conference dates are not substituted for this publication date. - DOI: 10.1145/3527321 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Targets EVM bytecode only. The metrics are operand resolution, structured control flow, function and jump-target precision, external-call and event coverage, timeouts and speed against the 2022 Gigahorse artifact and Panoramix; they do not measure equivalence to or recovery of original Solidity source, and the output is three-address IR rather than recompilable code. Experiments used one 5,000-contract sample from a five-month 2021 deployment window, a 120-second per-contract cutoff and Souffle 2.0.2. JEB, Trustlook SECaaS and EtherSolve were not compared, and EtherVM, Porosity and Vandal were excluded as inferior or unmaintained. Reported vulnerability discoveries built on Elipmoc are described as end-to-end impact, not a systematic evaluation. #### Why it fits this collection Adds a static EVM bytecode decompiler that DiSCo uses as a baseline, extending the bibliography’s smart-contract decompilation coverage. #### Publication and review notes Crossref and the author-hosted final PDF agree on the four-author order, the DOI, volume 6, issue OOPSLA1 and pages 1–27; the PDF numbers the article 77, and Crossref records a CC BY 4.0 license. Crossref’s title is in sentence case, while the PDF uses title case. No arXiv preprint was found. The code link is the Gigahorse toolchain that implements Elipmoc; its README cites this paper and a later 2025 paper on further changes. At reviewed master commit 1b06cef (2026-09-14), the LICENSE file is BSD 3-Clause with material from the University of Sydney marked in individual files, while the GitHub API reports NOASSERTION. Current setup requires recursive submodules, Souffle 2.3 or 2.4.1, Boost, Z3 and Python 3.13 through uv, unlike the paper’s Souffle 2.0.2 and Python 3.8.2. #### Primary sources 1. 2. 3. 4. 5. ### MappyLand: Fast, Accurate Mapping for Console Games > MappyLand, a Rust rewrite of the earlier Mappy system, instruments the FCEUMM NES emulator core to map action/adventure games as they are played from controller inputs. It hooks accesses to the picture-processing unit's scrolling registers and reads emulator memory to register scrolling, separate the playfield from menus, detect and track sprites, build grid-based tile maps and recognize room transitions. An online merging step combines observed rooms into a consistent room graph across backtracking and multiple play sessions. In a 34,514-frame test the authors report about 1.5 ms of mapping overhead per frame, against about 0.2 ms for emulation alone. - Authors: Joseph C. Osborn; Adam Summerville; Nathan Dailey; Soksamnang Lim - Venue: AIIDE 2021 - Status: Conference paper - Publication / posting date: October 4, 2021 - Date source: The AAAI OJS article page gives publication on 2021-10-04, and the publisher-deposited Crossref record gives the same published-online and issued date. The conference dates are not substituted. - DOI: 10.1609/aiide.v17i1.18892 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Limited to NES action/adventure games in which the player controls characters moving through a 2D, tile-based space with a single physical layer; independently scrolling layers and parallax backgrounds are unsupported, and other consoles are left to future work. The method relies on emulator instrumentation and memory reads rather than pixels alone, and needs the game image plus controller inputs. Maps were judged accurate only by human inspection of the authors' play on a sample of games; with no reference dataset, no automated quantitative accuracy evaluation was performed. Areas not seen during play stay unmapped, and visually similar rooms can be ambiguous. Timing comes from individual reported runs; the authors expect, but do not measure, similar overhead across NES games. Output is maps, room graphs and entity tracks, not game code, rules or assets. #### Why it fits this collection Adds emulator-instrumented recovery of game-world structure, namely maps, room graphs and entity tracks, from observed play, complementing pixel-only game replication and code-world-model research. #### Publication and review notes The OJS page and Crossref establish the four-author order, DOI, volume 17, issue 1 and pages 66–73. Crossref types the record as a journal article because AIIDE proceedings appear as an OJS series. The paper's footnotes link faim-lab/mappy and faim-lab/fceumm-libretro-hooks. The reviewed mappy snapshot at bbf99dd (2025-07-21) includes commits made years after the paper, uses Rust edition 2024 and an unpinned retro-rs Git dependency, declares no license, and bundles prebuilt instrumented emulator cores for Linux, macOS and Windows; the core source in fceumm-libretro-hooks at 4b2001d (2025-02-14) is GPL-2.0. Graphviz renders the map images. The earlier Mappy system (FDG 2017 PCG workshop, arXiv:1707.03908) is a separate paper. #### Primary sources 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ### DICE: Automatic Emulation of DMA Input Channels for Dynamic Firmware Analysis > DICE adds DMA input emulation to microcontroller firmware emulators that model neither peripherals nor DMA controllers. It watches firmware writes to the memory-mapped DMA controller region for pairs of source and destination transfer pointers, and infers the transfer direction from later firmware accesses. When firmware reads a peripheral-to-RAM destination buffer, DICE answers with analyzer-supplied input such as fuzzer data, growing buffer bounds conservatively. Prototypes patch the QEMU forks of P2IM (ARM Cortex-M) and a PIC32 emulator (MIPS M4K/M-Class). On 83 sample firmware covering 9 DMA controllers from 5 vendors, the authors report 33 of 37 input channels detected with no false positives, correct input for 21 of 22 buffers and 3.4% average overhead. Fuzzing 7 real firmware for 48 hours found 5 previously unknown bugs. - Authors: Alejandro Mera; Bo Feng; Long Lu; Engin Kirda - Venue: IEEE S&P 2021 - Status: Conference paper - Publication / posting date: May 2021 - Date source: The publisher's Crossref deposit records print publication in May 2021, the month of the May 24–27 symposium. IEEE Xplore could not be retrieved automatically, and no publication day is asserted. - First arXiv submission: July 3, 2020 - arXiv: 2007.01502 - Reviewed arXiv version: v3 - DOI: 10.1109/SP40001.2021.00018 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Emulates DMA input channels only; it does not model peripheral behavior, recover peripheral semantics or produce a faithful device replica, and supplied inputs are analyzer data rather than real peripheral traffic. It assumes transfer descriptors are written to DMA controller registers, so descriptors stored in RAM are unsupported. Destination-only configurations, used by two controller models such as nRF52832 EasyDMA, are also missed, accounting for 7 of 52 stream configurations. Buffer sizes are heuristic estimates. Ground truth came from datasheets and firmware inspection, and results cover the authors' 83 sample firmware and 7 fuzzed firmware. Bugs were found in two of the seven fuzzed firmware with a basic memory sanitizer. The PIC32 prototype runs only firmware whose other peripherals can be handled by simple default register handlers. #### Why it fits this collection Adds DMA input-channel emulation for firmware rehosting, complementing the collection's MMIO-modeling and fuzzing-oriented MCU rehosting research. #### Publication and review notes Crossref establishes the four-author order, the 2021 IEEE S&P proceedings, pages 1938–1954 and the DOI; IEEE Xplore refused automated retrieval. Reviewed arXiv v3 of 2021-01-15 (v1 2020-07-03) carries journal reference “42nd IEEE Symposium on Security and Privacy, S&P 2021” and links the repository. The reviewed master snapshot 2b3b8c8b was pushed on 2023-10-14. Its LICENSE releases DICE under Apache-2.0 unless otherwise stated, while AFL and P2IM's AFL changes are Apache-2.0 and QEMU, P2IM's QEMU changes, the PIC32 extensions and P2IM itself are GPL-2.0; GitHub reports no single SPDX license. The p2im and mips-emulator directories are submodules pinned to RiS3-Lab/p2im 0a4870b4 and sergev/qemu a2e0277d. README supports Ubuntu 16.04 or 18.04 only, noting problems on 20.04. It applies DICE as patches to QEMU and supplies precompiled QEMU binaries plus evaluation firmware binaries, sources and scripts; bundled vendor sample firmware keeps its own terms. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### DeepDi: Learning a Relational Graph Convolutional Network Model on Instructions for Fast and Accurate Disassembly > DeepDi disassembles x86 and x64 binaries by decoding a superset of candidate instructions, linking them in an Instruction Flow Graph of forward, backward and overlap relations, and classifying true instructions with a Relational Graph Convolutional Network; heuristics and a small classifier then recover function entry points. On BAP corpora, LLVM 11 built with MSVC on Windows, and SPEC CPU2006 and CPU2017, the authors report accuracy comparable or superior to IDA Pro, Binary Ninja, Ghidra, Datalog Disassembly and XDA, robustness on Linn–Debray and Hikari obfuscated binaries, single-core CPU throughput of 146 KB/s (about twice IDA Pro) and GPU throughput of 24.5 MB/s (about 350 times IDA Pro). - Authors: Sheng Yu; Yu Qu; Xunchao Hu; Heng Yin - Venue: USENIX Security 2022 - Status: Conference paper - Publication / posting date: August 2022 - Date source: Publication month from the official USENIX BibTeX (month = aug) and the final PDF cover for the 31st USENIX Security Symposium, August 10–12, 2022; no exact publication day is asserted. - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Covers x86 and x64 ELF and PE binaries only. ELF ground truth assumes no data in code sections and uses linear disassembly plus symbol tables; PE ground truth comes from PDB files, with data lengths estimated because PDBs give only data addresses. Results are the authors’ 2022 comparisons against Binary Ninja 2.2, IDA Pro 7.2 and Ghidra 9.1.2 on their datasets and hardware, with one GTX 2080Ti GPU; Datalog Disassembly supports only x64 ELF and so covers part of the evaluation. Obfuscation tests use Linn–Debray samples and Hikari-built binaries; the authors note that a strong adversary using the model’s gradients could construct adversarial examples, which they leave to future work. The malware case reports 10-fold cross-validation accuracy on training data and log loss from the challenge’s online judge, because test labels are not public. Disassembly accuracy does not establish correct function boundaries in every case, decompilation or source recovery. #### Why it fits this collection Adds learned disassembly, the step whose errors several similarity and decompilation records list as a threat to validity, complementing IDA Pro-dependent pipelines such as jTrans. #### Publication and review notes No paper DOI or arXiv identifier was verified; the record uses the USENIX Security presentation-page and sec22-yu-sheng.pdf profile. The USENIX BibTeX gives the 31st USENIX Security Symposium, pages 2709–2725, USENIX Association and month August; the presentation page also links a prepublication PDF and an abstract PDF. The paper describes a binary release. At reviewed commit e308252 (2026-05-01), the repository ships the model core as a prebuilt DeepDiCore.so under the DeepDi Trial Period Software Demonstration License Agreement, and license.txt applies MIT only to the other code, a Python wrapper, API notes and Dockerfiles; the GitHub API reports NOASSERTION, and the linked license PDF returned HTTP 404 when checked. The README calls this a community edition for non-commercial use, requires Docker and a free key from Deepbits, and supports optional CUDA GPUs. The model and training pipeline are not open source. #### Primary sources 1. 2. 3. 4. 5. ### Noncompliance as Deviant Behavior: An Automated Black-box Noncompliance Checker for 4G LTE Cellular Devices > DIKEUE checks 4G LTE control-plane (NAS and RRC) implementations in commercial phones and modems for noncompliance through differential testing rather than predefined security properties. Its FSM inference module runs TTT active automata learning in LearnLib through an LTE-specific adapter on a modified srsLTE network with a USRP B210 radio, adding a context checker, query cache, inconsistency resolver and reset without rebooting. An equivalence checker then encodes pairs of learned input-output finite state machines for the nuXmv model checker and enumerates diverse deviation-inducing input sequences, which the authors analyze manually. - Authors: Syed Rafiul Hussain; Imtiaz Karim; Abdullah Al Ishtiaq; Omar Chowdhury; Elisa Bertino - Venue: ACM CCS 2021 - Status: Conference paper - Publication / posting date: November 12, 2021 - Date source: ACM's Crossref deposit records published/print publication on 2021-11-12 and online publication on 2021-11-13. This entry uses the print date, not the November 15–19 conference dates. - DOI: 10.1145/3460120.3485388 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Covers control-plane NAS and RRC procedures with a chosen input alphabet and queries up to length 12; session management, data-plane protocols and 5G are left to future work. Learned machines are hypotheses bounded by Wp-method conformance testing and custom termination conditions. The authors list false-negative sources, including omitted message predicates, pruned infeasible sequences, models disconnected by removing deviating transitions, and devices that are noncompliant in the same way. Findings cover 14 devices with basebands from five vendors (Qualcomm, Intel, MediaTek, HiSilicon and Exynos): 17 deviations, 15 of them new, of which the authors class 11 as exploitable and 3 as potential interoperability issues. Deviations were triaged and attacks constructed manually, and the results do not establish the behaviour of other devices, firmware versions or networks. #### Why it fits this collection Reconstructs protocol state machines of closed cellular basebands through black-box interaction and uses cross-implementation differences to locate noncompliance, extending the catalog's automata-learning work from Bluetooth Low Energy to 4G LTE devices. #### Publication and review notes Crossref and the author-hosted PDF agree on the five-author order; pages 1082–1099 come from ACM's Crossref deposit. The 17-page author copy was uploaded in September 2021. The Apache-2.0 repository snapshot at 5975807 (2023-06-07) contains the FSM learner, modified srsLTE stack and configurations, device resetter and equivalence checker. Its README lists Ubuntu 18.04 (tested), a USRP B210 (tested SDR), adb, Graphviz, JDK 11, Maven, Python 2 and pydot; it also requires a SIM card programmed to srsLTE requirements and per-device airplane-mode reset functions, and reports about 40–45 minutes for the equivalence checker on two sample FSMs. The README bases the modified stack on srsLTE 19.03, whereas the paper names srsLTE v19.10. The authors report responsible disclosure to GSMA and the affected vendors. #### Primary sources 1. 2. 3. 4. 5. 6. ### LibreCAN: Automated CAN Message Translator > LibreCAN reverse-engineers proprietary CAN message formats from traffic recorded at a vehicle's OBD-II port, without the OEM's DBC translation files. Phase 0 extracts candidate signal boundaries from bit-flip behaviour, extending the earlier READ algorithm; Phase 1 correlates extracted signals with standard OBD-II PIDs and smartphone IMU data to identify kinematic signals and estimate their scale and offset; Phase 2 filters the CAN IDs recorded while a driver performs 53 scripted body-related events to shortlist candidate IDs for each event. - Authors: Mert D. Pesé; Troy Stacer; C. Andrés Campos; Eric Newberry; Dongyao Chen; Kang G. Shin - Venue: ACM CCS 2019 - Status: Conference paper - Publication / posting date: November 6, 2019 - Date source: ACM's Crossref deposit gives 2019-11-06 for both print and online publication. The November 11–15 conference dates are not substituted. - DOI: 10.1145/3319535.3363190 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evaluated on four newer vehicles from a single OEM, using DBC files the authors obtained as ground truth and their own judgement of which CAN signals correspond to each reference signal; they call the evaluation partly subjective because the OEM was not involved. Phase 0 recovered 51.6–62.4% of DBC signals, but only 21.0–36.4% of extracted signals had correct boundaries, partly because normal driving rarely exercises high value ranges. With extracted boundaries, Phase 1 precision was 61.1–78.1% and recall 25.6–57.3%; Phase 2 cut candidates more than tenfold, with 8.5–15.0% precision. Only buses reachable through OBD-II were analysed, so signals on other buses were missed. The system reads traffic only and recovers a partial translation table, not complete DBC files, ECU logic or validated injection. #### Why it fits this collection Adds automated reverse engineering of proprietary in-vehicle CAN message formats from passive traffic and reference signals, complementing the catalog's CAN tooling and network-protocol inference research. #### Publication and review notes Crossref records the title LibreCAN with the subtitle Automated CAN Message Translator, the six-author order and pages 2283–2300. The 18-page copy on the University of Michigan Real-Time Computing Laboratory site is an ACM-formatted author version created on 2019-09-25. The paper reports roughly 40 minutes of manual data collection (a 30-minute drive and a 10-minute event session) and 70–79 seconds of computation per vehicle; its 10-participant event-recording study received IRB approval. Data came from an ELM327 dongle, an OpenXC dongle on a Y-cable and the Torque Pro Android app, and computation used Python 3 on Ubuntu 16.04. The mdp93/LibreCAN_CCS repository at e10aea7 contains only a project README and site configuration, with no license or implementation, and no DBC ground truth or vehicle traces were found in the reviewed sources. #### Primary sources 1. 2. 3. 4. ### Automatic Firmware Emulation through Invalidity-guided Knowledge Inference > µEmu emulates ARM Cortex-M microcontroller firmware without real hardware or hand-written peripheral models by symbolically executing the image with unknown peripheral registers as symbols. Invalidity-guided exploration detects invalid states such as unexpected infinite loops and steers execution toward valid paths, caching the chosen responses at individual peripheral access points in a tiered knowledge base whose rules range from simple storage to PC- and calling-context-based matching. During dynamic analysis the knowledge base answers peripheral reads while an integrated, modified AFL fuzzer supplies data-register input. The prototype extends S2E 2.0 with Cortex-M support. - Authors: Wei Zhou; Le Guan; Peng Liu; Yuqing Zhang - Venue: USENIX Security 2021 - Status: Conference paper - Publication / posting date: August 2021 - Date source: The BibTeX on the USENIX presentation page gives August 2021 for the 30th USENIX Security Symposium proceedings. Month precision is retained; the symposium dates are not substituted for a publication day, and the July 2021 arXiv dates belong to the extended version. - First arXiv submission: July 16, 2021 - arXiv: 2107.07759 - Reviewed arXiv version: v2 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Targets ARM Cortex-M firmware; the repository lists DMA and other architectures as unsupported help-wanted items. Responses only have to satisfy the firmware's own checks rather than reproduce real peripheral values, so successful emulation does not establish hardware equivalence. Invalidity checks can miss unhandled error paths, data registers can be mis-categorized (3 of 43 were missed against ground truth taken from chip manuals), and long loops whose concrete counters depend on symbols may go undetected. On P2IM's 66 unit tests the final paper reports 63 passes (95%) without manual help, and all after adding one invalid program point to each failure. Across 21 real-world firmware samples, 6 needed a user-defined invalid point and 3 a manually added data register. Coverage counts QEMU translation blocks against IDA-counted basic blocks, following P2IM. #### Why it fits this collection Adds symbolic-execution-based inference of peripheral behaviour for rehosting microcontroller firmware, complementing the catalog's HAL-replacement and MMIO-modelling approaches. #### Publication and review notes The USENIX presentation-page BibTeX establishes the four-author order, proceedings title, pages 2007–2024 and August 2021. A footnote in the final PDF points to the authors' extended version on arXiv, titled with an "(Extended Version)" suffix (v1 2021-07-16, v2 2021-07-27), which is recorded as the arXiv identifier; no publisher DOI was found. The presentation-page abstract reports a 93% unit-test passing rate, whereas the final paper and the arXiv abstract report 95%. The MCUSec/uEmu snapshot at c82fc0a (2023-11-20) has mixed terms: its add-on plugins use the Cyberhaven Research License of S2E 2.0 (non-commercial use only), its AFL changes Apache-2.0, QEMU GPL-2.0, and other S2E libraries LGPL-2.1, BSD/MIT or NCSA licenses; GitHub reports NOASSERTION. The README supports Ubuntu 18.04 or 20.04 (64-bit) or a Vagrant VM, fetches sources through a repo manifest, estimates about an hour to build on four cores, keeps unit-test and real-world firmware configurations in separate repositories, and uses an IDA script to count basic blocks for coverage. #### Primary sources 1. 2. 3. 4. 5. ### What Your Firmware Tells You Is Not How You Should Emulate It: A Specification-Guided Approach for Firmware Emulation > SEmu builds microcontroller peripheral models from vendor reference manuals rather than from the firmware itself. An NLP pipeline built on the Stanford tagger and parser turns register descriptions, interrupt tables and DMA channel tables taken from the manuals into structured condition-action rules, which the emulator checks, executes and chains at run time to answer MMIO accesses and raise interrupts or DMA requests. A symbolic-execution diagnostic tool built on S2E and µEmu traces invalid states back to the rules likely responsible, so that a person can correct them. The authors also use the models for fuzzing and to check driver code against specification rules. - Authors: Wei Zhou; Lan Zhang; Le Guan; Peng Liu; Yuqing Zhang - Venue: ACM CCS 2022 - Status: Conference paper - Publication / posting date: November 7, 2022 - Date source: ACM's Crossref deposit gives 2022-11-07 for both print and online publication. The conference dates are not substituted. - First arXiv submission: August 16, 2022 - arXiv: 2208.07833 - Reviewed arXiv version: v3 - DOI: 10.1145/3548606.3559386 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Rule extraction is not fully automatic. The NLP engine mishandles cross-sentence references and nested conditions, and the raw rules for the clock peripherals of all three unit-test chips broke booting, so every one of P2IM's 66 unit tests failed until those rules were revised. After diagnosis-guided manual correction (26 rules added, 21 fixed and 3 removed, against 3,602 rules extracted from 23,424 sentences), the authors report that all 66 unit tests and 17 additional samples were emulated. Users must identify the MCU, configure memory maps and copy the needed manual sections into the pipeline, and diagnosis needs prepared test firmware; three developers took about two hours on average to fix the F103 I2C rules. The prototype covers 26 peripherals on five boards from three vendors (STM32F1, F4 and L1, NXP K64 and Atmel SAM3X), and trace-fidelity comparisons used real-hardware traces from only the K64F and F103RB boards. Rules model documented behaviour and do not establish equivalence with the silicon. #### Why it fits this collection Adds specification-derived peripheral modelling for rehosting microcontroller firmware, complementing firmware-guided approaches such as MMIO modelling and invalidity-guided inference. #### Publication and review notes Crossref records the title, subtitle, five-author order, pages 3269–3283 and print and online publication on 2022-11-07; the ACM full text is not open access. arXiv v3 (2022-10-11; v1 2022-08-16) is the authors' 18-page extended version and states that Wei Zhou and Lan Zhang contributed equally; the figures in this record come from it. The MCUSec/SEmu snapshot at 6dc8be9 (2025-04-22) declares Apache-2.0 for the rule extractor and the non-commercial Cyberhaven Research License of S2E 2.0 for the S2E-based rule doctor, and points to IoTS-P/SEmu-Fuzz, which is Apache-2.0, for fuzzing; GitHub reports NOASSERTION for the main repository. The repository also redistributes vendor reference-manual PDFs, whose terms are separate, and directs users to a Google Drive copy of the Stanford tagger and parser. Building the rule doctor follows µEmu's S2E 2.0 package list and repo manifest, with an estimated 30–60 minutes on four cores. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### Conware: Automated Modeling of Hardware Peripherals > Conware builds reusable software models of hardware peripherals from recordings of real firmware–peripheral interactions. An LLVM pass instruments Arduino source code to log MMIO reads, writes and interrupts on the real board, with existing hardware-in-the-loop recording as an alternative. Each recording becomes a per-peripheral graph whose read values are summarized as simple sub-models such as patterns; graphs are merged and optimized into automata that can be combined across peripherals and run in an Avatar²-based emulator. The authors model ten peripherals on an Arduino Due (SAM3X Cortex-M3) and emulate an uninstrumented smart-door-lock firmware from models trained only on vendor example code. - Authors: Chad Spensky; Aravind Machiry; Nilo Redini; Colin Unger; Graham Foster; Evan Blasband; Hamed Okhravi; Christopher Kruegel; Giovanni Vigna - Venue: ACM ASIA CCS 2021 - Status: Conference paper - Publication / posting date: May 24, 2021 - Date source: ACM's Crossref deposit records published/print publication on 2021-05-24 and online publication on 2021-06-04. This entry uses the print date, not the June 7–11 conference dates. - DOI: 10.1145/3433210.3437532 - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-03 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Training needs the real board with the peripherals attached, plus source code for the LLVM-based recorder. The evaluation covers bare-metal Arduino Due firmware with ten hobbyist peripherals, and port-mapped I/O systems are out of scope. Models encode only behaviour observed during recording, assume that state transitions follow MMIO writes, and attach interrupts to transitions rather than to the writes that trigger them, so read-triggered transitions and exact interrupt timing are not supported. The unseen-firmware result is a single door-lock program built from six peripheral models. Its UART output matched real hardware, and it executed 362 of the 609 basic blocks (59%) and 58 of the 68 functions (85%) reachable from loop(); the authors measure survivability of execution rather than full peripheral fidelity. Record-and-replay comparisons ran each sample once for 10 minutes, since replays are deterministic. #### Why it fits this collection Adds record-and-model reconstruction of peripherals from real hardware interactions, complementing the catalog's HAL-replacement, firmware-guided and specification-guided rehosting approaches. #### Publication and review notes Crossref records the nine-author order, pages 95–109, print publication on 2021-05-24 and online publication on 2021-06-04. The 15-page copy on Christopher Kruegel's UCSB site carries the ACM reference format and DOI. The paper cites ucsb-seclab/conware for its code; the snapshot at 05dfdf5 (2020-07-19, committed as the submitted version of the code) declares no license. Its README pipeline instruments Arduino code with LLVM, runs it on a real Arduino with the peripheral attached, dumps logs over UART, and then generates, optimizes and emulates models with Avatar² and OpenOCD; the install script builds LLVM. Two submodules, pretender and avatar2-pretender, use SSH URLs on the UCSB lab's own Git server, and the pinned requirements include Python 2 backport packages such as enum34. #### Primary sources 1. 2. 3. 4. 5. 6. 7. ### A Taxonomy of C Decompiler Fidelity Issues > Open-codes decompiled/original C function pairs to classify how decompiler output departs from the source beyond missing names and types. Using a statement-alignment abstraction and thematic analysis, the authors build a hierarchical codebook of 15 top-level categories and 52 codes, covering correctness issues such as nonequivalent expressions and incorrect return behavior and readability issues such as extraneous variables, non-idiomatic control flow and decompiler-specific macros. The codebook, developed on Hex-Rays output, is applied to Ghidra, retdec and angr, and the authors suggest type prediction, rule-based fixes and whole-program learned techniques to address classes of defects. - Authors: Luke Dramko; Jeremy Lacomis; Edward J. Schwartz; Bogdan Vasilescu; Claire Le Goues - Venue: USENIX Security 2024 - Status: Conference paper - Publication / posting date: August 2024 - Date source: Publication month from the official USENIX BibTeX (month = aug) and the final PDF cover for the 33rd USENIX Security Symposium, August 14–16, 2024; no exact publication day is asserted. - Sources reviewed: 2026-10-27 - Added to the catalog: 2026-11-04 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations A qualitative taxonomy, not a benchmark score or decompiler ranking. Coding centres on a random sample of 200 Hex-Rays decompiled/original pairs from the small-function set plus ten large functions; the authors report 235 coded pairs in total. Ghidra, retdec and angr were compared with Hex-Rays only on a 25-function subsample. Inputs are Hex-Rays decompilations of GHCC builds of majority-C GitHub repositories, biased toward projects with recognizable, working build scripts and filtered by a step that also removed some valid functions; the dataset contains no obfuscated binaries and is unlikely to include malware. Missing variable names and types were deliberately not labeled. The Java check applies the codebook to 25 Defects4J functions decompiled with JD-GUI as a side study. The issues’ effect on reverse-engineer productivity is left to future work. #### Why it fits this collection Adds an empirical taxonomy of what decompiled C gets wrong, complementing decompiler benchmarks with automated scores and LLM repair methods such as FidelityGPT. #### Publication and review notes No paper DOI or arXiv identifier was verified; the record uses the USENIX Security 2024 presentation-page and usenixsecurity24-dramko.pdf profile. The USENIX BibTeX gives the 33rd USENIX Security Symposium, pages 379–396, USENIX Association and month August; the presentation page also links a prepublication PDF. The paper’s Availability section points to Zenodo DOI 10.5281/zenodo.8419614, a CC BY 4.0 dataset record dated 2023-11-07 by the same five creators with codebook.pdf and dataset.zip; that DOI identifies the coded examples and codebook, not this paper. The paper versions only JD-GUI (1.6.6) and names no Hex-Rays, Ghidra, retdec or angr versions. Intercoder agreement is reported as Cohen’s kappa and is weaker for rare issues. #### Primary sources 1. 2. 3. 4. ### Refining Decompiled C Code with Large Language Models > The paper proposes a two-step hybrid LLM approach to refine IDA-Pro decompiled C code for recompilation. On popular C test cases, it reports a recompilation success rate above 75% with moderate effort. - Authors: Wai Kin Wong; Huaijin Wang; Zongjie Li; Zhibo Liu; Shuai Wang; Qiyi Tang; Sen Nie; Shi Wu - Venue: arXiv - Status: Preprint - Publication / posting date: October 10, 2023 - Date source: First arXiv submission date. - First arXiv submission: October 10, 2023 - arXiv: 2310.06530 - Reviewed arXiv version: v2 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The pilot study examines obstacles in recompiling IDA-Pro output; the evaluation uses a set of popular C test cases. #### Why it fits this collection It addresses reverse engineering of executables by improving decompiled C code for recompilation. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### ICSREF: A Framework for Automated Reverse Engineering of Industrial Control Systems Binaries > ICSREF automates reverse engineering of PLC binaries compiled with CODESYS. It was evaluated on collected and in-house PLC binaries and used to generate an attack against a chemical process testbed. - Authors: Anastasis Keliris; Michail Maniatakos - Venue: Proceedings 2019 Network and Distributed System Security Symposium - Status: Conference paper - Publication / posting date: 2019 (exact date not verified) - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: December 9, 2018 - arXiv: 1812.03478 - Reviewed arXiv version: v1 - DOI: 10.14722/ndss.2019.23271 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers CODESYS-compiled PLC binaries from public code repositories and in-house development, plus an attack orchestrated by a commercial smartphone against a chemical process testbed. #### Why it fits this collection It presents a framework and methodology for automated reverse engineering of industrial control system binaries. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### On Manually Reverse Engineering Communication Protocols of Linux Based IoT Systems > Presents a manual framework for reverse engineering communication protocols in embedded Linux IoT systems. It applies the framework to several systems and details a WeMo smart plug case study. - Authors: Kaizheng Liu; Ming Yang; Zhen Ling; Huaiyu Yan; Yue Zhang; Xinwen Fu; Wei Zhao - Venue: arXiv - Status: Preprint - Publication / posting date: July 23, 2020 - Date source: First arXiv submission date. - First arXiv submission: July 23, 2020 - arXiv: 2007.11981 - Reviewed arXiv version: v2 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The detailed evaluation covers a WeMo smart plug: extracting firmware from flash, analyzing it statically and dynamically, and examining network traffic. The framework covers read-only and writable embedded Linux filesystems. #### Why it fits this collection It describes a practical workflow for discovering an IoT device’s communication protocol through firmware and traffic analysis. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### Frankenstein: Advanced Wireless Fuzzing to Exploit New Bluetooth Escalation Targets > Frankenstein emulates Bluetooth firmware dumps and fuzzes a virtual modem. It evaluates Broadcom and Cypress stacks, finding three zero-click vulnerabilities, host escalation issues, and BlueFrag on Android. - Authors: Jan Ruge; Jiska Classen; Francesco Gringoli; Matthias Hollick - Venue: USENIX Security 2020 - Status: Conference accepted - Publication / posting date: June 17, 2020 - Date source: First arXiv submission date; the arXiv comment names the venue. - First arXiv submission: June 17, 2020 - arXiv: 2006.09809 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers Broadcom and Cypress Bluetooth stacks, Wi-Fi/Bluetooth coexistence, a Bluetooth 5.2 link-key flaw, and Android devices. #### Why it fits this collection It uses emulation of closed-source firmware dumps to examine Bluetooth behavior and find vulnerabilities. #### Publication and review notes The arXiv comment reads: To be published at USENIX Security #### Primary sources 1. ### From Library Portability to Para-rehosting: Natively Executing Microcontroller Software on Commodity Hardware > The paper uses a POSIX-based portable MCU and replaceable peripheral drivers to rehost MCU software for native execution and security testing on commodity hardware. - Authors: Wenqiang Li; Le Guan; Jingqiang Lin; Jiameng Shi; Fengjun Li - Venue: Proceedings 2021 Network and Distributed System Security Symposium - Status: Conference paper - Publication / posting date: 2021 (exact date not verified) - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: July 4, 2021 - arXiv: 2107.12867 - Reviewed arXiv version: v1 - DOI: 10.14722/ndss.2021.24308 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations It rehosts nine MCU operating systems, including Amazon FreeRTOS, ARM Mbed OS, Zephyr, and LiteOS. AFL and ASAN testing found 28 previously unknown bugs; five received CVEs and 19 were confirmed by vendors at the time of writing. #### Why it fits this collection It presents a way to run MCU firmware on commodity hardware so existing dynamic analysis tools can find bugs. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### Trex: Learning Execution Semantics from Micro-Traces for Binary Similarity > Trex learns execution semantics from function micro-traces, then uses that knowledge to match semantically similar binary functions. - Authors: Kexin Pei; Zhou Xuan; Junfeng Yang; Suman Jana; Baishakhi Ray - Venue: arXiv - Status: Preprint - Publication / posting date: December 16, 2020 - Date source: First arXiv submission date. - First arXiv submission: December 16, 2020 - arXiv: 2012.08680 - Reviewed arXiv version: v3 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers 1,472,066 function binaries from 13 software projects, across architectures, compiler optimizations, and obfuscations. #### Why it fits this collection It addresses binary function similarity by learning execution behavior from traces. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### A Cross-Architecture Instruction Embedding Model for Natural Language Processing-Inspired Binary Code Analysis > The paper learns instruction embeddings that capture semantic relationships within and across architectures. It evaluates them on semantic basic-block comparison, outperforming a code-statistics approach. - Authors: Kimberly Redmond; Lannan Luo; Qiang Zeng - Venue: arXiv - Status: Preprint - Publication / posting date: December 23, 2018 - Date source: First arXiv submission date. - First arXiv submission: December 23, 2018 - arXiv: 1812.09652 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evaluates semantic basic-block comparison across architectures on disassembled binary code. #### Why it fits this collection It addresses cross-architecture binary code analysis through learned instruction representations. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### D-LiFT: Improving LLM-based Decompiler Backend via Code Quality-driven Fine-tuning > D-LIFT uses D-Score to guide LLM fine-tuning and output selection, improving decompiled code while prioritizing accuracy. It evaluates Ghidra output from coreutils and util-linux. - Authors: Muqi Zou; Hongyu Cai; Hongwei Wu; Zion Leonahenahe Basque; Arslan Khan; Berkay Celik; Dave; Tian; Antonio Bianchi; Ruoyu; Wang; Dongyan Xu - Venue: arXiv - Status: Preprint - Publication / posting date: June 11, 2025 - Date source: First arXiv submission date. - First arXiv submission: June 11, 2025 - arXiv: 2506.10125 - Reviewed arXiv version: v4 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers functions from coreutils and util-linux, using Ghidra and a range of LLMs. D-Score measured 55.3% more improved functions than baseline LLMs and improvements to 68.2% of native decompiler functions. #### Why it fits this collection It addresses the accuracy and readability of source code reconstructed from binaries. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### BaseSAFE: Baseband SAnitized Fuzzing through Emulation > BaseSAFE partially rehosts closed-source cellular baseband firmware for instrumented fuzzing and uses a sanitizing allocator to detect heap buffer overflows. - Authors: Dominik Maier; Lukas Seidel; Shinjo Park - Venue: Proceedings of the 13th ACM Conference on Security and Privacy in Wireless and Mobile Networks - Status: Conference paper - Publication / posting date: July 8, 2020 - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: May 15, 2020 - arXiv: 2005.07797 - Reviewed arXiv version: v1 - DOI: 10.1145/3395351.3399360 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation fuzzed rogue-base-station-accessible parsers in a Nucleus RTOS-based MediaTek baseband, using LTE signaling message test cases. It found memory corruption and reached about 15,000 test cases per second in total. #### Why it fits this collection It reverse engineers and rehosts commercial baseband firmware to expose its parsers to off-device security testing. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### Towards Neural Decompilation > The paper trains a neural machine translation decompiler using a compiler. It evaluates translation from LLVM IR and x86 assembly to C, successfully decompiling over 97% and 88% of its respective benchmarks. - Authors: Omer Katz; Yuval Olshaker; Yoav Goldberg; Eran Yahav - Venue: arXiv - Status: Preprint - Publication / posting date: May 20, 2019 - Date source: First arXiv submission date. - First arXiv submission: May 20, 2019 - arXiv: 1905.08325 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers LLVM IR and x86 assembly translated to C on the paper's benchmarks. #### Why it fits this collection It addresses reverse engineering by recovering human-readable source code from low-level program representations. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### FoC: Figure out the Cryptographic Functions in Stripped Binaries with LLMs > FoC uses FoC-BinLLM to summarize cryptographic functions in stripped binaries and FoC-Sim to retrieve similar implementations. It evaluates both models and applications to virus analysis and 1-day vulnerability detection. - Authors: Xiuwei Shang; Guoqiang Chen; Shaoyin Cheng; Shikai Guo; Yanming Zhang; Weiming Zhang; Nenghai Yu - Venue: arXiv - Status: Preprint - Publication / posting date: March 27, 2024 - Date source: First arXiv submission date. - First arXiv submission: March 27, 2024 - arXiv: 2403.18403 - Reviewed arXiv version: v3 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evaluation uses a constructed cryptographic binary dataset and automatically generated semantic labels. It reports a 14.61% higher ROUGE-L score than ChatGPT for FoC-BinLLM and 52% higher Recall@1 than previous best methods for FoC-Sim. #### Why it fits this collection It addresses reverse engineering of cryptographic functions in stripped binaries through semantic analysis and similarity retrieval. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### Asteria-Pro: Enhancing Deep-Learning Based Binary Code Similarity Detection by Incorporating Domain Knowledge > Asteria-Pro adds domain-knowledge pre-filtration and re-ranking to Tree-LSTM-based binary code similarity detection. It evaluates firmware vulnerability search across diverse IoT hardware architectures. - Authors: Shouguo Yang; Chaopeng Dong; Yang Xiao; Yiran Cheng; Zhiqiang Shi; Zhi Li; Limin Sun - Venue: arXiv - Status: Preprint - Publication / posting date: January 2, 2023 - Date source: First arXiv submission date. - First arXiv submission: January 2, 2023 - arXiv: 2301.00511 - Reviewed arXiv version: v2 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers a firmware bug-search task: pre-filtration reduced calculation time by 96.9%; re-ranking improved MRR by 23.71% and Recall by 36.4%. A large-scale search found 1,482 vulnerable functions at 91.65% precision. #### Why it fits this collection It studies binary function similarity and its use in finding vulnerable code in firmware. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### Snipuzz: Black-box Fuzzing of IoT Firmware via Message Snippet Inference > Snipuzz fuzzes IoT firmware as a client, using device responses to infer message snippets that guide mutations. It was evaluated on 20 real-world IoT devices and compared with four IoT fuzzing approaches. - Authors: Xiaotao Feng; Ruoxi Sun; Xiaogang Zhu; Minhui Xue; Sheng Wen; Dongxi Liu; Surya Nepal; Yang Xiang - Venue: ACM CCS 2021 - Status: Conference accepted - Publication / posting date: May 12, 2021 - Date source: First arXiv submission date; the arXiv comment names the venue. - First arXiv submission: May 12, 2021 - arXiv: 2105.05445 - Reviewed arXiv version: v2 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers 20 popular real-world IoT devices and comparisons with IoTFuzzer, BooFuzz, Doona, and Nemesys. It reports five newly discovered zero-day vulnerabilities, three exposed only by Snipuzz. #### Why it fits this collection It infers message structure from device responses to guide black-box testing of IoT firmware. #### Publication and review notes The arXiv comment reads: Accepted to ACM CCS 2021 #### Primary sources 1. ### Asteria: Deep Learning-based AST-Encoding for Cross-platform Binary Code Similarity Detection > ASTERIA uses a Tree-LSTM to encode function ASTs and compare binary functions across platforms. It was evaluated on function pairs and used to search IoT firmware for vulnerabilities. - Authors: Shouguo Yang; Long Cheng; Yicheng Zeng; Zhe Lang; Hongsong Zhu; Zhiqiang Shi - Venue: 2021 51st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN) - Status: Conference paper - Publication / posting date: June 2021 - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: August 13, 2021 - arXiv: 2108.06082 - Reviewed arXiv version: v1 - DOI: 10.1109/dsn48987.2021.00036 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The model was trained on 1,022,616 function pairs and evaluated on 95,078 pairs. Its cross-platform scope covers differing IoT architectures; a firmware search identified 75 vulnerable functions in 5,979 images. #### Why it fits this collection It studies reverse engineering through binary function similarity and vulnerability search in IoT firmware. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### Exploring the Efficacy of Large Language Models (GPT-4) in Binary Reverse Engineering > The paper evaluates GPT-4 for binary reverse engineering through interpretation of human-written and decompiled code, from basic code explanation to malware analysis. - Authors: Saman Pordanesh; Benjamin Tan - Venue: arXiv - Status: Preprint - Publication / posting date: June 9, 2024 - Date source: First arXiv submission date. - First arXiv submission: June 9, 2024 - arXiv: 2406.06637 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers GPT-4, human-written and decompiled code, basic code interpretation, and more complex malware analysis. #### Why it fits this collection It directly studies the use of a language model to interpret code in binary reverse engineering. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### InternalBlue - Bluetooth Binary Patching and Experimentation Framework > The paper reverse engineers Broadcom Bluetooth controllers and presents InternalBlue for patching their firmware. It evaluates the framework through vulnerability tests, bug fixes, and added security features. - Authors: Dennis Mantz; Jiska Classen; Matthias Schulz; Matthias Hollick - Venue: Proceedings of the 17th Annual International Conference on Mobile Systems, Applications, and Services - Status: Conference paper - Publication / posting date: June 12, 2019 - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: May 2, 2019 - arXiv: 1905.00631 - Reviewed arXiv version: v1 - DOI: 10.1145/3307334.3326089 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The work covers multiple Broadcom Bluetooth chipsets used in smartphones, wearables, and IoT devices, with experiments on their controller firmware and Bluetooth stack. #### Why it fits this collection Examines commercial Bluetooth controller internals and uses the recovered functions to modify firmware. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### Manticore: A User-Friendly Symbolic Execution Framework for Binaries and Smart Contracts > Manticore uses dynamic symbolic execution to analyze binaries and Ethereum smart contracts. The paper presents its architecture and demonstrates bug finding and code verification used for commercial clients. - Authors: Mark Mossberg; Felipe Manzano; Eric Hennenfent; Alex Groce; Gustavo Grieco; Josselin Feist; Trent Brunson; Artem Dinaburg - Venue: arXiv - Status: Preprint - Publication / posting date: July 8, 2019 - Date source: First arXiv submission date. - First arXiv submission: July 8, 2019 - arXiv: 1907.03890 - Reviewed arXiv version: v3 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The paper covers the framework’s architecture, customizable API, and demonstrations involving binaries and Ethereum smart contracts. #### Why it fits this collection It presents a framework for systematically exploring binary program behavior through symbolic execution. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### ECMO: Peripheral Transplantation to Rehost Embedded Linux Kernels > ECMO transplants peripheral drivers into embedded Linux kernels to boot firmware in QEMU. It evaluated 815 firmware images across 20 kernel versions, 37 device models, and 24 vendors; 710 reached a user-space shell. - Authors: Muhui Jiang; Lin Ma; Yajin Zhou; Qiang Liu; Cen Zhang; Zhi Wang; Xiapu Luo; Lei Wu; Kui Ren - Venue: Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security - Status: Conference paper - Publication / posting date: November 12, 2021 - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: May 29, 2021 - arXiv: 2105.14295 - Reviewed arXiv version: v2 - DOI: 10.1145/3460120.3484753 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers embedded Linux firmware across differing SoCs, QEMU kernel rehosting, kernel crash analysis, rootkit forensics, and kernel fuzzing. #### Why it fits this collection It presents a firmware rehosting technique that enables dynamic analysis of embedded Linux systems. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### Automated Dynamic Firmware Analysis at Scale: A Case Study on Embedded Web Interfaces > The paper emulates firmware images and uses static and dynamic tools to find vulnerabilities in embedded web interfaces. It evaluated 1,925 images from 54 vendors and found vulnerabilities in 185 images. - Authors: Andrei Costin; Apostolis Zarras; Aurélien Francillon - Venue: arXiv - Status: Preprint - Publication / posting date: November 11, 2015 - Date source: First arXiv submission date. - First arXiv submission: November 11, 2015 - arXiv: 1511.03609 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The study covers embedded web interfaces and network services in COTS device firmware, including routers, modems, VoIP phones, and IP/CCTV cameras. Its method is designed for different vendors, devices, and architectures. #### Why it fits this collection It presents a scalable firmware analysis method that combines full-system emulation with static and dynamic vulnerability discovery. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### REx86: A Local Large Language Model for Assisting in x86 Assembly Reverse Engineering > The paper fine-tunes eight local models from CodeLlama, Qwen2.5-Coder, and CodeGemma on 5,981 x86 assembly examples and evaluates their help with binary reverse engineering. - Authors: Darrin Lea; James Ghawaly; Golden Richard; Aisha Ali-Gombe; Andrew Case - Venue: 2025 IEEE Annual Computer Security Applications Conference (ACSAC) - Status: Conference paper - Publication / posting date: December 8, 2025 - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: October 23, 2025 - arXiv: 2510.20975 - Reviewed arXiv version: v1 - DOI: 10.1109/acsac67867.2025.00024 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Evaluation covers a curated x86 assembly dataset and a 43-person user case study of line-level understanding and problem solving. #### Why it fits this collection It studies local language-model assistance for understanding and commenting on x86 disassembly used in binary reverse engineering. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### Towards usable automated detection of CPU architecture and endianness for arbitrary binary files and object code sequences > The paper builds open datasets and tools to identify CPU architecture and endianness in binary files and object code. It evaluates classifiers on executable code sections, reporting over 98% accuracy. - Authors: Sami Kairajärvi; Andrei Costin; Timo Hämäläinen - Venue: Proceedings of the Tenth ACM Conference on Data and Application Security and Privacy - Status: Conference paper - Publication / posting date: March 16, 2020 - Date source: Published date in the Crossref record for the DOI listed on arXiv. - First arXiv submission: August 15, 2019 - arXiv: 1908.05459 - Reviewed arXiv version: v1 - DOI: 10.1145/3374664.3375742 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Classifier results use code sections from executable binary files. #### Why it fits this collection Identifying the correct instruction set and endianness helps reverse-engineering tools interpret binary code accurately. #### Publication and review notes The DOI comes from the arXiv record, and the venue and date from Crossref. #### Primary sources 1. 2. ### CEBin: A Cost-Effective Framework for Large-Scale Binary Code Similarity Detection > CEBin combines code embeddings to shortlist candidate functions with pairwise comparison to detect similar binary code, including vulnerable functions. - Authors: Hao Wang; Zeyu Gao; Chao Zhang; Mingyang Sun; Yuchen Zhou; Han Qiu; Xi Xiao - Venue: arXiv - Status: Preprint - Publication / posting date: February 29, 2024 - Date source: First arXiv submission date. - First arXiv submission: February 29, 2024 - arXiv: 2402.18818 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations The paper evaluates CEBin on three binary code similarity datasets and a large-scale benchmark for 1-day vulnerability detection. It reports finding similar functions among millions of candidates in seconds, with 85.46% recall on the vulnerability task. #### Why it fits this collection It studies large-scale binary code similarity detection and its use in finding functions similar to vulnerable code. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### HELIOS: Hierarchical Graph Abstraction for Structure-Aware LLM Decompilation > HELIOS gives an LLM a hierarchical summary of binary control flow and function calls alongside decompiler output, with optional compiler feedback. It evaluates compilability and functional correctness. - Authors: Yonatan Gizachew Achamyeleh; Harsh Thomare; Mohammad Abdullah Al Faruque - Venue: arXiv - Status: Preprint - Publication / posting date: January 21, 2026 - Date source: First arXiv submission date. - First arXiv submission: January 21, 2026 - arXiv: 2601.14598 - Reviewed arXiv version: v2 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evaluation covers HumanEval-Decompile on x86_64 with Gemini 2.0 and GPT-4.1 Mini, plus six architectures from x86, ARM, and MIPS. #### Why it fits this collection It addresses binary decompilation for reverse engineering by using program structure to help generate recompilable, functionally correct code. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### kTrans: Knowledge-Aware Transformer for Binary Code Embedding > kTrans uses a knowledge-aware Transformer to embed binary code. It evaluates the embeddings through outlier detection and visualization, and on binary code similarity, function type recovery, and indirect call recognition. - Authors: Wenyu Zhu; Hao Wang; Yuchen Zhou; Jiaming Wang; Zihan Sha; Zeyu Gao; Chao Zhang - Venue: arXiv - Status: Preprint - Publication / posting date: August 24, 2023 - Date source: First arXiv submission date. - First arXiv submission: August 24, 2023 - arXiv: 2308.12659 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - Code: - BibTeX: - Catalog page: #### Scope and limitations Covers binary code and three downstream tasks: binary code similarity detection, function type recovery and indirect call recognition, with reported improvements of 5.2%, 6.8% and 12.6%. #### Why it fits this collection It applies binary code embeddings to reverse-engineering tasks. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### Automated Attack Synthesis by Extracting Finite State Machines from Protocol Specification Documents > Extracts protocol FSMs from RFC prose using technical word representations, zero-shot text mapping, and rules, then uses the extracted FSMs to synthesize attacks. - Authors: Maria Leonor Pacheco; Max von Hippel; Ben Weintraub; Dan Goldwasser; Cristina Nita-Rotaru - Venue: IEEE Symposium on Security and Privacy 2022 - Status: Conference accepted - Publication / posting date: February 18, 2022 - Date source: First arXiv submission date; the arXiv comment names the venue. - First arXiv submission: February 18, 2022 - arXiv: 2202.09470 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations Evaluates FSM extraction on RFCs for six protocols: BGPv4, DCCP, LTP, PPTP, SCTP, and TCP. Attack synthesis case studies cover TCP and DCCP. #### Why it fits this collection Reconstructs protocol state machines from prose specifications for security analysis. #### Publication and review notes The arXiv comment reads: To appear in IEEE Security and Privacy, 2022 #### Primary sources 1. ### ReF Decompile: Relabeling and Function Call Enhanced Decompile > ReF Decompile relabels jump targets and uses function calls to recover variable information when converting binary code to source code. It was evaluated on the HumanEval-Decompile Benchmark. - Authors: Yunlong Feng; Bohan Li; Xiaoming Shi; Qingfu Zhu; Wanxiang Che - Venue: arXiv - Status: Preprint - Publication / posting date: February 17, 2025 - Date source: First arXiv submission date. - First arXiv submission: February 17, 2025 - arXiv: 2502.12221 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers binary code decompilation on the HumanEval-Decompile Benchmark, with comparisons to similar methods and a reported performance of 61.43%. #### Why it fits this collection Recovering source code and program logic from binaries is a reverse engineering task. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### Extracting Protocol Format as State Machine via Controlled Static Loop Analysis > The paper extracts protocol message formats from parser code by analyzing parsing loops as state machines. It evaluates format inference and the use of the extracted machines in protocol fuzzers. - Authors: Qingkai Shi; Xiangzhe Xu; Xiangyu Zhang - Venue: arXiv - Status: Preprint - Publication / posting date: May 22, 2023 - Date source: First arXiv submission date. - First arXiv submission: May 22, 2023 - arXiv: 2305.13483 - Reviewed arXiv version: v4 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The analysis targets protocols with constraint-enhanced regular-expression formats parsed by finite-state machines. Reported results include over 90% precision and recall in five minutes, 20%–230% higher fuzzer coverage, and ten additional zero-days detected. #### Why it fits this collection It reverse engineers protocol message formats from parser implementations and uses the recovered state machines to improve fuzzing. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1. ### Assessing LLMs in Malicious Code Deobfuscation of Real-world Malware Campaigns > The paper evaluates four LLMs on deobfuscating real-world malicious scripts from the Emotet malware campaign and examines their use in reverse engineering. - Authors: Constantinos Patsakis; Fran Casino; Nikolaos Lykousas - Venue: arXiv - Status: Preprint - Publication / posting date: April 30, 2024 - Date source: First arXiv submission date. - First arXiv submission: April 30, 2024 - arXiv: 2404.19715 - Reviewed arXiv version: v1 - Sources reviewed: 2026-11-06 - Added to the catalog: 2026-11-06 - Original paper: - PDF: - BibTeX: - Catalog page: #### Scope and limitations The evaluation covers four LLMs and malicious scripts from the Emotet campaign. #### Why it fits this collection Deobfuscating malicious scripts helps researchers understand code behavior during malware reverse engineering. #### Publication and review notes The date and venue come from the arXiv record. #### Primary sources 1.