# retroReversing pairs a link directory with a browser File Lab

> The RetroReversing project is a Jekyll site cataloguing retro game development and reverse engineering resources, with a browser based File Lab that runs R2 and Pyre against loaded executables.

**RetroReversing/retroReversing** — Awesome website for reverse engineering retro games:

- Repository: https://github.com/RetroReversing/retroReversing
- Website: https://www.retroreversing.com
- Stars: 717 · Forks: 304
- Language: JavaScript
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/retroreversing-retroreversing

## A link directory that ships its own analysis tools

RetroReversing is described in its own README as a curated list of retro game development and reverse engineering resources, tools, docs and related projects, published as a GitHub Pages site at https://www.retroreversing.com/. The site is the point. Its collections cover Games with Debug Symbols, Development Kits under hardware, Software Development Kits, Games Source Code, Game Engines, Game File Formats and Game Console Hardware Architecture, and each console gets a page of its own, from the NES and Game Boy through the Mega Drive, Saturn, Dreamcast, PlayStation 1 and 2, the Nintendo 64, Gamecube, Wii, 3DS, WiiU, PSP and Xbox. Alongside the reference material the repository carries a working tool: a File Lab that loads an executable in the browser and runs two engines over it. So this is not a static link dump. It is a Jekyll site with a custom front end bolted on, which changes how you should judge it.

## Inside the File Lab, three engines and one bundled spec set

The File Lab is built from three separately compiled plugins, named in the deployment workflow as R2, Pyre and the Kaitai File Lab plugin, each with its own npm lockfile under public/js/file-lab/plugins. The README is specific about how the engines are fed. PS2 EE ELF files use a bundled R5900 spec, and IOP IRX modules use bundled MIPS32 specs, so the architecture the parser assumes is decided by the file format rather than chosen by the user. Both engines download external runtime assets at analysis time, and the File Lab depends on the root coi-serviceworker.js to establish cross-origin isolation on /file-lab/. That dependency has a consequence worth stating plainly: the analysis path is not self-contained, and a deployment without proper cross-origin isolation headers will fail to load the engines rather than degrade. The site also ships a bundled Wasmer runtime and a Kaitai viewer, and the deployment job checks those against the built output before publishing.

## Building the plugins and the site from the repository root

The plugins are not prebuilt artifacts checked into the repository, so a local build has to compile them before Jekyll runs. The README gives a single loop that installs dependencies and builds each plugin, then builds the site and validates the result. Generated dist/ directories stay out of version control, which is why this step is not optional for anyone who wants the File Lab to work.

```bash
for plugin in r2 pyre kaitai-viewer; do
  npm ci --prefix "public/js/file-lab/plugins/$plugin" &&
  npm run build --prefix "public/js/file-lab/plugins/$plugin" || exit 1
done
bundle exec jekyll build
node scripts/validate-file-lab-assets.mjs _site
```

Each plugin installs with npm ci so the lockfile decides the dependency tree, and the build stops at the first failure because of the exit 1 in the loop. The final line runs a validation script against the generated _site directory, so a build that produced missing or stale assets is reported before you look at the site.

## Ruby 3.3, the gems, and a live preview

Local development targets Ruby 3.3 because Ruby 3.2 is end of life. On macOS the README points at the prebuilt Homebrew formula as the easy route:

```bash
brew install ruby@3.3
```

If you would rather pin an exact patch release, the rbenv path is the alternative:

```bash
brew install rbenv ruby-build
rbenv install 3.3.12
rbenv local 3.3.12
```

Once the interpreter is right, the site is a standard Bundler project:

```bash
bundle install
```

The preview is the usual Jekyll server with live reload attached, run from the project root as `jekyll serve --livereload`, and the README then points the reader at a local address to open in a browser.

## Pages deployment runs the plugin build, branch builds do not

The Build and deploy Pages workflow is more than a Jekyll publish step. It builds the R2, Pyre and Kaitai File Lab plugins with their npm lockfiles before building Jekyll, and it verifies the published plugin modules, workers, stylesheets, the bundled MIPS and R5900 Pyre specs and the Wasmer runtime against the built files before uploading the Pages artifact. The source is selected in the repository settings under Settings > Pages > Build and deployment by choosing GitHub Actions, and once the workflow sits on the default branch, pushes to that branch deploy the site; it can also be run by hand from the Actions tab. The sharp edge is that branch-based Pages builds do not run the plugin build steps, so a deployment route that skips the workflow gives you a site whose File Lab front end has no compiled engines behind it.

## A visual regression harness for the site's own images

The repository also carries a screenshot testing setup. The Node tooling lives in a package.json named retroreversing-tools, marked private with version 1.0.0 and license UNLICENSED, and it exposes four scripts driven by backstop.config.js: backstop:reference to capture the baseline, backstop:test to compare against it, backstop:approve to accept the differences and backstop:open-report to open the result. Runtime dependencies are @resvg/resvg-js for rasterising SVG and geopattern for the generated background patterns that the theme uses, while backstopjs is a development dependency. The reason a site with this much hand-drawn imagery needs that pipeline is not hard to guess: retro console pages carry dense text layouts and badges, and a text change can reflow them silently.

## Where the project stops and where it points elsewhere

The catalogue is honest about its edges. There is a Future Posts to be written section that lists open assignments for contributors, including the TUME Map Editor, the Psy-Q CD emulation system, Deluxe Paint IV source code, the Cross Products Sega Saturn development kit, an SN64 DEV KIT, Neon64, an Animal Crossing NES emulator hack, Klik & Play, the Rebel Assault source release, a 3DS emulation write-up in C++ and a Jak and Daxter disassembly. That list is an admission that the site is incomplete by design and depends on outside writing. The same is true of the tooling it points at: the console pages link to SegaRetro, Ultra64.ca, the Super Famicom Development Wiki, Codeshop articles in Edge magazine and a set of YouTube channels whose videos the project will embed. The reverse engineering itself happens in other people's tools. The last push was on 2026-10-20, the repository is not archived, and released versions have gone 1.2 in April 2023, 1.3 in August 2024 and 1.4 on 2025-08-30.

## Conclusion

Take retroReversing if you want one bookmark for retro game reverse engineering material and a quick way to inspect a PS2 executable in a browser tab. Leave it if you need a reverse engineering tool you can script, since the site links to those tools rather than wrapping them. Before you rely on it, check three things: that the R2 and Pyre views in /file-lab/ load your own file, that the bundled R5900 and MIPS32 specs match the target you are feeding them, and what licence your own use of the site falls under, since the repository records no licence and the tooling package.json is marked UNLICENSED.

## FAQ

### What is RetroReversing and who is it for?

It is a curated collection of retro game development and reverse engineering resources, tools, docs and related projects, published as a GitHub Pages site at retroreversing.com. The README frames it for retro game development and reverse engineering work, and it indexes consoles, devkits, SDKs, source code and file formats.

### How do I build the RetroReversing site locally?

Use Ruby 3.3, install the gems with bundle install, build the R2, Pyre and Kaitai File Lab plugins from the repository root, then run bundle exec jekyll build and validate the output with node scripts/validate-file-lab-assets.mjs _site. The README states that Ruby 3.2 is end of life and that Ruby 3.3.x should be used for local development.

### Can the RetroReversing File Lab analyse PS2 executables?

Yes. The README says that after deploying you open /file-lab/, load an executable and check the R2 and Pyre views. PS2 EE ELF files use the bundled R5900 spec and IOP IRX modules use bundled MIPS32 specs, and R2 needs the root coi-serviceworker.js for cross-origin isolation on /file-lab/.

### Is there a licence for the RetroReversing project?

The repository records no licence. Its Node tooling package.json is marked private with license UNLICENSED, and the generated plugin dist/ directories stay ignored.

## Sources

- [Issues](https://github.com/RetroReversing/retroReversing/issues)
- [Project website](https://www.retroreversing.com)
- [README](https://github.com/RetroReversing/retroReversing/blob/master/README.md)
- [Releases](https://github.com/RetroReversing/retroReversing/releases)
- [RetroReversing/retroReversing on GitHub](https://github.com/RetroReversing/retroReversing)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/retroreversing-retroreversing