Notes from inside your Wii

HackMii header image 2


June 14th, 2008 by bushing · 36 Comments

Something that has caught my obsession has been the question — How are Wiis made? Specifically, after the parts are soldered down, how are they programmed? There do not seem to be any data ports which could be used to upload data, nor download output. (My motivation here, of course, is that we might be able to use the same technology for unbricking.)

I’ve found a few hints (but nothing to get excited about) — some may find this interesting.

There are two ways to dump the Wii’s NAND flash filesystem.  If you use something like dhewg’s wiifuse or Waninkoko’s NAND FS dumper, you will get one set of files.  If you dump the raw, encrypted filesystem and then decrypt it with Segher’s zestig, then you will get the same set of files — plus one.



BOARD_TEST is presumably the initial test done to see if there are any short circuits, everything powers up, etc. WRITE_NAND_DATA1 is interesting to me, because it suggests that the NAND flash chips are NOT pre-programmed — at least, not on an individual, per-Wii level. (They may have boot1 and a special boot2 preprogrammed.) It also suggests that this log is not written on the NAND flash as is being generated — instead, it must be stored elsewhere and copied onto the NAND at a later time. (Otherwise, I would not expect to see the first two steps.)

SERIAL_NO_REGISTER is interesting — presumably, unique data about this Wii is read out and stored in a DB somewhere.

WIRELESS_TEST may be the WiFi, the Bluetooth, or both. I don’t know what the PRECHECK_DATA and CHECK_NAND_DATA steps are.

On my ios9wii, this file looks somewhat different:

AGING_TEST=LOOP 1/19,1.0.0
AGING_TEST=LOOP 2/19,1.0.0
AGING_TEST=LOOP 3/19,1.0.0
AGING_TEST=LOOP 4/19,1.0.0
AGING_TEST=LOOP 5/19,1.0.0
AGING_TEST=LOOP 6/19,1.0.0
AGING_TEST=LOOP 7/19,1.0.0
AGING_TEST=LOOP 8/19,1.0.0
AGING_TEST=LOOP 9/19,1.0.0
AGING_TEST=LOOP 10/19,1.0.0
AGING_TEST=LOOP 11/19,1.0.0
AGING_TEST=LOOP 12/19,1.0.0
AGING_TEST=LOOP 13/19,1.0.0
AGING_TEST=LOOP 14/19,1.0.0
AGING_TEST=LOOP 15/19,1.0.0
AGING_TEST=LOOP 16/19,1.0.0
AGING_TEST=LOOP 17/19,1.0.0
AGING_TEST=LOOP 18/19,1.0.0

Note the presence of “AGING_TEST” in the middle of the WRITE_NAND_DATA1 step; also, this is a newer BOARD_TEST. I originally thought that AGING might be Nintendo-speak for “burn-in”, but perhaps this refers instead to a test of the wear-levelling?

Speaking of wear-levelling. This “ios9wii” of mine — the one I got on eBay that had never been updated from the original software it came with from the factory — it gives us a rare opportunity, because it may be the closest I can come to getting a dump of the files that Nintendo installs into the NAND fs for use inside the factory, and then later deletes. Just like with a normal hard drive, the wear-levelling algorithm used for NAND flash ensures that we’ll see some bits and pieces of old files if we look hard enough.

I did, and here’s what I found:

AGING_TEST=LOOP 1/19,1.0.0
AGING_TEST=LOOP 2/19,1.0.0
AGING_TEST=LOOP 3/19,1.0.0
AGING_TEST=LOOP 4/19,1.0.0
AGING_TEST=LOOP 5/19,1.0.0
(binary garbage)

cardedit "cardedit (lab use)" "MemoryCard Utility in SDK" 0xA083

MCcopier "MCcopier (lab use)" "MemoryCard copy tool" 0xA084

Waikiki "Waikiki test (lab use)" "Echo back program using Waikiki" 0xA085

CardEmu "MemCardEmu Test" "Memory Card Emulator Test" 0xA11C

flashcus "TestTool for sales" "Memory Card 59, 251 Test Tool for sales" 0xA11D

efbDump "EFB Dump (lab use)" "Dump EFB to console. Can be converted to a BMP on PC" 0x1289 
efbStress.dol "-bmp"

efbtest1 "EFBTest1 (lab use)" "Check EFB C & Z" 0x1288

EtxKeyV "EtxKeyV (lab use)" "Embedded Texture (1 Ptn) Waits for KEY before verify - Verbose" 0x128a

efbbitsT "efbbitsT (lab use)" "Targeted at efb-write xtalk/hold-time bank A bug" 0x2013
efbbits.dol "-inter" "_interactive_" "-crc" "_crc_"  

pirstsw "pirstsw (sort)" "Manual test of the software Reset switch." 0x0400

cbars2 "cbars2 (sort)" "Displays colorbars - for visually checking Composite Video signal" 0x0800

HiraL2 "HiraL2 (lab use)" "L2 cache check program by Hiratsu" 0xA001
HiraL2.dol "-crc" "Check"

MidiChk "MidiCheck" "Midi Adapter Checker for Check Tool edition" 0xA087

NandChk "NandFlashTest" "NAND FLASH Phsycal layer test from BW access" 0xA088

AesChk "AES engine simple checker" "Waikiki(SLOTB), only console" 0xA08B

mouseM "USB Mouse Demo (Manual)" "OHCs control to a connected USB-Mouse." 0x0204

sdi0RegM "SDI Register Check for WP (manual)" "Manual Chk HC0 reg for WP. 1st, SDCd isn't present." 0x0B01
sdio_hcreg.dol "-sdiboth" sdi0MemS

"SDI MEM Rd/Wt/Vfy (stress)" "Wt/Rd/Vfy SDCd. Need SDCd." 0x0B04
sdio_memrw.dol "-stress"  sdi1RegA

"SDI Register Check (sort)" "Check HC1(Wi-Fi) register" 0x0B02
sdio_hcreg.dol "-sdi10" sdiWifiA

"SDI Wi-Fi Check (sort)" "Rd/Wt/Vfy Wi-Fi reg. Need Wi-Fi module" 0x0B07

sdiDup16 "SDI MEM Card Dupli 16M (lab only)" "Max 16MB. Rd frm SDc, and write to other SDc" 0xA0B0
sdio_dupli.dol "-16M"

sdiDup48 "SDI MEM Card Dupli 48M (lab only)" "Max 48MB. Same sdiDup16, but don't check data correct." 0xA0B1
sdio_dupli.dol "-48M"

sdiIMemA "SDI IOP API MemRW (sort)" "use IOP API in this test. Need SDCd" 0x0B09
sdio_api_memrw.dol "-auto"

sdiIMemS "SDI IOP API MemRW (stress)" "use IOP API in this test. Need SDCd" 0x0B0A
sdio_api_memrw.dol "-stress" 

Goyan "Goyan (lab use)" "Gekko Max-Power Application by Gouda/Ohya" 0x3005

zebraM "Zebra Manual" "Character Pipeline - Gekko Skinning Demo" 0x3006
zebra.dol "-crc" "Check" "-manual"

clothM "Cloth Manual" "Cloth Manual - Mostly CPU" 0x3008
cloth.dol "-crc" "Check" "-manual" 

carM2DM "Cardemo Manual" "use MEM2(GDDR3), access DVD" 0x3009
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-manual" "-gddr" "-dvd" 

carM1DM "Cardemo Manual" "use MEM1(Napa), access DVD" 0x300a
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-manual" "-dvd"

carM2M "Cardemo Manual" "use MEM2(GDDR3)" 0x300b
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-manual" "-gddr" 

carM1M "Cardemo Manual" "use MEM1(Napa)" 0x300c
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-manual" 

carM2DSM "Cardemo Manual" "use MEM2(GDDR3), access DVD & SDc(IOS)" 0x300d
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-manual" "-gddr" "-dvd" "-sdmI" "0x20" 

carM1DSM "Cardemo Manual" "use MEM1(Napa), access DVD & SDc(IOS)" 0x300e
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-manual" "-dvd" "-sdmI" "0x20" 

carM1DSA "Cardemo Auto" "use MEM1(Napa), access DVD & SDc(IOS)" 0x300f
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-auto" "-dvd" "-sdmI" "0x20" 

carM1DSS "Cardemo Stress" "use MEM1(Napa), access DVD & SDc(IOS)" 0x3010
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-stress" "-dvd" "-sdmI" "0x20" 

carM2DSA "Cardemo Auto" "use MEM2(GDDR3), access DVD & SDc(IOS)" 0x3011
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-auto" "-gddr" "-dvd" "-sdmI" "0x20" 

carM2DSS "Cardemo Stress" "use MEM2(GDDR3), access DVD & SDc(IOS)" 0x3012
cardemo.dol "-polygon" "Normal" "-crc" "Check" "-stress" "-gddr" "-dvd" "-sdmI" "0x20" 

u_efbt10 "EFB 10Ptn Verbose" "Embedded Frame Buffer Color & Z Test - 10 patterns"0x128d

u_blend "Blend test" "Blend Test" 0x1287
blend.dol "-inter" "_interactive_" "-crc" "_crc_"  

u_vtxdes "vtxdesc" "Tests Vtx packet & description combinations" 0x1131
vtxdesc.dol "-s" 

u_array "array" "Tests Vertex formats & Array strides" 0x1135
array.dol "-s" 

u_strm "strm" "Tests revA->revB bug fixes in CP" 0x1136
strm.dol "-s" 

u_pinwhe "su/pinwheel" "Checks for holes and double-hits"0x1420
pinwheel.dol "-s" 

u_attlig "AttenLight" "Tests lights and light attenuation" 0x1722
AttLight.dol "-s" 

u_xf024 "xf024 (sort)" "Tests multi-texture, texgen & bumpmap" 0x1718
misc004.dol "-test" "xf024" "-clip" "-init_efb" "-copy_out" "-gold" "d30e282b" "-dgold" "32c4d3d2" "-mgold" "2fe0ccc2" "-dgoldB" "507b5a20" "-inter" "_interactive_" "-crc" "_crc_"  

u_bumpte "bump" "Tries all 64 possible 1,0 indirect matrices" 0x1010
bumptest.dol "-s" 

u_cartoA "cartoonA (sort)" "Demonstrates cartoon rendering technique" 0x201e
cartoonA.dol "-o" "cartoon" "-gold" "BC07FD51" "-dgold" "1ff43e0d" "-mgold" "799941cb" "-dgoldB" "5536E088" "-inter" "_interactive_" "-crc" "_crc_"  

u_spindA "spndAuto (sort)" "Auto version of Spin Donut - Checksum over 100 frames" 0x201d
spinDAut.dol "-f=100" "-crc=979d2cfd" 

u_multdA "multDntA (sort)" "Multi-Donut Auto combination graphics test" 0x201f
multiDA.dol "-m" "-c" "-f" "100" "-crcVal" "0bd7a00c" "-inter" "_interactive_" "-crc" "_crc_"  

u_Mcomp "MComp (Sort)" "Motion Compensation Test" 0x2029

u_rtcrom "RtcRom Test" "Checks Rtck and RtcSram." 0x061F

u_gpits "GPITS" "Gekko Portable Integrated Test Suite" 0x010F

u_memspd "PI<->MEM speed test" "Calculates processor bandwidth usage" 0x4011

u_aidsp "AI Dsp" "AI Dsp" 0x091A

u_dspdec "DSP Dec (sort)" "DSP Adpcm Decoder" 0x0A2B

u_dsprm2 "DSP ROM2 (sort)" "DSP Security Check" 0x0A2C

u_dspacc "Dsp Accelalator" "Akagi's Dsp Test 1" 0x0A86

u_dcre "dcre (lab use)" "DCRE-int happens at same time with AI-DMA and CPU int" 0x0A2A

ViOrig "ViOrig (lab use)" "VI Test Program" 0xA200

ViRw "ViRw (lab use)" "VI Register R/W - NTSC, PAL, MPAL, Interlace, Progressive" 0xA201

ViGazou "ViGazou (lab use)" "VI Test Images" 0xA202
tvtest.dol "-crc" "Check"

Lcd3D_2 "Lcd3D_2 (special)" "3D LCD version of smp-onetri_dl" 0xA204
vi3d_onetri.dol "-crc" "Check"

Lcd3D_3 "Lcd3D_3 (special)" "3D LCD Static Images"0xA205
vi3dtest.dol "-crc" "Check" 

onetriP "onetriP (lab use)" "PAL / NTSC version of onetri" 0xA206
onetriP.dol "-crc" "Check" 

GunTest "Gun test" "Gun test" 0xA20E

TaruTest "Taru konga test" "Taru konga test" 0xA20D

SramFlag "Sram Flag(lab use)" "Sram Flag information" 0xA213
SramFlag.dol "-crc" "Check" 

AVLGA "AVLGA(lab use)" "Colorbar75 & Sin1kHz for LGA" 0xA214

SBar "SBar(lab use)" "ON/OFF Test for Sensor bar" 0xA215

VIScale "VIScale test(lab use)" "VI Holizontal Scaling Test" 0xA216

flashIO "flashInOut" "Flash card insertion test" 0xA003

CardAge "flashAging" "Flash Write Stress test" 0xA006

CardAge2 "CardAge2" "Stress test for memory card 59." 0x068B

flashReg "flash Reg" "Flash Register Test Menu" 0xA007

flashCst "flash Cst" "Flash Customer Test Menu" 0xA008

flashLrg "flash Lrg" "Flash Large Test Menu" 0xA009

keyBoard "KeyBoard" "ASCII KeyBoard Test Menu" 0xA100

rstTest1 "SoftReset (lab use)" "SoftReset (lab use)" 0xA300

rstTest2 "HardReset (lab use)" "HardReset (lab use)" 0xA301

CELLHLBH "Cell-HL Hi (sort)" "Cell H/L burst pattern" 0x5025

DSYMACHH "DS Ymarch Hi (sort)" "Double Stripe Y-march pattern" 0x5026

YADSFT0H "YaddrShift Hi(sort)" "Y-address Shift pattern0" 0x502E

YADSFT1H "YaddrShift Hi(sort)" "Y-address Shift pattern1" 0x502F

CELLHLBL "Cell-HL Lo (sort)" "Cell H/L burst pattern" 0x5020

DSYMACHL "DS Ymarch Lo (sort)" "Double Stripe Y-march pattern" 0x5021

YADSFT0L "YaddrShift Lo(sort)" "Y-address Shift pattern0" 0x502C

YADSFT1L "YaddrShift Lo(sort)" "Y-address Shift pattern1" 0x502D

DSYMAC2H "DS Ymarch2 Hi (sort)" "Double Stripe Y-march pattern Uji version" 0x502B

WDHLD1_H "Wd-Hold1 Hi (sort)" "Write-Disturb Hold pattern-1" 0x5027

WDHLD2_H "Wd-Hold2 Hi (sort)" "Write-Disturb Hold pattern-2" 0x5028

DSYMAC2L "DS Ymarch2 Lo (sort)" "Double Stripe Y-march pattern Uji version" 0x502A

WDHLD1_L "Wd-Hold1 Lo (sort)" "Write-Disturb Hold pattern-1" 0x5022

WDHLD2_L "Wd-Hold2 Lo (sort)" "Write-Disturb Hold pattern-2" 0x5023

AC_gekko "AC test for Gekko" "AC test for Gekko" 0xAC00

AC_drive "AC test for drive" "AC test for drive" 0xAC01

AC_sdi "SDI AC measure (lab only)" "SDI0/1 AC measure. Need SDCd & Wi-Fi" 0xAC02

AC_ddr "AC test for GDDR3" "AC test for GDDR3" 0xAC03

NandIOS "NAND Flash Auto by IOS-API" "WAIKIKI output." 0x0CA2

PreWrite "PreWrite data writer for NAND flash" "WAIKIKI output." 0x0CA3

I think this raises more questions for me than it answers. Waikiki appears to be a debugging device — serial adapter? — that lives on the EXI bus. They are probably using it like a USBGecko for a console to run these tests.

I don’t know if all of those .dol files were stored on the NAND flash, and how they got them there if they were — I haven’t been able to find a trace of any of them on the flash. Pity.

Tags: Wii

36 responses so far ↓

  • 1 Nobody // Jun 14, 2008 at 5:53 pm

    To answer your question
    1. Flash IC is preprogrammed
    2. There is a programming port somewhere on the bus.
    3. There is a debug port somewhere on the bus that lets N emulate part of the CPU, similar to boundary scanning.
    4. There is an ASIC that has dedicated circuits for flash programming, and there is a debug port, memory card / SD reading, or (very unlikely) the device is programmed wirelessly.

    Since every pic of the Wii I’ve seen does not have a sticker on the flash IC’s, #1 is unlikely.

    I’d also bet that #3 is out simply because of the complexity of the endeavor.

    My guess is that #4 is true. There is probably some sort of hardware dongle required to put the unit in a ready-for-programming mode. This approach is similar to the PSP.

  • 2 penjuin // Jun 14, 2008 at 5:55 pm

    Let this be a lesson to people as to why you should securely erase your hard disk before selling it! 😉

  • 3 me! // Jun 14, 2008 at 6:00 pm

    “mouseM “USB Mouse Demo (Manual)” “OHCs control to a connected USB-Mouse.” 0x0204


  • 4 Nobody // Jun 14, 2008 at 6:03 pm

    Also, if you are not finding any trace of those apps on the NAND, they are most likely executed from the SD or memory card.

    The reason is because the Wii hardware tests most likely do some sort of comprehensive flash write / read test. While you CAN run these tests using code already stored in a flash, it’s not considered good testing practice.

    In your dumped NAND flash data for your test Wii, did you see any patterns like AA,55,CC,33,00, or FF written to the flash?

  • 5 bushing // Jun 14, 2008 at 7:17 pm

    @nobody: AFAICT, 2 /3 are not possible, although I’d love to be proved wrong. We’ve looked very hard for some debugging ports, and found nothing apart from some GPIOs which emit some simple status codes during boot.

    #4 is not possible. The NAND flash is connected to the Starlet ARM core, which is an SoC with a NAND I/O block. The ARM core has exactly one boot path inside its mask ROM — read the first 48 pages of flash, decrypt with a fixed AES key, optionally compare against a SHA1 hash stored in OTP (if it’s present), and jump to that code. See http://static.hackmii.com/boot0.html, http://hackmii.com/2008/05/boot0/ and my remarks about the Pandora Battery scenario in http://hackmii.com/2008/06/your-wii-is-not-a-psp/.

    So, that really leaves either #1 or #3.

    As far as executing tests from the same medium you’re testing — that would seem to apply to NAND flash, but also the SD card slot and the GC card slot, as tests are present in that list for all three. FWIW, I have never seen any support in the Wii for loading and executing code from somewhere other than a .dol in the NAND filesystem or from a disc.

    No, no obvious test patterns in the dump — aside from FFs where some blocks were never programmed (at the beginning and end) and 00s (for bad blocks).

  • 6 Kabili // Jun 14, 2008 at 7:53 pm

    Anyone ever watch “How It’s Made” on the Discovery Channel. Well it’s a show that shows you most of the manufacturing process of various thing. They had one that showed how a company made the electrical panels for stoves, microwaves, dishwashers, etc. Instead of putting a debug port on the motherboard, they would place a machine on top of the motherboard. The machine would make contact with all the electrical contacts on the board and test everything on the board. Maybe Nintendo does something similar to program the Wii.

  • 7 Nobody // Jun 14, 2008 at 8:39 pm


    My gut tells me that the flash is getting programmed sometime after the main board is built. There are no markings indicating that the part was programmed prior to placement. Without any markings, N’s factory could easily screw up and place an unprogrammed chip in place of a programmed one.

    That means that one of the following is happening.

    A. The part could be programmed during an in-circuit test. Are you positive that none of the address/data/control lines for the part lead to test points? Are all the vias coated with soldermask? Do you see any marring of the test points that would be caused by test probes? Are you sure that the system is not compatible with boundary scanning?

    B. If the part is blank when it hits functional test, then there MUST be a debug port or some dedicated logic that lets you load code from either the memory card, SD, or CD bus (the CD would not be attached at this point). The later would be in the form of a factory mode unlocked with a dongle or input pattern of some sort.

    One of these two has to be true. Otherwise, N is pulling off flash chips every time a board bricks during a functional test.

    You’ve combed through the code and found no evidence of a factory mode. If you are sure there is no extra logic anywhere that can facilitate it, the only plausible explanation I can come up with is “A”.


    That would mean that the build flow of the main board would be:

    1. SMT placement & reflow
    2. ICT / flash chip programming (w/ test code)
    3. Board level functional test
    4. Assemble into final unit
    5. Assembly level functional test
    6. Reprogram w/ app code
    7. Pack, ship, and sell Wii

    Medium Testing:

    The fact that you found 0xFF’s doesn’t say anything. If N runs tests on their NAND flash, they probably blank the flash to 0xFF prior to writing anything important to it.

  • 8 Nobody // Jun 14, 2008 at 9:01 pm

    BTW: Now you’ve got me thinking about when in the process they write to the OTP area.

  • 9 LittleStevie // Jun 14, 2008 at 9:37 pm

    @nobody: seeing as ATI make the chip i would assume that the OTP area is programmed on burn-in testing, i could be wrong but thats the only logical way i see this happening if none of the programming ports are externally accessable it would have to be programmed before dropping it on the motherboard.

    (sorry if that doesnt make sence i have the flu n cant think straight atm)


  • 10 Nobody // Jun 14, 2008 at 10:26 pm


    That’s what’s killing me, though. If it was done at ATI, how does N know what AES key to encrypt their flash in order to program it without the use of the Starlet?

    Answer: They can’t! They have to have some sort of external debugging method that grabs ahold of the Starlet and bends it to its will. (An Agent? LOL!) There has to be a way of forcing data into the NAND flash via the Starlet.

    That’s the only thing that makes sense, both logically and from a production point of view.

    Take, for example, the case where N needs to replace a NAND. They can’t just take any NAND and pop it on the board. They need a NAND that is preprogrammed with data encrypted by the target Wii’s key. How will they know what the key is? Will they look up the SN and reference the key from a database? Unless N was the one who initially handled the OTP programming, that would be too unreliable.

    It would make more sense if N could grab ahold of the system somehow and force data into the blank NAND flash. They could do it without ever knowing what the key was.

  • 11 Matti-Koopa // Jun 14, 2008 at 10:34 pm

    Maybe they use that NDEV device that Wii game developers are using for debug?
    Maybe they attach it to the USB ports – don’t know through…

  • 12 bushing // Jun 14, 2008 at 10:35 pm

    @Nobody: I’m inclined to agree… These pictures might help:


    The vias are not covered with soldermask; they’re not super-friendly, but they could be hit with pogo-pins. There are test points, but I haven’t found anything useful beyond that debug port (which is just 8 GPIOs that output e.g. the current flash page being read during boot0). Even under close examination, I haven’t seen any marks on any of the post points at all (which may say more about my skills of observation than anything else).

    I am *not* sure there are no JTAG pins, but again it’s a situation where I’ve gone to the ends of my imagination trying to find one.

    As for the OTP — I’m of two minds. Either they could be programmed during that factory testing — the “serial registration” — or they could be programmed while the Hollywood package is being assembled at NEC. BroadOn has a patent (http://www.freepatentsonline.com/y2005/0132217.html) which in many ways resembles the Wii, and it has language that states “The secure processor maintains the unique ID, code signatures or cryptographic hashes, and unique encryption or decryption keys, as well as any other information specific to the particular instance of the secure processor, in a non-volatile memory (such as for example an NVROM). The NVROM includes a non-bonded pin used during manufacture or configuration of the secure processor to record information specific to the particular instance of the secure processor, which is left non-bonded after manufacture or configuration, with the effect that the NVROM cannot be written a second time.” We don’t know if this applies; the OTP area seems to be embedded inside the Starlet die, so the “non-bonded pin” bit doesn’t really sound right.

    WRT the medium test: Yeah, I know what the FFs mean. What I find more interesting is that they *don’t* wipe the filesystem before shipping — otherwise I wouldn’t see any of this stuff left behind! (It’s even encrypted with the per-console AES key.) Also, the fact that that list of executables was sitting on the NAND suggests to me that it was either a logfile or a script file, stored in the NAND FS (perhaps along with the files it refers to).

  • 13 HyperHacker // Jun 14, 2008 at 10:46 pm

    Wouldn’t that be why they use OTP? ATI makes the chip, and N puts the key in it.

    It skips the hash check if the OTP is empty, right? The way I understood it OTP typically comes with all bits set, and they can only be cleared; once cleared, they can’t be set again, but you can clear more bits later. Is that possible?

    Anyway interesting find. Looks like some type of menu, with a name, description, filename, and parameters.

  • 14 HyperHacker // Jun 14, 2008 at 10:49 pm

    Ack, double-ninja’d.

  • 15 Nobody // Jun 14, 2008 at 11:34 pm


    Thanks for pointing out the OTP comment. I now see the branching in the BOOT0 code.

    I really need to dig into that tomorrow. What happens if the hash check for boot1 fails? Aside from going into lala land, does it get trapped in an infinite error loop?

  • 16 bushing // Jun 14, 2008 at 11:53 pm

    Yeah, if the hash of boot1 stored in OTP is all zeroes (which must be the default condition — I don’t think this is PROM, which comes as ones), it skips the hash check.

    If it does do the hash check of boot1 and it fails, it panicks with code F2 (meaning, it alternates between writing 0xF2 and 0x00 to the debug port / GPIO pins sitting at 0x0d800e3).

    I agree with the thought that Nintendo probably doesn’t know the per-console keys — I mean, they could grab them the way we do, but the system seems like it really *wants* to be a sealed, secure environment…

  • 17 Henke37 // Jun 15, 2008 at 3:41 am

    I would assume that the per console key can be generated by knowing the serial number.
    My guess is that they just take one of those hashing functions and hash the serial plus an undisclosed salt and then just take as many bits as they need.

  • 18 bushing // Jun 15, 2008 at 4:26 am


  • 19 marcan // Jun 15, 2008 at 4:29 am

    @Henke37: Got any proof of that?

  • 20 wowfunhappy // Jun 16, 2008 at 9:24 am


    Henke37 wrote: “I would assume that…”

    He’s just guessing.

  • 21 ZiggyTheHamster // Jun 19, 2008 at 10:55 pm

    Maybe the flash is preprogrammed with an unencrypted “installation program” or something like that on it that programs the OTP with the per-console key (which maybe it reads from the gamecube port?), erases the NAND, switches to encryption, extracts a second stage installer that runs all of the self tests and installs the base file system?

    And I mean.. what about the “Wii startup disc”? Some early launch consoles would boot up asking for that. Maybe that is part of the bootstrapping process.

    Another possibility is that AES keys are sequentially generated, or generated with a pattern, such that N knows that the 5th machine on assembly line A will have this key, and so on. Of course this would be bad if a human makes an error….

    Also just brainstorming here but maybe there is a programming port. But it’s hiding under the casing for a chip. What I’m getting at is some older computers, like the IBM PS/2 Model 55SX came with a CMOS chip made by Dallas Semiconductor. This chip is the CMOS chip as well as the CMOS battery – which is sealed in epoxy resin inside of the chip. Literally, there is a battery inside the chip. If you scratch away at the epoxy with a knife, you can get to the positive and negative terminals and attach a new battery (and cut off the original). I had to do this to my 55SX to get it to work. Maybe there are debug pins that exist on a chip that isn’t finished, or maybe on the other side of the metal casing for one of the processors, and then the chips are finished or the casing placed on them (perhaps with epoxy so you’ll never get them off).

    Anyway. Just some ideas. Probably not at all valid, but I’m trying :).

  • 22 Lyoko is Cool // Jun 23, 2008 at 8:49 am

    Is it possible that they could have programmed it with the chips having extended wires and just cut them off and soldiered them after programming.

    Sorry if none of this makes sense, I’m just starting to get interested in this and I don’t half know what I’m talking about >.>

  • 23 bushing // Jun 23, 2008 at 2:36 pm

    @Ziggy: What you mention about the pre-programmed installation program is probably spot-on. I think that’s what they have to be doing — it still means, though, that they’re preprogramming the chips, which seems strange to me.

    The boot2 that is currently shipping on Wiis is version 2 — I wonder if version 1 may be used in the factory for the above purpose.

    WRT the “Wii Startup Disc” — if anyone has one of these that I could borrow (or can send me an image of one), I’d be eternally grateful. My current theory is that the pre-launch Wiis came with a minimal stub of a system menu (1-2) that could only read “autoboot discs” (or as the Wii calls them, Diag Discs). This meant they could manufacture several thousand Wiis and even ship them to retailers for use as demo units before they finished the System Menu code. I also suspect that this might have used IOS4.

    Still, those Wiis had to have most of the current installation already set up — encrypted NAND flash, etc.

    @Lyoko: There are no wires. 🙁

  • 24 Lyoko is Cool // Jun 25, 2008 at 1:14 pm

    I would check out a local retailer the has a Wii demo and see if they still have a startup disc and see if you can borrow it, unless anyone here works at a Gamestop. >.> 🙁

  • 25 etc // Jul 1, 2008 at 4:27 pm

    […] / Factory — both of these have updates which deserve their own article.  Stay […]

  • 26 Pizza2004 // Jul 2, 2008 at 8:26 pm

    The CD drive isn’t attached yet write? Perhaps they plug something into the port for the CD drive that does this, and then they plug the CD drive in when it is done? I don’t really know anything though, so I could be very wrong.

  • 27 Pizza2004 // Jul 2, 2008 at 8:27 pm

    *I meant right, sorry about the typo. If I’m right, then couldn’t the same method be used to restore the wii or debrick it?

  • 28 bushing // Jul 3, 2008 at 12:38 am

    @Lyoko is cool: I’ve been searching for someone with a startup disc, with no success. If anyone out there has one, I’d love to either borrow it and rip it (you can have it back), or just a copy of the contents.

    @Pizza2004: You may be on to something here. We don’t understand the Disc Interface (DI) very well; one of the GameCube patents makes some mention about multiplexing JTAG lines with the DI bus. It’s something that would be worth exploring.

  • 29 Seoul // Jul 4, 2008 at 5:02 pm

    @bushing: I’ve got a launch PAL Wii, but for the disc pictured on the box, it says:

    9. Wii Disc [RVL-006{EUR)] Wii Sports.

    Does not mention anywhere in the manuals or box about a start up disc or set up disc, so I’m assuming the PAL Wii’s already had the updated firmware?

  • 30 Pizza2004 // Jul 4, 2008 at 9:36 pm

    @Seoul: The startup disk was only mentioned on the leaked contents of the box for the Wii prior to release, none actually were sold in the box to the public.

  • 31 ehntoo // Jul 7, 2008 at 12:14 am

    I’m not entirely sure if it’s helpful, but the Wii I got on launch day prompted me for a setup disc on boot, and wouldn’t do anything else. I couldn’t even sync the wiimote, leading me to believe the “setup disc” actually contained the firmware.

    I wish I hadn’t returned it now.

  • 32 factory 2 // Jul 7, 2008 at 8:43 pm

    […] (Note: this is a continuation of http://hackmii.com/2008/06/factory/) […]

  • 33 ericball // Jan 9, 2009 at 3:55 pm

    The Wii’s bootloader reminds me a lot of the Atari 7800 which had a boot ROM which would verify the digital signature of the cartridge before executing it. If the signature check failure, it would lock the system into Atari 2600 mode.

    Anyway, the following is how I would I would do it.

    First, boot0 will load an unencrypted boot1 if the OTP is zero. Thus, my assumption is this is how Hollywood delivered from the factory. The NAND is preprogrammed with an unencrypted custom boot1 along with a bunch of validation apps. After everything is soldered together, it’s put connected to an automated test station which probably controls everything via the USB port. The results are written to NAND so if there’s a failure a “fixer” can get that info and try to resolve it.

    Assuming the tests all pass, the NRAM is re-written by a the Wii itself with the encrypted boot1 and the rest of the normal contents. Then the OTP is written with the proper keys and checksums. Then the OTP WE line is locked out (by writing to a OTP bit which is OR’d with WE). Bang, Wii is now ready for shipment, no mystery bus required.

  • 34 bushing // Jan 13, 2009 at 4:57 pm

    boot1 is always encrypted; the hash is not verified if OTP is blank. However, this is not even necessary for the scenario you propose — the NAND flash chips could be preprogrammed with the production boot1 and a factory-specific (and console-agnostic) boot2. Somewhere during the factory process, the boot2 could encrypt the NAND FS with the per-console key, and then they could install the production boot2. (All of that seems to happen over the EXI bus, actually, using a “Waikiki adapter”).

    So, if they do use preprogrammed NAND flash chips, then they can do this without a magic bus, yes.

  • 35 profiles.google.com/11540748809… // Jun 19, 2012 at 3:32 pm

    (Idiot guess, but whatever)

    If Wiis aren’t manufactured with everything getting installed, wouldn’t those Wiis that face the “Insert startup disk” error have to of had some sort of stub-type thing of sysmenu on them? Since sysmenu is the only known thing that can actually talk to the DVD/CD (not sure, I think it’s DVD :P) drive, could all of the Wiis in the factory have Pre-Programmed NANDs with the Insert Startup Disk sysmenu stub? Or do they have to program directly?

  • 36 profiles.google.com/11540748809… // Jun 19, 2012 at 3:42 pm


    I don’t think it could happen through the Gamecube port. The GC ports have been scrapped in newer wiis.

You must log in to post a comment.