Before I delve into the details behind the process, I want to give a brief disclaimer. I am not an expert in any aspect of this process. In fact, I have fairly limited knowledge regarding actual reverse engineering. I’m writing this article to illustrate that anyone can make significant discoveries with publicly available programs and resources.
I also want to show that behind every discovery like this, there are dozens of people who inadvertently contributed to it with their versatile programs and scripts. I arbitrarily chose to look at WarioWare: Smooth Moves for Wii; I wanted to revisit Wii file formats, since I had learned more about them recently, and I chose an interesting looking game from my library.
The Dig Site
Wii game discs can be easily dumped to an external drive by using a Wii homebrew program. This external drive needs to be custom formatted for Wii. Digital copies of Wii games can be transferred from the custom drive to a PC using a program called Wii Backup Manager. After transferring the game to PC in ISO format, we can use Dolphin (a popular GameCube and Wii emulator) to extract the entire file system of the game. Right-click the game in Dolphin’s directory listing and select Properties. Then under the File System tab, right-click “Disc” and select Extract All.
Breaking Ground
Now that the game’s data is accessible, we can start looking at individual files. Scanning the root of the file system, we can see that things are categorized quite nicely. On the root of the file system, there’s a file named zzzzzzzz.zzz. Files of this nature are typically used to pad out the file system for disc-based games. The “zzz” padding data is burned to the disc last and pushes the real data to the edge of the disc, allowing it to be read faster. This is great in theory, but WarioWare’s padding data is a whopping 32KB of null bytes. Not only useless, but also not noteworthy. Some games like Persona 4 hide data from other video games as their padding, but that’s a story for another article.
There’s a directory here conveniently named “Test”, so let’s dive right into that. Test.fxm, Test.tpl, Test.tpx, and Test2.tpl are our stars here. Test.fxm appears to be an XML file detailing the position and ID of certain images. Next, let’s focus on Test.tpl and Test2.tpl. TPLs are the Source Development Kit image format for Wii. SDK formats are offered by the hardware developer as a standard format created to complement the hardware itself. Developers are often free to use their own custom file formats, so not every Wii game uses TPL. Opening the test TPL files in a hex editor, we can see that they should always start with 00 20 AF 30 00. These hex values are the file header used to identify a TPL file. This is super useful information for us, since TPLs may be hiding inside of other files.
We can convert TPL files using a program named “wimgt”, which is included in the “Wiimms SZS Tools” suite. TPLs aren’t always individual images. Some single TPL files can contain a huge amount of images. Wimgt is incredibly thorough and will extract/convert everything.
So that’s cool, we’ve got some test images now. It’s mostly different frames of Wario goofin’ around, and a bunch of the same Mona image. The key differences between all of them are image quality. One Mona image is monochrome, two have transparency, and all of the character images have varying levels of compression. This is clearly a test to see how different levels of image compression look/work. Depending on the console and media, developers may want to optimize images as best they can to reduce file size. Additionally, different levels of image compression may look and function differently in-game. It’s also worth noting that this test archive could have contained other images that were overwritten or removed as needed. However, there is no way to tell based o the information we currently have. Going back to our test archive though, aren’t we forgetting something? What the heck was Test.tpx? Opening it in a hex editor shows us those magic numbers: 00 20 AF 30 00. So this appears to either be a standard tpl, or maybe one they exported with certain settings and wanted to signify as such. After converting it, the images appear to be identical to Test.tpl.
Excavation
We’ve got three large directories that make up most of the game at this point. “Menu”, “Petit”, and “Stage”. Menu is the smallest and looks pretty straight-forward based on the file names. On the surface it doesn’t seem to contain anything important or suspicious, so let’s skip it. That leaves us with Petit and Stage. Taking into consideration the file names within each, Petit contains the core microgames and Stage contains the introduction screens and related level data. Stage also contains over 2GB in video files for cutscenes. These files are “THP”, and can be natively played using VLC Media Player. The rest of Stage looks somewhat uneventful, so we’re gonna skip it for now as well. Ironically, Petit is a massive directory. WarioWare: Smooth Moves boasts over 200 microgames, and there are appropriately 397 files in Petit. Many of these can be attributed to files that are language-specific, so let’s remove those. After searching for and removing all files containing _de, _es, _fr, _it, _us, and _uk, we’re left with 295 files. This is still a lot to go through.
Let’s sort by file type and get a broad look at the directory right now.
- 23 BREFF files
- 23 BREFT files
- 80 BRRES files
- 18 BRRESP files
- 1 TXT file
- 48 TPL files
- 10 TPLP files
- 87 TPX files
- 5 TPXP files
We already know about TPL/TPX, so let’s isolate all of those. Let’s take along the TPLP and TPXP files as well, since those are similarly named and look suspicious. This leaves us with 150 files. We’re going to do some batching here in a moment, since it will be too time consuming to convert 100+ files individually. We need to investigate those TPLP and TPXP files first, however. There are 15 of them total, which seems negligible on the surface, but it’s still 10MB worth of data that we should check out.
Opening a few of the TPLP and TPXP files in a hex editor, we can find our magic TPL numbers very early on. However, they’re not at the start of the file, which is a bit concerning. If we trim the first five bytes before the TPL header and save the file, what happens if we attempt to convert it using wimgt? Nothing. The data is “broken” in this state. So what’s going on exactly? Why are these ones broken? Let’s open a whole bunch of them and check out the headers.
The first byte is always 10. That’s a good sign, at least. The next three are always different. The one after that is mostly 00, but sometimes 01. And then finally the last bytes are our standard TPL header. What we have here is compression. This type specifically is called LZ77. It can either start with a 10 byte or an 11 byte. The three bytes that come after the 10 are the file’s uncompressed size in hexadecimal, stored in reverse order. The first file in the image above (Back.tpxp) contains the hex values 87, 67, 23. It is currently 509KB, and should decompress to a size of “236787”. Watch out, because even though it seems like a valid number, this value is represented in hexadecimal and not decimal. After converting to decimal, 236787 becomes 2,320,263 bytes. So we should expect a decompressed file around 2.2MB in size after decompression. To finish our analysis, the 00/01 byte appears to be a flag of some sort but I’m not actually sure what it does or signifies. There are a number of tools on the net that can decompress and compress LZ77, but I personally like to use BatchLZ77 which was written by DarthNemesis. It’s a simple, no-nonsense program that allows you to drag and drop hundreds of files at a time. Decompressed files are created alongside the original with a “.decompressed” extension appended. LZ77 compression is used in countless games on Nintendo DS, Nintendo Wii, and Nintendo 3DS, so keep an eye out for it!
Great, so we’ve got our 15 TPLP and TPXP files decompressed and ready for conversion. We’re still not going to convert 150 individually, so let’s check out the exact conversion process with wimgt. The command line instructions to convert a single image are as follows:
wimgt DECODE <filename.tpl>
Okay, pretty simple. There are no options we need to set, and the program just writes the images to the same directory. No need to specify that kind of stuff. We can loop this command using what’s called a batch file. It’s a small script used by Windows to execute command line instructions in various ways. These feature the file extension .bat, and we’ll be making one from scratch.
for %%i in (*.tpl, *.tpx, *.decompressed) do wimgt DECODE %%i
Okay that’s a whole lot of text. We’re gonna pop this entire thing in a text file and save it as “ConvertTPL.bat”. Some text editing tools may add a .txt extension anyways, so we’ll make sure the file ends with a .bat extension. What we’re telling Windows to do here is for every file (%%i) we input from this directory that bears the extension tpl, tpx, or decompressed, it should do the wimgt conversion instructions. Therefore, once you run the .bat file, any TPL, TPX, or Decompressed files in the same directory will be processed through wimgt. That saves us a lot of time typing out instructions in a command line window!
Recovering Artifacts
Since we put a lot of effort into decompressing those 15 TPL/TPX files, let’s convert those ones first. Wimgt makes easy work of the files, taking about 10 seconds to convert everything. We’re left with 681 images extracted from the 15 files.
Things went pretty well, none of the images look broken or distorted. There’s a lot of wild imagery here, but nothing you wouldn’t be surprised to find in any WarioWare game. There is one archive in here that’s a bit of an outlier however.
There are a few retro themed microgames in Smooth Mooves, but this Punch-Out!! microgame is the only one that’s been compressed. Within its TPL archive, we can find numerous sprites for characters, text/numbers, and a background image + TV overlay. This is all pretty standard, and it’s a similar setup for the other retro themed microgames. Something is a bit odd about Punch-Out!!’s background image, though.
It has a… border? On top of that, there’s some extra imagery on the left side of the border. I realized pretty quickly that this was an emulator screenshot taken by a developer at either Nintendo or Intelligent Systems. What I didn’t know was what emulator they were using. I’m not very familiar with NES emulation, so I asked some fellow TCRF contributors who were more likely to recognize it. Divingkatae did some research and determined that the UI cut off at the top matched that of an emulator named VirtuaNES.
Analysis
So… why does this matter? Nintendo owns Punch-Out!! and the NES/Famicom hardware, so they’re good to go, right? Technically, yes. VirtuaNES is released under a General Public License, which means companies like Nintendo can use it for commercial purposes. The main problem here is Nintendo’s actions directly contradict their statements. Let’s have a look at their official comments regarding copyright, ROMs, and emulators:
“…the greatest threat to date…” is a bit dramatic to describe emulation. I personally see it as a double-edged sword, but one that needs to exist. Without the emulator, the developers wouldn’t have had an easy way to capture a clean screenshot of the game. There is no denying that people will use emulators to pirate games, it’s just the nature of things. However, emulation is essential for preservation, as proven by Intelligent Systems/Nintendo’s actions. Frank Cifaldi of the Video Game History Foundation spoke at length about this subject in 2016 during the Game Developers Conference. I urge everyone reading this to watch Frank’s presentation, because he goes through some important aspects of why emulation is necessary and also not a giant looming threat to Nintendo’s business.
So there you have it! How to tell if Nintendo is using an emulator. I may have made mistakes in my explanation or process above, and I welcome anyone to correct me on specific things I messed up. To reiterate, I am not an expert at this kind of stuff. I just do what I can and hope for the best. You can do it too, with some time and patience. I plan on writing more articles in this format, so let me know what you think of the format and presentation. I want to make these as informative and enjoyable as possible, and your feedback is essential to achieve that. Until next time, keep diggin’!
