[Tino]

So I was wondering about something. Obviously, in order to hack a game successfully, you'll need to be able to at least alter game data. So what is a good way to figure out which bytes in a ROM do what? The only way I can come up with is just check out pretty much every single byte (or groups of bytes). Are there other ways to go about doing this efficiently (aside of looking at data that others might have gathered, of course)?

If not, that's no problem. I have plenty of time on my hands, anyways!   

edit: I suppose using ASM debugging is an option, but I'm not quite into that stuff yet. I'd first like to get the basics down, then move on to ASM.

[Ryusui]

ASM is the easiest way. Find out what the game loads from where and when, and that's the data.

You can also use ROM corruption. A ROM corruptor selectively tweaks bytes in a ROM; if the game screws up the way you want, then you've struck gold.

[FinS]

You could also learn how to search for cheat codes since cheat codes are just a ram or rom address followed by a piece of data to place there. 

[andlabs]

Or just learn how the hardware works and use that knowledge to figure out how the game works using a disassembler to produce ASM like Ryusui said above.

Example — Mega Drive/Genesis ROMs are raw 68000 boot ROMs loaded at memory space $0, so the longword at $4 is the pointer to the entry point. Longword at $70 is the pointer to horizontal interrupt; $78 is pointer to vertical interrupt. At that point, all I really need to figure out how a game does what is a memory map and hardware documentation. I've done a lot of disassembling so at this point I have quite a bit of all these parts down...

[Tino]

Thanks, guys! I'll be sure to check those things out.

[Gil Galad]

What I do first is figure out the ROM or disk(c) file format first. That helps me section various parts of the file so that I know what type of data they are as best as possible.

For example, if I was working with a NES/FC ROM. I know for starters that the file has up to three parts. Those would be header,RPG-ROM, sometimes CHR-ROM if the game has it. I also read the header and determine information about the file. For iNES and many others, there are many banks in a file. If you have a mapper 1 (MMC1) game, most of those have 16KB sized banks each about $4000h in size. Doing this will tell you the boundries and that most of the time you cannot easily hack past or outside of that bank. Commonly, a lot of the same information would be in one particular bank. Reset code, interrupts, framework for the entire ROM would be on one. You could have an entire audio music driver on another bank. Title screen and other misc things could be on another bank, etc. You just look around and deduce various things one at a time.

Some basic things you could do first is looking for text in a game. Once you find that and everything else on a particular screen. You can use GameGenie codes to find other data, perhaps stats and other things. You can do a lot of this stuff without doing too much assembly hacking right from the beginning. I didn't know assembly languages when I started. There are a lot of basic things you can do, just look in Getting Started on the left menu.

File system games are more difficult to hack and not usually a beginner's project. But it can be done.

They have various files in the disk(c) that are of various size and you can't change the files unless you know what you're doing.


I suggest that you do some research and then you can slowly figure out how to map out a ROM.