Skip to content

Game Identification

This page details the hashing method used for each supported system. First, systems where the entire game file is hashed are listed, and later systems where the RA hash may differ from the file MD5.

Systems that Hash the Entire Filelink

Apple IIlink

NOTE: As saving and other manipulations can mutate disk data, local copies of loaded images are required to ensure that their hashes do not change across sessions.

Atari 2600link

Atari 7800link

Atari Jaguarlink

ColecoVisionlink

GameBoylink

GameBoy Colorlink

GameBoy Advancelink

GameGearlink

MSXlink

NOTE: As saving mutates disk data, local copies of loaded images are required to ensure that their hashes do not change across sessions. We do not believe this is working, but have yet to find a game where saving to disk actually works.

N64link

NOTE: This may result in three unique hashes for each game. The z64 extension is big endian (ABCD). The n64 extension is little endian (DCBA). And the v64 extension is middle endian (BADC).

NeoGeo Pocket [Color]link

PCEngine (TurboGrafx16)link

PC-8001 / PC-8801link

NOTE: As saving and other manipulations can mutate disk data, local copies of loaded images are required to ensure that their hashes do not change across sessions.

Pokemon Minilink

Sega 32Xlink

Sega Master Systemlink

Sega MegaDrive (Genesis)link

Vectrexlink

VirtualBoylink

WonderSwan [Color]link

Systems that Hash a Portion of the Filelink

3DOlink

The volume header (first 132 bytes of sector 0) and the contents of the LaunchMe file are hashed.

Arcadelink

The filename string without the extension (path/galaga.zip -> galaga) is hashed. It is case-sensitive.

Atari Lynxlink

If the ROM starts with LYNX\0, the first 64 bytes are ignored and the remaining file contents are hashed. If the ROM does not start with LYNX\0, the entire file is hashed.

Famicom Disk Systemlink

If the ROM starts with FDS\1a($46 $44 $53 $1A), the first 16 bytes are ignored and the remaining file contents are hashed. If the ROM does not start with FDS\1a ($46 $44 $53 $1A), the entire file is hashed.

NOTE: As saving mutates disk data, local copies of loaded images are required to ensure that their hashes do not change across sessions.

NESlink

If the ROM starts with NES\1a($4E $45 $53 $1A), the first 16 bytes are ignored and the remaining file contents are hashed. If the ROM does not start with NES\1a ($4E $45 $53 $1A), the entire file is hashed.

Nintendo DSlink

An NDS ROM has a 0x160 byte header. In this header are pointers to icon/title information and to the boot code for both processors. The hash method combines the header, the two pieces of boot code, and the icon/title information and hashes the result.

  • The icon/title information is 0xA00 bytes starting at the address stored in the header at $68
  • The arm9 code address is stored at $20 in the header, and the size is stored at $2C in the header
  • The arm7 code address is stored at $30 in the header, and the size is stored at $3C in the header

PCEngine CDlink

The boot code and disc title are hashed as follows: Read 128 bytes from sector 1 of the data track (PCE predates ISO-9660, so there's no file system to read). If "PC Engine CD-ROM SYSTEM" does not exist at 32 bytes into the data, discard as invalid. Copy the last 22 bytes of the data into a buffer. This is the disc title, and usually identifies the game. The first three bytes of the data are a little-endian sector index for the boot code. The fourth byte is the number of sectors that the boot code occupies. The boot code is appended to the buffer (N sectors, starting at sector X) * The buffer is hashed.

PC-FXlink

The boot code and disc title are hashed as follows: Read 32 bytes from sector 0 of the data track (PC-FX predates ISO-9660, so there's no file system to read). If "PC-FX:Hu_CD-ROM" was not read, discard as invalid. Read 128 bytes from sector 1 of the data track into a buffer. This is the volume header and includes the disc title. The 32-bit value at 32-bytes into the buffer is the first sector of the boot code. The 32-bit value at 36-bytes into the buffer is the number of sectors that the boot code occupies. The boot code is appended to the buffer (N sectors, starting at sector X) * The buffer is hashed.

PlayStationlink

The primary executable and its name are hashed as follows: The SYSTEM.CNF file is loaded and parsed. The primary executable is identified by the BOOT= line within. The primary executable name (and it's path) are extracted from SYSTEM.CNF and written to a buffer. The contents of the primary executable are appended to the buffer. The buffer is hashed.

Sega CD / Sega Saturnlink

The first 512 bytes of track 0 are hashed. This contains the volume header and ROM header.

Immediately following those 512 bytes are an arbitrary amount of code that validates the region and loads the primary executable. Without processing the code, we cannot determine what additional file(s) to hash, so this was determined to be sufficient as an alternative to hashing the entire CD.

SNESlink

If the size of the file is 512 bytes more than a multiple of 8KB, the first 512 bytes are ignored and the remaining file contents are hashed. If the size of the file is not 512 bytes more than a multiple of 8KB, the entire file is hashed.

Changeloglink

Last 10 changes on this page:

  • [2020-06-13 17:45] Jamiras: add PC-FX
  • [2020-06-07 11:41] Jamiras: update for new systems
  • [2020-05-07 07:28] meleu: Updated Game Identification (markdown)
  • [2020-05-06 19:52] meleu: alphabetical order
  • [2020-05-06 13:22] meleu: fix heading
  • [2020-05-06 13:22] meleu: group by hashing methods
  • [2019-12-01 17:57] Jamiras: more detail in DS hashing algorithm
  • [2019-12-01 17:54] Jamiras: document Nintendo DS hashing algorithm, add entries for Jaguar, WonderSwan, and Pokemon mini
  • [2019-11-02 15:02] Jamiras: document PCEngine-CD hashing algorithm
  • [2019-09-20 18:57] Jamiras: update Sega CD