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.

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. [Read more →]

One of the medium-to-long-term projects that Marcan and I have been working is hacking Skyeye to get it to emulate the Starlet. I don’t think will ever be useful as more than a tool for debugging the lowest-level hacks to boot2 that we plan to attempt, but it’s neat to actually see this code really running.

Skyeye is a generic ARM emulator, and it happens to emulate a lot of devices that we don’t need and can’t use (LCD panels, keyboards, networking, etc…). So, we’ve been coding drivers for the other parts of the Starlet that we know about — OTP and SEEPROM for keys, NAND flash driver, AES and SHA engines, GPIO ports, debug port …

At this point, it can either boot a modified version of boot2 (directly from a specially-crafted ELF), or it can boot from a specially-crafted ELF of boot0, its bootrom. After months of hacking on it, if I give it a real NAND flash dump, boot0 can load and run boot1, and boot1 can load, verify, and run boot2 (which then dies when it tries to load the FS driver due to an MMU problem — we’ll get there eventually).
[Read more →]

I didn’t think that I had to explicitly say this, but I see the same things come up over and over again, so I’m hoping I can clear this up for people.

The Wii is not a PSP, or an Xbox, or any other console system. Stop making guesses about the Wii based on your experience with other consoles. It Doesn’t Work Like That.

(Warning: I don’t own either of those systems; most of what I know came from TyRaNiD’s excellent presentation about the Pandora Battery at 24c3, my conversations with him afterwards, and a little bit of Google searching.)

Downgrading
I see a lot of talk (questions, ideas) about “downgrading the firmware” of a Wii. As far as I can tell, this comes mostly from the PSP world, where there was once a firmware which contained no signature checks whatsoever (1.0) and a firmware which contained an easily-defeatable check (1.5). Later firmwares fixed these bugs, so it was desirable to take a PSP with a new version of the firmware and downgrade it to an old version.

This is meaningless in the Wii world. First, there is no such thing as a “firmware version” on the Wii — the Wii stores a copy of every firmware (IOS) that has been released, and new firmwares for new games are just added to the collection. You also have the System Menu, which has the only visible version number — 3.1E, etc — but it tells you nothing about the firmware. The System Menu is responsible for launching most code (from disc or NAND), but it’s the IOS firmware which does the security checks.

Even the IOS version numbers don’t really matter so much. Any program on the Wii can switch to a different IOS version while it’s running with one simple function call — it’s not really a hack, but more like how the system was designed.

From a homebrew point of view, there is almost no difference whatsoever between any of the IOS versions. With one famous exception, there are no security holes that have been fixed between versions of IOS — it’s all a game-compatibility thing. The one exception — IOS37 — is still harmless because it’s never used; a future system menu will probably use it, but even that could be bypassed by using something like the Twilight Hack with Gecko Region Free. (Remember, you can easily switch back and forth between IOS versions in the middle of any program!)

For more info about the IOS system, see Wii System Software: a guided tour and On firmware patching, risk and responsibility.

This came up most recently in discussion about Waninkoko’s “Downgrader” video. In his defense, he never said this was useful to do, but people jumped on it because of the title. This is not a solution to any currently existing problem. If a problem develops, this would be the wrong solution; a better solution would be patching the System Menu TMD to use a different version of IOS. It’s possible for Nintendo to go back and patch all of the versions of IOS to fix the signing bug, which would prevent that from working; the best solution would eventually be to patch IOS37 to disable the fix. Which brings me to…

Custom Firmware
Dark Alex is consistently mentioned in the same breath as “custom firmware”. It looks like he’s done some quality work — as far as I can tell, it’s mostly

Ability to use different versions of the firmware for better game compatibility without losing the exploits
Warez issues (enhanced versions of built-in isoloader code?)
Recovery code
Of those three things, the first is completely irrelevant — we can already switch firmware versions all we want. If Nintendo only patches IOS without patching boot2, we can just go an patch them back. The second is of no interest to me, and probably much harder on the Wii anyway. The third is much more interesting, and is something I’m working on for boot2. And speaking of recovery,
Unbricking
The PSP has a much smaller NAND Flash chip (32MB vs 512MB), and when it becomes corrupted, the unit becomes bricked — much like a Wii. Originally, the recovery method available involved reflashing this chip with a dump from someone else’s unit — not possible on the Wii, because each NAND Flash is uniquely encrypted per console. The second, nicer method (and the main subject of TyRaNid’s talk) involves a battery and a memory stick, and to plagiarize from his presentation:

The Pre-IPL was not very large, less than 4KBytes
Based on a hardware register the Pre-IPL would either:
Read IPL from Flash
Read IPL from Memory Stick
This tied in with the leaked information about the service mode
The Pre-IPL is the equivalent of our boot0. We have no such ability to read code from another source. There will never be a “Pandora Battery” equivalent.

Banning
Both Sony and Microsoft are known for banning people from their various online services, particularly Xbox Live! Nintendo’s online services are not nearly so sophisticated

repeaterDS is a free music application for the Nintendo DS that allows you to “play” a sample by drawing on the DS screen. The vertical axis controls repeat length. The horizontal axis controls the playback offset into the sample.

Features include:

Control repeat length and offset using the stylus
Record and playback your gestures to create repeating stuttering noise
Shift your recorded gestures in realtime to create evolving patterns
Load in your own sounds
BPM settings

R6 gold can control games via motion, now we have test the #0340 passed,but i'm too lazy don't want to make the video for it

more info: http://www.neoflash.com/forum/index....ic,5174.0.html
i think r6 gold user will can use this new menu for support more games motion play in next week

and the lastest R6 menu : R6_motion_menu_v3.1.1037_for_R6 [6-20-2008]

R6 motion menu v3.1.1028 for R6 Silver and Gold
[2008-6-15,happy Fathers Day! ^_^]

more info: http://www.neoflash.com/forum/index....ic,5166.0.html

history:
* Support more 18 roms,like #2141, now the games compatibility >98.5%
* Fixed one bug for the normal TF

download:

Korean version: http://www.neoflash.com/download/R6_...d_Gold_KOR.rar

English version: http://www.neoflash.com/download/R6_...d_Gold_ENG.rar

No SNEmul is not dead, it’s simply sleeping. I Hope I will have more time later to fix bugs and add improvements to the emulator, but it’s not really possible for the moment.

Due to a change in the MySql from my provider, Wordexpress was not working correctly since some months. I was hoping that the bug will get fix itself but it seems I needed to upgrade Wordexpres. Anyway it seems ok now…

Hi!

I finally finished book II of the Lone Wolf series for the Nintendo DS: "Fire On The Water". For those who had missed the first volume, Flight From The Dark, this is an attempt at porting good old paper gamebooks to the DS console.

So what's new in this second book?
- A totally new and exciting adventure!
- Improved the game engine for handling more complex events
- Made 4 new musics (1 intro and 3 ingame) for even more variety
- Added mini-games
- Added merchants
- and many other fixes and improvements

You can get the game here : http://www.projectaon.org/staff/frederic/index.php