Snake2 for Wii is a Wii homebrew version of the game snake.

June 19. 08 - v2.1 beta
Added Twoplayer Mode
Added Sound (again)
Added Menu
June 04. 08 - v2.0
Added Wiimote Support
Added New Look And feel
Added Score Displaying while the Game is running
Added eyecandy

Duck Hunt is a clone of the classic NES/Famicom game Duck Hunt where you shoot ducks.

All are welcome to try my first Wii project, good ol' Duck Hunt

I have tried my best to replicate as much as the original that I can. This is my first wii experience, so I hope you all like it, I can be found hanging around #dsdev and #wiidev on the Blitz IRC network. Many thanks to Wintermute and the others there for helping me understand what is going on with the Wii.

The earlier versions of this game were not meant to really be posted to the general public, but whoever did that, thanks, now I have some motivation to fix this game.

I am now up to version 1.8.

With this version, I fixed up some bugs from v1.7 and added some things that are listed below.

For 1.9, I am going to add sound and hopefully fix up the source code for better handling of the controller, and get the levels working

If you notice any bugs, please feel free to let me know, I would like as many bugs squashed for original version by the time I release v2.0

Everything but clayshooting that is.

Following various bug appeared in version 0.5, I just put online version 0.6 of Wii Homebrew Launcher. The problems encountered in version 0.5 is due to mismanagement of memory, I implement a memory manager to manage and use the memory MEM2 of the Wii, leaving a maximum of conventional memory to load homebrews.

In addition, the library LIBOGC was last for days and benefit from the rapid initialization of the wiimote (more pressing need (1) + (2)).

Finally, it is possible to use the lever classic. The new version the ELF, DOL and WAD (string) is available in the Downloads section.

Okay, I’ve spent a little bit of time trying to reconstruct the C code used to build the channel from my disassembler. The full IDA Pro output for those funcs is here: http://static.hackmii.com/verifyzelda.html.

Below, you’ll find my C version. I’ve tried to make it function exactly like the one in the new system menu. Hopefully I did a good job, because I’d like to see people try to find bug in this that could lead to an exploit. There are at least two here, which we used in combination; can you find any more?

Don’t worry, I’ll give the answers if nobody gets them

// this helper function gets called during the NAND check
// for the TP hack files

int ipl::utility::ESMisc:eleteSavedata(u32 titleid_h, u32 titleid_l) {
char pathname[0x100];
int deleted_files = 0;

sprintf(pathname, “/title/%08x/%08x/data/”, titleid_hi, titleid_lo);

int num_dir_entries = 0;
int retval = nandReadDir(pathname, 0, &num_dir_entries);
if (retval != 0 || num_dir_entries == 0) {
OSReportError(”iplESMisc.cpp:eleteSavedata: ”
“Could not read1 %s: %d\n”, pathname);
goto done;
}

dirent_t *direntries=malloc(sizeof dirent_t * num_dir_entries);
if (direntries == NULL) {
OSReportError(”iplESMisc.cpp:eleteSavedata:”
“Could not alloc: %d\n”);
goto done;
}

retval = nandReadDir(pathname, num_dir_entries, direntries);
if (retval != 0) {
OSReportError(”iplESMisc.cpp:eleteSavedata: ”
“Could not read2 %s: %d\n”, pathname);
goto done;
}

int i;
for (i=0; i < num_dir_entries; i++) {
char buf[0x100];
strcpy(buf, pathname);
strcat(buf, direntries[i].filename);
retval = NANDPrivateDelete(buf);
if (retval != 0) {
OSReportError(”iplESMisc.cpp:eleteSavedata: Failed to delete %s: %d\n”, buf);
goto done;
}
deleted_files = 1;
}
done:
if (direntries != NULL) free(direntries);
return deleted_files;
}

// this function is called upon boot or something
ipl::utility::ESMisc::VerifySavedataZD(u32 titleid_hi, u32 titleid_lo) {
int savegame_bad = 1;
char pathname[0x100];

sprintf(pathname, “/title/%08x/%08x/data/%s”, titleid_hi, titleid_lo, “zeldaTp.dat”);

if(ipl::utility::ESMisc::ChangeUid(titleid_hi, titleid_lo)==0) goto done;

int retval = nandPrivateOpen(pathname, &fd, O_RDWR);
if (retval == -ENOENT) {
OSReportError(”iplESMisc.cpp::VerifySavedataZD: Does not exist %s: %d\n”, pathname);
goto done;
}

if (retval == 0) {
OSReportError(”iplESMisc.cpp::VerifySavedataZD:O pen save data file failed: %d\n”);
goto done;
}

u32 file_length;
retval = NANDGetLength(fd, &file_length);
if (retval != 0) {
OSReportError(”iplESMisc.cpp::VerifySavedataZD:G et file length failed: %d\n”);
goto done;
}

char *buf = malloc(file_length);
if (buf == NULL) {
OSReportError(”iplESMisc.cpp::VerifySavedataZD: Alloc failed: %d\n”);
goto done;
}

int bytes_read;
bytes_read = NANDRead(fd, buf, _align_size(file_length, 32));

if (bytes_read != _align_size(file_length, 32)) {
OSReportError(”iplESMisc.cpp::VerifySavedataZD: Read file failed: %d\n”);
goto done;
}

if (WADCheckSavedataZD(buf) == 0) {
OSReport(”iplESMisc.cpp::VerifySavedataZD: Verify failed for %016llx\n”,
titleid_hi << 32 | titleid_lo);
NAND_Close(fd);
fd = 0;
ipl::utility::ESMisc:eleteSavedata(titleid_h, titleid_l);
}
savegame_bad = 0;

done:
if (buf) free(buf);
if (fd) NANDClose(fd);
ipl::utility::ESMisc::ChangeUid(1,2);

return savegame_bad;
}

int _align_size(int value, int alignment) {
// round up value to next highest multiple of alignment
// e.g align_size(40, 32) = 64
return value + (alignment-1) & ~alignment;
}

int _check_strlen(char *string, int max) {
int i;
for (i=0; i< max; i++) if (string[i]==’\0′) return 1;
return 0;
}

int _check_save(char *buf) {
if (!_check_strlen(buf + 0×56, 8)) return 0; // random strings
if (!_check_strlen(buf + 0×60, 8)) return 0; // inside savegame
if (!_check_strlen(buf + 0×7A, 8)) return 0;
if (!_check_strlen(buf + 0×96, 8)) return 0;
if (!_check_strlen(buf + 0×1BC, 17)) return 0; // player name
if (!_check_strlen(buf + 0×1CD, 17)) return 0; // horse name
return 1;
}

int WADCheckSavedataZD(char *buf) {
int i;
// check 3 primary saveslots
for (i=0; i<3; i++) if (!_check_save(buf + i*0xA94)) return 0;
// check 3 backup saveslots
for (i=0; i< 3; i++) if (!_check_save(buf + 0×2008 + i*0xA94)) return 0;
return 1;
}

// this function is called when any savegame WAD is being
// installed (copied from SD)
int _wad_check_for_twilight_hack(WAD *wadfile) {
int i;
for (i=0; i < wadfile.numfiles; i++) {
// skip any leading directory names
char *p = strrchr(wadfile.filename[i], ‘/’);
if (p == NULL) p = wadfile.filename[i];
else p++;
if (strcmp(wadfile.filename[i], “zeldaTp.dat”)==0) {
return WADCheckSavedataZD(wadfile.filedata[i]);
}
}
}

I’ve had a few people ask about this — the way that I found out what titles had been updated was using Marcan’s nifty tool, wiimpersonator:

http://wii.marcansoft.com/wiimpersonator/reports/

It’s a collection of Python scripts that attempt to emulate an actual Wii’s update check process, and then generates reports to show what changed, eg. 20080617-030018.log and 20080617-040048.log.

It’s pretty neat; I’d say it’s the spiritual descendent of e.g. roto’s http://mozy.org/wii/old/index.html

Breaking news (har har har)! Check back for updates.

Several pieces of Nintendo system software have been updated:

====== Titles Changed ======

SystemMenu
Title ID: 00000001-00000002
Version: 0x 161
Size: 23511040
Contents: 9 (of which 6 are shared)

IOS30
Title ID: 00000001-0000001e
Version: 0x a10
Size: 1933312
Contents: 15 (of which 14 are shared)

IOS31
Title ID: 00000001-0000001f
Version: 0x a10
Size: 1933312
Contents: 15 (of which 14 are shared)

bc
Title ID: 00000001-00000100
Version: 0x 4
Size: 98304
Contents: 2 (of which 0 are shared)

mios
Title ID: 00000001-00000101
Version: 0x 8
Size: 262144
Contents: 2 (of which 0 are shared)

Channel 'HACA'
Title ID: 00010002-48414341
Version: 0x 5
Size: 8290304
Contents: 7 (of which 3 are shared)I’m currently disassembling these to see what has changed. Please do not pester me about this or ask what our response will be; this isn’t exactly easy or quick. Comments will be enabled once i’ve completed my analysis.

Update 1: IOS30 and IOS31 have been changed — specifically, the kernel. The old timestamps read:

$IOSVersion: FFS: 06/08/07 18:10:10 64M $
$IOSVersion: ES: 07/10/07 18:11:26 64M $
$IOSVersion: IOSP: 06/25/07 14:17:16 64M $The new timestamps read

$IOSVersion: FFS: 06/08/07 18:10:10 64M $
$IOSVersion: ES: 07/10/07 18:11:26 64M $
$IOSVersion: IOSP: 04/03/08 19:37:33 64M $It’s interesting that Nintendo bothered to update the IOSP timestamp, because the only change I see in IOSP is that the version reported changed (there’s a variable that stores the value “040308″). They’re trying to be clever; the actual bug fix was in ES, where the encryption code lives.

The strncmp signing bug has been fixed in IOS30, which is what the system menu uses. (The new signature-checking code is identical to that in IOS37.) This probably means that it will no longer boot Trucha-signed discs, but I have not yet tried it. Early reports on IRC indicate that the Homebrew Channel still works; this is consistent with my understanding that the system menu does not verify the content of already-installed content.

I don’t know why IOS31 was patched.

Update 2: Okay, now this is just silly. Three functions have been added to the system menu. Guess what they do:

ipl::utility::ESMisc:eleteSavedata((unsigned long long, EGG::Heap*))
ipl::utility::ESMisc::VerifySavedataZD((unsigned long long, EGG::Heap*))
WADCheckSavedataZD
We Are Not Impressed.

Update 3: They wrote a special-purpose function to try to check for the exact exploit we used — specifically, if a savegame is for Zelda, it checks the length of 6 strings inside the savefile (two of which are the player name and horse name). It repeats this check for all 3 saveslots, and then another three times for all 3 backup slots.

No, we do not have a response to this yet; we will probably take a few days to formulate one. I predicted Nintendo would *not* do this; I’m disappointed. This was the first bug we found, in the first game we tried. We’ll find others, and they’ll have to try to catch up to each.

I’ll open up comments, but please only post if you have something constructive to say.

Update 4: It’s interesting to look at the timestamps here. The System Menu has a build marker of “systemmenu.rvl.0803060727″ – yes, that’s March 6, 2008, 07:27. This update to the menu only accomplished one thing, as far as I can tell — the blocking of the TP hack. (I guess we can count the IOS30 patch together with it.) They spent 3 months testing it — this isn’t actually that surprising, when you consider the potential financial damage if they roll an update out that bricks Wiis.

Congrats to tmbinc and tehpola for finding a combination of two bugs in the code that Nintendo added that — when combined — allow us to fool their check into ignoring the TP hack. More info will be forthcoming — I still wouldn’t rush to update my system, anyway.

This still leaves the issue of how to deal with IOS30; there are several different ways to deal with this — some of which have already been released by people — and we’ll need to take some time to decide on the best one to use and test it thoroughly. There’s no urgency here, no need to rush into something.

Inspired by henke37’s idea of making a diagram that shows how the different processors on the Wii relate to each other, I took a stab at it. I got a little carried away I guess.

I can’t promise everything here is right — there are just too many things we don’t know, and even some of the things we do know, we don’t all agree on. So, here’s my first attempt at summing it all up:

boot1 is the second stage of the Wii’s bootloader. It lives at the beginning of flash; it is encrypted by AES, using a fixed key. It is hashed using SHA1, and verified against a hash that is burned into OTP memory inside the Hollywood during manufacturing. Therefore, boot1 can be changed in a Wii before it leaves the factory, and new Wiis could have a new version of boot1 — but it’s not possible to upgrade or modify boot1 in an existing Wii.

Fortunately, there is at least one bug in boot1 — the strncmp / hash verification bug — and this is what makes all of our firmware hackery possible.

If you want to look at boot1 yourself (to follow along), grab the first few kilobytes of any Wii NAND Flash dump, strip out the spare data (0×40 of ECC data after every 0×800 block), and then decrypt it with a command like:

openssl enc -d -aes-128-cbc -K 9258a75264960d82676f904456882a73 -iv 0 -nopad -i boot1-encrypted.bin -o boot1-decrypted.bin

You should end up with 17184 bytes. This is much much larger than boot0, and is already to the point where it’s difficult to follow all of the code by just staring at a disassembly. That space is broken down about like so:

1167: initialization code; AES, SHA, signature checking, NAND, ECC functions
2336 bytes: main(), described below
6134 bytes: low-level hardware setup code (to configure the DRAM, talk to the SEEPROM, initialize GPIO pins, etc)
3850 bytes: RSA verification code
2816 bytes: Library code: strncmp, memcpy, printf (!)
872 bytes: Data, including jumptables, the common key (why?!) and the public half of the Root key.

boot1 is interesting to us because it is the first vulnerable code in the Wii. It’s what decides whether or not a hacked boot2 will run. So, we must understand all of the checks it makes if we want to construct a boot2 that will be allowed to run.

[... several days pass ...]
Analyzing boot1 has proven much more difficult than I had feared, so I’m just going to post my disassembly for those who are interested. I’ll follow up soon with the output of SkyEye, which I will post with an explanation of what is actually happening.

Disassembly: boot1.txt

Update: I’ve had some requests for it, so here’s the binary of boot1: boot1-dec.bin

And here’s an IDC file: boot1.idc

Load boot1-dec.bin into IDA Pro (I use 5.2) as an “unknown” file, set processor type to ARMB (ARM Big-Endian), and set it to load the file to 0×0d400000. Once it has loaded, run the IDC file, and you should have something resembling my IDB file. Feel free to post with any questions or ideas.