GenPlus - Mega Drive Emulator

GenPlus - Mega Drive Emulator

Download here

Developer:
LoPsT

Features:
includs support for the Wiimote and the classic controller.

Homebrew app: GRRLIB ver 1.6

Download GRRLIB ver 1.6

What is this?

A package of little template of effect demos


How do I create my own?

Use this template.

Homebrew App : Minesweeper

Creator: mangaman3000

DOWNLOAD HERE

Controls:

A = Clear space
B = Toggle flag,question mark & square
Start = Pause
Left/Right/Up/Down = Change selection
Z = Speed up cursor

Info:

Accessories needed: GameCube controller

Return to loader: (Main menu option)

Loaders useable: Zelda Chainloader

Installation for Zelda Chainloader: Install as usual

Wii Linux (Proof of Concept 4)

Wii Linux PoF ver. 4

Download here.

Featuring:
USB keyboard support.

Homebrew apps/TCP Loader SOURCE CODE

Advanced stuff:

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

Cheers!

Twilight Hack / Loader 0.1 alpha 3b

Twilight Hack / Loader 0.1 alpha 3b

DOWNLOAD HERE

Changes: Experimental version with FAT32 support. Only try this if you receive an error message while loading boot.elf.

WII Proof of Concept LINUX 0.0.3

Wii Proof of Concept LINUX 0.0.3

DOWNLOAD HERE and try it out

Wii Homebrew Launcher

DOWNLOAD HERE

HOMEBREW APP PACK
Created by Hell Hibou
Install:

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.

Wii Shop Update!

A new Wii update that updates and prepares the Wiiware store does NOT affect the exploit

Woot!

Wiifuse 0.2.0

Download here.
Starting with version v0.2.0, you can also remotely mount your wii nand filesystem with wiifuse_server and a usbgecko adapter.

Requirements :

• An operating system which is supported by FUSE,
• FUSE 2.6.x (or higher) and
• OpenSSL

CHANGE LOG:

• v0.2.0

• completely revamped wiifuse_server

• v0.2.0-wip1

• 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

Homebrew Status: March 2008

Whats new in the Wii homebrew land?

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.

Cheers!

Team Twiizers - Wii Homebrew Channel Loader

Upcoming Team Twiizers will release their Wii homebrew channel soon. Check the video out, its great quality too, enjoy.


Wii Homebrew Channel - video powered by Metacafe

Twilight Hack 0.1 Alpha 3a!! is out

Download it here!

More and more features. We are all thankful for all development!

Latest changes:

0.1alpha3a

Correctly loads geckoloader code from USBGecko flash

0.1alpha3

Front 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 Linux

Wii Homebrew MP3 Player

Wii Tetris

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.

WriteELF GUI using WriteELF 1.6

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:

1. To use this program, you need to download a copy of the WriteELF program first.
   
   
2. Extract the writeelf.exe file to the same folder as the WriteELF GUI program.
   
   
3. Connect the SD Card to your computer.
   
   
4. Open the program. Choose the .ELF file and choose the drive where the .ELF file will be written.
   
   
5. 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).
   
   
6. Click on the GO button. A new window will pop up. Wait until the writing process finishes.

AtaWii beta 1 - Atari ST simluator for Nintendo Wii

AtaWii by NoNameNo

Download Here

This is an Atari ST emulator for Wii (port of the lame emulator, castaway)

Source is included in the download

Geckoloader 0.0.3

Download Geckoloader 0.0.3


Change Log:

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)


Requirements:

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.

Smash Brawl won't break your exploit

Smash Brawl ( the NTSC version) includes a system update which is a requirement before you can actually play. This update looks like just a bunch of bug fixes and has no affect on the Twilight Hack on regular, modless consoles.

Wii Linux PoC (Proof of Concept) v 0.2

Get it here.

Updated version of Wii (GC) Linux released.

Geckoloader v 0.0.2b

Get it here

and an older version 0.0.2 just in case:
Here

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


CHANGELOG:

v0.0.2b

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

coded by dhewg

WuM (Wii Update Manager) is out!

Get it here.


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

devkitPro version 14 released

New version, check it out.
http://www.devkitpro.org/

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.

devkitPPC for the Wii

devkitPPC (release 14) which is the gamecube toolchain was just released with Wii support

Get started right here.

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!

Interview with a Wii hacker

By Alex Bradner | January 29, 2008

Source: http://www.atomicmpc.com.au/article.asp?CIID=102079

Disassembling in the dark

Last night, Atomic talked to Wii hacker Bushing about every conceivable aspect of Wii hacking. To make things even more incredible, the first “Hello World” program to ever to run on a Wii was executed during our discussion.

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.

Enjoy!


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

Wii Hacking - First Stages (P. 2)

Some more photos of the process:

http://www.flickr.com/photos/bbyer/2221727801/in/set-72157603216569771/

Wii Hacking - First Stages

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 tehsceen, "Bushing along with Segher ... [were] able to modify a saved game from Zelda to crash the [Wii] and run their own code on it".

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

The best part is that no modchip is requited to try is out.
Try this at your own risk, theres no guarantee that something won't go wrong.
Good luck and dont brick your wii!