n64rd v0.2.0 By Parasyte

[dlevere]

By Parasyte

Greetings, fellow game hacking enthusiasts!

I am writing today to inform you of a long-lost project called n64rd which has recently resurfaced (thanks in no small portion to Modman for the encouragement.)

n64rd was started in February 2012 as an attempt to fix the remaining issues with the GameShark Pro v3.30 firmware. Research started with a MIPS vr43xx disassembler that I wrote by hand in Python. This disassembler is part of a related project to provide a debugger GUI; it is now being rewritten in JavaScript using node-capstone.

The original Python-based disassembler is still available in this gist: https://gist.github.com/parasyte/f8fa1de4e7070048846a

Try it out with something like:

python vr43xx.py ramdump.bin 0x80000000

With a disassembler I could trust (kind of... I have had to fix some bugs along the way!) I dumped all of the N64 memory and reverse engineered the GS Pro trainer to find all of the commands it supported, including a very helpful one that reads N64 memory 32-bits at a time, and is not bound to any address range... This awesome little command is even available while in the GS Pro main menu, so I dumped that, too!

I've now reversed enough of the GS Pro firmware that n64rd supports firmware upgrades. The one caveat is that I have not yet added Windows support, because parallel port access in that environment requires installing a driver. n64rd is open source, so please feel free to submit a pull request with Windows support!

n64rd source code: https://github.com/parasyte/n64rd

I have also reverse engineered a lot of the GS Pro firmware that is not related to the communications protocol. Here's what I know:

• The 5-second count down during boot up is utterly pointless, and only serves for some perceived "coolness" factor.
• Key Codes set the GS Pro firmware's internal checksums to match the CIC boot code on the inserted game. GS defaults itself to use the checksums for CIC-NUS-6102 (called "Mario World 64 & Others" in the Key Code menu).
  When setting a Key Code, the firmware's header is modified to use the requested checksums. The second part of the Key Code is the entry point address. The firmware will be loaded into a different location in memory by the CIC boot code. This isn't entirely necessary, but that's what they did!
• We have collected every known LPT-enabled GS Pro firmware in the wild, including IceMario's "Perfect Trainer" and two official variations of 3.30. The two variations were built three weeks apart and have identical code lists. It is not yet known what was changed.
• I have fully documented the LPT communications protocol, GS-button behavior, 7-segment display illumination patterns, and EEPROM commands (for erase, write, vendor ID, etc.)
• "How it works" is now a solved a mystery! It "hooks" the OS by installing a general exception handler which prevents itself from being overwritten. The protection comes from the CPU's built-in watchpoint support. Each time the GS exception handler is invoked, it checks the cause:
• Watchpoints are caused when the game's OS attempts to install an exception handler; the installer is rerouted to store the OS exception handler in an unused location in memory.
• Controller interrupts trigger the code engine, followed by the OS exception handler.
• All other exceptions are simply redirected to the OS exception handler.
• When using the "CC" code type, the GS exception handler is a bit different; instead of triggering the code engine only on controller interrupts, it triggers the code engine on all non-watchpoint exceptions.
• Later N64 OS (E.g. NFL Blitz 2001, Pokemon Puzzle League) changed how the exception handler was installed, which is explains why some games require a master code with the F1 code type and value: 0120. This forces the exception handler to be installed to the "rerouted" location in memory at address 0x80000120!
• Even later N64 OS (E.g. Mario Party 2 & 3) disables watchpoints before attempting to install the exception handler! This explains why some games require master codes with F1 code type that uses value: 2400. This is a 16-bit shortcut for the NOP instruction, disabling the watchpoint disabler!
• Because of this protective "hook", it is generally not possible to use watchpoints with an unmodified GS Pro firmware, though software like GSCC2K2 attempts it with unstable results.
• I've determined that even though the GS hardware ships with two 128KB EEPROMs, it is possible to replace them with two 512KB Flash ROMs, which increases the total capacity by 4x. The firmware needs modifications to support the Flash ROM commands for saving options, code lists, checksums (Key Codes), and firmware upgrades.
• Install SMC PLCC32 sockets to make chip replacements much easier! (See photo below)
• It would be nice to replace the clunky Key Code interface with a 5-position switch to select the proper checksums. That experiment is ongoing.

Replace EEPROMs with sockets:

[MathUser]

If you could set it to autodetect needed keys that would be more awesome. I hate how you have to switch it all the time.

[Helder]

Someone already reverse engineered the CIC, maybe that can be implemented and solve the who key code problem.