4 ms·

Classic NES Series Anti-Emulation Measures

161 points by jpfau 12y ago

michielvoo 12y ago
The STM to DMA registers (using a single CPU instruction to trigger DMA) seems like a valid optimization, unrelated to piracy prevention.
- centizen 12y ago
  It certainly seems valid, but in context of all of the other protections it's difficult to say for sure if is or not. But considering it either hasn't been used in other games, or at least infrequently enough this emulators author has never seen it before, I'm leaning towards it being another protection.
  - ianferrel 12y ago
    Or they upgraded their compiler/enabled more optimization. Combining sequential writes into an STM is a standard optimization.
- kstenerud 12y ago
  With STMIA it's an understandable optimization, but nobody would expect STMDA to work the way it does. That would require careful testing and a deliberate choice to use the weird one even though it feels counterintuitive.
  - pm215 12y ago
    The order is guaranteed by the architecture though (not merely by the implementation), provided the target is Device or Strongly Ordered memory. ("For a VLDM, VSTM, LDM and STM instruction with a register list that does not include the PC, all registers are accessed in ascending address order for Device accesses with the non-Reordering attribute." -- v8 ARM ARM.) So you don't need to test at all, you can just rely on the documentation to tell you it works. Incidentally, the note "Since the write is done with one instruction, a DMA cannot preempt the CPU in the middle of the writes" from the article is likely not correct. The STM may be only one insn but it may generate multiple memory accesses to the bus, so it's quite plausible that a DMA device might get accesses in between words. (Of course RAM is usually mapped Normal in which case caches and store buffers will be heavily reordering it anyhow, so nobody relies on ldm/stm ordering here.)
mschuster91 12y ago
Using stuff like the pipeline stage is really bad imo, because it may prevent your game from running successfully if it is decided on a later stage to either upgrade the internal hardware (like it was done with the shitload of PS3 variants) or it is decided years later that the successor console should be able to play legacy platform games.
- klez 12y ago
  I suppose that, since the cartridge was developed by Nintendo, maybe they knew there weren't going to be such hardware upgrades. Or they were just shortsighted.
- JonathonW 12y ago
  The first of these games was released in February 2004, late in the GBA's product cycle. At that point, the Nintendo DS hardware would've already been pretty much finalized (it released in Nov 2004), so they already knew what things looked like for backwards compatibility (the DS includes the GBA's ARM7 processor).
AshleysBrain 12y ago
This doesn't seem to me to be evidence of deliberate anti-emulation features - just imagine a hastily written port by relatively inexperienced developers who don't know about these quirks, and then it could be said: #1 - memory mirroring - accidental bug that doesn't matter since hardware ignores those bits #2 - code in vram - possible technique to save memory in another memory area? #3 - STM to DMA - shortcut to DMA that "just worked" without the original developers knowing the CPU write ordering #4 - save type faking - just a library bug that breaks the emulator heuristics? #5 - prefetch abuse - idk, maybe a legit attempt to prevent reverse engineering? Don't really know enough to comment if there's a reasonable purpose for it #6 - audio FIFO irregularities - just a bug in the emulator? How many C/C++ devs accidentaly rely on undefined behavior or specific x86 quirks? It's really easy to do, and doubly so if you're targeting a single exact hardware configuration. I'm sure it's easy to see these as hostile attempts to make emulator developer's lives harder, but I think they could just as easily be accidents, especially with a complex project like porting NES games to GBA hardware. On the other hand, I dunno, maybe Nintendo pull out all the stops to try to prevent reverse engineering and deliberately use these kind of tricks, but really, they'd go the extra mile for old NES game ports? Having said that, still a great article for covering some fascinating hardware quirks and the challenges of writing a bug-compatible emulator!
- hibikir 12y ago
  It's not as if it's a defense against emulating the consoles on a PC: That's not really a problem worth investing time into. However, those tricks also work against bootleg hardware, which can be seen as emulation. It even works against counterfeit cartridges, in the case of the save game trick. DS games also come with copy protection to stop people from running it in cartridges that run gmaes off of images, like the R4. In that case, the product the pirates offered was actually better than buying an original cartridge: I could buy 20 games and carry a case of games, or keep them al in a single micro SSD card, and switch games at will from the boot menu.
- cdr 12y ago
  > This doesn't seem to me to be evidence of deliberate anti-emulation features - just imagine a hastily written port by relatively inexperienced developers who don't know about these quirks If it were one thing, maybe, but six things done in almost no or no other games repeated across (presumably) thirty ported games? Infinitesimally unlikely. Also, these were done by Nintendo Japan - how likely is it that they're "relatively inexperienced developers writing hasty ports". These tricks would seem the hallmark of very experienced developers who know the hardware intimately.
frozenport 12y ago
>>I’m not sure why they put all of this effort into causing trouble for emulator developers in this one specific case, I know why! If went to bazaar in 90s Russia you would see these '40-in-one' video-game cartridges which were a bunch of normal bootleg games linked together by a bootscreen. You could imagine the NES emulator falling under the same category. Sometimes emulators were sold on CDs. http://i.imgur.com/dJ142.jpg?1 http://i.imgur.com/dJ142.jpg?1
- freshyill 12y ago
  There were actually mall kiosks in the US that sold similar things that actually had pirated copies of Nintendo's first-party games. This was either late '90s or early 2000s.
- nogridbag 12y ago
  Ah memories. I had one of those gold NES honey bee adapters with a 250 in 1 cartridge we got from a Chinese friend. At least a quarter of the games were dups with minor differences and we paid $250 for it, haha. At the time it seemed like a good deal!
  - vlunkr 12y ago
    Yes I played one of these as well that a friend got at the mall. Except I would say about 3/4 of the games were clones, usually with some terrible color palette swap. He bought it in the US though, I can't believe a product like that made it to the market. Especially since every game on there was pirated.
- lmm 12y ago
  Sure, but these are NES games; the ROMs for all of them are already on the internet. This is putting security locks on the barn door decades after the horse has bolted.
glinscott 12y ago
I wouldn't say the GBA was too forgiving about mistakes. You had very limited resources, and sometimes needed some tricks to get things running acceptably. I do remember a few things like a divide by zero in a game that ended up jumping off into the middle of RAM and by luck, the game just happened to continue. But the examples from the article seem to be on purpose. 2) Code in VRAM was sometimes faster than executing code from the ROM, due to waitstates. This was used on the Nintendo DS as well. There was a lot of VRAM, and it was 0-waitstate, while your instruction cache was tiny. 3) STM to DMA registers was an optimization that was used fairly commonly, at least in homebrew games 5) This is definitely anti-emulator code :)
- ConnorG 12y ago
  Do you happen to know anywhere to read further on the topic of programming tricks used in GBA (or any platform) games? I always find these things really interesting.

161 points by jpfau 12y ago

The STM to DMA registers (using a single CPU instruction to trigger DMA) seems like a valid optimization, unrelated to piracy prevention.

centizen 12y ago
It certainly seems valid, but in context of all of the other protections it's difficult to say for sure if is or not. But considering it either hasn't been used in other games, or at least infrequently enough this emulators author has never seen it before, I'm leaning towards it being another protection.
- ianferrel 12y ago
  Or they upgraded their compiler/enabled more optimization. Combining sequential writes into an STM is a standard optimization.
kstenerud 12y ago
With STMIA it's an understandable optimization, but nobody would expect STMDA to work the way it does. That would require careful testing and a deliberate choice to use the weird one even though it feels counterintuitive.
- pm215 12y ago
  The order is guaranteed by the architecture though (not merely by the implementation), provided the target is Device or Strongly Ordered memory. ("For a VLDM, VSTM, LDM and STM instruction with a register list that does not include the PC, all registers are accessed in ascending address order for Device accesses with the non-Reordering attribute." -- v8 ARM ARM.) So you don't need to test at all, you can just rely on the documentation to tell you it works. Incidentally, the note "Since the write is done with one instruction, a DMA cannot preempt the CPU in the middle of the writes" from the article is likely not correct. The STM may be only one insn but it may generate multiple memory accesses to the bus, so it's quite plausible that a DMA device might get accesses in between words. (Of course RAM is usually mapped Normal in which case caches and store buffers will be heavily reordering it anyhow, so nobody relies on ldm/stm ordering here.)

mschuster91 12y ago

Using stuff like the pipeline stage is really bad imo, because it may prevent your game from running successfully if it is decided on a later stage to either upgrade the internal hardware (like it was done with the shitload of PS3 variants) or it is decided years later that the successor console should be able to play legacy platform games.

klez 12y ago
I suppose that, since the cartridge was developed by Nintendo, maybe they knew there weren't going to be such hardware upgrades. Or they were just shortsighted.
JonathonW 12y ago
The first of these games was released in February 2004, late in the GBA's product cycle. At that point, the Nintendo DS hardware would've already been pretty much finalized (it released in Nov 2004), so they already knew what things looked like for backwards compatibility (the DS includes the GBA's ARM7 processor).

AshleysBrain 12y ago

This doesn't seem to me to be evidence of deliberate anti-emulation features - just imagine a hastily written port by relatively inexperienced developers who don't know about these quirks, and then it could be said: #1 - memory mirroring - accidental bug that doesn't matter since hardware ignores those bits #2 - code in vram - possible technique to save memory in another memory area? #3 - STM to DMA - shortcut to DMA that "just worked" without the original developers knowing the CPU write ordering #4 - save type faking - just a library bug that breaks the emulator heuristics? #5 - prefetch abuse - idk, maybe a legit attempt to prevent reverse engineering? Don't really know enough to comment if there's a reasonable purpose for it #6 - audio FIFO irregularities - just a bug in the emulator? How many C/C++ devs accidentaly rely on undefined behavior or specific x86 quirks? It's really easy to do, and doubly so if you're targeting a single exact hardware configuration. I'm sure it's easy to see these as hostile attempts to make emulator developer's lives harder, but I think they could just as easily be accidents, especially with a complex project like porting NES games to GBA hardware. On the other hand, I dunno, maybe Nintendo pull out all the stops to try to prevent reverse engineering and deliberately use these kind of tricks, but really, they'd go the extra mile for old NES game ports? Having said that, still a great article for covering some fascinating hardware quirks and the challenges of writing a bug-compatible emulator!

hibikir 12y ago
It's not as if it's a defense against emulating the consoles on a PC: That's not really a problem worth investing time into. However, those tricks also work against bootleg hardware, which can be seen as emulation. It even works against counterfeit cartridges, in the case of the save game trick. DS games also come with copy protection to stop people from running it in cartridges that run gmaes off of images, like the R4. In that case, the product the pirates offered was actually better than buying an original cartridge: I could buy 20 games and carry a case of games, or keep them al in a single micro SSD card, and switch games at will from the boot menu.
cdr 12y ago
> This doesn't seem to me to be evidence of deliberate anti-emulation features - just imagine a hastily written port by relatively inexperienced developers who don't know about these quirks If it were one thing, maybe, but six things done in almost no or no other games repeated across (presumably) thirty ported games? Infinitesimally unlikely. Also, these were done by Nintendo Japan - how likely is it that they're "relatively inexperienced developers writing hasty ports". These tricks would seem the hallmark of very experienced developers who know the hardware intimately.

frozenport 12y ago

>>I’m not sure why they put all of this effort into causing trouble for emulator developers in this one specific case, I know why! If went to bazaar in 90s Russia you would see these '40-in-one' video-game cartridges which were a bunch of normal bootleg games linked together by a bootscreen. You could imagine the NES emulator falling under the same category. Sometimes emulators were sold on CDs. http://i.imgur.com/dJ142.jpg?1 http://i.imgur.com/dJ142.jpg?1

freshyill 12y ago
There were actually mall kiosks in the US that sold similar things that actually had pirated copies of Nintendo's first-party games. This was either late '90s or early 2000s.
nogridbag 12y ago
Ah memories. I had one of those gold NES honey bee adapters with a 250 in 1 cartridge we got from a Chinese friend. At least a quarter of the games were dups with minor differences and we paid $250 for it, haha. At the time it seemed like a good deal!
- vlunkr 12y ago
  Yes I played one of these as well that a friend got at the mall. Except I would say about 3/4 of the games were clones, usually with some terrible color palette swap. He bought it in the US though, I can't believe a product like that made it to the market. Especially since every game on there was pirated.
lmm 12y ago
Sure, but these are NES games; the ROMs for all of them are already on the internet. This is putting security locks on the barn door decades after the horse has bolted.

glinscott 12y ago

I wouldn't say the GBA was too forgiving about mistakes. You had very limited resources, and sometimes needed some tricks to get things running acceptably. I do remember a few things like a divide by zero in a game that ended up jumping off into the middle of RAM and by luck, the game just happened to continue. But the examples from the article seem to be on purpose. 2) Code in VRAM was sometimes faster than executing code from the ROM, due to waitstates. This was used on the Nintendo DS as well. There was a lot of VRAM, and it was 0-waitstate, while your instruction cache was tiny. 3) STM to DMA registers was an optimization that was used fairly commonly, at least in homebrew games 5) This is definitely anti-emulator code :)

ConnorG 12y ago
Do you happen to know anywhere to read further on the topic of programming tricks used in GBA (or any platform) games? I always find these things really interesting.