I’m not really sure why Nintendo went all out with these games, considering that these are just ports of NES games.
Indeed. I’ve wondered that about a lot of Nintendo’s copy-protection efforts. As the creator of an emulator for this system (which is the GBA, though the article title is a little confusing), the author is qualified to state that other games for it didn’t receive such measures. I assume it was an irrational decision, but … well, I guess I’ll never know.
Given that the games were ports from a different system and more likely than not involved a different toolchain from usual GBA development, it’s possible that some of these differences were not deliberately engineered as anti-emulation measures.
I would have thought that, but it’s hard to imagine what else the reliance on prefetch behavior could possibly have been. If I were trying to come up with a subtle thing that a real processor does, that an emulator usually doesn’t, I could hardly ask for a better one. And even if self-modifying code were useful in this engine for some reason, this one really doesn’t seem like it could be.
I did say some of these differences and that was what I meant. #2, #4, and #5 sound like anti-emulation measures to me. #1, #3, and #6 don’t especially.
I sometimes find it hard to ascribe intent to code but that’s probably because I’m bad at reversing :)
Makes sense. :)
Could it be that some of these were anti-cheating measures, ie to block things like Game Genie?
I could definitely see #2 (code in VRAM) being intended for that. The GBA was the last Nintendo system that was amenable to the old-style Game Genie implementation strategy, since the program ROM is executed directly out of the cartridge rather than copying it to RAM first, giving the cheat hardware a chance to selectively interpose on some reads and not others. Running code out of VRAM would make that harder, especially if it validated a checksum first.
I don’t see the other things described here as relevant to cheating devices, but of course I can’t be sure.