Personal Observations from the Gigaleaks
Me want beytah right now because beytah better than final!
November 26, 2024
Category: Infodump
Remember the 2020/21 Nintendo data leaks? I certainly do, remember them like I was yesterday. Certainly gave me a reason to wake up in the morning during the COVID-19 pandemic, when I was stuck at home with nothing to do for the remainder of 10th grade.
I kinda wanna use this page to insert my own findings and things of interest that I found after a curory look back at them. :3
DISCLAIMER: experts it is okay if you cringe at my surface-level analysis of everything, i'm just poking at what i think is cool and curious and am not an expert in literally anything ever. this is not a complete analysis of the leaks, it is just what i personally find interesting
With that out of the way, onto the findings.
unsorted.7z
unsorted.7z is the name of one of the earliest archives from the BroadOn breach, appearing on May 1st, 2020. This comes hot onthe heels of various development files and CIAs for Pokémon games on the Nintendo 3DS, as well as all of the title keys for DSi, 3DS, and Wii U.
This archive comes in the form of three CVS repositories.
One of the first things I noticed is that the depot repository is that the earliest commit goes to 2002, and this repo is relating to the iQue Player, which released in November 2003.
depot/hw/chip/lib/kilopass/081205/ is a folder that contains verilog files and documentation to the Kilopass XPM products as of 2005, which are proprietary one-time-programmable non-volatile memory solutions. This information is kept separate from the rest of the iQue Player project since it is property licensed from another firm.
depot/rf/ contains more interesting stuff. The rf in the path is supposed to designate RouteFree, which would later become BroadOn, and then iGware, and now the company exists as Acer Cloud Technology.
Anyway,
doc contains documentation on something called the "BB Game System", or "BB Player", which is a recurring name throughout this repository.
"BB" was the working name for what would eventually become the iQue Player, and supposedly means "BroadOn Board.
There are a handful of files under bb_depot that refer to remote_mgmt_files but I'm not sure if these graphs where intended to be used for anything. They seem to be about an internet connection on the iQue Player itself.
What ended up actually happening was we initially got the iQue Depot, which was a store Kiosk the user would bring their iQue Player to in order to purchase and download games.
This later got replaced with some Windows software called "iQue@Home." All iQue Player units had to have their firmware "SKSA" updated in order to access iQue@Home.
The rest of the documentation is pretty much the standard stuff: System software notes, SoC block diagrams, the works. Here's a cool picture of a really shiny iQue Player, its "Industrial Design."
However they do have some extra docs on porting Nintendo 64 games to the iQue Player, which notes how the PIF (Peripheral Interface) was missing on the iQue. On the N64, the PIF was responsible for being a security chip, handling controller input, the soft reset button, and various other information about the current configuration. It also nows the differences in access timings between N64 Game Paks and the flash memory in the iQue, and mentions how they had to alter game save behavior due to lack of EEPROM/SRAM.
The MIPS core was also slightly different, with the MIPS data cache line size being increased from 16 bytes in the original to 32 bytes. This also meant that DMA and RCP buffer alignment had to be altered.
The iQue Player also had DDR memory over the N64's RDRAM. "Should not be any issues," the engineers wrote.
Much of libultra, the N64 SDKs operating system, had to be altered to accomodate these changes. For example, the osEeprom routines were altered to emulate either a 256 byte or 2KB EEPROM using the onboard flash. For SRAM, libultra does not have any specific routines so they had to make those changes on a game-by-game basis.
rf/hw/ contains source files behind the motherboard, the cartridge board (nicknamed "Dookie"), as well as various other things. The board layouts are in DSN format, which require OrCAD to view, but they probably don't work in modern versions of the software.
chip contains verilog files for the iQue Player SoC and other components, with a top level verilog source file for the SoC appearing to be at rf/hw/chip/src/bb.v. This file, to my understanding, provides the skeleton for each of the specific units and describes how they are supposed to connect, like here in this screenshot they created an instance of the MIPS and are defining names for each of the pins.
I do find it humorous that they renamed RCP to BCP.
This section of the repostiory is reminiscient of the "Oman Archive," which was an old data dump from 1999 that came internally from a SiliconGraphics employee. It contained a lot of verilog and source files for the N64 and its hardware.
rt/sw/bbplayer contains a lot of source code used in development. apps and apps.released contain a lot of testing programs used in-house. The morphcube demo contains this picture of Batman that goes really hard.
Other than that, these demos are the usual testing programs.
There is this cool demo from the N64 SDK that makes a return called Mirror House Cornflakes, developed by Monegi. Made simply as a demonstration of the libultra and the N64 SDK and how to program this strange machine.
The highreso demo has this wonderful image of a Pikachu.
depot/rf/sw/n64os20l/lib/BringupBoot/IPL4 contains full source code to the Nintendo 64DD's IPL.
Since Super Mario appears in the IPL there is a handful of original source code from Super Mario 64 in here, mostly for animation data.
The first commit for depotrvl was made in January of 2006, despite having files that go back to much earlier than that.
depotrvl is a repository that's dedicated to the Nintendo Wii, signified by the rvl suffix.
Once again, we're given the folder structure of doc, hw, and sw. doc contains the usual set of documentation, hw contains a bunch of verilog source code (but not for anything really notable), and sw contains a lot of important source code.
hw/chip/sim/aes/compile is a script designed for simulation of AES encryption circuitry, written in Verilog. What I find interesting here is that this script actually calls for CSH instead of something more common like Bash. On top of that, the script calls for a command called ncverilog, which a bit of digging showed that "Incisive" was their circuitry simulator.
sw/nintendo/boot/ appears to have four revisions of firmware images for an early "Nintendo Revolution emulator" board, if the strings inside the ROM images are to be believed. Couldn't really dig up more information than that.
sw/nintendo/di-dvd/DVD_src/build/libraries/dvd/src/ and sw/nintendo/di-dvd/DVD_src_PATCH_17Jun2005/build/libraries/dvd/src/
contain source code to what appears to be libraries for controlling the DVD drive, with dates going back to 1998.
sw/rvl/boot/boot0/ contains source code to the Wii's boot0. In here, key.c contains the key used to decrypt the boot1 executable.
In fact, all of this code lines up with the assembly dump that is available on WiiBrew.
sw/rvl/boot/boot1/ contains the source code to boot1. The job of this thing is to initialize more hardware devices and load boot2. Interestingly enough, there are also folders for boot1.diag and boot1.n.
sw/rvl/boot/boot2/ contains a binary image of boot2.
There is however, an alternate version of boot2 called sd_boot, located in boot2.mfr. This alternate variant is used in the factory setup process, after boot0 has been imprinted into the MaskROM inside Hollywood. sd_boot would be contained inside a special "prewrite" NAND image that also contained the final boot1. Instead of reading or writing to the NAND, sd_boot instead would load some WAD files from an SD card, one of which contained an ARM binary that would be run on the IOP, better known as the Starlet. Typically, this image will install the NDEV menu and a couple versions of IOS.
After this, a disc known as "123J" would be inserted into the Wii. Not much is known about this disc.
The next disc used in the factory is RVL_UJI_DIAG, which is a disc that performs various diagnostics programs to ensure a working RVL unit, kinda like the AGING programs used in other consoles.
Next, would be disc "122E," which installs DATA CHECK & LOG CHECK to ensure everything passed.
rvl-factory is a small repository that contained various files used by BroadON and Nintendo during the factory, such as SD Card images and NAND blocks.
Not exactly sure how to use these since none of the WADs are usable in Dolphin.
3DS_manu.7z
3DS_manu.7z was a file that dropped on May 9th, 2020, containing the complete collection of files used for the European version of the New Nintendo 2DS XL, which I will from now on refer to as JAN units.
These programs are designed to validate all of the hardware for the JAN units. They can be run on RED (New 3DS XL) units, but cannot be run on Old 3DS units.
None of these testing programs work on Citra, so please excuse the videos I recorded four years ago.
Worthy of note: the file CTR_CPU_Board_Sequencer_Program.ver.020023.master.srl is actually a Nintendo DS executable. Take from that what you will.
And now, a collection of interesting looking images from inside the executables.
Doohickey headquarters up here.
ctr.7z
ctr.7z consists of two folders, ctr and svn.
ctr/include/aoss/ is a folder that contains header files relating to A.O.S.S. by Buffalo Technology, which was an old way of quickly setting up Wi-Fi connections with a single button press.
ctr/include/gles2 has header files for OpenGL ES 2.
ctr/sources/bootrom/CTR/private/build/bootrom/ctr_bootrom includes the source code to the Nintendo 3DS Boot ROMs, both the ARM9 and the ARM11.
ctr/sources/bootrom/CTR/doc/CTR_BootRomInfo.vsd contains this interesting page about the 3DS' Blue Screen error when it fails to boot.
To translate, the formatting is as follows:
BOOTROM (ROM revision, usually 8046)
ERRORCODE:
- Byte 1: Lid closed detection: 00 for Open, 01: for closed by DS_R7, and 02 for closed by MCU
- Byte 2: NOR Load Error
- Byte 3: Card Load Error
- Byte 4: NAND Load Error
Example error code: 00F800FE
The top eight bytes of information show error codes for the first eight partitions of the NAND, in this order:
3, 2, 1, 0, 7, 6, 5, 4
The bottom left four bytes refer to NAND control errors, and the bottom right four bytes refer to NAND internal errors.
There are a lot of listed errors and I won't go into all of them, but take this following example message:
BOOTROM 8046
ERRCODE: 00F800FE
00000000 00000000
00000400 00000000
F8 refers to recieving bad data from NOR, and FE refers to a NAND initialization error. The 00000400 refers to communication timeout when attempting to initialize the NAND.
Since in this particular case, we cannot communicate with the NAND, we can't really get any data on its partitions or status, thus the other messages remain at zero. An error code like this usually occurs if the NAND has failed or if a hardmod has been botched.
ctr/sources/kernel contains the source code to the Horizon OS kernel, written in C++ and Assembly.
ctr/sources/libraries contains the source code to all of the system libraries. What I find curious is how they had built-in MP3 decoding support in here. They also had a random number generator, using the Mersenne Twister method.
ctr/sources/processes contains the source code to all of the background processes of the Nintendo 3DS, including things like boss, nwm, mcu, and more. The mcu folder also contains 14 different builds of the MCU ROM image.
ctr/source/tools contains the source code to many SDK tools, including things like DevMenu. The folder makerom contains the C# source to a Windows tool that I can only assume was used for producing CIAs, CSUs, and other 3DS package/executable formats.
ctr/source/tools/USBDIO contains a package relating to devices known as "USB-DIO." These are little USB breakout boards that can be controlled with libraries for Visual Basic, MSVC, and MSVC++. The folder also contains a driver for Windows XP and Vista.
Perhaps Nintendo used this during development of the 3DS as a means of debugging? Dunno.
ctr/svn contains two SVN repositories, ctr_mcu and ctr_Repair.
ctr_mcu contains the source code and development history of the Nintendo 3DS MCU ROM image.
ctr_Repair contains the source code and development history of tools that were used in the 3DS repair centers.
BoxyardEraser is a tool that appears to be designed to remove 3D Movie Player videos, which were all codenamed "BOXYARD." I don't really have much more information than that.
I dunno what CardCup or CardSaveData are supposed to do.
ConsoleDataMigration was a set of internal tools used by Nintendo to transfer data between Nintendo 3DS units. The program would require the operator to insert a blank SD card, and the CTR Console Backup would dump important system contents to it.
The contents of the newly created backup would be as follows:
CTRBackup/ - CTRNAND Contents
TWLPhotoBackup/ - DSi Camera Backup
TWLSoundBackup/ - DSi Sound Backup
TWLBackup/ - DSi NAND Backup
MoveContext.bin - Unknown encrypted file
Migration_Log.txt - Backup of the contents of the logging on the bottom screen
movable.sed - Console-unique private key file
NtrNorSetting.bin - Nintendo DS name, color, birthday, and message settings
serial.bin - Console serial number
rtc.bin - Real-Time Clock Calibration
CountrySetting.bin - Location information
FileList.txt - List of files extracted on SD card
TwlTitleList.txt - List of DSi installed titles
version.bin - System version information
deviceId.bin - Device ID (Unsure specifically what this is)
Region.bin - Region information
CTR Console Restore was another program that was used to to the reverse, using an SD backup to restore to a different Nintendo 3DS unit.
It also has the ability to transfer the assignments of a user's SD Card over to the new system. Once it's done doing that, it will ask the operator to insert the SD Card used in the backup process, where it will then write the following files:
WriteFinished - Write confirmation
UpdateFinished - Update confirmation
ConsoleInitialized - Init confirmation
TryRestoreSameConsole - Init confirmation
tpCalibration.bin - More data extracted from NAND
RtcSyncFinished - RTC sync confirmation
AccountDeletedChecked - Confirmation that the old user account has been deleted(?)
AccountTransferedChecked - Confirmation that the user account has been transferred
DownloadSDCIFinished - SD Card management information has been successfully created
cfgCalibration.bin - More data extracted from NAND
ctr.7z/ctr/sources/bootrom/CTR/private/build/bootrom/ctr_bootrom/ARM9/main.c contains this comment:
This commented out line would supposedly "detach" (unmount?) the eFuse region from memory if OTP decryption failed. The comment then goes on to explain that they need to write the "TWL eFuse" before detaching. I don't recall anything about eFuses on the Nintendo DSi, so... maybe it would be referring to the unique console ID of the DSi, somehow?
ctr.7z/ctr/sources/firmware/CTR-Kernel/updater1st contains the source code for what appears to be the factory initialization program for the Nintendo 3DS family. Of particular note are the folders labelled things like UpdaterNgc and UpdaterNgcFirm. The code word here is "NGC," which I believe refers to a "Nitro Game Card," which would mean that the program used to initialize Nintendo 3DS systems was actually on a Nintendo DS-mode cartridge. This lines up with the ARM9 boot ROM feature of being able to boot from a Nintendo DS game cart if X+Start+Select is held and the system is closed while booting. Nintendo likely had a special jig to trigger this. Note that in this instance, Nintendo DS game cart does not inherently mean that it was a Nintendo DS executable.
That's pretty much all there is for ctr.7z that I found interesting. Everything else here is rather mundane.
svn_1.068.zip
This file contains the source code to the Nintendo 3DS Virtual Console.
svn_1.068/patch/Sample.patch shows a sample layout for how game-specific patches were implemented in the Virtual Console emulator. The developer could apply custom CGB palettes and also patch various memory addresses.
svn_1.068/Tools/NESROMMaker contains a tools that appears to convert iNES and FDS ROM images into ones that were used for Nintendo Virtual Console, and was developed by "Chentian" of iQue.
svn_1.068/src/AGB contains a Game Boy Advance emulator, written in 2009, presumably before Nintendo added OS/Silicon support for Game Boy Advance titles to be run. What's really curious is that it contains a dynamic recompiler that has the capabilities of emitting machine code for both ARM and x86.
The Nintendo 3DS Virtual Console emulator is very portable, and svn_1.068/src/PC contains code that allows it to be compiled for Windows. Same goes for svn_1.068/src/EmuShell/PC.
ctr-etc.7z
ctr-etc.7z contains documentation about the Nintendo 3DS security model, dev board, boot process, and crypto. I talso contains many internal and SDK programs such as DevMenu, SystemUpdater, and a bunch of sample demos.
ctr/CTR Security.pdf has a presentation from BroadOn about the Nintendo 3DS security, but what I find interesting is their sort of "if this happens we are so screwed" attitude towards certain things.
other.7z
other.7z contained six archives:
CGB.7z - CGB source code for The Legend of Zelda: Link's Awakening
Famicom_NES.7z - Master ROM database for Famicom/NES
NEWS.7z - Unknown, various Sony NEWS workstation backups?
SFC.7z - Various Super NES game source code and demos
agb_bootrom.zip - SVN tree of Game Boy Advance and Game Boy Color boot ROMs
dmg.7z - DMG source code for The Legend of Zelda: Link's Awakening
The files in Famicom_NES.7z/HVC date back to July of 1994, so I imagine that Nintendo of Japan had a digital archive project so that they could keep all of these ROM images around in the event that the physical ROMs died.
Interestingly, Famicom_NES.7z/NES/ROYALTY is all dated April of 1996.
Anyway, all of these are raw ROM dumps, no iNES header is found here like what Nintendo would begin to use later on once they hired Kawasedo.
At the time of the leak, many of these ROM images were undocumented, and Famicom_NES.7z/NES/NOA/NESXZIP.066 would actually end up containing an unseen alternate revision of the Nintendo World Cup cartridge ROM!
other.7z has several prototype builds of Star Fox 2.
NEWS.7z/StarFox2/SF2/SF.ROM
NEWS.7z/StarFox2/KAWAGOE/SF.ROM
SFC.7z/ROM/StarFox2/usa/SXJ03.COM
SFC.7z/ソースデータ/StarFox2/SF2/SF2_CES.zip
That last one sounded a few alarms when it first leaked. That's the ROM that was used on the development cartridge at CES 1994 when Star Fox 2 was first being shown off. The cartridge that was famously almost stolen by an Arizona man who was quickly arrested and charged with felony grand larceny.
SXJ03.COM is the master ROM that Nintendo had of Star Fox 2, dated September 21, 1995. It is actually not the same as the ROM that was officially released in 2017 as part of the Super NES Classic, there's a few touch-ups they made here and there.
NEWS.7z/StarFox2/KAWAGOE/SF.ROM
SFC.7z\ソースデータ\ヨッシーアイランド\ツール\donkey_test is a folder located in the source code of Yoshi's Island.
There are two files: super_donkey_1.bin and super_donkey_2.bin.
SFC.7z\ソースデータ\ヨッシーアイランド\ツール\sleep_test is another folder here, and it contains another unused game idea.
Both of these prototypes use the same art style, so what I think was going on here was that Nintendo had the idea for this hand-drawn art style, and tried various ideas but nothing stuck until they went with Yoshi's Island.
The BIN folder of the Star Fox 2 source code contains a lot of DOS tools used by Argonaut during development. Here's a few of them:
SFC.7z/ソースデータ/StarFox2/SFCAD contains the "Starfox CAD Tool," created in 1994 by Dylan Cuthbert.
Make sure you open these images in a new tab to see full size!
other.7z/agb_bootrom.zip contains the SVN repos where the source code to the Game Boy Advance boot ROMs was stored, which includes both the AGB and CGB boot ROMs. There isn't any actual development history behind the ROMs, but it's great to have the final source nonetheless.
It's a known fact that the GBA boot ROM has unused code that detects if a CGB game is inserted, and fades out before booting the CGB game. However, Nintendo could never get this to work, most likely due to the difference in voltage between AGB (3.3v) and CGB (5v) cartridges.
This leak actually has the source code behind the routines!
I find it odd how the routine uses the BG palette to perform the fade instead of REG_BLDCNT and REG_BLDY, like there there for this exact type of thing, right?
We also get Nintendo's official compression tool, used for LZ77, Diff, Huffman, or RLE compression of arbitrary data.
The GBA boot ROM also uses the MusicPlayer2000 engine, included as part of the SDK, and responsible for sound in a large amount of the console's lineup (and also infamous for having a poor mixer early on).
In multi18_Arm.s we can see the keys used to decrypt and transfer multiboot images over SIO.
When put together, the sequence 4B 61 77 61 73 65 64 6F. This creates the string Kawasedo, the pseudonym of Tomohiro Kawasae, who is most famous for being hired by Nintendo for his NES emulation work, and eventually writing the NES emulator for Dōbutsu no Mori, or Animal Crossing as we know it over here in the United States.
20100713cvs_backup.tar.7z
20100713cvs_backup.tar.7z seems to be a snapshot of someone's /usr/local/cvsrepo on a Linux/*NIX machine. The groups that are tagged in the .tar archive are ensata_usr, cvspokemon, The users in the files are yama, imatake, teruki, and noriko.
/usr/local/cvsrepo/ensata is what appears to be the source code to the Ensata emulator that was made by Nintendo for the IRIS, later on the Nintendo DS. From what I gather, it's a fork of an existing Game Boy Advance emulator called GBE, and appeals to be capable of being compiled for both Windows and the GameCube.
/usr/local/cvsrepo/imatake/dmgdasm contains an official Game Boy LR35902 disassembler.
/usr/local/cvsrepo/noriproj contains the source code to "WallPaperPasswordMaker." Nobody knows what this is.
/usr/local/cvsrepo/pokemon contains a slightly incomplete CVS repo of Pokémon Diamond and Pearl. We wouldn't get the complete repository until October of 2024, and that was actually an SVN repo. No idea what a CVS version is doing here.
/isr/local/cvsrepo/turnout contains the source code the the Game Boy emulator for the Wii Virtual Console.
netcard.7z
netcard.7z was a file that contained source code and design files for the iQue Game Boy Advance, as well as files relating to an unreleased peripheral called the "Netcard."
gba/depot-offline/hw/chip/lib contains all the modules used by iQue for the development of the iQue Game Boy Advance. All coming from ARM, Altera, BroadOn, Kilopass, Samsung, and more.
gba/depot-offline/hw/chip/altera contains the Altera Quartus project file. We can see that the FPGA that iQue was using was a Stratix EP1S60F1020C6.
gba/depot-offline/hw/system/fpga_board contains the design layout for the FPGA test board that the iQue GBA was tested with.
Amongst other things in gba/depot-offline/hw/system/, there contain board gerbers, pick and place machine configurations, schematics, and more for both the test board and possibly the final board.
Throughout gba/depot-offline there is a lot of Wii source code, such as the source code for the Wii's IOS that would run on the IOP. What I think is going on here is that the Netcard, which would allow players to connect to the internet and engage in things like online leaderboards and chat, would be driven by an IOP-like processor or microcontroller to handle all of the underlying system functions, and iQue was using the existing Wii IOS as a starting point or reference.
iqgba/iQue-GBA/viewer contains the source code to two programs, Viewer_NC and lobby. Its CVSROOT folder contains a number of things:
Source code to F-Zero: Maximum Velocity, most likely the iQue version.
12 compiled builds of NetCard viewer in iqgba/iQue-GBA/CVSROOT/Viewer_New/bins
GPL source code to Quake III Arena
Various GBA ROM images from GoodGBA
VisualBoyAdvance source code
There were also some interesting screenshots of the employees' desktops.
iqgba/iQue-GBA/viewer/Viewer_NC/ncpart appears to contain an MPEG-3 decoder. I assume this would have run on the Game Boy Advance CPU or if the IOP-like controller in the Netcard would have been able to decode this codec.
Oh, those builds of the NetCard Viewer are unfortunately nothing all too interesting, since none of the NetCard, related functionality works in emulators.
LuigiBlood has footage of one of the Viewer menu mockups, which supposedly works on a VisualBoyAdvance modified with NetCard support. Not sure where this was located in the archive.
At the root of netcard.7z are these files:
These files outline a cancelled online Pokémon project that was internal to iQue at around 2004. They intended it to be based on FireRed/LeafGreen.
bbgames.7z
bbgames.7z is a repository that contains source code to a handful of Nintendo 64 and Game Boy Advance games, not all of which are complete.
The list of games is as follows:
1080 - 1080° Snowboarding
cba2 - NBA Courtside 2: Featuring Kobe Bryant
dm64 - Doctor Mario 64
f0x - F-Zero X
forest - Animal Crossing
marioAGB - Super Mario Advance
mk64 - Mario Kart 64
sf64 - Star Fox 64
sm64 - Super Mario 64
wario4land_gba_ique Wario Land 4
wr64 - Wave Race 64
yoshi - Yoshi's Story
z_majora - The Legend of Zelda: Majora's Mask
z_ocarina - The Legend of Zelda: Ocarina of Time
z_ocarina2 - OoT backup? Folder is smaller than z_ocarina
While the source code to most of these games is incomplete, it still can be compiled if you know what you're doing. CrashOveride95 was able to compile the Dr. Mario source, Super Mario 64 source, Super Mario Advance source, among others. Seemingly, Dr. Mario 64 seems to be the only complete project amongst the repositories.
From what I gather, Nintendo only ever sent iQue what would have been necessary for localization. Everything else was sent as precompiled object files.
sm64/shape/Player/Luigi contains the original long-lost source files that were for Luigi before he was cut from Super Mario 64. Each of these files are in a .sou file format, which is a 3D model format that I had never heard of. But some people smarter than I have written tools to convert SOU to OBJ, and thus, we have the assembled Luigi.
(image credit: tcrf)
There is a lot more to find in this archive, so I'd highly recommend you look at the TCRF page for Super Mario 64.
marioAGB contains all of the original MIDIs and AIFFs for the audio in that game, which could be useful for researching MusicPlayer2000. It's really obnoxious how there hasn't been a proper up-to-date copy of the MP2K source, what we got in the GBA boot ROM leak was way out of date.
forest/forest_lib/MFC contains the source code to the NES emulator in Animal Crossing. Interestingly, the files in this folder appear to use the iNES header.
forest/forest_lib/F3DZEX2-2.08J_PosLight-001109 appears to contain the libraries used for the RSP microcode. Good stuff.
emeralds.7z
emeralds.7z is a file that contains six other archives:
BOOT-DIAG.7z - RVL boot diagnosis tool
RVL-FFWP.7z - Wii Virtual Console for Donkey Kong
RVL-RAAE.7z - Wii Startup Disc
RVL-WTester.7z - Wii Wi-Fi Tester
pm_eme_ose.7z - Pokémon Emerald source code, includes pokeviewer tool
tako_main_052306.tgz - Verilog and design files for ATI Hollywood
The Wii Startup Disc is hella interesting. It was a disc that was used internally by Nintendo and various retailers like GameStop to initialize Wii consoles with Wii System Menu version 0. All known Wii System Menu versions will refuse to boot a disc with the ID of "RAAE," and this is the reason.
In the factory, it wasn't uncommon for Wii units to be flashed with a preliminary NAND image that instructed the user to insert the Wii Startup Disc. There were however a small handful of units that got released with this NAND still written, and they weren't shipped with a Startup Disc. Nintendo, on their official website, said "hey please send this back we screwed up." They just wanted these Wii units gone.
Before Bushing passed away, he was able to dump one of these Wiis, which was found by another Netizen on eBay listed as "broken." We can actually use this NAND in combination with the Wii Startup Disc and recreate the process!
tako_main_052306/052306/doc contains awesome HTML documentation on the Hollywood, or "Project Vegas"
NEC_BGA_Bump_IOSLOT_assign_051018.xls contains an Excel sheet that shows the layout of all the pins on the Hollywood and what they attach to.
ird_nngc_portable_block_july.doc contains a block diagram for a dockable handheld Nintendo GameCube. Sound familiar?
Much of this documentation is stuff that we've already seen, just that it now comes from ATi and has documentation on the Hollywood.
tako_main_052306/052306/hdk/win32/arm_tools appears to contain the version of GCC that was used to compile things like boot0 and IOS.
tako_main_052306/052306/hw contains the possibly complete verilog for the Hollywood. Includes documentation for all of the used modules and components that were synthesized into the final design.
Given all of the verilog information from both this and previous data dumps, it might genuinely be possible to reconstruct a Nintendo Wii from scratch if given the proper resources to do so.
platinum.7z
platinum.7z contains seven archives:
20090512.rar - iQue Wii Startup Disc
dgb_sgb.7z - Game Boy / Game Boy Color master ROM lot
MASTER_CPUJ00.zip - Source code to Pokémon Platinum
ntr-bootrom.7z - SVN Repo for Nintendo DS boot ROM
twl.7z - Miscellaneous Nintendo DSi data
patch_from_MASTER_CPUJ00_to_FIELDTEST2.zip - Pokémon Platinum patch
patch_from_MASTER_CPUJ00_to_FIELDTEST2_nobanner.zip - Ditto
20090512 contains a little bit more than just the iQue Startup Disc. It also contains the final Chinese version of the Photo Channel, as well as archives of all the System Menu Channels for both Korean and Chinese Nintendo Wii units. Additionally, there are ten different dummy Chinese WADs.
The Nintendo DS boot ROM has something of interest, there is a copy of the Game Boy Advance boot ROM, a file named NitroAgbMonTS1_040304.bin, however the hash does not match the final ROM image. The only difference lies at offset 0x3F0C, which changes 0x00000000 -> 0x00000001. The only reason this was done was to alter the return value of the GetBiosChecksum(), as a potential means of machine identification.
dgb_sgb.7z, the Game Boy master ROM lot, had numerous unreleased or outright lost ROM images contained in it, such as the infamous "Work Boy" cartridge that was lost for 30 years, in DMG/POOL/DMGWYE-0.781.
Along with an unreleased game called Sutte Hakkun (すってはっくん) which was never released on the Game Boy. It had a Super Famicom release, but not a Game Boy release. File is DMGASPJ0.1.
The English version of a Japan-exclusive game called X was found here as well, DMG/POOL/DMGECE-0.477.
We even got a set of interesting test programs for the MBC5 ROM Mapper, DMG/TESTPRG/mbc5_tester.
That's nowhere close to all of them, in total there were 136 ROMs that were undumped or lost in this archive.
twl.7z contains four SVN repositories:
twl_mcu - Nintendo DSi Microcontroller source code
twl_wrapsdk - ???
TwlIPL - Nintendo DSi IPL source code
TwlToolsRED - ???
twl_mcu isn't actually a valid SVN repository, the actual untracked source code is in twl/twl_mcu/_archive/MCU_TWL/
The README in twl_wrapsdk mentions that the libraries fatfs, sdmc, and sc never be made public. Turns out, Nintendo had an agreement of some kind back then with EBS, Inc and they were provided some libraries for accessing DOS filesystems.
twl_wrapsdk/tools/prom appears to have some EXO files leftover, designed for programming Xilinx PROMs.
TwlIPL/bin/ARM9-TS/Release/forDebug/mb_card_rom.srl contains a Nintendo DS Download Play sample.
TwlIPL/add-ins/NTR_IPL2_Gaiji_Font_PC contains a TTE font of the non-standard glyphs used in the Nintendo DSi.
TwlToolsRED/tools/bin contains a number of tools designed for Windows to perform DSi-related... stuff?
All of these tools appear to have been made in .NET Framework. I could only ever get the English ones working.
Oh yeah, the source code to all of these tools is over in
TwlToolsRED/build/tools/MasterEditor/MasterEditorTWL_System/MasterEditorTWL/. :3generic.7z
generic.7z contained four archives:
DSiWareROM.rar - Archive of Nintendo DSi data sent to iQue from Nintendo
ro.rar - Some Chinese Nintendo DSi executables
sd.rar - Contents of an iQue dev's SD card
windows.rar - Pokémon Generation 4 DPDeliver program for Windows
windows/DPDeliver.exe was used to create a Pokémon distribution event ROM image for Generation 4.
It also came with some dummy programs. One for the Game Boy Advance and another for the Nintendo DS.
Other than that, there isn't too much else that's all that interesting, unless I am willing to look through every single DSiWare ROM that is in here.
paladin.7z
paladin.7z is a massive archive that contains the following contents:
Dungeon/ - Pokémon Mystery Dungeon GBA and NDS ROMs
E3/ - Various unknown versions of Pokémon FireRed and LeafGreen
NetCardWads/ - Various Wii WADs for iQue NetCard? Can't really install them
Ranger_e3_060420/ - Pokémon Ranger E3 Demo
FMC_DISK.7z - Famicom Disk System master disk database
PokeRanger_Euro.zip - Pokémon Ranger PAL translations
Ranger_EURO.zip - Final Pokémon Ranger PAL translation
rangereu.7z - Pokémon Ranger builds
ctr_card_test - Source code to the 3DS equivalent of memtest86
ctr_eFuse.zip - Source code to 3DS tool that generates eFuse IDs
ctr_firmware.zip - ~2008-2009-ish source code to Nintendo 3DS boot ROM
ctr_test_tools.zip - Source and binaries for TwlBkpCheck
ctr_tools_red.zip - Source to various tools used by Nintendo Research & Engineering Division (RED)
irisSDKbulb-snapshot-031203-forToolMaker.tar.gz - Dec 3, 2003 IRIS SDK
irisSDKbulb-snapshot-031203.tar.gz - Another Dec 3, 2003 IRIS SDK
irisSDKbulb-snapshot-031212.tar.gz - Dec 12, 2003 IRIS SDK
irisSDKbulb-snapshot-040120-private.tar.gz - Jan 20, 2004 IRIS SDK Private files
irisSDKbulb-snapshot-040120.tar.gz - Jan 20, 2004 IRIS SDK
FMC_DISK.7z contains all known disks that Nintendo had in storage.
They had their own format called "RDA/RDB," which I can only assume stood for Nintendo Research and Development. RDA was for Side A and RDB was for Side B.
As part of this archival process, which took place from January to February of 2007, they also took photos of each and every disk label.
Under this archive, there also exists their own tool to convert RDA/RDB images to FDS, which is the dump format the emulation community developed.
The file DiskWriterSoftPak_ZEL.zip contains the disk dump for The Legend of Zelda, which was damaged in their master archive. Kawasedo-san was tasked with recovering the data, to which he was able to recover it from an EPROM that existed on an FDS disk writer cartridge from back in the day, but the EPROM was formatted as "SCAT Soft Pack." They even had to write a tool, scattoqd.exe to convert the EPROM dump to their Virtual Console format.
scattoqd ROM1.bin ROM2.bin ROM3.bin ROM4.bin out.qd
All of those IRIS SDKs come from the development of the Nintendo DS, which was the original Game Boy Advance successor, having one screen and capable of 3D.
ios-releases.tar.7z
ios-releases.tar.7z was a massive archive, 24 GB uncompressed, that contains a metric crap-ton of development data relating to the Wii's IOS. In large part, in contains the following:
- Firmware images for sd_boot
- System Menu WADs
- Firmware WADs
- IOS blobs
- Dupes of existing BroadOn/iQue source trees such as GBA and NetCard
Something of note is that this archive is not actually a source tree or repository, it's kinda just a folder that BroadOn employees used to store release builds and whatnot.
To my knowledge, nothing here is particularly useful in Dolphin, but there are probably some brave souls willing to rewrite their Wii NANDs to try to get the System Menu WADs booting.
Many of these IOS releases are distributed as flash dumps, consisting of the first five blocks of NAND. Some are also compiled twice, being split between NDEV units with 128 MB of DDR3 and NDEV units with 64MB of DDR3.
Some of the Netcard stuff made it into here, and ios_images9.1.0_rc3/root_gbasrc_2006090117.tgz contains a bunch of Netcard related source code.
gba_root/usr/src/gba/manufacture/function inside of this archive contains a test program that validates the functions of the NetCard coprocessor, which, as previously mentioned, was going to be programmed with code based on IOS.
In many of the READMEs, there are notes about programming the flash of an NDEV unit with a specific IOS image.
And now, an interesting list of observations amongst IOS revisions:
- IOS 4.0.1 has a note saying "Enabled DVD Video access using TMD."
- Apparently there were many different NDEV configurations, some of the notes name them as NDEV1 and NDEV2.
- IOS version 0.0 was released on March 9, 2006.
- IOS 0.7 broke the filesystem API tests on NDEV systems.
- IOS 0.6.5 added support for filesystem encryption, SD driver, an updated boot1, and better hardware initialization with help from ATI.
wiidump.7z
wiidump.7z is a file containing a lot of early Wii SDKs as well as other things.
In each of the SDK dumps, there is a copy of Metrowerks Codewarrior, which is the IDE that Nintendo used for GameCube development. I even managed to get it to install!
Nintendo had provided drivers for the RVL SDK that worked on both Windows 2000 and Windows XP, as well.
Inside of wiidump.7z is an archive called NUP.rar which contains early RVL discs containing software setup. Decrypting the one named BackToolForSys1_64_US_RC1_1.gcm was a very confusing task.
To start, the first 0x8000 bytes of the disc had to be stripped with dd. Next, WiiScrubber was used to extract files using the NDEV common key. Hilariously enough, the NDEV common key is really hard to find. Next, I had to generate the Korean common key, otherwise WiiScrubber would throw a fit. But with all of that in place, I was able to extract the various WADs inside of this disc. The WADs then needed to be resigned using the RVL common key.
systemmenu.rvl.255.9.us.wad is a WAD that contains a barebones disc loader as the Wii System Menu. Likely commonly used on a bunch of later NDEV units as development progressed.
systemmenu.rvl.wad is a way more interesting file though, especially since it's much bigger. It contains Wii System Menu 1.0 RC1. This version of Wii System Menu only boots if the Z Button on GameCube controller port 4 is held down on startup.
The other disc in NUP.rar is callde swupdate2_SDK2.2.gcm and it contains a systemmenu.rvl.104.wad. This appears to be a prerelease NDEV system menu that actully has a navigable menu.
Documents.7z
Documents.7z was a file that contained a lot of security-related documents and also proof of the existence of Nintendo Ninjas.
CTR is a folder that contains many, many screenshots of the 32c3 conference, which had a talk from derrek, plutoo, and smealum about hacking the Nintendo 3DS.
セキュリティチーム運営/プロジェクト/コードレビュー/データ書込みソフト_セキュリティホール確認用_20140509/CTR_TRIAL contains the source code to a version of CTRAging from 2014, but that date signals that it's possibly a version made for the New Nintendo 3DS family of systems.
セキュリティチーム運営/セキュリティ仕様書/XBOX360 contains a few documents that Nintendo wrote about the Xbox 360's security model, perhaps using some of it as a reference for security on the Nintendo Switch? The files are dated 2013, which was after the release of the Nintendo 3DS and Wii U, but still, likely means something.
While I won't be showing any Nintendo Switch stuff,セキュリティチーム運営/プロジェクト/NewSwitch/on_the_rotor_head.jpg has... this?
I'm sure this image will be extremely important to hackers.
In 2013, Nintendo hired a private investigator to profile Neimod, who at the time was a prolific Nintendo 3DS hacker discovering hardware and software exploits for homebrew access. This investigation ultimately led to the "Belgian Waffle" Knock & Talk initiative.
セキュリティチーム運営/プロジェクト/Knock_And_Talk_directcnotact contains the documentation.
Day 1: Tuesday, July 16, 2013
Knock & Talk team assembled the strategy room in Belgium, and they rehearsed their dialogue to recite to Neimod at his door. They all proceeded to discuss potential outcomes.
Day 2: Wednesday, July 17, 2013
The team set up their monitoring equipment and positioned themselves at a Café nearby and waited for Neimod to leave his workplace and arrive home, to which he was promptly confronted. Introductions were made to both Neimod and his parents, and Neimod agreed to discuss in the backyard garden. Neimod ultimately agreed to signing an NDA, lest Nintendo take legal action against him. For the settlement agreement, there was hesitation and Neimod would call later that evening to indicate interest in committing to the settlement's terms.
Day 3: Thursday, July 18, 2013
Nintendo of America and NERD began discussing with Neimod about potential "missions," which Neimod was interested in. One such named mission was reverse engineering and analysis of Gateway3DS flashcarts.
Hilariously, one of Nintendo's biggest objectives was avoiding negative PR, a thing that... hasn't really held up very well. Taking down emulation and fan projects, making a crappy emulation service, Super Mario 3D All-Stars, like I don't think that PR for Nintendo has been very great these past several years, but I digress.
Their next steps were to build profiles and target people such as Yellows8, marcan, and GeoHot. They needed to profile, identify, and classify each of their targets.
They also had what they dubbed the "Hearts & Minds" initiative, which entailed them leveraging Neimod's Knock & Talk to influence hackers. Perhaps even providing a hacker bounty program for the sake of providing positive PR.
They also built a profile on smealum but I'm not sure if anything really came of it.
Now, this type of behavior shouldn't exactly be news to anyone. Not only is it perfectly legal, but many other companies do it. Sleep well on that. >:3c
At the root of Documents.7z are some Windows BitLocker keys. Have fun with that.
t210_t214_brom.7z
Won't go too in-depth here, but this file, released on Christmas Eve of 2020, contained the source code to the T210 "Erista" and T214 "Mariko" Tegra boot ROMs.
T210 is dated February 1st, 2018 and T214 is dated May 24, 2018. I'm not entirely sure if the Erista ROM is the patched variant or not.
NVIDIA absolutely shafted Nintendo to hell and back with their broken ROM image.
bb2.7z
Part of the unexpected 2021 leak, bb2.7z contained files relating to an unreleased "BroadOn Board 2," which would be a Chinese GameCube with DVD playback support.
sw/nintendo/GC_IPL contains, you guessed it, the source code to the GameCube IPL, both bootstages too. There's BS1 which is written in assembly, and BS2 which is written in C.
sw/nintendo/X86/bin/ contains a few server executables, one of interest was DVDServer.exe.
My guess was that this tool was used for some kind of development disc drive emulator that would communicate over the network to retrieve data.
doc/ contains the documentation for the BB2.
Something interesting is all of this documentation on an "ALi SoC," the ALi M3358 which was a heavily modified M3357. Supposedly this chip would the glue that holds all of this stuff together for the BB2.
doc/marketing/BB2-MRD.doc goes into detail about who the BB2 would target.
The ALi T-Square chips that BroadOn had requested were all "Networked DVD Multimedia Processor" chips, which were MIPS32 chips that came with a DSP, designed for handling things like DVD playback. The M3358 would be contained inside an MCM (Multi-Chip Module) that contained other components like a SEPROM, an A/V Mux, and other components.
doc/system_hw/mechanical/bb_2_f_r_panel.vsd contains engineering drawings for the physical case.
teru-sama_mail_2006.7z
teru-sama_mail_2006.7z is a 2006 copy of the mail inbox of a Nintendo employee by the name of Teruki Murakawa. The mail export can be viewed in a program called "HidemaruMail."
I cannot read Japanese, but here's a few interesting things about it, by no means all of it, but a few things that I was able to spot:
- Comparison between PSP and NDS wireless capabilities
- Discussion of Nintendo DS homebrew
- Comparison of prices between Apple products and Nintendo (proof that Nintendo was kinda going for Apple vibes for a while around that time?)
- Talks about XaviX using Jackie Chan in promotional materal for the XaviXPORT.
- PlayStation 3 discussions
- Talks between Nintendo and Metrowerks about CodeWarrior
- Ensata emulator discussion
- Emails and documents from NoA and NoK
- Nintendo Wii E3 prep?
- Wii Virtual Console Lot Checks
- Stuff related to handheld GameCube (NNGC)?
- Spam
- Lots and lots of emails between Intelligent Systems and Nintendo of Japan
Some of that Wii VC lot check stuff is interesting. Nintendo of Europe seemingly handled lotchecks of those titles and would give feedback like this:
Final Thoughts
- Internally, Nintendo was still using SVN for the longest time, maybe even up until the Wii U.
- Nintendo really likes using source code from their previous machines in their new hardware. It's a known fact that the Nintendo Switch's OS is based on Horizon from the Nintendo 3DS.
- Nintendo likely has digital backups of nearly everything they ever made, especially when it comes to game ROMs.
- Nintendo is really, really good about using original assets in their own projects, but it's not uncommon for them to contract other developers and that's where you get silly moments like Super Mario Maker using contents from The Spriter's Resource.
- We likely won't ever get verilog files of the Nintendo 3DS.
- Nintendo hardware always had the marketing vibe of "this crap is pure freakin' magic." It's rather refreshing to see documentation that "No, actually. Nintendo is no different from literally any other electronics vendor."
- Why did they design the Wii around using so many versions of IOS?
- The hell kind of URL is http://source/cgi-bin/cvsweb.cgi?
- NVIDIA not only regularly screws over Linux consumers but also screwed over pretty much everyone that used a Tegra T210.
- Nintendo is genuinely freaking huge.
Notes and Credits
- Rare Gaming Dump- RetroReversing
- Beta64
- CrashOveride95
- MrCheeze
- TCRF
- ecumber95