WriteELF v 1.6 Released!

Change Log:

• NOW WORKS IN VISTA! (HUGE thanks to predakang of #wiidev@efnet)
• allow -z option to be used without writing a file
• added url to output header

Get here.

Disable censorship in Manhunt Wii

You can use the Trucha Signer to remove censorship in Manhunt for the Wii. To uncensor the game change the values:

Find levelSetup.ini:

RHTE54/root/global/levelSetup.ini

Replace:

# ----------------------------------------------------------------------------
# [GK] execution colour ramp options: flash fadein (sec), flash duration (sec), flash fadeout time (sec)
EXECUTION_COLRAMP_TEXTURE FE_execramps
EXECUTION_COLRAMP_FLASH_TIMES 0.05, 0.05, 0.1
EXECUTION_COLRAMP_FADE_TIME 5.0

Put this in:

# ----------------------------------------------------------------------------
# [GK] execution colour ramp options: flash fadein (sec), flash duration (sec), flash fadeout time (sec)
EXECUTION_COLRAMP_TEXTURE
EXECUTION_COLRAMP_FLASH_TIMES 200, 0.6, 0.3
EXECUTION_COLRAMP_FADE_TIME 5.0

Download Trucha Signer 0.21

Trucha Signer is a tool to extract and replace files within a Wii game disc and after that insert a “trucha signature” to be authenticated by the Nintendo Wii. wiikeyset.reg included.

Get it here

WriteELF version 1.0

This application is used to get your files from your PC on to your SD card to use with the exploit.

Really useful, but make sure you read the instructions.

CMDs:

writeelf : [-b]

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.

Converting Gamecube Homebrew into Wii Homebrew

So now we can use DolTool 3 (Get here: http://download.wiigen.fr/Hadrien28/News/doltool/DolTool3.rar)

To convert Gamecube homebrews in .dol into .ELF files to use with the latest Wii exploit.

Cheers!

GamecubeLinux using the exploit and USB Gecko

Here we go Linux on Wii is possible to run now with the current exploit:
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

(http://downloads.sourceforge.net/gc-linux/linux-2.6.24-gc.patch.gz)

release we have added support for the USB Gecko

(http://www.usbgecko.com/faq.htm)

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

(http://wiibrew.org/index.php?title=Twilight_Hack).

We have released a small usbgecko-enabled Proof of Concept

http://downloads.sourceforge.net/gc-linux/wii-linux-PoC-0.1.tgz

mini-distro to prove it.

Wii Homebrew: MP3 Player

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.

Steps:
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.

Using MP3PLAY:
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 !

WiiScrubber 1.0 Released

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

Wii Homebrew Status: February 26, 2008

1. Nintendo released : Wii Menu 3.2
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. "

2. Snes9xGx.wii_0.01b_DOL.rar
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.

SD Gecko Adapter : This is what you need.

To run homebrew using the current exploit you will need this: SD Gecko ( or similar)

http://www.amazon.com/Gecko-Memory-Adapter-Nintendo-GameCube/dp/B000RC51Q4

Wii Homebrew Apps: Tetris Wii

We can now run homebrew on wii because we finally got our ELF loader.

Try this out:

TETRIS Wii:

http://www.auby.no/files/wii/tetris.elf




Try at your own risk, HOW TO instructions are in previous posts

Twilight Hack Version 0.1 Alpha 2 Released

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.

"Installation
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.

Problems:


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 "

Wii Homebrew Pong ( Video )

First Wii Homebrew App, its a game - Pong, however still no controls

Slow loading video (SWF) can be found here :
http://www.auby.no/files/wii/pong.swf

Or here:
http://www.youtube.com/watch?v=rDPTkMRYUq0

Video: Twilight Princess Homebrew Demo Hack Tutorial

Twilight Hack / Exploit version 0.1 alpha 1 b

A newer version ( alpha1b) of the exploit from Team Twiizers has been released
get it here:
Get here

now supports:

RVL-RZDP-0A-0 JPN
RVL-RZDE-0A-0 JPN
RVL-RZDE-0A-0 USA
RVL-RZDE-0A-2 USA

cheers.

How Zelda:TP exploit works - stack buffer overflow

During a stack buffer overflow, program writes outside of the intended program data structure in the memory address.

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.

Installing the Zelda exploit

Just to clarify with everyone, heres that difference between the files for the exploit:

This is used for PAL:    cp rzdp.bin $MOUNT/private/wii/title/RZDP/data.bin
And this one for NTSC:   cp rzde.bin $MOUNT/private/wii/title/RZDE/data.bin

New version of Wiiuse

source: http://wiiuse.net/
Wiiuse
Version : 0.10 released

Added a lot of new features so check it out.
"
Added:
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_USING_SPEAKER()
Macro WIIUSE_IS_LED_SET(wm, num)
wiiuse_init() now autogenerates unids
orient_t::a_roll/a_pitch
wiiuse_resync()
wiiuse_cleanup()
wiiuse_set_timeout()
Fixed:

[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
Removed:
wiiuse_startup(), no longer needed

"

Twilight Hack v0.1 (Alpha 1) - Additional Link

Twilight Hack v0.1 (Alpha 1) - Additional Link

http://rapidshare.com/files/91224093/15902_twilighthackv0.1alpha1.zip.html

How the Wii was hacked...

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:

http://rapidshare.com/files/91218358/Twilight_hack_binary.rar.html

that file includes:
Twilight hack binary.nfo
initloader.bin
loader.bin

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
version 0.3.4


For the libOGC use the support forums: http://www.tehskeen.com/forums/forumdisplay.php?f=86

Current State - "Develop, Develop"

After the mouthwatering video of the exploit and the "coming soon" ending, a lot of us started to wonder about the possibilities. Wii homebrew possibilities, right now we can anticipate a loader.

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.

cheers.

Exploit with PAL versions of Zelda

It was reported that the current ZTP exploit works with PAL Versions of the game.
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.

Zelda: TP Exploit Compatable Versions

To check your version, compare the text on the zelda cd (center part of the cd).

RVL-RZDP-0A-0 JPN - working
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.

cheers.

Wii Zelda Twilight Princess Hack Released

Finally we got a confirmation video and a real file that shows how you can run code on your Wii.

Go ahead and try it out, but don't forget that you are risking your Wii.
Grats Everyone, check out the links:
File:

http://chaoshq.de/~crediar/twilight-hack-v0.1-alpha1.zip

Source:
http://wiibrew.org/index.php?title=Twilight_Hack
Video:

Wiifuse - New Version

http://wiibrew.org/index.php?title=Wiifuse

Install (debian/ubuntu) :

apt-get install build-essential fuse-utils libfuse-dev libssl-dev

Current Changelog:

v0.1.2

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

v0.1.1
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

Developer : dhewg

WiiBrickBlocker v1.3R2 Released

Source: http://wbb.rockman18.com/?page=home&ln=en

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.

Current State - "Whats next?"

After all the news about the zelda exploit and a couple of other attempts, users might ask "Whats next?"

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.

Dual Layer Wii disc ripper (p2.) PIC

Dual Layer Wii disc ripper rumored to be out and working

source: http://wii.qj.net/Dual-Layer-Wii-disc-ripper-rumored-to-be-out-and-working/pg/49/aid/112862

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. Pictures on his blog seem to indicate that the process has worked for him using Super Smash Bros. Brawl as the test subject. He also appears to have attempted to put videos up of the procedure working, but those vids seem to have been taken down by YouTube. In any case, we'll keep you updated on this new development, as well as any additional news related to the Dual Layer Wii disc ripper. In the meantime, keep checking QJ for updates.

[Via Nekokabu's Blog]

"

German Wii hacking

Source : http://debugmo.de//?p=59

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 bugs specialities, 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!