ROM Corruption

Spikeman

New member
I'm trying to hack a title screen for a GBA game and I have found the palette data and the map data. I have been trying to find the tile data but I think it might be compressed or something. I have heard the term ROM corruption before. I guessed it had to do with filling certain portions of a ROM with random bytes to see if it messes up the game. So I made a simple program to do that but I can't really figure out how to use it to find the title screen data. Any pointers?
 
I believe it goes like this:

1) Backup your rom
2) Corrupt some of the rom
3) Load it up and see if the Title Screen got changed
4) If not, delete the corrupt copy, goto step 1

You keep corrupting different parts of the rom in sequence (this is part of what your corrupter program should do) until you notice a change in the title screen. When you notice a change, make a note of what data you corrupted and go inspect it in a hex editor to try and make sense of it.
 
Ok thanks, that is what I was doing but I had the problem that it would mess up some other parts of the data and I wouldn't even get to the title screen. Eventually I found where the data is. Now I have to figure out how the compression works. I'm almost 100% sure it is compressed because it looks nothing like the tile data does in VBA. Now I guess I need to figure out how it is compressed and how to decompress it, then change the picture, recompress it and insert it right? Will I need to use asm to figure out the compression? I know some asm from implementing a DTE hack (which you helped me with <img src=smilies/magbiggrin.gif>) but I don't know how I would use it to decompress the data.

> You keep corrupting different parts of the rom in sequence
> (this is part of what your corrupter program should do)

I'm kinda confused by what you mean here. Should my program step through and sequentially corrupt the program? I'm asking because once I finish it maybe I will upload it here (can we upload helpful utilities here?)
 
Sorry, can't help you with the compression part. Maybe someone more knowledgeable on the subject will have pity on you <img src=smilies/magbiggrin.gif>

> Should my program
> step through and sequentially corrupt the program?

That's pretty much what I meant. You would basically define how much data to corrupt at a time and where to start corrupting. Then it would go through and corrupt it, one chunk at a time, until you told it to stop. Of course you do have to decide what to do between corruption tries...

> I'm
> asking because once I finish it maybe I will upload it here
> (can we upload helpful utilities here?)

You can upload it as an attachment if you want, but I doubt it'll get added to ZD until they get their new backend finished. By the way, there are a few existing corruptors http://www.zophar.net/utilities/corruptutil.htmlout there</a>.
 
there's a program called unLZ-gba, it searches through your rom and finds the gba compressed graphics. if you're really lucky, they used the gba's built in compression bios code and you'll be able to easilly reinsert your own graphics. the only place to download the program was off a message board

http://magicstone.de/rhwboard/thread.php?threadid=351&sid=b8e3496b381f3cc89de29ae674d83d8b

it's like the fourth message down, in an attachment. if you do find the graphics you're looking for, you can find programs used by gba homebrew makers to compress your graphics, and then overwrite the data by hand in a hex editor.

I'll try to attach it also.

nope it's corrupt, get it from the linked message board.

C:Serverxampphtdocszopharoldwwwthreadsattachmentsunlz-gba.zip
 
Also keep in mind that corruption should *not* be random (as most people think). A good corrupter should allow to change only certain values, to avoid overwriting certain things . . . The most common ASM opcodes come to mind. I know NoChaos (my corruptor) does this and I'm pretty sure that Corrupster and a few others do as well.

As for the compression:
In a hex editor, try changing just one byte at a time and see what happens (look for patterns too, obviously). If you're lucky, it will be close to typical RLE format . . . For example:
00-7F would represent various tiles
80-FF would tell the game to repeat the next tile (ie- 83 34 would repeat tile 34, 3 times)

That is, of course, just a very basic example, but variations of RLE are quite common and you could get lucky in recognizing a pattern.
 
> there's a program called unLZ-gba, it searches through your
> rom and finds the gba compressed graphics.

Hm, something like this may be helpful to someone trying to hack NDS games as well (may be easier than extracting the graphics from the file and trying to uncompress them one at a time). I *think* the NDS supports the same compression the GBA does....someone feel free to tell me if I'm wrong though.
 
Back
Top Bottom