Mupen64+ Reverser Edition (RE) is a fork of the Mupen64+ Nintendo 64 emulator tailored for reverse engineering.

The main aim is to generate information that will be useful for the disassembling and decompilation of your chosen game.

It does this by tracing and logging information about asm instructions, functions, memory addresses, DMAs etc as the user plays the game.

The main output after the user has finished playing is a couple of files: an n64split config file and a tracing JSON file.

Using DMA and TLB data we can auto detect regions of the rom which are interpreted as assembly instructions and use this information to write out a N64Split config file with asm region information.

Using DMA and TLB tracing information we can generate a list of sections in the rom which are used to transfer data to memory.

We also log the 4 byte header of each region which can be very useful for finding compressed data, e.g MIO or RNC are common headers.

This information is written out into the n64split config file allowing the splitter to separate binary sections from assembly and eventually to use the header information to generate uncompressed assets.

We provide a json file with common function signatures from libultra, this is used to auto detect which functions are included in the game and putting a name to the function.

This information is also written out into the n64split config file as a label which can further help the process of starting a new reversing project.

We store the byte pattern of every function we come across while playing multiple games and can use this information to find common functions across games.

This can be very useful for finding common libraries used across multiple games as well as finding out common game engines used by companies.

It was very common for the same development house to use a game engine for multiple games, one example is the Turok2 engine being used for the South Park game.

This also means we only need to name a function once and it can be detected in other games, sharing the knowledge between multiple projects.

This information is written out into the labels section of the n64split config file and if you find functions with names that start with a different game name then you have likely found a common library or engine function.

Here is part of the n64split label output of playing a single race in top gear overdrive, note that it finds common functions that it has seen before when playing Road Rash and BlastCorps. Along with finding common libultra symbols.

Logging of the RSP Audio decoding allows us to identify which parts of the rom are audio files.

One effective way to find out what to name certain areas of a rom is to corrupt it and witness the result. For example we currently detect audio regions of the rom but can’t detect WHAT audio is playing, to help with this we support custom config paramters that allow you to choose the section to corrupt at runtime, allowing you to effectivly name unmapped regios of the ROM.

Sometimes the developer leaves in printf statement to help debugging, we can log these to json and also print them to the console, also useful for homebrew development.