I have a collection of ROM files for the NES, SNES, Nintendo 64 and others. These ROMs match exactly those games that I own or owned growing up.

Recently, I found out about the "No-Intros" database, and thus made a script to import all the filenames and hashes into my database. I then looped through all my ROM files and checked if they match their data.

None of them do.

I have very carefully double-checked that it's not a bug in my script. My database does contain the correct information from their database.

I do it like this:

  1. Pick a ROM file, such as: Tetris (Europe).nes
  2. Calculate the SHA1 hash sum for the file, in this case: 817169b819aadaae52cce6b3d8d2fc24270566d7
  3. Check what SHA1 hash No-Intros claims that this exact file name has in my database: 66883b9eddec933e36b6bff0479cefd2434ffb40
  4. Conclusion: They don't match!

Apparently, every single ROM I have is modified somehow.

Now, I vaguely know that many ROMs circulating over the decades have been "dirty" ones with modified headers (but otherwise identical game contents), messing up the hashes. That's likely what's happening here. I also vaguely know about programs that can scan and "repair" dirty ROMs to make them clean. However, I feel very, very scared about running software on my computer, so this would have to be a last resort, plus I'm not sure I can find any usable such software.

If possible, I would like to "clean" the ROMs myself with some simple logic or some very trustworthy self-contained script or something. But even more than that, I would like to know if my guess is even right at all.

I assume that No-Intros' data is correct, or at least is not so massively incorrect as to give the wrong hashes for every single ROM I own.

This makes me feel uneasy. I hate the thought of having some kind of "hacked" ROMs where some dude in 1997 or something modified the game slightly so that it runs differently. I want to be sure that I have only the exact data on the cartridges. Nothing more and nothing less.

This is all very confusing to me since my ROMs follow a very strict naming convention. For example: Zelda II - The Adventure of Link (Europe) (Rev B).nes. It seems unlikely (although definitely possible still) that somebody would go out of their way to rename bad ROMs to such a strict and specific naming scheme.

What do you suggest?

  • 1
    Two possible reasons: 1. Every ROM file you have was modified, 2. You are doing something wrong calculating the hash. Any other idea? And, by the way, I don't understand you feeling about "your ROMs" - I guess you have downloaded them from somewhere, you don't OWN them physically, do you? Sep 16 '20 at 11:42
  • A good idea could be to ask the people running that website exactly how they calculates the SHA1.
    – UncleBod
    Sep 16 '20 at 11:47
  • 2
    It's possible that the software you used to rip/dump your ROMs stored the metadata differently than the software No-Intro used. Maybe there's even a timestamp stored in the file. First, you would need to learn their procedure and follow it exactly. Or, figure out how to isolate just the raw data so you can hash it, and hope No-Intro has done the same! This is why sidecar files are useful. Sep 16 '20 at 12:41
  • 1
    Just to throw in my 2 cents, are the ROM images just binary dumps of the original ROMS, or do they have a 'format' where there might be header data? If so, the NoIntros hash might be including or not including the headers in the calculation.
    – Geo...
    Sep 16 '20 at 13:38
  • 2
    Cinemaware permits its titles to be distributed for free and it made several NES games. So, why not download a copy of e.g. Defender of the Crown that is known to match the no-intro hash and then test: (i) whether it matches per your script; and (ii) if so, how it differs from your own copy? That is, hoping you have at least one Cinemaware title in your collection; I'm not aware of any other formerly-commercial NES titles that are now free to distribute but they may exist.
    – Tommy
    Sep 16 '20 at 14:07

There are multiple header formats for NES and SNES ROMs. For SNES and N64 ROMs there are also byte ordering issues. Unless you know precisely what source ROMs they used to make the database you can only use trial and error to find the matching ripper settings.

The simplest option is probably to download No Intro ROM packs that others have assembled and discard the ROMs you do not wish to keep (e.g. for copyright reasons). BitTorrent is a safe and easy way to do that and the packs are easily available.

Otherwise the only option is to try every combination of ripper settings until you find the ones they were using. Looking at their web site they do not seem to have documented the settings anywhere, or even clearly which version of the games they ripped in some cases. It's not uncommon for there to be multiple retail versions of the game for a particular region.


To elaborate on what user said:

  1. Have you tried the hashes from DAT-o-MATIC instead? Those are what I go by.

  2. In my experience, NES hashes are typically calculated against the ROM data with the iNES header stripped off, so the hashes don't depend on header values which vary from dumper to dumper and may have been modified to automatically trigger emulator-specific compatibility tweaks.

    If I remember correctly, it's the first 16 bytes you need to skip on those.

    It's also possible your ROMs are in a different format, though less likely.

  3. N64 ROMs can take four different forms, depending on how the dumper laid out the data it retrieved. (byte-swapped, word-swapped, both, or neither)

There's an open-source swiss army knife for ROMs named uCON64 which can serve pretty much any ROM reformatting needs you might have. (For example, see ucon64 --help --n64 for more info on byte-swapping N64 ROMs.)

(It does technically also do hash checking, but its built-in checksum verification and "rename to match filename defined in datfile" (-rdat) functions are archaic, so you'd need something like DatUtil (EXE and source) to convert more modern hash database formats to what it expects.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.