Classic NES Series Anti-Emulation Measures

Emulator countermeasures are so vicious because the stakes are so low.

As it turns out, these games exploit several tricks and undefined behaviors that make emulating them challenging. This appears to be a deliberate attempt to dissuade copying these games. In the interest of accuracy, I have painstakingly investigated, implemented and chronicled all of the unusual things I've found these games to do. [...]

The processor in the Game Boy Advance has a pipeline that has three relevant stages for accurate emulation: fetching, decoding and executing. In the fetching stage, the memory bus is queried for the memory associated with an instruction. This is then passed to the decoding stage, where the processor figures out which instruction it is. Finally, the processor actually executes the instruction. A naïve interpreter may merge all three stages, either for hypothesized speed reasons, or just an uninformed idea of how processors work. mGBA was actually assuming the decoding and execution stages were combined until recently. However, an important observation was made while digging through the Classic NES Series games' code: the game was modifying an instruction that was very close in proximity to where code was being executed already. [...]

What's imperative to understanding what's going on in this block of code is to realize that, once the instruction has been fetched by the pipeline, changing the memory that backs that address is irrelevant. This is similar to how cache coherence works, but is even more stringent. This means that if your pipeline is long enough, the instruction that enters into the pipeline during the write is the one that stores 255. If it's too short, it stores 0. As it turns out, the games will fail to boot if it finds the value 0 in register r1, but boots fine if it's 255.

Previously, previously, previously.

Tags: ,

9 Responses:

  1. 1237897941 says:

    Great article about the copy protection on Dungeon Master, which used a physical "fuzzy bit" on the disk which would return random values when read but could not be copied by available hardware at the time.

  2. Owen Davis says:

    Great article about the copy protection on Dungeon Master, which used a physical "fuzzy bit" on the disk which would return random values when read but could not be copied by available hardware at the time.

  3. Ewen McNeill says:

    Relatedly, there was an interesting talk at this year's CCC conference (31C3) about Preserving Arcade Games, which amongst other things used battery backed RAM to keep key data without which the game will not work (and thus are dying of old age) and used a processor with an in-chip decryption while reading from ROM. The video recording from it is already online (I've watched it, and recommend it).

    Exploiting the CPU pipeline length to detect accuracy of environment is a pretty cool trick.

    Ewen

  4. When I interviewed at Blizzard about 15 years ago one of the programmers there I talked to has written an Apple ][ emulator. We ended up discussing how the copy protection I did for the Apple version of Return of Heracles gave the emulator fits.

  5. When I interviewed at Blizzard about 15 years ago one of the programmers there I talked to has written an Apple ][ emulator. We ended up discussing how the copy protection I did for the Apple version of Return of Heracles gave the emulator fits.

  • Previously