HackMii

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
  usb_mouse.dol”

  helllllllllo

• 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

  @Bushing

  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”.

  So…

  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)

  LittleStevie

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

  @Stevie

  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:

  http://tinyurl.com/6rlqt7
  http://tinyurl.com/64prca
  http://tinyurl.com/5rqlt8

  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

  @HyperHacker

  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

  Why?

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

  @Henke37: Got any proof of that?

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

  @marcan

  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

  @Ziggythehamster

  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.