Dumping the GBA Wireless Adapter Firmware
As you might have already guessed based on some of my previous posts, I love dealing with the GBA and all of the hardware that goes into it. But one of the most interesting and perhaps underused peripherals for the GBA was the Wireless Adapter, which could be bought either as it’s own unit or with Pokemon Fire Red or Leaf Green. It worked on a select few titles which included the former titles plus Pokemon Emerald, the NES Classics for wireless multiplayer, and a few other games.
These days, most emulators for the GBA support the wireless adapter, but one of the things which has been missing for quite a while has been the actual multiboot firmware which the wireless adapter transfers to the GBA at boot. Most people never saw this, unless they powered on their GBA without a cart, but with the wireless adapter attached, activating the cart’s multibooting capabilities. What most people called a “secret menu” is one of the small features of the adapter which allowed you to transmit games to other GBAs with wireless adapters, essentially the equivalent of the NDS’s Download Play.
Why is this firmware so important? Well, considering it went undumped for so long it wasn’t strictly all that important, however it does provide some functionality to emulators which otherwise would have never happened, specifically for the NES Classic games. These games allowed you to let someone else play a NES game by transmitting it over wireless, and this menu was used for this purpose. The other reason, and my main reason for dumping it, was research. Firmwares like this are far and few between, we already have very few games which use the wireless adapter, and adding another title to the list (especially one completely dedicated to the wireless adapter itself) is great for research.
So how did I go about dumping this exactly? Well, it actually started several months ago when I realized that this menu hadn’t been dumped, and as such I searched around to see if anyone had made a multiboot client spoofer to dump these downloadable binaries. I managed to find an ancient link to “mbdumper”, a program made by Loopy (who now does 3DS capture cards I believe). His program worked for Gamecube multiboots such as the Colloseum Demo WSHMKR Jirachi distribution program. However, it did not work at all for my wireless adapter or other multiboot programs I tested against, although Loopy’s program did end up helping later on. For a while though, I decided I didn’t want to go through the hassle of making a dumper myself.
A few days ago I remembered that I had wanted to do this for a while, and being motivated by the Lanette Time Capsule project I decided to implement some basic serial IO to try and spoof a Pokemon trade. But alas, I got distracted and ended up making a multiboot dumper myself. It took a while, but I eventually managed to get a program up and going which could dump any standard multiboot program using an EZ Flash IV flash cartridge. The program itself (source here) almost fully implements the standard multiboot slave protocol, however the difference is in the fact that I also happened to store the program in RAM, and once decrypted, onto the EZ IV’s SD card as a file able to be ran in an emulator. However, I ran into a slight problem: The Wireless Adapter, being the pain it is, happened to be the only peripheral (outside of unofficial peripherals) to implement the 32-bit “normal” serial IO multiboot. I had implemented the 16-bit “multi” SIO multiboot. No fun.
So naturally, I was back to floor 0, kinda. I had to reimplement a 32-bit serial exchange function, and from there adjust the protocol to follow proper. Lucky for me though, libgba happened to have XComms, a section of the library which used 32-bit SIO to talk over the old XBoo cables. So the implementation there was actually already done. From there though, it took quite a while to get my wireless adapter to even talk to me at all. I was able to read out what it was saying, but it would promply quit multiboot for some reason.
What I needed was my end to send a 0x7202, and in return, get a 0x6102. However, it just sent 15 0x6200′s and then quit. No fun.
I eventually figured out that the 32-bit protocol actually has the slave device shift it’s replies to the top half of the 32 bits, so I would send 0x72020000, and in return, get 0x72026102 (their reply shifted on top of mine). Although, with the wireless adapter, the master doesn’t have my reply shifted on top of theirs due to how they implement the serial, so we just get 0x6102 in return.
However, another problem arose, and during the 0x60-long header exchange, it would also stop talking. I eventually figured out that this was a timeout issue, and that I needed to stop printing things for it to pass. Several more issues like this later, and my program finally works! Most of the mistakes were either timing or not adjusting things to the 32-bit protocol (certain replies and keys differ between different multiboot modes).
The result? A completely emulatable binary of the wireless adapter firmware:
Since this is an ancient firmware anyhow, I decided I’d put up downloads to this firmware that you can take a look at. The name I dubbed this firmware was rfu_firm.mb, due to the wireless adapter being named RFU internally (guessing it stands for Radio Frequency Unit).
The decrypted binary can be found here. This binary cannot be directly emulated due to it’s polling of the link port for a post-boot check. A binary with that check patched out can be found here.
