[PacoChan]

Hi everyone.

I did a Banjo-Kazooie Spanish translation some time ago. I was able to edit almost everything: texts, graphics, etc. But there was a strange problem when I tried to edit the menus. The slightest change made the game go crazy. It had some random problems like Banjo being uncontrollable, and the Bottles tutorial couldn't be completed. And it wasn't a compression problem, the menus appeared translated perfectly. Debugging for a while, I saw that the game did some kind of CRC check. It generated a value based on the menus and code data, then compared that value with another one. If they were different, the game went crazy. I changed that value it was comparing with, and the problems were fixed, but then appeared some new ones. I couldn't fix it and I couldnt translate the menus.

Now I've started to translate Mario Party. I've managed to make a decompressor/compressor and I've been able to edit the font and some graphics thate were compressed. Then I wanted to change some character widths of the font, and I found the table uncompressed in some part of the ROM. I edited it and... Mario Party turned into a crazy party (well, not as crazy as Banjo-Kazooie). The game has some weird flickering in the intro. Although the character widths and the text appear perfectly. This only happens when I change some byte in that character table.

Debugging, I found again that the game was checking the data at boot time (if I change the character widths in RAM when the game is already booted, everything works fine). Then I found that the code that does this check is from the CIC. So I don't know how to handle this. I thought CIC's purpose was to let the N64 know if the cartridge is original. So I don't know how can affect to the game behaviour. And BTW, I make sure to recalculate both CRCs. The game doesn't boot if I don't.

[KingMike]

It's possible. I noticed the same thing when I attempted to hack some of the menus in Custom Robo.
(menu text is in EUC format, dialog is probably compressed)

[PacoChan]

Oh, man... It wasn't a problem to leave the characters widths unedited, they were small details. But now I have found some important texts that appear in all the maps that fuck the game up. And I discovered that this protection or whatever it is not only does that massive flickering at the intro, but the game crashes when trying to start a game or minigame. And I'm not able to find a workaround.

Hacking PSX games is much easier...

[KingMike]

Actually, it doesn't seem out of the question that the game would want the CIC to calculate the checksum.

If you haven't heard, there were at least 5 different CIC versions each for NTSC and PAL consoles. The checksum will only match if the CIC matched the one the game was expecting.
I guess Nintendo had caught on to the pass-through devices on the NES and SNES (having two cart slots, one slot for a licensed cart to boot the console, and it would run through the second slot.), and decided to make life harder for unlicensed developers, pirates and importers.

[PacoChan]

Now I feel stupid.

The problem was just a Project 64 problem. When I changed the CRCs of the ROM, Project 64 didn't recognize the game as Mario Party (emulators detect games based on their CRCs). Normally it's not a problem, but it seems that Mario Party requires a very specific configuration to be emulated properly. So the game stops working when the emulator doesn't load the proper configuration.

Then I checked Banjo-Kazooie again to see if it has the same problem. And it hasn't. I was able to investigate further and it has indeed a protection system. It generates some kind of CRC on some files, and the code that generates and checks those CRCs is generated at runtime. I tried many things, but none of them worked. Investigating, I found that this is called self-modifying code and it's used, among other things, to prevent reverse engineering. So I give up xD. Actually I found a method to bypass this, and it's modify that CRC at runtime with GameSharks. But it's not an elegant solution.

Has anyone been able to deal with self-modifying code?


Anyway, my Mario Party translation is going quite well and I expect to release it soon. (I don't know if there is many spanish speaking people here, but just in case xD)

[Zoinkity]

It's possible. I noticed the same thing when I attempted to hack some of the menus in Custom Robo.
(menu text is in EUC format, dialog is probably compressed)

Dialog is compressed, as are most of the images you'll also need to handle.  Use the Custom Robo decomrpessor found on this site.  You'll also find a comrpessor.  (Mothballed a CRV2 translation a long while back.)

As for the CRC, if you change anything in the first couple megabytes starting at 0x1000 it needs to be recalculated. Just run it through one of the automatic CRC correction programs.  You could also break on the BNEAL/BEQAL that sends it into a permanent loop, then copy those two values to the CRC in the header (0x10).  Otherwise, if you're lazy and don't want to calc it, NOP the loop and ignore the warning about an unknown bootcode type ;*)


Oh, and self-modifying code doesn't have anything to do with copy protection.  That's when you write, overwrite, or rewrite ASM during runtime.  You see it especially after a transfer from ROM when you need to alter addresses into the current address space.  Emulators, to get their higher speeds, cache executable code.  Ticking that tells the emulator to watch for changes to that code, excluding the effects of emulator-side cheats, of course ;*)