The Wii's security has been broken a few month ago by Team Twiizers and we are now able to run our self-written code on it. However, the IOS running on the co-processor Starlet currently still limits our abilities because it provides wrapper functions around most of the new hardware like the internal SD card slot, the disc drive and the USB ports.
Bushing and marcan figured out how to access the internal SD slot and I re-reverse enegineered it (basically to finally have a reason to learn some powerpc assembler) from the twilight hack and released some source code to do the required IOS calls.

So we're able to read data from the SD slot now but there is still more hardware that could be used to read data: The disc drive.
It can already be used to read data from any DVD when using a modchip in the Gamecube compatibility mode. So why isn't this possible in Wii mode right now?
The problem is that only Starlet has access to the DVD drive and provides a compatibility layer
in Gamecube mode (aka MIOS running on Starlet) that allows to read any data from the disc. They had to allow this because Gamecube games are - just like default DVDs - neither signed nor encrypted.
Wii discs however are encrypted with AES and signed with RSA so Starlet doesn't necessarily have to provide a similar layer - and it does not. It only provides a device node that allows unencrypted reads up to a certain offset (somewhere after the partition table). All data beyond this offset is encrypted and signed and can only be read after the signature check is passed. This signature check will defiantly fail on normal DVDs and we are therefore currently unable to read any data from a disc.
We sure could create a disc, encrypt it, calculate all needed hashes and the sign it by exploiting a bug - but that is a really nasty and annoying solution. DVDs are therefore a no-go unless we are able to run code on Starlet or find a function that allows raw reading of the whole DVD (ioctl code 0x8E is a candidate for this but I never looked at it and I'm not really interested in looking at it because it could also lead to piracy :/).

But if we need to have more data available on the Wii? If you for example want a media center for the Wii you defiantly don't want to copy your music (well... maybe that would be possible) and movies to SD cards and swap them around when you want to listen or watch something else. A possible solution would be to use the integrated wireless network card and stream the content from your PC but I don't want to boot my PC (no, I don't have a media server in my network :P) just to listen to some music or watch a movie.

Thankfully the Wii also has two USB slots that are ideal for this purpose: USB hard discs are really cheap today and can be used to store really much data. Libogc already has support for raw USB messages - the mass storage driver is the only thing missing.
There's one catch though why all those piracy kids can now stop reading and visit some other site: Only USB 1.1 is supported by the hardware so you're not going to be able to load your warez copies legal backups from the HDD. It's never going to be fast enough

The USB mass storage protocol itself is not very complicated after all once you understood it. The device basically provides two bulk endpoints through which it transfers all data. One of them is for receiving data from the host (i.e. the Wii) and the other one for sending data to it.
The protocol itself does however not specify how to tell the device what sector you want to read. It's just a wrapper around the real protocol implemented by most devices: SCSI multimedia commands.
To send a command to the device you have to go through the following procedure once it is in configured state:


Write a "Command Block Wrapper" (CBW) which contains the SCSI command and informations about the length of the data you want to transfer/receive to the OUT endpoint.
Read requested data from the IN endpoint, write the data to the OUT endpoint or do nothing here if no data except for the SCSI command is needed
Read a "Command Status Wrapper" (CSW) which tells you if you command succeeded from the IN endpoint.
Looks really simple, doesn't it?
To just read and/or write data you'll also only need three SCSI commands: One to read the capacity and sector size of the drive (READ_CAPACITY), one to read data (READ_10) and one to write data (WRITE_10).
Writing code to do this was not really difficult as you probably can imagine.
It only took me about one week because I though that the IOS did less than it actually does. Once a USB device gets connected to a host it normally starts the so-called enumeration process and should put the device in addressed state afterwards. Once a driver is selected for it then the driver reads all descriptors which contains informations about what protocols are supported. USB devices have support for more than

Fixed a bug in POWCNT1 register.
Fixed a bug in BLX opcode.
Fixed a bug in Character Base Block.
Fixed a bug in Textures Management.
Fixed a bug in 0xE AR opcode.
Fixed a bug in LDRH Post Index Opcodes.
Fixed a bug in free textures.
Fixed a bug in Alpha Blending Effects.
Fixed a bug in bind textures.
Fixed a bug in Texture Coordinates Transformation.
Fixed a bug in Textures Blending.
Added advanced Textures Management.
Added support for GdiPlus for scaling operations.