Before jumping in this article, I’ll give you a small warning that what is written here might be quite “techy” to some people, I advise reading lots of GBAtek (And maybe a bit of dsibrew) when you get lost.

Research™ has shown that getting a DS cart to boot on a DSi requires quite a bit more effort then it did on a (DS)Lite. Cart timings are very important, you cannot eject the cartridge and insert a new one beyond the DSi menu. But most important of all, the DSi menu does additional integrity checking prior to booting the cartridge.

The integrity checking is there to ensure that the cartridge booted is a genuine licensed game cartridge. There is a whitelist stored in the DSi’s NAND, that has an entry for every DS game released, consisting of multiple SHA1 (How these hashes are constructed exactly hasn’t been confirmed) checksums for the cart header, ARM9 binary and ARM7 binary.

I hear you thinking, what about newly released DS games? How will they ever boot on a DSi without an update to the whitelist? Newer DS games come with a RSA signature in the header and so don’t need to be explicitly whitelisted.

So back to the Action Replay DSi cartridge, something that I immediatly noticed is that when the cartridge is inserted into a DSi the icon and title of the game “Game & Watch Collection” show up. That’s a little weird.. but when selecting the icon you are thrown into a AR DSi menu.

Let’s take a step back, if all game binaries and headers are checked against a whitelist or need to have a valid RSA signature, then how does this Datel cart manage to boot?

I went to find the sourcecode of my cartridge dumper and dumped the AR DSi cartridge on an old DS-Lite. after checking out the resulting binary I was surprised. No signs of the “Game & Watch Collection” ROM header or icon data, or main data for that matter..

$ hexdump -C ardsi.nds | head -n 2
00000000 4d 45 44 49 41 50 4c 41 59 45 52 20 41 53 4d 41 |MEDIAPLAYER ASMA|
00000010 30 31 00 00 07 00 00 00 00 00 00 00 00 00 00 04 |01..............|

This doesn’t match up with what I saw when the cart was booted on a DSi, huh? Neither would this cartheader qualify as anything whitelisted/valid, so there is no way it could boot on a DSi like this.

After a small discussion with neimod he showed me a cart access trace he made of a game cartridge in a DSi. Something noticeable was that a DSi would send the ROM ID cart command right after the reset command, before sending the get header cmd. My dumper software was doing it in a bit different order… (The order an actual (DS)Lite would do it in)

This small difference in order of cart commands allows the AR DSi cartridge to distuingish between a DS(-Lite) and DSi console.

For the sake of clarity:

DS-Lite cart init sequence:
CMD 9f00000000000000 # reset
CMD 0000000000000000 # get header
CMD 9000000000000000 # get rom_id
CMD ...

DSi cart init sequence:
CMD 9f00000000000000 # reset
CMD 9000000000000000 # get rom_id
CMD 0000000000000000 # get header
CMD ...

After making this small change to my dumper software, I was indeed getting back something that looked like a Game&Watch collection ROM.

$ hexdump -C ardsi2.nds | head -n 2
00000000 47 41 4d 45 20 57 41 54 43 48 20 43 41 57 54 45 |GAME WATCH CAWTE|
00000010 30 31 00 00 06 00 00 00 00 00 00 00 00 00 00 00 |01..............|


Almost there! .. or so I thought. When I started comparing the original game & watch collection ROM against the result I just dumped, I got nothing but mismatches after the initial 0x8000 bytes (header + secure area).

More and more inspection of the dump and head-to-table banging later I noticed something funny, the data in the dump at 0x8000 (right where the mismatches start) was exactly the data that was supposed to be at 0x10C00, which coincendetly matched up with the exact start offset of the icon/title data. What’s going on? Why does this data show up in the wrong location of the dump?

Then a pattern started to emerge, the right data WAS there, just in the wrong order .. then it hit me. The AR DSI cart was completely ignoring the offset field in the read (0xB7) commands I was sending, and simply advancing a preconstructed buffer that would exactly match the reply data of the commands a DSi console would normally send. This has advantage that they only need to require a bare-minimum of data of the original game ROM.

With this knowledge in hand I tried reordering the dump in order to get a final ROM image. This proved to be quite tricky since I didn’t know when what was exactly read. I then proceeded to hack up Desmume to log all cart reads and match that against a table of the filesystem to figure out in what order the files we’re read. Even now it was hard to get a good reconstruction of the dump, some files are only read partially, etc.

So I decided to build a list of MD5 hashes of each 0x200 block in the original ROM dump, and the shuffled AR DSi dump .. which was the best idea of the day. A couple of minutes later I knew in which order to put what blocks back, and was left over with 3 blocks that didn’t match (0x600 bytes total) any of the blocks in the original ROM.

Due to the preceding read commands I could see where in the dump these 0x600 bytes should go (comparing it against the
cart read access log I made using DesMuMe), and I finally had a final image. Now it was time to figure out how this
thing actually worked it’s magic. The answer was obviously in those 3 changed blocks.

To give you a quick idea of exactly how much code/data they borrowed from the original ROM, there is 1984 blocks of 0x200 bytes from the original ROM, of which 1825 blocks are unique, 1825 * 0x200 = ~912Kb of data from the original ROM.

Sure enough the 3 new changed blocks didn’t fall within the area of the ARM9 or ARM7 binary of the game, else it wouldn’t pass the whitelist. I expected it to be a file-based exploit in one of the few files within the nitro filesystem on the cartridge, but all the offsets of those files weren’t in range.

I had a quick look at the 3 new blocks in a hex editor and noticed there was plain ARM opcodes in there, and a big landpad with EAFFFFFE’s in front (label: b label). I started by disassembling this code, not caring HOW it eventually ends up in memory.

The small amount of code does some basic initialisation, then proceeds to send a special cart command that puts the ARDSi cartridge in a different mode. After this three read (0xB7) commands are executed to read and copy out the header, ARM9 binary and ARM7 binary respectively. By this I mean ofcourse the *actual* AR DSi menu header / binaries.

Knowing what their shellcode did was half of the job, now I had to figure out how it ended up executed in memory. Going back to the ROM I realized I didn’t check the *entire* filesystem range for the offset in which the blocks lie. To be more precise, I had only checked within the boundaries of the filesystem entries that have an entry in the File Name Table.

Nintendo DS ROMs can feature a thing that is known as “filesystem overlays” or “rom overlays”. These overlays are described in separate tables (pointed to by the NDS cartridge header). Overlay tables consist out of entries that look like this:

/* 0x00 */ u32 id;
/* 0x04 */ u32 ram_addr;
/* 0x08 */ u32 ram_size;
/* 0x0C */ u32 bss_size;
/* 0x10 */ u32 sinit_init;
/* 0x14 */ u32 sinit_init_end;
/* 0x18 */ u32 file_id;
/* 0x1C */ u32 unknown;


These overlays are pieces of code that normally aren’t loaded together with the main binary, but rather can be loaded on-demand by the main binary.

The important fields here are: id – a unique identifier (incrementing number) for the current overlay, ram_addr – the address the overlay is copied to in memory when it is loaded, ram_size – the size in RAM reserved for this overlay, file_id – the index of the overlay file in the filesystem table.

Cross checking the filesystem indexes of the overlays against my card access trace from desmume I determined that the 3 changed were infact the first 3 blocks of overlay 0x01.

To not make this article any more lenghty than it already is, here’s what happens:

• DSi console sends cart initialisation sequence
• ARDSi cart determines it’s being ran on a DSi console and starts responding a fixed pattern on every read block request
• Game’s header, ARM9 and ARM7 binary are loaded by the DSi menu and checked for integrity
• Integrity checks pass since all data is 1:1 compared to the original ROM
• Game starts running, parsing filename and file allocation tables of filesystem on cartridge
• Game loads overlay 0x01 to 0x020BBF00
• Game does more stuff and eventually branches to code inside loaded overlay @ 0x020BBFE8
• The initial 0xE8 bytes of the datel payload are inifite-loop opcodes, entrypoint right behind it, payload gets executed
• Payload sends secret F005000000000000 (Not so secret anymore now, huh?) cart command to put cartridge in secondary mode
• Payload uses normal 0xB7 read commands to read the header, ARM9 binary and ARM7 binary respectively
• Some IPC magic is done to capture execution of the ARM7 cpu
• Finally a softreset SVC/SWI is issued to execute the newly loaded ARM9 code

And here I was hoping datel had a clever technique under their belt to leverage code in DS mode on a DSi. But it seems like everyone else (read: HK flashcart companies), they aswell had to resort to ‘borrowing’ bits of a commerial game ROM. The only clever thing here is storing the actual payload inside a ROM overlay that is loaded early in the game. The overlays dont seem to be checked by the DSi menu during the integrity check, and they don’t have to rely on a buffer overflow or other tricky attack in order to get their code running.

EDIT: Normmatt just mentioned on IRC that the DSi menu might be infact checking the ROM overlays. Comparing the SHA sums in the whitelist for a game that has overlays and for a game that doesn’t shows that one of the hashes is empty for a game that has _no_ ROM overlays. This all make sense, the DSi menu initially reads the overlays to check their integrity, but when the game is ran it loads the overlay on demand, different data is served and the system is fooled into loading the malicious code in memory.

The thing I’m wondering most is how Datel was planning to get away with this? Someone mentioned the argument of the ROM data being there “just for interoperability” and that would justify it a bit. But in my opinion borrowing roughly a megabyte of original ROM data is a different ballgame than borrowing a couple of (Ok, 48) bytes for the Nintendo logo. I would be interested to hear you guys’ opinions on the ethical part of this whole thing.

Oh well, it made for a nice sunday of reverse engineering anyway. Hopefully you enjoyed the read as much as I did working this out, ciao! ;-]

P.S. Oh, and before I forget here’s some bonus picture material for you all.

P.P.S If you are interested in the quick disassembly I did: click here. Sorry for not having used the correct base-address in that listing, but the code is position independent, you should get the idea. I hope datel doesn’t mind me ‘borrowing’ something from them.

In order to hinder Nintendo’s attempts at fixing it, and to avoid misuse by warez kiddies, sven and I had a lot of fun obfuscating the exploit over a couple afternoons. We decided not to release information about it, hoping it would last long enough to be useful for future installers and BootMii. Later we kind of forgot about this, but on a few occassions people have asked us to document it, and we proposed a challenge: we would document the exploit as soon as someone “broke” our obfuscation and figured out how the exploit works. The intent was to promote reverse engineering and also see just how long it would take people to crack it. Apparently, either people weren’t very interested or we did a pretty good obfuscation job, because it took pretty long

Well, I’m happy to say that today I received an e-mail from an anonymous hacker who successfully reverse engineered our layers of obfuscation. He (or she!) discovered the inner workings of the STM Release Exploit, as I will be calling it, and did so after three weekends of reverse engineering. Hats off to you, and thank you for taking the challenge!

This bug was discovered by accident, and in fact it is a real honest-to-goodness software bug that is not only exploitable, but a nuisance during regular use. To understand it, you need to understand how STM works.

STM is the IOS module in charge of random hardware functions such as handling the fan, “idle” (WC24) mode, the front slot LED (including the blink patterns), and the buttons. I have no clue what STM means, but I’ve seen it called “State-TM” somewhere on the Wii. One of the main functions of STM is to provide a way for PowerPC software to get notifications when either the Reset or the Power buttons are pressed. It’s worth noting that I have no clue why they did this –the PowerPC already knows about Reset via the legacy GameCube interface, and can be given direct access to Power including IRQ via the shared GPIO system, and IOS doesn’t use these buttons at all– but they did. It works like this: STM creates two devices, an “immediate” device, and an “event” device. The immediate device is used to issue commands to STM that take effect immediately, while the event device is the callback mechanism. The PowerPC code issues an IOS_IoctlAsync() call on the “event” device, and this call blocks (asynchronously) until there is an event (such as a button press). When this happens, the call returns with the event code, and the PowerPC code reissues it to listen for further events.

One problem with this approach is that the PowerPC needs a way to shut down the event callback. The IOS IPC mechanism doesn’t provide a way for the PowerPC to cancel an ongoing request; it must wait until its completion. When PowerPC code needs to hand off execution, it needs to clean up all references and file descriptors to IOS, so it needs a way to get rid of the event call. STM implements this by having a call on the immediate interface that forces the event call to return with a zero event code. So far so good. If you’re interested, check out stm.c on libogc (particularly the functions with EventHook in the name).

In order to better understand the mechanism, it’s worth looking at the individual messages as they are exchanged with IOS. Here’s what it might look like:

Now, when I was reverse engineering STM, I noticed that things didn’t work well when using the Twilight Hack. This is because Zelda’s STM eventhook is still active, and STM won’t let you register a new one. So I added an STM eventhook release to the Twilight Hack code. One slight issue is that we can’t know if there was an old eventhook or not, depending on what the state of the machine was (since the Twilight Hack can be relaunched from software, as an SD loader of sorts, and this was popular in the early days), so we just make it attempt to release the eventhook always. This is fine, as the release function will return an error if there is no eventhook active.

Then IOS started crashing sometimes.

Looking closely at the release function in STM, here’s what I found:

release_eventhook
                 MOV     R12, SP
                 STMFD   SP!, {R4-R6,R11,R12,LR,PC}
                 LDR     R4, =hook_msg
                 MOV     R6, R0
                 SUB     R11, R12, #4
                 LDR     R0, =aRelease
                 BL      printf_disabled
                 LDR     R3, [R4]
                 MOV     R5, #0
                 CMP     R3, R5
                 MOVL    R1, -6
                 MOV     R0, R6
                 BEQ     loc_20300C04

loc_20300BD8
                 STR     R5, [R4]
                 MOV     R0, R3
                 LDR     R3, [R3,#0x18]
                 MOV     R1, R5
                 STR     R5, [R3]
                 BL      AckMessage
                 MOV     R0, R6
                 MOV     R1, R5
                 BL      AckMessage
                 LDMFD   SP, {R4-R6,R11,SP,LR}
                 BX      LR

loc_20300C04
                 BL      AckMessage
                 LDR     R3, [R4]
                 B       loc_20300BD8

This translates to the following C code:

struct ios_message {
    // this isn't exactly right on the IOS side, but it doesn't matter here
    u32 command;      // 0x00 = 6 for ioctl
    s32 result;       // 0x04
    s32 fd;           // 0x08
    // arguments for ioctl
    u32 ioctl_number; // 0x0c
    void *buffer_in;  // 0x10
    u32 in_size;      // 0x14
    void *buffer_out; // 0x18
    u32 out_size;     // 0x1c
};

struct ios_message *hook_msg;

void release_eventhook(ios_message *imm_msg)
{
    struct ios_message *the_hook_msg = hook_msg;

    printf_disabled("Release\n");
    if (!the_hook_msg) {
        AckMessage(imm_msg, -6);
    }
    hook_msg = NULL;
    *(u32*)the_hook_msg->buffer_out = 0;
    AckMessage(the_hook_msg, 0);
    AckMessage(imm_msg, 0);
}

Notice anything wrong? They forgot a return; statement right at the end of the if(!the_hook_msg) block! This means that if there is no callback registered, it will try to ack the immediate message twice (which does nothing), it will try to ack a NULL message (which the kernel catches and does nothing), but most importantly, it will dereference a NULL structure, get a pointer from it, and write 0 to the address pointed to by that pointer. In other words, that line of code becomes **(u32**)0x18 = 0;, as 0x18 is the offset of buffer_out inside the structure. And 0x18 is an address in low MEM1 that we completely control from the PowerPC. Whoops.

In the Twilight Hack, this location usually contained some odd value, which caused IOS to crash with an unaligned access exception. We added a workaround in a later release of the Twilight Hack so IOS will no longer crash. It looks like this:

    // STM bug workaround
    // On attempt to release callback when it's already released
    // or when it has fired and auto-released, STM dereferences a
    // member of a NULL IPC structure and then tries to write 0
    // to outbuf. End result, STM tries to:
    // **((u32**)0x18) = 0;
    // so we set 0x18 here to a valid address (0x14) to prevent
    // a crash.
    *((u32*)0x80000018) = 0x00000014;
    sync_after_write((void*)0x80000014, 8);
    printf("Releasing STM callback...");
    /* ... */

The comment was removed from the Twilight Hack public source code release ( ), but the code is still there.

I chose IOS34 for the exploit because it is not used for homebrew or any games that I own (so I can patch it for debugging with impunity), and it shares the same STM binary with IOS35, which is mostly what I’ve been reverse engineering. The exploit is quite simple: we simply find the address of the stack location that contains the return address for the function (LR), and write it to 0x18. Then we release the STM callback twice. The second time around, STM zeroes out the return address and the function returns to execute code at address 0. We place our own code there, and clean up afterwards by jumping to the real return location, so STM keeps on running happily.

But wait, we need to somehow break into the kernel to disable the signature check. How can we do that? Well, it turns out that Nintendo left behind some useful IOS syscalls. They look like this:

wtf1
                 MOVS    R3, #3
                 STR     R3, [R0]
                 MOVS    R3, #0
                 STRH    R3, [R1]
                 BX      LR

wtf2
                 MOVS    R3, #1
                 STR     R3, [R0]
                 MOVS    R3, #0
                 STRH    R3, [R1]
                 BX      LR

Which translates to:

void wtf1(u32 *a, u16 *b)
{
    *a = 3;
    *b = 0;
}

void wtf2(u32 *a, u16 *b)
{
    *a = 1;
    *b = 0;
}

These functions appear to be used as configuration for certain global settings, such as whether IOS is monolithic or modular, so they just return constant values by dereferencing their arguments. In any case, there are no permission checks and these calls happily write to any address that you want, with full kernel permissions. We just pass along an address inside the signature check function that we want patched out, and we win.

Now, this exploit isn’t just caused by the small bug in STM; it’s also a consequence of poor security in IOS in general:

• IOS should unmap the zero page and cause NULL dereferences to abort.
• IOS should NEVER allow or use execute permission for memory controlled by the PowerPC (!!!).
• IOS system calls should be code-reviewed and checked for validation of arguments, as they are critical to security.
• Nintendo needs to backport security fixes to all IOSes. They had found the syscall bug and fixed it in newer IOS forks, but this is useless without backporting it back to all older IOSes. In fact, changes like that draw attention to the bugs.
• Which of course brings us to the fact that having dozens of forks of security-critical software is a maintenance nightmare and a really really bad idea.

Unfortunately, given later exploits and Nintendo’s changes to IOS, it seems they can’t be bothered to do any of the above. They fixed the STM bug and backported the syscall fix from other IOSes, but there are others with similar bugs.

Hope you had fun reading this latest episode of How To Pwn a Nintendo

The N64 chips are different, and I haven’t seen a ROM dump of those yet, so all of the following is NES/SNES only.

There is one chip inside the console, and one in every cartridge; the code inside the chip decides what to do based on a pin strap (the console one will be the “lock”, and the cartridge one will be the “key”). The two chips run off the same clock, and they run the same code, so they run in lockstep (sometimes they execute different codepaths, but the code is careful to take the same number of cycles on both paths in these cases). The chips communicate over two wires, one from key to lock, one from lock to key. Both chips calculate what bits they will send, and what the other guy should send; if what they receive is not the same as what they should have received, they panic, and the lock chip resets the console.

Here is the pinout of the CIC:

              +------------------+
 DATA_OUT <-- | 1 P0.0    +5V 16 |
  DATA_IN --> | 2 P0.1        15 |  ?
     SEED --> | 3 P0.2        14 |  ?
LOCK/-KEY --> | 4 P0.3        13 |  ?
              | 5 Xout   P1.3 12 | <-- RESET_SPEED_B
              | 6 Xin    P1.2 11 | <-- RESET_SPEED_A
              | 7 RESET  P1.1 10 | --> SLAVE_CIC_RESET
              | 8 GND    P1.0  9 | --> -HOST_RESET
              +------------------+

The LOCK/-KEY pin is the strap pin I talked about above. The SEED pin has a capacitor connected to it; the discharge time of that is supposedly somewhat random, the lock chip times it and uses that as a random generator, to decide which of 16 possible streams to generate. It tells the key chip which one it chose.

The lock chip can reset the key chip (pin 10 on the lock is wired to pin 7 on the key), and it can reset the console. The RESET_SPEED pins are used on the 3195 to decide at what speed to “blink” the reset line (it’s connected to a LED as well): about 0.4s, 0.6s, 0.8s, 1.0s each of on/off.

There are dumps of the ROMs here, here, and here. All credits for doing these go to neviksti; thanks!

All the bits in those dumps are inverted (0 vs. 1); if you want to play along with the disassembler I’ll give a link to in a second, you’ll need to fix that; also, that third ROM is 768 bytes, which I don’t handle in my little conversion script, so you’ll need to remove the extra columns (they are empty anyway). Or enhance the script if you want to.

Okay then, here is that disassembler. Usage should be self-explanatory.

This ancient CPU looks mighty strange to modern eyes. Let me try to explain the architecture:

First, it is a 4-bit CPU. Yessir. It has an accumulator register, A, and a secondary register, X, both 4 bits. All RAM accesses are done via a single pointer register B, which is 6 bits; the CIC chip only has 32 nybbles of RAM though. There is also a carry flag, C.

Then, there is the process counter, PC. It is 10 bits, but there are only 512 bytes of ROM (except on the 3195, it has 768). The ROM is divided into banks of 128 bytes. When the CPU increments PC, it never touches the bank number.

Well, “increments”. To save chip area, they didn’t use a binary counter, but a polynomial counter; “incrementing” works by shifting the PC by one bit to the right, and setting the the top bit to 1 if and only if the bottom two bits were the same.

There are no conditional branch instructions; instead, various instructions can skip the next instruction if some condition is true (the instruction still takes time, it just doesn’t do anything). Oh, all instructions take one cycle; except for the two byte instructions, which take two cycles.

Finally, there is a four entry stack for the PC; it’s not in RAM, it is separate.

Now the instruction set:

"skip" means "do not execute next instruction"
"M" means "the RAM nybble addressed by B"
"BL" means "the low four bits of B"
"BM" means "the high two bits of B"
"PN" means "I/O port number BL"
"x.y" means "bit y of x"

00+N  adi N     "add immediate", A := A + N, skip if overflow   (00 is nop)
10+N  skai N    "skip acc immediate", skip if A = N
20+N  lbli N    "load B low immediate", BL := N
30+N  ldi N     "load immediate", A := N

40    l         "load", A := M
41    x         "exchange", swap A with M
42    xi        "exchange and increment", swap A with M, increment BL, skip if overflow
43    xd        "exchange and decrement", swap A with M, decrement BL, skip if underflow
44    nega      "negate acc", A := -A (two's complement)
46    out       "output", PN := A
47    out0      "output zero", PN := 0
48    sc        "set carry", C := 1
49    rc        "reset carry", C := 0
4a    s         "store", M := A
4c    rit       "return", pop PC from stack
4d    ritsk     "return and skip", pop PC from stack, skip
52    li        "load and increment", A := M, increment BL, skip if overflow
54    coma      "complement acc", A := ~A (ones' complement)
55    in        "input", A := PN
57    xal       "exchange acc and low", swap A with BL
5c    lxa       "load X with acc", X := A
5d    xax       "exchange X and acc", swap X with A
5e     ?        SPECIAL MYSTERY INSTRUCTION

60+N  skm N     "skip memory", skip if M.N = 1
64+N  ska N     "skip acc", skip if A.N = 1
68+N  rm N      "reset memory", M.N := 0
6c+N  sm N      "set emmory", M.N := 1

70    ad        "add", A := A + M
72    adc       "add with carry", A := A + M + C
73    adcsk     "add with carry and skip", A := A + M + C, skip if overflow

74+N  lbmi N    "load B high immediate", BM := N

78+N NN  tl NNN    "transfer long", PC := NNN
7c+N NN  tml NNN   "transfer module long", push PC+2, PC := NNN
80+NN    t NN      "transfer", low bits of PC := NN

It would seem that on the 3195, the sc and rc instructions are swapped, as are the coma and nega instructions.

If you look at the code in the ROMs, you’ll notice something strange with the ldi instructions: sometimes it runs two in a row. Descriptions for similar CPUs say that if you have two or more ldi instructions in a row, all but the first are skipped. The code still doesn’t make sense then; I suspect that this CPU does this skip only if some condition that I do not know yet is true.

This architecture is quite different from what we are used to today, and so it requires quite different programs; I’ll leave it to you to discover all the intricacies yourself though, it’s more fun that way!

I put a commented disassembly of these ROMs here. Some of that is a work in progress.

I hope you all find this as fascinating as I did!

[edit: fixed op 52 "li" description]

I’ve tried to create a similar environment here (on this blog), on IRC, and to a lesser extent, on the Wiibrew forum. I realized that there is a need for a place where we can have high-quality conversations over a long period of time, and where we can moderate out all the noise.

So, my latest experiment is http://lostscrews.com/ — come by, read the explanation, and participate!

We once again managed to snag a couple of tables in the Hackcenter for console hacking, and we did actually have a few consoles — mainly some Wiis and DSis in pieces.  Hardware was exchanged, and we looked at soldering the 50+ wires needed to connect up a twlfpga board to a DSi and just sort of gave up due to lack of lighting and the chaotic environment.   No, CCC is more of an occasion to meet old friends and make new ones.  I was also selling Proxmark3s that I had made for the occasion, and had the chance to meet some of the people behind that project.

There were plenty of interesting talks, and the nice thing about CCC (compared to the American conferences I’ve been to) is that you can watch them from home, either live via streaming video, or download the video in a variety of formats after the conference.  Here are some of the ones I considered to be personal highlights:

All presentation links contain a further description and slides or a video torrent.

• GSM: SRSLY? was a talk on how it’s now possible to launch passive and active attacks on GSM calls with <$10K of equipment (depending on the setup).  Fascinating and scary stuff — they were supposed to give the world’s first public live demo of this on the fourth day of the conference, but were threatened and backed out of it at the last minute.
• Building a Debugger was one of the more personally interesting and useful ones; Travis Goodspeed talked about his neighborly open-source “universal” hardware debugger interface / serial interface, GoodFET.  It currently supports a couple of JTAG-based protocols (mainly TI products, but there’s no reason you couldn’t add support for other processor families) and SPI-based protocols (SPI flash, AVR ISP).  It also supports voltage-glitching, and Travis explained how you can use that to read out the code from locked AVR chips.  It’s free as in speech, and about as close to free as in beer as you can get — if you can solder a couple of surface-mount parts, Travis will be neighborly enough to send you a free PCB if you email him and ask nicely (see the project webpage for his email address), and you can sample one of the chips for free from TI and then order the other one from DigiKey, etc.  Neat stuff — I used the SPI flash client to dump the SPI flash chip on the DSi’s Wifi dongle.   He also introduced a new “FYN-FYTN protocol“, which was unfortunately cut from the final, archived video — fortunately, I preserved it for posterity.
• Finding the key in the haystack was a great introduction to Differential Power Analysis, a side-channel attack on AES which shows a lot of promise for use on things like the DSi (if you can wade through the math, at least )
• Blackbox JTAG Reverse Engineering (by our very own tmbinc!) gave a great insight into how JTAG actually works and how it can be used on random devices.  We’re still looking for it on the Hollywood and the DSi’s CPU…

There are too many presentations for me to list, so I suggest you go look at the full schedule yourself.

Afterwards, we went to the traditional c-base afterparty, where we gave marcan a couple of drinks and watched him code up a rotating cube on the spot on some random computer.

Sadly, I can’t say that we have any new breakthroughs from the event — work still is underway on the DSi front.  If nothing else, it was a lot of fun to see everyone — I believe we had the majority of Team Twiizers in attendance.

We will not be presenting anything this year, sorry!  There’s not much new to report with the Wii, and we don’t have anything complete enough to show for the DSi.   Also, honestly, I’m looking forward to actually getting some sleep this year and seeing some presentations — I barely emerged from the basement for the last two years.

If we do get some space to set up, we’ll probably have at least one Wii, hopefully a DSi-hacking setup, and then you’ll get to see the rest of the projects that have occupied our time over the last year — lasers, all sorts of SunPlus devices, etc.  Should be good times.

Post a comment if you’re planning on attending.

I don’t have an actual explanation for any of the 4.2 bricking, and I suspect Nintendo doesn’t really, either — I don’t think they keep a copy of the NAND keys for each device, and I doubt they have any readily-available way of retrieving them.   As a matter of personal curiosity, I would be interested in doing a post-mortem on such a Wii myself.

If you have a bricked Wii that fulfills the following requirements:

• Worked just fine before the 4.2 update
• Is now unusable after the 4.2 update (black screen, error message from system menu, etc)
• Has an old, vulnerable boot1 (such that BootMii/boot2 could be installed), or
• Has a known set of keys (either from a BootMii NAND backup or running xyzzy at some point in the past)
• Did not have anything too odd done to the system menu or boot IOS (but I’m a bit flexible on this point)

… please let me know.   I would be interested in getting a dump of the NAND from the system so I can figure out exactly what caused it to die — if you already had such a dump (and the keys), that would be great, but if I not I could dump it myself (again, assuming you have the keys or it’s old enough that I could install BootMii/boot2 with a flash programmer.)

Somewhere in the noise about this most recent update the point I was trying to make got lost.  Let me recap the facts:

• The most recent system update was the largest update ever done — 32 titles were added or updated, and each system downloaded approximately 50MB of data.
• A certain firmware graybeard tells me that, on average, 1 in 1000 updates (of any software, on any system) will fail.
• The Wii performs updates atomically on a per-title basis.  What this means is that the system menu downloads each title from the Nintendo Update Server and feeds the data directly to IOS/ES.  As each chunk of data for a given title is downloaded, IOS writes it into /import, and then once the entire title has finished downloading, it renames the files in /import to overwrite the older version of the title (in one step, “atomically”).  That rename step probably only takes a second or two for each title.
• Contrary to Nintendo’s claims, an update will not start over from the beginning if interrupted.  Rather, the updates will be downloaded and installed in this order: boot2, IOS of the new system menu, a new system menu, and then everything else.  If the update is interrupted after (for example) the IOS is installed but before the System Menu has finished downloading, the partially downloaded System Menu will be deleted upon the next reboot.  You will still be told “an update is available”, and it will restart the update — but since it won’t reinstall the same version of something that’s already there, it will skip over boot2 and the IOS and restart downloading the system menu.
• Any failed update on three of those pieces (boot2, system menu, IOS) will cause the system to irreparably brick.
• Any failed update on another part of the system (for example, another IOS) could either cause strange behavior (certain games won’t launch) or could cause the system to brick (if it damaged the filesystem in NAND).

As far as updating boot2 goes:

• The 1-in-1000 number applies to boot2, although there are some protection mechanisms in place to try to mitigate that risk.   There are two separate copies of boot2 stored in flash, and if one is corrupted, it will try to boot the other — this is the only real “safety mechanism” in the entire device.
• The boot2 update code is completely separate from any other update code, and has never been used before on any retail Wiis.  That does not mean it’s necessarily broken or buggy, just that it has been nearly as well-tested as any of the other updater code.
• During the development of BootMii/the HackMii Installer, I ran into a bug where the ECC data was not always written when writing boot2.  Let me be clear here — this is not a huge bug.  It only applies to the boot2-area blockmap page, and when it happens, the effect is generally harmless — if there is a bit error in that page, it will not be detected or corrected, but there are three copies of that data in that page and boot1 will choose the best 2 out of 3.  (The only real indication you will see of this is if you find the message “Ninty forgot to write spare data for page xxx” in your installer.log file after installing BootMii/boot2.)  I don’t really think this will cause a system to get bricked, but it’s evidence that the code has not been thoroughly tested.
• Our boot2 updater code presumably carries the same 1-in-1000 risk of failure, but a failure there will still allow at least one of the two old copies of boot2 to work.  (We do something mildly clever there to avoid overwriting each copy, and to prevent problems with BC/MIOS.)
• There is no benefit or pitfall to installing boot2v4, other than the fact that if you don’t install it, it will keep trying to install it whenever you update, and if you had BootMii/boot2 installed, it will overwrite it.

Various employees of Nintendo — from lowly tech support staff and forum moderators to executives — have made the claim that “most of the bricked systems were a result of other modifications to the system.”  This is a lie, and I’m disappointed in Nintendo for trying to make this claim.  It’s not supported by evidence — how could they possibly get that kind of statistic?   (There hasn’t been time for them to get bricked units back and do much analysis, and even in the case where they do have a bricked console in their hands, there’s nothing they can do to see whether it was modified or not.)  It’s not supported by logic, either — the reason why this update “kills homebrew” is because it overwrites EVERYTHING, but the same is true for unmodified Wiis.   It’s not even supported anecdotally — there were comments on Nintendo’s official Tech Forums from people who had bought a new Wii that day and had it brick the first time they did their connection test and system update.

If we were to write a boot2 installer, there’s no guarantee that it would be any safer than Nintendo’s.  We sincerely believe it to be safe — we’ve tested it as much as we possibly can, we have an unreasonable number of safety checks in there, and I have yet to hear of a single case of bricking in somewhere between 10-20,000 installs — but then again, I’m sure Nintendo feels the same way about their code.

The distinction here is a more subtle than “whose code is buggier”.  When you run the HackMii installer and install anything we’ve written, you are taking some risk.  The difference here is that

• For the (say) 20,000 people that run the HackMii installer, each one of them has done so deliberately and with some goal in mind — tinkering with their system, playing homebrew games, whatever.  In the case of BootMii/boot2, we even give you a strong defense against bricking your console through updates (oh, the irony).  If you run into problems, you can be mad at us, you can be mad at yourselves, but at the end of the day, you took a calculated risk.
• For the 55 million people who own Wiis but did not run the HackMii Installer — yet are forced to update anyway — they run the risk of bricking with no tangible benefit to them whatsoever, and no choice in the matter.

If we take this 1-in-1000 statistic of failed updates, and say that 1-in-100 of those failed updates will result in a bricked system, and then extrapolate that over the top two groups — you end up with maybe one or two homebrew-running people with bricked Wiis, and 550 unmodified, bricked Wiis.  If you have one of those, go to Nintendo and ask them to fix it for free.   If you haven’t updated, there’s no good reason to — other than to stop it nagging at you to update.   If you do feel compelled to update, your chances of running into problems are no better and no worse than anyone else’s,  and they wouldn’t be much different if we wrote the update code instead of Nintendo.

This is the reason why it’s a big deal when anyone releases a bootloader update — it’s inherently risky, and for most people, it’s not worth the risk.

And please:

• Read our updated FAQs first. For the HackMii installer and The Homebrew Channel, see here. For BootMii, see here. Better read those twice.
• We have a bug tracker. If you think you found a bug, be so kind and open an item here.

Download.

As always: Please link to this post instead of mirroring the binary, thanks.

Enjoy.

Beware: Everything installable with this installer works with every system menu version, you do not have to update to v4.2! We even advise you not to update! On the last article bushing wrote:

The [boot 2 update] code [from Ninty] is so buggy that we decided to write our own for the HackMii installer.

It’s really sad, but that wasn’t exaggerated at all. The first reports about bricks due to this official boot2 update are reported on Nintendo’s forums. Replies, which Ninty doesn’t like, are getting deleted. Anyway, it’s up to you if you want to risk it.

If you already updated to v4.2, this version is the only one that works. If you don’t have HBC installed, use e.g. Indiana Pwns to launch this installer.

If you want to update to v4.2, you should install HBC before updating. Because of the new title IDs, the HBC and DVDX version from this installer won’t get deleted on v4.2. Installing the new HBC before updating ensures that you have a working HBC afterwards.

If you updated to v4.2:

• BootMii/boot2 was wiped only if your boot2 version was v2 or v3. Just reinstall it.
• BootMii/IOS will still be there.
• DVDX got deleted, reinstall it.

General advice: Don’t use some random update application, just update through the system menu if you really want to update.

General note: If you install anything with this installer version, update all the components you have already installed. E.g.: BootMii required some changes too, so the HBC with the new title ID gets loaded.

Note about DVDX enabled applications: Because of the new title ID, all current applications will fail to load DVDX. libogc needs additional code that checks for the new title ID. All DVDX enabled apps need to be recompiled afterwards.

Because Ninty fails to deliver new features with the latest update, I guess we have to compensate for that. Focus on this release are the promised improvements for HBC.

The changelog:

HackMii installer (v0.5):

• New exploit to enable (un-)installation of all components on fully updated Wiis.
• Fix hangs on some setups (they’re all related to retarded IOS patches).

BootMii beta 4 (v1.1):

• Properly write the keys to nand.bin.
  This fixes the “NAND dump is from another Wii” issue on restoring beta 3 backups. If you don’t know how to fix those dumps, you have to backup the NAND again. Dumps from all other versions are not affected.

The Homebrew Channel v1.0.5:

• Faster startup.
• Prefer boot.elf over boot.dol when launching apps.
• New shiny fonts, tweaked to the last subpixel.
• Widescreen support.
  If your Wii is set to 16:9 in the system menu options, HBC won’t stretch the picture like it did on older versions. Unfortunately the fonts might look a little weird then, it really depends on the used display unit. Blame the lack of true widescreen support on the Wii for that.
• Grid view.
  Hit 2/Y while browsing applications to switch between the old and the new view. This shows 4 columns on 16:9 setups, 4:3 users only get 3.
• Device hot-plugging.
  You can remove and insert devices (front SD slot, USB mass storage, and SDGecko in both slots) at all times now without reloading HBC.
  To change to another device, hit 1/X to bring up a simple option dialog.
• Application sort order.
  You can now choose how to sort the shown entries. Current options: either by the name or by the release date.
  Note that for the latter sort order a valid release_date tag has to be present in the meta.xml file.
  Again, hit 1/X for the options dialog to set this.
• wiiload overhaul.
  On-the-fly compression: Uploaded files are automatically compressed on PC side: This makes it way faster, especially on bigger files. ScummVM, anyone?
  Improved USBGecko support: Faster uploads, and you don’t have to stop reading debug messages from the device while uploading files.
  libftdi support: Because ftdi-sio fails, especially on OSX.
  Note: Because of these improvements, older wiiload version and 3rd party upload clients are incompatible. Use the bundled v0.5, binaries and source code are included.
• Basic application management.
  To add apps: Just wiiload a ZIP archive, it will then get extracted to the active device. The ZIP file must be structured in a certain way, check this description for the details.
  To delete apps: There’s a new button on the application dialog.

DVDX:

• Allow PPC side hardware access.
  Also known as the magic HW_AHBPROT register.
• TMD version bumped to 2, in case anyone needs to check for e.g. HW_AHBPROT.

Either grab the new installer here, or use the HBC online update (a confirmation dialog should pop up when launching HBC).

As always: Please link to this post instead of mirroring the binary, thanks.

Enjoy.