5.8 ROM hacking “protection”

For various reasons some that edit ROM images have not wanted their works to be used as a base for a further work and so have attempted to protect their work by technological means; this sort of thing tends to be seen in games that have high level tools made for them which usually means Pokemon, Fire Emblem, Mario platformers and Mario Kart games, Final Fantasy, Advance Wars (kind of), Golden Sun and similar franchises. Other protections can include protections added to a game so those trying to do repros (a term for the carts that have hacked/modified versions of games and are done up to look like originals) can not remove the “if you paid for this then you were ripped off” type screens.

As the rest of the document aims to demonstrate if you have the file in front of you on a machine you control then you can edit it. This means in addition to asking in the readme/release notes (a better method in general), putting a bit of text somewhere or otherwise “signing” (in the classical sense rather than the cryptographic sense) so as to be able to demonstrate origin, a technique used across computing and modern intellectual property fields, you do not have much choice in the matter.

Most of the time in the high levels tools world this edit is a simple flag placed somewhere in the ROM (or one of several places if it is especially advanced) that any GUI tools that want to comply with the standard will read and tell the user that the ROM has been “locked”. Occasionally things will be taken a step further and part of the ROM is broken and then fixed at runtime (usually seen in Scene groups that make intros for games but occasionally seen elsewhere) or a similar technique to the Playstation raw LBA reads approach (conventional filesystem ignored and deferred to elsewhere) was made/hinted at. This is mainly mentioned as some of these techniques can frustrate flash cart operation with several scene trainers on the DS doing as such and some GBA hacks took to changing the header (specifically the 4 bytes reserved at the offset BE hex) in a GBA ROM which most emulators and header viewers did not complain about but carts like the EZFlash 4 did not agree with (maybe as a function of needing the 00 to end a read similar to some of the potential problems discussed in DEADBEEF padding).

Those that tend to be aimed more at reproductions/repros, these tend to be made by well versed hackers and programmers so any method you can dream up is a possibility here. Typically they only care about leaving the credit/if you paid… screens in so they are unlikely to trouble your flash cart, emulator or further hacking work. In the case of the latter many translation teams that seek to protect their work will realise someone might want to change the stats, levels, music and more of the game and as such will tend not to do things like whole binary checks.

Part III
Examples, oddities and techniques. =============================================

Where the previous part was a bit theory heavy and example light this part will largely contain examples of common things, a few examples of less common things, some techniques and concepts that are worth knowing and being able to employ as well as act as a bit of ROM hacking/game development general knowledge dump. On the face of it this part might seem less valuable than previous one but this is aiming to be something of the equivalent to the time you spent a couple of hours messing with something back when that you use to this day as opposed to the hours and hours spent say memorising facts you do not envisage ever having to know again outside of a trivia night.