Hash records

This site hosts no ROM files. It records which URL served which file, with which hash, on which date. That carries less legal risk than mirroring and is more useful than mirroring.

Records

0 records

Nothing recorded yet. Only hashes computed here from a file actually downloaded are accepted, so this grows one verified entry at a time.

Checking a file

macOS / Linux

shasum -a 256 <file>
# or
sha256sum <file>

Windows (PowerShell)

Get-FileHash .\<file> -Algorithm SHA256

Windows (cmd)

certutil -hashfile <file> SHA256

What this catches, and what it does not

Catches	Corruption in transit, substitution by an intermediate mirror, and files from sites impersonating the distributor. Flashing a corrupted ROM is a common way to end up in the EDL case, and this removes most of it.
Does not catch	A compromised upstream. If what was distributed was already malicious when recorded, the hash matches. For a build produced by a small independent team, no third party can extend a signature chain down to your machine.

A hash secures the path from the distributor to you. Whether the distributor deserves that trust is a separate question, and not one this site can answer for you.

Record format

/data/roms.json is the data. One entry looks like this.

{
  "id": "…",
  "device": "…",
  "rom": "…",
  "file": "…",
  "source_url": "https://(upstream URL)",
  "sha256": "(64 hex)",
  "size": 0,
  "verified_at": "2026-08-09"
}

mirror_url and hashes transcribed from upstream are rejected by scripts/validate.mjs — the policy lives in code because policies get forgotten. Records are produced by scripts/hash-rom.sh, which streams the file through sha256 without storing it, so a 9 GB ROM costs no disk.