Tuesday, April 29, 2008
Controls:A = Clear space
B = Toggle flag,question mark & square
Start = Pause
Left/Right/Up/Down = Change selection
Z = Speed up cursor
Accessories needed: GameCube controller
Return to loader: (Main menu option)
Loaders useable: Zelda Chainloader
Installation for Zelda Chainloader: Install as usual
Thursday, April 10, 2008
Svpe has been using the recent developments in homebrew and have created a loader that loads stuff over TCP.
It is a TCP server running on the Wii that listens on port 8080 by default that will run any binary that is sent to it. Both DOL and ELF executables are supported. There is no IP address display in the Wii part.
This is a very great thing, considering the fact that certain devices can be modified and updated through TCP, the Wii should not be an exception.
Source if u are interested
HOMEBREW APP PACK
Created by Hell Hibou
Copy boot.elf to an SD-card
Create a folder named homebrew on the root of the SD-card. (X:\homebrew)
Create a folder in the homebrew folder(Max 8 symbols long)(X:\homebrew\12345678)
Place The elf in that folder and name it "boot.elf"
OPTIONAL: For a custom name: add a "title.txt" containing the channel's title
OPTIONAL: For a custom image: add a "title.bmp", it has to be a 24-bits bitmap of 132x95 pixels.
For each homebrew:
- Create a folder in the homebrew folder(Max 8 symbols long)(X:\homebrew\12345678)
- Place The elf in that folder and name it "boot.elf"
- OPTIONAL: For a custom name: add a "title.txt" containing the channel's title
- OPTIONAL: For a custom image: add a "title.bmp", it has to be a 24-bits bitmap of 132x95 pixels.
It requires the use of a gamecube controller.
- D-pad: Select a channel
- A: Launch the channel
- R/L: Change page (more then 11 homebrew channels)
- Z: Refresh the channel list.
Friday, March 21, 2008
Starting with version v0.2.0, you can also remotely mount your wii nand filesystem with wiifuse_server and a usbgecko adapter.
- An operating system which is supported by FUSE,
- FUSE 2.6.x (or higher) and
- completely revamped wiifuse_server
- new client/server mode. requires an usb gecko and wiifuse server running on a gamecube or wii in gc mode - for now ;)
- new metadata: title id symlinks, tmd infos
Thursday, March 20, 2008
Team Twiizers are working on an easier way to launch homebrew applications, having a separate homebrew channel will be beneficial to open a bigger user base of Wii homebrew. However earlier this month Team Twiizers informed us that they will NOT be making a loader for backup games due to legal reasons.
In the future we have a lot more wii homebrew applications coming up and more developer groups will begin to show their interest in this platform.
Sunday, March 16, 2008
Saturday, March 15, 2008
Download it here!
More and more features. We are all thankful for all development!
0.1alpha3aCorrectly loads geckoloader code from USBGecko flash
0.1alpha3Front SD slot is now supported; SDGecko slot support has been removed.
FAT16 is now supported; you should save your ELF executable on your SD card as "boot.elf".
RZDJ is now supported
Added support for Geckoloader stub: If you have a USBGecko installed and have already run the Geckoloader program to install into flash, then the Twilight Hack will try to load that stub if it does not detect an SD card.
For new users, this is what you need:
You will need:
- 1x Wii
- 1x SD card, formatted as FAT16 (There seems to be a problem with formatting an SD card as FAT 16 in OS X, try to format your card in Windows.)
- 1x copy of The Legend of Zelda: Twilight Princess that has been run at least once
- 1x Computer
- 1x Some way to read SD cards on a computer
- (Optional) 1x or more GameCube controller
- (Optional) 1x USBGecko
Inside the zip archive, you will find several savegame files; you will need to choose the correct one based on your version of Zelda: Twilight Princess. The easiest way to check your version is to compare the text string which is on the inner cycle of the data surface with the ones below.
- RVL-RZDP-0A-0 JPN - rzdp0.bin
- RVL-RZDE-0A-0 JPN - rzde0.bin
- RVL-RZDE-0A-0 USA - rzde0.bin
- RVL-RZDE-0A-2 USA - rzde2.bin
- RVL-RZDJ-0A-0 JPN - rzdj0.bin
- If it does not already exist, make a directory called "/private/wii/title/RZDx/" on your SD card; replace "RZDx" with RZDE, RZDP or RZDJ as appropriate. Copy the above file into that directory, renaming it as "data.bin".
- Next, take your homebrew Wii executable, and save it in the root directory of your SD card as "boot.elf".
- Now, put the SD card into your Wii and turn it on. Go into Wii Options --> Data Management --> Save Data --> Wii. Find your Zelda save, click on it, and click "Erase", and click Yes. Now, go into SD card, and select the "Twilight Hack" save (the icon says "Wiibrew Loader"). Click copy, and yes. Now, go back out of that menu.
- Insert Zelda, and run the game. Load file A, and walk backwards.
What Wii homebrew applications with this hack can I use ( list )?
Wii Homebrew MP3 Player
Genesis / Megadrive Emulator (requires SD-gecko or similar)
GeckoLoader ( search this blog for links)
Atawii ( same, link in this blog)
Ballion (Destroy blocks with a ball)
EasyIOS This app is for browsing the device tree, and trying out quick IOS commands w/out doing builds.
Thursday, March 13, 2008
Download WriteELF GUI
What is this?:
In the first place, WriteELF lets you write files on your SD card using your pc. This version of WriteELF GUI uses WriteELF 1.6
HOW TO USE:
- To use this program, you need to download a copy of the WriteELF program first.
- Extract the writeelf.exe file to the same folder as the WriteELF GUI program.
- Connect the SD Card to your computer.
- Open the program. Choose the .ELF file and choose the drive where the .ELF file will be written.
- If needed, you can choose the -z option to clean the SD Card before writing the ELF file (the SD Card WILL NOT be formatted, only their first sectors will be cleaned).
- Click on the GO button. A new window will pop up. Wait until the writing process finishes.
AtaWii by NoNameNoDownload Here
This is an Atari ST emulator for Wii (port of the lame emulator, castaway)
Source is included in the download
Download Geckoloader 0.0.3
a gamecube pad isn't required anymore, the wii reset button is used to confirm the flash process
the loader code is executed straight away if it has been flashed before (no interaction required)
.elf file support thanks to tmbinc
the stub doesn't overwrite the globals anymore, fixed by WinterMute
a received binary is now written to MEM2 before relocating
ported the client to win32 (binary included)
the client now uses default device names on linux and os x
the audio and dsp subsystems are initialized on reloading (no more annoying noise)
a usbgecko adapter
a way to boot wii homebrew
What is this again?:
It is wii application which helps you to load and execute wii homebrew binaries in the easiest and fastest way possible.
Monday, March 10, 2008
Friday, March 7, 2008
Tuesday, March 4, 2008
and an older version 0.0.2 just in case:
Geckoloader is used for load Wii homebrew binaries. It acts as a server using a USBgecko adapter.
To make it work make sure you have:
a usbgecko adapter
a gamecube pad
a way to boot wii homebrew
Some of the Features:
100% native wii mode
no medium ejecting, rewriting and inserting required whatsoever
this is especially useful for wii coders (fast development cycle)
How to make it work:
1. use the in Twilight Hack combination with the included geckoloader.elf to get this running
the boot code will show up
2. you have to write the loader code to the onboard usbgecko flash once, so press Z on a gamecube pad to do that
3. flashing has to be done only once, press A the next time you reboot the wii to skip that step
after that you will see the loader code in action
4. use a compatible client (like the included one
geckoupload, or the official windows geckotool) to send a .dol
5. the transfered binary should execute
6. if you loaded a game/app which has an option to jump back to 0x80001800, you will be able to transmit another binary without reboot
- fixed a timing issue in the usbgecko flash code. since i couldn't reproduce this on my setup, thanks go out to my testing bitches bLAStY and NoNameNo
the included client now works on osx thanks to bushing
added an extra check for malformed .dol files (some doltool converted .elf's)
included a tiny test application
- fixed a timing issue in the usbgecko flash code. since i couldn't reproduce this on my setup, thanks go out to my testing bitches bLAStY and NoNameNo
Win and Linux version available for download.
It is a freeware tool to:
analyze a Wii game ISO file (or directly the DVD on linux) and tell you :
which is the region of the game (and other informations)
which is the region of the update
if there is a firmware update inside
if there is a risk to perform this update
if the update has already been modofied by WUM
patch the update of this iso to :
put an inerte update inside : function Brick Block
replace by another update : can be use to make tests or unbrick semi-bricked wii
Monday, March 3, 2008
The 14th release of the gamecube toolchain is now final and available for download. This version brings Wii support now that we have the ability to run code on Wii thanks to the efforts of Team Twiizers and their Twilight Hack.
Those of you used to the old build system with prior versions of devkitPPC and gamecube programming will need to review the updated examples and templates. libogc has now been removed from inside the toolchain and is installed in a separate directory in the same way we maintain the gba and ds support libraries for devkitARM. This allows us more leeway to update the toolchain and libraries separately and avoid dependency issues which have been causing problems for users in the past.
Several packages have been updated and some new ones added, notably the addition of Monk’s gcube emulator which appears to provide most compatibility with devkitPPC compiled code, including the ability to run code intended for Wii. We don’t advise using the emulator exclusively for development testing but it should be convenient for quick test builds prior to running on hardware. A windows native binary has been provided but currently lacks the debug features of the OSX and linux versions, hopefully we will be able to provide this with a future update. Currently there are no builds for other platforms but we will be happy to host prebuilt versions should someone volunteer to provide them.
Windows users should use the devkitPro installer updater to obtain devkitPPC and the support libraries, this ensures that everything is installed properly. For other platforms instructions are provided on the wiki Getting Started page which includes links for the windows install package.
Saturday, March 1, 2008
Thursday, February 28, 2008
# [GK] execution colour ramp options: flash fadein (sec), flash duration (sec), flash fadeout time (sec)
EXECUTION_COLRAMP_FLASH_TIMES 0.05, 0.05, 0.1
Put this in:
# [GK] execution colour ramp options: flash fadein (sec), flash duration (sec), flash fadeout time (sec)
EXECUTION_COLRAMP_FLASH_TIMES 200, 0.6, 0.3
Tuesday, February 26, 2008
Really useful, but make sure you read the instructions.
driveletter = drive letter of the sd card reader
elffile = path to elf file you wish to write to the sd card
-b = backup existing data from the write location
Note: If elffile is "-", it will not write anything to the SD card, and will automatically turn on backup mode.
Get it here.
Get it here:
Taken from the official site:
Long time, no see Although we haven't posted any news in the last 2 years, we have silently continued our work keeping the kernel patches up to date. With the latest 2.6.24
release we have added support for the USB Gecko
adapter as a console and terminal, so you can now logon into your gc-linux distro using minicom or HyperTerminal (TM). And last but not least, we have finally run natively Linux on the Nintendo Wii through Team Tweezers' twilight-hack
We have released a small usbgecko-enabled Proof of Concept
mini-distro to prove it.
Get it here: http://rapidshare.com/files/95122486/MP3Player.zip.html
What it does and how it install it:
Built using libogc cvs for wii mode via the zelda tp exploit.
These are instrutions on how to setup your SD card to have both this .elf and
mp3's on the same SD card.
1. Format your SD card.
2. Copy the file called padding to your SD card
3. Use dd or writeelf (for windows) to copy MP3PLAY.elf to (physical)sector 2048
4. On the SD card, create a DIR called MP3 in root and place all your .mp3's in here
(4096 is the limit of files allowed) and no subdirs allowed.
5. Run the exploit on zelda and enjoy.
Press Left and right to find mp3's, once you've found the mp3 you want, press A to
play it, once playing, there's instructions on how to go back/next song. Also press
Y whilst browsing mp3's to return to the exploit. (You may also swap sd cards at
the menu of the mp3 player but only before going to the exploit)
(c) emu_kidid '08
Thanks emu_kidid for all your hard to work !
Get it here: http://gbatemp.net/index.php?download=1868
What it does:
"Removes all the garbage data of Wii ISOs and in most cases drastically reduces the size of the ISO. However this is not just for smaller storage, the ISOs still work on the Wii AFTER being compressed."
A system update, exploits are still working, so we are good :) .
"Changes: No major feature changes, some unknown background work which allegedly improves system performance. "
Version 0.01 of the snes emulator released, this one is great, because finally it use the "Wii mode" to run, not like most of the old homebrew, which had to use the Gamecube mode. http://rapidshare.com/files/95120955/Snes9xGx.wii_0.01b_DOL.rar.html < Get it here.
Wednesday, February 20, 2008
GET IT HERE: http://chaoshq.de/~crediar/twilight-hack-v0.1-alpha2.zip
Now with an ELF loader.
To run all this you have to have a USB Gecko for gamecube, current Wii SD Slot is NOT supported.
Extract the zip archive into any folder.
Backup your old Zelda save if you want to, by copying data.bin out of *SD Card*/private/wii/title/RZDP or *SD Card*/private/wii/title/RZDE and into another folder.
If you have a PAL Zelda game (identified by the code "RVL-RZDP-0A-0 JPN" around the inside on the shiny side of the disc), copy the file rzdp.bin (from the zip archive you extracted) into *SD Card*/private/wii/title/RZDP/data.bin.
If you have an NTSC later revision Zelda game (identified by the code "RVL-RZDE-0A-2 USA" around the inside on the shiny side of the disc), copy the file rzde2.bin (from the zip archive you extracted) into *SD Card*/private/wii/title/RZDE/data.bin.
If you have any other NTSC revision Zelda game (usually identified by any other code involving the letters "RZDE" around the inside on the shiny side of the disc), copy the file rzde.bin (from the zip archive you extracted) into *SD Card*/private/wii/title/RZDE/data.bin.
Now, put the SD card and Zelda into your Wii and turn it on. Go into Wii Options --> Data Management --> Save Data --> Wii.
Find your Zelda save, click on it, and click "Erase", and click Yes. Now, go into SD card, and select the "Twilight Hack" save (the icon says "Wiibrew Loader"). Click copy, and yes.
Now, go back out of that menu and start the game.
Select the first save file (called Twilight Hack), complete the brightness setting, and talk to the man in front of you. What will later be the ELF loader will load.
If you are a PAL user and are experiencing a line of text lost off the bottom, try changing your TV type under Wii options --> Wii settings --> screen to 576i (50hz).
Please could PAL users add a post to the right section to say whether they had this problem or not with non-576i settings, as I would like to know if everyone has this problem or if it's just my TV.
If you have a USBGecko, try unplugging it from the Wii before running the exploit. There's a bug in the USBGecko code used in the exploit that will make the game hang if you have a USBGecko plugged in to the wii, but not connected to any program on your computer.
This exploit does not work with every version of Zelda:TP. Easy way to check your version is to compare the text string which is on the inner cycle of the data surface with the ones below.
RVL-RZDP-0A-0 JPN - working
Some minor problems reported e.g. Some greeny lines around the top area of the screen that appear with the penguin and if the TV type is set to 480i/p (60Hz or EDTV mode) the bottom is cut off
RVL-RZDE-0A-0 JPN - working
RVL-RZDE-0A-0 USA - working
RVL-RZDE-0A-2 USA - working
RVL-RZDJ-0A-0 JPN - not supported yet "
Friday, February 15, 2008
Thursday, February 14, 2008
Wednesday, February 13, 2008
Tuesday, February 12, 2008
This is used in the Twilight Hack, when you are in game, a lengthy name of Epona - the horse is used to generate a stack overflow. This occurs during the conversation with the man near you when you load your save, when he loads the name to use in the dialog box or when you are entering the next zone, where you have to ride a horse.
Version : 0.10 released
Added a lot of new features so check it out.
Real dynamic linking (by noisehole)
Changed from callback to SDL style
Guitar Hero 3 controller support
API function wiiuse_set_accel_threshold()
API function wiiuse_version()
Macro WIIUSE_IS_LED_SET(wm, num)
wiiuse_init() now autogenerates unids
[Windows] Fixed bug where it did not detect expansions on startup
Renamed INFO/WARNING/DEBUG macros to WIIUSE_* (by noisehole)
Updated Makefiles (by noisehole)
Fixed incorrect roll/pitch when smoothing was enabled
Fixed nunchuk and classic controller flooding events when significant changes occured
Fixed bug where IR was not correct on roll if IR was enabled before handshake
wiiuse_startup(), no longer needed
TikTok 'n' Botch Released the binary data for other people to look at( dumps from the Twilight Hack). So if you are interested here you go:
that file includes:
Twilight hack binary.nfo
Also the official Wii SDK is not used for the wii homebrew yet, however open source tools are used to develop applications to use with the ELF compiler. As stated earlier ELF files can be used and executed on the Wii. More development kits to use : devkitPro and libOGC.
devkitPro 0.3.4- http://www.devkitpro.org/
to download it and check it out : http://sourceforge.net/project/showfiles.php?group_id=114505&package_id=199021&release_id=552359
For the libOGC use the support forums: http://www.tehskeen.com/forums/forumdisplay.php?f=86
Monday, February 11, 2008
A loader that will find a way to have an easier way to launch all homebrew apps that we want. One of the first loaders will have a possibility to load ELF files. ELF's are "Executable and Linking Format" Files, which are based on objects in UNIX.
As I said earlier in my blog posts, now we will have to wait for more information on the loader.
However we are very close to simple wii homebrew than ever before.
After a few try outs it was reported that it with the release version of the PAL Zelda: TP. Exploit also worked with Zelda: TP PAl Euro.
Some graphical issues may appear though, which is not that big of a deal.
Other sources say that it works with the PAL and NTSC Version but not with the Japanese. To get a PAL version look for a "P" on the end of the cd serial, if there is no "P" it means that its an NTSC version.
Sunday, February 10, 2008
To check your version, compare the text on the zelda cd (center part of the cd).
RVL-RZDE-0A-0 JPN - working
RVL-RZDE-0A-2 USA - reportedly not working
Looks like we will need a Japanese version of the game to successfully launch the exploit.
Go ahead and try it out, but don't forget that you are risking your Wii.
Grats Everyone, check out the links:
Wednesday, February 6, 2008
Install (debian/ubuntu) :
apt-get install build-essential fuse-utils libfuse-dev libssl-dev
- added more disc ids
support for virtual console partitions (found 14 vc games on brawl)
stat compliant - `du` works now
statvfs compliant - `df` works now
minor cleanups and fixes
fixed some serious u64 offset bugs
corrected the main.dol size calculation
some easy partition validation
support for symlinks
cleaned up and extended the available metadata
A new version of the WiiBrickBlocker is out.
What it does is it prevents the updates from your Nintendo Wii games that can harm your console by bricking it, duplicating channels or cause any other issues.
Check the source for other interesting information about this utility.
Tuesday, February 5, 2008
Right now homebrew developers need time to find a way to run a possible "loader" that fixes the crash after the Zelda Save game. That loader needs to be able to bring the Wii to its main "welcome screen" but with a few adjustments , which will allow users to load homebrew applications.
It is a complicated process, but its on its way to your Wii.
Sunday, February 3, 2008
Heres what happened:
We've just learned that a Japanese coder by the name of Nekokabu has released the first Dual Layer Wii disc ripper for the Wii. As the name implies, it's essentially a dumping utility that supposedly allows users to backup dual-layered Nintendo Wii discs.
[Via Nekokabu's Blog]
After bushing had shown the first homebrew exploit, a lot of stuff has happened in the Wii-world. The exploit was based on a hole in the disc hashing&verification, but the original finder (segher) decided that he doesn’t want the bug to be published. While this caused some controversy, the reason behind this was that the hole could be patched very easily in a future firmware version, as no original function relies on it. The next goal was to find a bug which could not be patched so easily, for example a savegame exploit. Patching such game exploits is considerable harder. Of course you could patch the game code when it is loaded (like some gamecube games are fixed in compatibility mode by the “gamecube compatibility IPL”), but we could just move on to another game. We wouldn’t lose that much power if a game bug is fixed, vs. a critical system bug. I can totally understand that people are annoyed by us not doing full disclosure. Nevertheless we try our best to balance our different interests. It’s not always easy, even inside a team. Still, the rule is: If you find a bug, it’s your choice what you do with it. If you don’t like that, find your own bug.
I’ve concentrated less on the high-level things, I’m generally more interested in the system design and security architecture. So I’ve digged into the bootloader.
What we knew before was that there is a fixed block of code called “boot1″, which is supposed to be the first code executed from flash. It’s ARM (”Starlet”) code, btw, the powerpc (Broadway) is booted much later. We didn’t knew how boot1 is encrypted (rumours ranged from an LFSR-based streamcipher to AES), nor if and how it was hashed. But what we had was a program called “BC” (title id: 1-100), extracted out of a system update. We are absolutely not sure why BC does even exist (it might be used to return from GC mode to Wii mode, but why would you want to do so?), but what BC is doing matches what boot1 could be doing: Reading a bunch of sectors from flash, decrypting them, and checking a signature against a previously decoded cert chain, then jumping there. Once we re-coded the algorithm, it was clear that this in fact decrypts boot2. Encrypting a new boot2 requires signing the new hash. Now it turned out that “BC” also contains “the bug” (well, a similar one), so chances were big that boot1 also does. But flashing a new boot2 is dangerous if you have no return - there is a backup mechanism to boot another copy of boot2, but we cannot count on that for several reasons (for example, if our new boot2 code hangs, the backup would not be tried, as boot1 thinks that everything is right).
It also became clear that once we are able to execute starlet code, it will be a lot of trial&error. So what I did was to revive my old FPGA-based NAND flash emulator, which I once built for the Xbox 360. I wired the Wii’s flash pins to the FPGA. Now the Wii flash has different properties (large block, larger size, different ECC algorithm used), but I could adapt it in a matter of hours. I had to fix the RESET handling (the Wii is waiting for R/#B to go low for a short moment of time), and some minor things, but then it worked! I could boot from my FPGA instead of the original Flashrom. So I could do code changes in a matter of seconds, instead of always reprogramming the flashrom (potentially external). Because my FPGA board has “only” 512MB of RAM, I couldn’t fit the whole flash contents into the RAM. As part of the NAND emulation happens on the embedded PowerPC core in the FPGA (a Virtex 2 Pro), I just added an ethernet MAC, and used lwip to fetch the flash pages from a TCP server. That made the development cycle even easier, as I could now just modify the virtual NAND content on my PC!
bushing prepared a fixed boot2 for me (he just changed a dummy byte), and hey, it worked! I could now run code on the Starlet! First thing would obviously a “hello world”, but where to output? I’ve wanted a software UART, like I had done in GC mode before using the EXI_CS line, but I wasn’t be able to find any useful GPIO. Finally I was able to blink the sensorbar!Unfortunately, all those IOs aren’t TTL, and I didn’t wanted any level shifting.
An hour later I finally got the idea which I should have got in the first minute: Using the already existing NAND interface. I would just issue a non-standard command (the Starlet NAND controller is simple enough to be able to issue any command), and use the address bytes as payload. I’ve added the proper code on the FPGA side (luckily I hadn’t even to change my VHDL code…) to output the address bytes of the private command to the FPGA’s UART.
Some hours later I’ve dumped boot1 (it still was in memory), and some hour later I’ve dumped a new piece of code, which turned out to be decrypting something from the beginning of the NAND flash into memory, then calculating a SHA-1 hash over it, and compares that to a hash read from some “internal memory” (which we believe is an OTP area). It turned out that this was - the bootrom! Hooray! I decided to call this piece of code “boot0″.
So, to sum things up:
- First thing which ever executes on the Wii is the “boot0″ code, which is probably stored inside the hollywood in a mask rom.
- boot0 loads the first 0×2F pages (”boot1″) from flash, decrypts them with a fixed aes key, calculates a SHA-1 hash (with some obscure
bugsspecialities, I still couldn’t calculate it by hand), and checks that versus the expected values, read from some internal memory.
- If the hash bytes in the “internal memory” is all-zero, the hash check is skipped. This is probably used for production, and maybe for devkits.
- boot1 then searches a certain header in flash, where it extracts specific information where to find boot2.
- At that position, some certificate chain is checked, and finally the boot2 “tmd” is verified, and the hash extracted.
- The boot2 payload is load from flash, decrypted, and hash-checked (against the hash from the boot2 tmd).
- boot2 will then load the firmware, or whatever. That’s not my region of interest at the moment. :)
If I had to evaluate the quality of the security, I’d have mixed feelings. Having a bootrom is a good idea. We’ve seen systems trying to work around that (for example the gamecube), but while of course a whole decrypt, hash, sign check is possible in pure hardware, it often gets simplified (gamecube, for example, had a static keystream, no hashing, and a big fat hardware bug). Then the bootrom is larger than 512 bytes, and should be large enough to use some real algorithms (especially since the hardware offers SHA-1 and AES, so all that needs to be done is to setup the engines) instead of bogus ones. Having a OTP area, which stores a fixed hash is also a nice method, since it allows changing boot1 without swapping the bootrom. They could have done RSA in the ROM (like Microsoft on the Xbox 360), but this way is also ok, and it removes a great deal of complexity out of the bootrom. Also, while the boot0 code doesn’t look nice, it also doesn’t look terrible. Some GCC version string inside shows that the code is not hand-assembled but compiled. This is generally also a good sign, since it’s easier to verify a C code than an assembler code. Unless a bug shows up in the bootloader (which I don’t want to rule out yet, we just haven’t found one so far), I’d consider this as a good concept. What I don’t like is that the encryption key is fixed in ROM (it could have been in the OTP area as well), as well that the hash check is skipped when the OTP area is empty. While production probably requires this, they could have reverted to a backup hash, so that with an unprogrammed OTP, only a certain, previously determined software would run (which would then burn the correct key into the OTP, given it’s field programmable). If there is a hardware attack to null the OTP area (which might be hard, but we don’t know), this would make the ROM giving up (nearly) all security. But that’s really more a theoretical risk.
However, there is no revocation mechanism. boot1 cannot be updated on retail machines, as the hash is OTP. And boot1 is buggy. New produced Wiis could contain a fixed boot1, of course, even without modifying the mask rom, thanks to the flexible approach with the OTP hash. boot1 looks everything but nice to me. The whole decrypt function is completely chaotic (and while this might be just an optimizing compiler, I would bet the source looks similar..), doesn’t do nearly as much header sanity checks as required, and contains, as said, at least two completely critical bugs. Given that in the early stage of booting a real chain of trust is used (each code inherits all security priviledges from the caller), this is what breaks the security.
On the hardware side, what I would have liked is a possibility to turn off the bootrom (and not just mask it behind an MMU), and PEOPLE: You designed a perfectly cool AES engine into the hardware. You also have a secure key store (the OTP). WHY didn’t you JUST added the possibility to use the OTP area as key material for the AES engine, and disallow reading of these areas by the CPU? You could have hidden the boot1 key in hardware, for example. Or even the boot2 key. Or even really important stuff. But everything is exposed to software. Once you’re in, you own it. That IS a security problem. Security by obscurity doesn’t work, but obscurity while doing the security (without sacrifying any real security, that’s the important part) often helps to gain time. It isn’t important whether your product is hacked in 10 years, it’s important if it’s hacked TODAY. By doing some tricks here and there, you can make it much harder to hack your product, gaining time. Still, and that’s very important, you need real security. Obscurity is no replacement for security!)
I have to add that I really liked our teamwork, even if it wasn’t easy all the time. It really helps if more than one person is working on something, even (or especially) if everybody is working in another direction, but all on the same topic. I would also like to thank d. for sharing his NAND logs with me (he also built a nand sniffer&emulator, long before mine was ready), it helped a great deal in determining what went wrong. And of course I have to say that I’m happy about everyone who is taking part of this discoveries, be it public or non-public, be it in an overcrowded or three user channel. There is a lot to be learned about the Wii, and I’ve always liked being part of the gamecube development community (at least up to a certain point, but that’s another story). It amazed me how much good work came from a relatively small group of people. Let’s continue on that!
Wednesday, January 30, 2008
Interview with a Wii hackerBy Alex Bradner | January 29, 2008
Disassembling in the dark
Over the next four pages you’ll find all the details you could ask for about the world’s first proper Wii hack: no mod chips required. It's powerful stuff.
Atomic: First off, what's your programming background?
Bushing: I've been programming since age 8 (on an Apple IIc); I spent a lot of time growing up, hacking on Linux. I did Electrical Engineering and Comp. Sci in college, and now I do software development professionally.
Atomic: What was the appeal in hacking the Wii?
Bushing: Mostly that it hadn't been done. I don't play many video games, but I saw one at my boss's house at a party this summer, and it was fun, so I bought one. And I like to hack everything I own, and it was a big flashing target because I knew that nobody had yet been able to do it.
... check the source for the full version of the interview.
Again source is : http://www.atomicmpc.com.au/article.asp?SCID=14&CIID=102079&p=4
Finally the wii homebrew scene is more clear now, a better way to run code has been found though a game - The Legend of Zelda: Twilight Princess.
As wiili.org wiki says:
This exploit takes advantage of a buffer overflow in the game "The Legend of Zelda: Twilight Princess".
Originally discussed on efnet in #wiidev then put teh
The process requires than once you modify a save game it is signed with 3 keys!
Some info from Bushing:
"Once the Wii decrypts the save game, it checks its signature. Every Wii has its own private key which is used to sign save games, and when you save a game, the Wii actually saves three bits of data:
- The encrypted save game
- The signature for the save game (using your console's private key)
- A copy of your console's public key, signed by Nintendo."
Try this at your own risk, theres no guarantee that something won't go wrong.
Good luck and dont brick your wii!