Slashdot Mirror

Cisco iOS (used in routers) or BroadOn iOS (used in Wii)?

DRM in some form has existed for years... Even the original Nintendo had it https://hackmii.com/2010/01/th...

Do you have a link for more information?

It involves Jodi Daugherty from Nintendo's anti-piracy department. (Yes, the same Jodi after whom the "Return of the Jodi" jailbreak is named.) Look at this page and this page and search them for "phone".

Do you have a link for more information?

It involves Jodi Daugherty from Nintendo's anti-piracy department. (Yes, the same Jodi after whom the "Return of the Jodi" jailbreak is named.) Look at this page and this page and search them for "phone".

Whilst an evolution of the existing hardware is logical, really they need to rethink the whole software architecture too. The Wii has never improved over time in the way that its competitors have e.g. got a better browser, new stuff on home screen etc, and new peripherals like MotionPlus are not backwards compatible, because of the decision to basically bundle different versions of the whole "OS" with each game.

Also: seriously guys, stop pretending that the hardware specs don't matter at all because they DO, e.g. be generous with the RAM for a change. This is especially important early in the console's lifecycle, when developers don't know how or have the time to hand-tune assembly to get some performance out of the thing. Remember all those terrible ports like Far Cry? First impressions count, especially with a casual gamer heavy audience.

There are about 600K Wii's with the Homebrew channel (as reported by http://hackmii.com/ ) Which is a 'requirement' for Wii piracy.

There are over 75 million Wii units sold according to Wikipedia.

Claiming that 1% of the users has a huge impact on game sales is quite something.

Oh wait... The Wii tried to do what he described (public/private keys) and failed pretty miserably. See old posts at HackMii for details.

I don't have a Wii, but everything I can find on Google about the Homebrew Channel points to it being applications that run under the Wii OS. It's not Dual Boot at all, just a channel that appears along side all of the other Wii menu items, no?

All parts of the Wii OS that run on the main CPU, such as the "home" menu, are statically linked into the game executable. The Homebrew Channel that appears in the Wii Menu is a chain-loader analogous to loadlin, and HBC apps use the loaded IOS much as a PC uses BIOS. Closing an HBC app goes back to HBC, and switching from HBC back to the Wii Menu is more like a reboot. It's as if Chrome OS for the jailbroken iPad were packaged as an iOS app that rebooted the tablet into Chrome OS.

You might be interested in these numbers:
339170 Homebrew Channel installations ( http://hackmii.com/2010/08/the-scope-of-homebrew-channel/ ). Of 70mil Wiis ( http://en.wikipedia.org/wiki/Wii )
We are talking about about 0.5% of the consoles having been "homebrew enabled", this is pretty much a required step for running 'backups' on the Wii. (Not all homebrew installs are for piracy, but a lot are) Yes, piracy happens, but only in a small amount. And the Wii is ridiculously easy to hack.

Why is this modded troll? Anyone who follows the Wii homebrew scene knows Waninkoko has been very disruptive to people who want to write and run homebrew code without having anything to do with piracy.

See also for example this post from another Homebrew Channel developer. And this from marcan (presumably the parent) about how he wrote an USB loader in 6 hours just to show it's no big deal, given everything other people had already done.

Why is this modded troll? Anyone who follows the Wii homebrew scene knows Waninkoko has been very disruptive to people who want to write and run homebrew code without having anything to do with piracy.

See also for example this post from another Homebrew Channel developer. And this from marcan (presumably the parent) about how he wrote an USB loader in 6 hours just to show it's no big deal, given everything other people had already done.

• If there exists no approved method for end users to make and run code, or if running code requires a substantial additional purchase and recurring fee, it's a "jailbreak".
• If the end user can trigger it by accident, it's a "hole".

The owner of a Windows machine is the administrator. Windows supports configuring a "software restriction policy" requiring validation of Authenticode signatures, but this mechanism explicitly allows the machine's owner to sign software. So any vulnerabilities are holes.

But for iOS devices, the approved method of running code outside the store involves buying a $599 additional hardware device made by the same company (Mac mini) and a $99 per year subscription (iPhone developer certificate), so this is a jailbreak. And in the case of Wii homebrew (which was restored on 4.3 within the past week), it's also a jailbreak because Nintendo is even stricter: becoming an authorized developer involves leasing office space, not coding out of a bedroom. And yes, this is affecting developers: see Bob's Game.

Could they refuse to replace a broken glass screen if they find out your iphone is or was ever jailbroken, JUST BECAUSE it was jailbroken?

Nintendo has already done this to someone who softmodded a Wii and sent it for repair, charging more than the retail cost of a new Wii to repair the Wii sent in. Granted, that was in Germany, but in answer to your question, companies would love to do something like that.

Not that big a deal for new games, but what about the huge library of existing games that won't be able to support it?

If the games were reading existing controls through an API rather than bit-banging hardware ports, the driver should be able to translate keyboard keypresses into player 1's gamepad keypresses. It'd be like JoyToKey for Windows, except in reverse. But then the operating system on something like a Wii is so thin that it might not be possible.

Or you could have a Wii which lags behind the updates

I too follow this method.

Unless you want to play the very newest games [...] or use the Wii Shop channel

Or buy a Wii console for the first time. Or leave your Wii console where another family member not aware of the dangers of updating can get to it. Or keep your warranty intact; Nintendo charges the full price of a console for disc drive replacement on a Wii console that has had HBC installed on it (source).

As for adding new functionality, Nintendo has been adding new functionality to the Wii from time to time as well (dare I say more than Sony has done with PS3). This update is the first anti-piracy-only Wii update that doesn't add new functionality (or fix other problems).

They really haven't. Let's consider the timeline of updates to the Wii software since the first exploit was demonstrated. Note that there's no technical need to update the System Menu, any version of IOS (the invisible "firmware" that implements all of the interesting security features of the system), or any channel at the same time. IOS fixes can never add functionality by themselves, they can only work around some bugs in disc-based games. Any update that claims "behind the scenes updates" or "system improvements" refers to IOS updates, most of which are to patch exploits and very few of which actually impact performance, despite their claims.

• v3.3 June 17, 2008 -- No features, added code to the System Menu to block the Twilight Hack.
• v3.4 November 17, 2008 -- Fixed anti-Twilight Hack code. Updated Parental Controls, and added USB keyboard to the Mii Channel (?). Strange attempt to block the default slot number used by a code example I released.
• v4.0 March 25, 2009 -- Considerable update to the System Menu to add support for running channels that are stored on SD card.
• v4.1 July 2009 -- Fixes an obscure System Menu bug. Added code to better block copy-protected saves.
• v4.2 September 28, 2009 -- First attempt at blocking Bannerbomb.Also added code to delete the Homebrew Channel and DVDX. Added code to check to see if a console had its region altered, in some cases forcing a brick (!). Improved region-checking code for games. Forced a bootloader update (boot2v4) that didn't actually fix any bugs or exploits -- it just overwrote your bootloader "just in case" you had modified it, and caused a fair bit of collateral damage which Nintendo tried to blame on "hacking", even on virgin consoles. (There's a reason they tell you not to reflash your BIOS if you don't really need to...)
• v4.2 June 21, 2010 -- Second attempt at blocking Bannerbomb. Deletes (again!) the Homebrew Channel and BootMii(/IOS), and patches IOS exploits used to install them.

The only update Nintendo has done in the past 2 and a half years that has actually benefitted users was v4.0, which added the SD support (as crude as it was). All the others have just been ways to fix various exploits. They fail at using the carrot; their stick is the fact that the Shopping channel will break unless you update, and many games will force you to update before you can play them.

As for adding new functionality, Nintendo has been adding new functionality to the Wii from time to time as well (dare I say more than Sony has done with PS3). This update is the first anti-piracy-only Wii update that doesn't add new functionality (or fix other problems).

They really haven't. Let's consider the timeline of updates to the Wii software since the first exploit was demonstrated. Note that there's no technical need to update the System Menu, any version of IOS (the invisible "firmware" that implements all of the interesting security features of the system), or any channel at the same time. IOS fixes can never add functionality by themselves, they can only work around some bugs in disc-based games. Any update that claims "behind the scenes updates" or "system improvements" refers to IOS updates, most of which are to patch exploits and very few of which actually impact performance, despite their claims.

• v3.3 June 17, 2008 -- No features, added code to the System Menu to block the Twilight Hack.
• v3.4 November 17, 2008 -- Fixed anti-Twilight Hack code. Updated Parental Controls, and added USB keyboard to the Mii Channel (?). Strange attempt to block the default slot number used by a code example I released.
• v4.0 March 25, 2009 -- Considerable update to the System Menu to add support for running channels that are stored on SD card.
• v4.1 July 2009 -- Fixes an obscure System Menu bug. Added code to better block copy-protected saves.
• v4.2 September 28, 2009 -- First attempt at blocking Bannerbomb.Also added code to delete the Homebrew Channel and DVDX. Added code to check to see if a console had its region altered, in some cases forcing a brick (!). Improved region-checking code for games. Forced a bootloader update (boot2v4) that didn't actually fix any bugs or exploits -- it just overwrote your bootloader "just in case" you had modified it, and caused a fair bit of collateral damage which Nintendo tried to blame on "hacking", even on virgin consoles. (There's a reason they tell you not to reflash your BIOS if you don't really need to...)
• v4.2 June 21, 2010 -- Second attempt at blocking Bannerbomb. Deletes (again!) the Homebrew Channel and BootMii(/IOS), and patches IOS exploits used to install them.

The only update Nintendo has done in the past 2 and a half years that has actually benefitted users was v4.0, which added the SD support (as crude as it was). All the others have just been ways to fix various exploits. They fail at using the carrot; their stick is the fact that the Shopping channel will break unless you update, and many games will force you to update before you can play them.

As for adding new functionality, Nintendo has been adding new functionality to the Wii from time to time as well (dare I say more than Sony has done with PS3). This update is the first anti-piracy-only Wii update that doesn't add new functionality (or fix other problems).

They really haven't. Let's consider the timeline of updates to the Wii software since the first exploit was demonstrated. Note that there's no technical need to update the System Menu, any version of IOS (the invisible "firmware" that implements all of the interesting security features of the system), or any channel at the same time. IOS fixes can never add functionality by themselves, they can only work around some bugs in disc-based games. Any update that claims "behind the scenes updates" or "system improvements" refers to IOS updates, most of which are to patch exploits and very few of which actually impact performance, despite their claims.

• v3.3 June 17, 2008 -- No features, added code to the System Menu to block the Twilight Hack.
• v3.4 November 17, 2008 -- Fixed anti-Twilight Hack code. Updated Parental Controls, and added USB keyboard to the Mii Channel (?). Strange attempt to block the default slot number used by a code example I released.
• v4.0 March 25, 2009 -- Considerable update to the System Menu to add support for running channels that are stored on SD card.
• v4.1 July 2009 -- Fixes an obscure System Menu bug. Added code to better block copy-protected saves.
• v4.2 September 28, 2009 -- First attempt at blocking Bannerbomb.Also added code to delete the Homebrew Channel and DVDX. Added code to check to see if a console had its region altered, in some cases forcing a brick (!). Improved region-checking code for games. Forced a bootloader update (boot2v4) that didn't actually fix any bugs or exploits -- it just overwrote your bootloader "just in case" you had modified it, and caused a fair bit of collateral damage which Nintendo tried to blame on "hacking", even on virgin consoles. (There's a reason they tell you not to reflash your BIOS if you don't really need to...)
• v4.2 June 21, 2010 -- Second attempt at blocking Bannerbomb. Deletes (again!) the Homebrew Channel and BootMii(/IOS), and patches IOS exploits used to install them.

The only update Nintendo has done in the past 2 and a half years that has actually benefitted users was v4.0, which added the SD support (as crude as it was). All the others have just been ways to fix various exploits. They fail at using the carrot; their stick is the fact that the Shopping channel will break unless you update, and many games will force you to update before you can play them.

It's amusing to me the back and forth between Nintendo and homebrew, and homebrew just about always tends to come ahead in the end. Every time an exploit is patched, a work around is usually available in the next few days.

The sad part of the story is that Homebrew was never about piracy, but about giving the ability for people to play around with the Wii architecture. In the beginning some of the Homebrew developers even offered to help patch/expose certain exploits only to be completely snubbed by Nintendo. Now the developers don't even really care about disabling piracy given Nintendo's smug attitude.

Sadly for Nintendo there are already two exploits known to work on 4.3U, this one (http://wiibrew.org/wiki/Smash_Stack) and this one (http://wiibrew.org/wiki/Indiana_Pwns). Granted you have to have a copy of the game to use them but for most people that is not a problem.

The main thing they blocked are bannerbomb (http://wiibrew.org/wiki/Bannerbomb) the exploit used by most everyone to "softmod" a Wii which allowed you to place a file on the SD card and run it via the system menu and the hackmii installer (http://hackmii.com/2009/08/hackmii-installer-v0-3/) which installed the Homebrew channel and bootmii. The hackmii installer should be updated in the coming days as they've been stockpiling exploits and not releasing them to the public in case the one they currently used was ever blocked.

All that said there is no reason to update anyway if you already have homebrew. The shopping channel can always be updated with a homebrew tool and accessed on any version of the system menu. They didn't add anything new to the System menu this time around it was just aimed at removing homebrew just like the last update (4.2).

This is not "how to exploit NULL pointers" ... this is "how to exploit a kernel NULL function pointer".

No, it's just the "simplest" example of exploiting NULL pointers. If your NULL pointer is not a function pointer, you can still exploit it in many cases, you just need to work slightly harder.

no null pointer reads and writes in kernel mode (which are more common) will get you root.

Wrong

to deference any NULL pointer would effectively be calling that function, assuming this memory mapping really works.

It's not as simple as that. If the kernel contained a read access to that pointer in the exploitable code, it would still perform a read, even though the memory location contained executable code. The only thing would be, that now you would have the numerical value of the instructions in a register, that's it.

But in many cases, the NULL pointer dereference would still be exploitable, it would only be slightly more complicated.

TFA explains how to exploit a theoretical kernel bug that happens to "read a function pointer from address 0, and then call through it". That's a long shot from turning "any NULL pointer" into a root exploit as the summary claims.

Having the NULL pointer being a function pointer was just the easiest "use case" for this kind of bug.

For another example, involving a write to a doubly dereferenced NULL pointer, read here.

And, with most structures containing pointers to other structures, double dereferencing doesn't look so far-fetched.

Here is one example how to exploit a different kind of NULL pointer dereference.

The article is rather long, but the short summary is, the kernel does a->some_field->x=NULL , where a is the NULL pointer.

The NULL page is under the control of the exploiter. So he can set some_field to point to a memory location he wants to zero out. That could be any location in kernel space (such as a hypothetical byte that contains the user id of the current process). In our case, the exploiter used the return address on the stack. Which caused the system call to "return" to address NULL, nicely transforming a "write to NULL" exploit into a "call NULL exploit", and from there, we continue just like in the tutorial.

One of the many exploits that we've used to own the Wii (in fact, the very first runtime IOS exploit that we used, which I found and implemented) was a NULL pointer dereference bug, and it wasn't even a function pointer.

I wrote a detailed blog post about it recently. The short version is that they doubly dereference a near-NULL address and write to it, and NULL happens to be real physical memory that we control (call it 'insecure', if you wil). The double dereference lets us direct the write anywhere, including the stack, and it's game over. That's the "usermode" exploit. Privilege escalation into the kernel is trivial because they have some huge kernel holes. The fact that they map the 'insecure' memory as executable (!) in every application makes it even easier.

Check out the attacks on the DSi, especially the RAM sniffer/injector by scanlime. You can even download the code and give it a go, if you can make the hardware setup that he built. Essentially, you downclock the DSi to a more manageable speed and then tap the entire RAM chip (address and data), so you can get a realtime trace of everything that the console does with external RAM, and change anything. The implementation itself is done using an FPGA and a USB 2.0 FIFO chip. It's really quite amazing.

This would be nearly impossible to pull off with the type of RAM on the PS3, but it definitely beats random glitching.

If you want an older example, check out bunnie's xbox hack from 2001. He taps the LDT (HyperTransport) bus on the Xbox1 using a custom sniffer board and highly tuned FPGA code in order to capture the fast DDR bus transfers and sniff out the secret boot sector.

Check out the attacks on the DSi, especially the RAM sniffer/injector by scanlime. You can even download the code and give it a go, if you can make the hardware setup that he built. Essentially, you downclock the DSi to a more manageable speed and then tap the entire RAM chip (address and data), so you can get a realtime trace of everything that the console does with external RAM, and change anything. The implementation itself is done using an FPGA and a USB 2.0 FIFO chip. It's really quite amazing.

This would be nearly impossible to pull off with the type of RAM on the PS3, but it definitely beats random glitching.

If you want an older example, check out bunnie's xbox hack from 2001. He taps the LDT (HyperTransport) bus on the Xbox1 using a custom sniffer board and highly tuned FPGA code in order to capture the fast DDR bus transfers and sniff out the secret boot sector.

Yes, the loader is using a rom-hack to load, and shows up on the DSi menu as a different game

I was going based on what I read at hackmii.com. If the cart's firmware includes the "different game", that'll be even harder to defend in court.

Every single DSi-compatible DS cart, including Datel's Action Replay DSi, includes portions of a pirated cart ROM. Nintendo started signing all executables and retroactively signing the existing library of DS games (they include the hashes built in to the DSi firmware), so the only way you can get an unofficial DS cart to run on the DSi is by pirating a game's executable/header and partial data and then using a data file exploit (data files aren't signed) to make it bootstrap your code. These DSi-compatible cartridges even show up with the game icon of a real game in the menu, since that part is also signed.

If that isn't a lawsuit in the making then I don't know what is.

Nintendo has been known to ask for 210 EUR (that's over current retail price now!) to repair a Wii that they've determined had homebrew installed, even if it was in warranty. They can't really tell if the console is completely bricked, though, only if enough of the software is functional to let their rescue discs boot.

In the wii, downloadable upgrade must be done in the game itself since there is no operating system running when the game run. marcan explains that very well in http://hackmii.com/2009/02/why-the-wii-will-never-get-any-better/

Posting AC not to undo moderation...

Yes, software is definitely where it's at! Just look at the Wii sales, despite its graphics that are lagging behind even the old xbox, and by a long shot. The 2nd best selliong console? The DS, which also doesn't have high end graphics. It comes down to having a lot of new, fun games. Not everyone is dying for the latest WW2-themed FPS in 1080p.

That beind said, I recently stumbled across a short "article" named why the wii will never get any better. That provides a lot of ingisht about the Wii's software stack. They better get their act together, or their sales of the next gen consoles will probably drop just like before the NES/famicom.

I'm buying a 360 soon, half because it's a DLNA player, and half because it supports newer games. The gamepads also work with our PCs as a bonus.

I've heard people don't even have the homebrew channel disabled when they get a Wii back from repair

And I've read anecdotes to the contrary. People sending in a Wii console out-of-warranty to replace a broken disc drive (should be about $75 if that) are charged for essentially a new console because Nintendo detected a "Softwarehack".

Indeed, there is no operating system on the nintendo wii. Basically when a game boots, it takes the all control on the platform. The only things that stays is some kind of IRQ that is used for networking. The "wiimote input library" is statically linked into each game. So it will not be changed easily. More information on http://hackmii.com/2009/02/why-the-wii-will-never-get-any-better/

Read: It's a near impossibility to support older titles. It would be nice to head over to http://hackmii.com/2009/02/why-the-wii-will-never-get-any-better/ and find out why; specifically:

As it turns out, Nintendo chose not to have any operating system or common code at all running on the Broadway CPU. When you run a game, everything that shows up on your screen, ever, is being loaded from that spinning polycarbonate disc. And there are no mechanisms for anything else to run on that CPU: no update infrastructure, no Home Menu updates, nothing. If they ever want to have a "hypervisor" run above games, they'll need to get a new CPU with full-blown virtualization capability (or an emulator), because games assume they have direct access to the CPU and most of the hardware.

If you've been following the Wii scene, you might be thinking, "what about IOS?" Indeed, Nintendo's security and I/O Operating System runs alongside games (on a separate CPU built in to the Hollywood chipset) and it is updated as part of system updates. It includes some important bits and pieces like some peripheral drivers. However, as it turns out, Nintendo has decided that every new feature will be developed as a separate fork. Your Wii contains many IOS versions, and the older have never been updated except for security reasons (to fix our exploits). Not that they've added many new features, but if you look closely, new IOS features do not operate when you're playing older games. This includes any updates to the WiiConnect24 downloads code, and even some minor things like the "slot LED blinks when you eject a disc" feature - try it when you're playing Zelda and you'll see that it doesn't work, because it's using the very old IOS9.

No, you're wrong.

If it copies to NAND (the internal Wii memory) before launching, then, by definition, games aren't being launched directly off SD card.

go to hackmii.com

Actually, it sounds like from what marcan said, it might have closed the hole more or less permanently.

# Twilight Hack no longer works. Iâ(TM)d like to remind everyone that this exploit has been in use for over a year. Whether it comes back or a new game exploit takes its place, I think we can say itâ(TM)s served us all well.

No, you don't seem to understand at all, there is no need to move to a different game.

For eternity people will be able to buffer-overflow zelda, it's a pressed disc.

The problem is hacking the wii's system software (ios) to gain control of the co-processor that handles all the security certificates etc.

Hacking zelda and controlling the PPC is child's play, the ARM doing the gruntwork is the goal.

Right, so I should probably include relevant links for those too lazy to Google. Consider this a mini-guide to homebrew on the Wii.

• The Homebrew Channel: This is essentially a launcher for unsigned code on the Wii. Follow the instructions on the page to install it onto your pre 4.0 Wii. As of now, there are no hacks to install it on 4.0 but it will only be a matter of time. This page also includes the Twilight Hack, which is a hacked save file for Twilight Princess that causes the Wii to crash and I presume elevate privileges so that you can run unsigned code from SD. The idea is that you run the Twilight Hack, which launched the HBC installer, and then it's on your Wii's system memory.
• HackMii: The blog of Team Twiizers, the group that does all the ground breaking hacking of the Wii. Definitely add them to your RSS reader if you decide to hack your Wii. It's also an interesting technical read. Note that Team Twiizers are firmly against piracy, and any mention of it there will not be tolerated.
• WiiBrew: Also run by Team Twiizers and co, this is the wiki for Wii homebrew. Contains apps and general information about Wii hacking, as well as technical information on the software and security of the Wii. In particular, this list is a fairly thorough list of legit homebrew applications on the Wii.
• The Homebrew Browser: This gets a special mention out of all the apps because it's basically a package repository type program for the Wii. The guy also runs a blog at codemii.com with updates on included applications and also a few basic Wii coding tutorials.

Phew. That's probably the most effort I've ever spent on a Slashdot post. These links should be enough to get anyone started. Since I'm tired of typing HTML tags, I'll just list a few recommended apps: GeeXBoX is an excellent media center app, and there's also a handful of mplayer ports, then there's all the emulators, Gecko OS lets you tweak a few aspects of the System menu as well as use cheats (but don't use them online, people have been getting banned), FTPii is useful if you're too lazy to take your SD card out of your Wii, there are a few Wii Linux distros in their infancy, and of course, a plethora of games (including Quake!).

One last thing, Team Twiizers is working on something called BootMii, which is essentially a replacement of some very low level boot code on the Wii. Once this is finished, Wii homebrew will essentially have complete access to everything on the Wii. Keep an eye out for it; among other things it should make a Wii relatively brick-proof. It'll be on Hackmii of course.

Right, so I should probably include relevant links for those too lazy to Google. Consider this a mini-guide to homebrew on the Wii.

• The Homebrew Channel: This is essentially a launcher for unsigned code on the Wii. Follow the instructions on the page to install it onto your pre 4.0 Wii. As of now, there are no hacks to install it on 4.0 but it will only be a matter of time. This page also includes the Twilight Hack, which is a hacked save file for Twilight Princess that causes the Wii to crash and I presume elevate privileges so that you can run unsigned code from SD. The idea is that you run the Twilight Hack, which launched the HBC installer, and then it's on your Wii's system memory.
• HackMii: The blog of Team Twiizers, the group that does all the ground breaking hacking of the Wii. Definitely add them to your RSS reader if you decide to hack your Wii. It's also an interesting technical read. Note that Team Twiizers are firmly against piracy, and any mention of it there will not be tolerated.
• WiiBrew: Also run by Team Twiizers and co, this is the wiki for Wii homebrew. Contains apps and general information about Wii hacking, as well as technical information on the software and security of the Wii. In particular, this list is a fairly thorough list of legit homebrew applications on the Wii.
• The Homebrew Browser: This gets a special mention out of all the apps because it's basically a package repository type program for the Wii. The guy also runs a blog at codemii.com with updates on included applications and also a few basic Wii coding tutorials.

Phew. That's probably the most effort I've ever spent on a Slashdot post. These links should be enough to get anyone started. Since I'm tired of typing HTML tags, I'll just list a few recommended apps: GeeXBoX is an excellent media center app, and there's also a handful of mplayer ports, then there's all the emulators, Gecko OS lets you tweak a few aspects of the System menu as well as use cheats (but don't use them online, people have been getting banned), FTPii is useful if you're too lazy to take your SD card out of your Wii, there are a few Wii Linux distros in their infancy, and of course, a plethora of games (including Quake!).

One last thing, Team Twiizers is working on something called BootMii, which is essentially a replacement of some very low level boot code on the Wii. Once this is finished, Wii homebrew will essentially have complete access to everything on the Wii. Keep an eye out for it; among other things it should make a Wii relatively brick-proof. It'll be on Hackmii of course.

That seems strange. Do you use the Twilight Hack to launch homebrew every time or have you just never gotten into homebrew? Once the Homebrew Channel is on your system you can launch homebrew through it from an SD card. Just install the HBC and you don't need TP anymore. You just have to be careful not to delete the HBC, and check wiibrew.org before every update in case it removes the HBC. So far, no updates have, although they have removed hacked TP saves.

# Twilight Hack no longer works. Iâ(TM)d like to remind everyone that this exploit has been in use for over a year. Whether it comes back or a new game exploit takes its place, I think we can say itâ(TM)s served us all well.

While this doesn't necessarily mean that the hack is dead, it seems like they're moving on to the next exploitable game. Also, you don't really need the Twilight Hack once you've installed the Homebrew Channel, and this update does not remove the Homebrew Channel. I held off on updating for a while but I actually buy WiiWare games, so this update is actually useful for me, and I keep my Homebrew Channel. The Twilight Hack finally being fixed does not really matter to me.

Someone's been living under a rock since December 2007.

I'll just point you to the recent 25th Chaos Community Congress Console Hacking talk (slides, video) which neatly summarizes a year of hacking and how much of a horrible failure Nintendo's security has been.

Spoiler: their signatures used to have 8-bit security. Literally.

We've had lots of fun.

The advert at the top of the page right now may well be telling you that you can save a fortune buy paying someone to learn how to run wii games for free (it is for me).
I'd hope that none of you would fall for this but be aware that all these sites provide is a bundle of freely available software including the twilight hack and homebrew channel. The makers of this software are not at all pleased about this sort of thing.
Is there any way to mod an advert down?

Yes, you can. You will need to make use of the Twilight Hack, so you definitely need Twilight Princess if you don't own a modchip. It's ok if you borrow it for an hour or so, you just need it to get your foot in the door.

Check out everything you need to know here: http://hbc.hackmii.com/

According to the blog, SDHC support can be done entirely in software. So it's just a matter of coding it in, both for homebrew creators (there will probably be a lib for it, if not one already) and for Nintendo.

It can't, unless you have a modchip and are willing to develop a DVD-playing application. There's rampant misinformation on this, as usual.

Let's set a few things straight:

• Currently, there is no public method for reading DVD-Rs on an unmodded Wii.
• This isn't the first "Custom Firmware" (I hate that word) for the Wii. Not even close. Not even the first public one. Or, alternately, this isn't and there has never been a true wii Custom Firmware, depending on how you look at it.
• The "Custom Firmware" is only a small patch to the firmware that does two things: disable signature checks and disable a certain read restriction on the DVD code. What this does is let you use standard-format DVD-Rs (i.e. ISO9660 or Video DVDs) with the DVD drive on the Wii, but you still need a modchip.
• The difference between this firmware and the original is exactly 5 bytes. 4 for the DVD maximum read restriction (an unsigned int), and one code byte patch for the signature disable. Hardly earth-shattering.

We released a legal open source firmware patcher some time ago. Approximately three days before this purpoted "custom firmware" came out, svpe had added the DVD restriction removal patch to it (this was in response to an outright modification to an older firmware, released with the original code and hence illegally, by nitrotux, which he distributed with a disc dumper, but our patcher patches all of the recent versions of the firmware which use a completely different subroutine for the check, so the patch is different even though the result is the same). The first revision of Waninkoko's "custom firmware" was so hastily done that it was basically a PPF patch over the original firmware. Except it's encrypted. And he even changed the key. Hence, the patch was useless and he ended up distributing the entire patched-and-reencrypted file in the form of the patch (the entire patcher was 2MB, which is the size of the entire firmware). The fact that he made this trivial mistake makes me think that he did this very quickly and stole the patches from the open source patchmii (the DVD patch is identical except for the actual number involved in the restriction, and the signature check disable patch, which is relatively hard to find and there are several ways of doing it, is exactly the same). He later released a newer version without the blatant patch fuckup which is presumably legal to distribute now, although it still requires people to rip the original firmware from a recent game (whereas our open source patcher automatically downloads it from Nintendo's servers).

Now onto the news. Recently, we actually did figure out a way of reading DVD-Rs without a modchip (!). Since this can be used for piracy (and could potentially cause quite an increase in it, since a free simple non-warranty-voiding pirate-game-playing hack is very appealing compared to the current modchip situation), we have tried to contact Nintendo about it (privately and publicly). If they ignore us, then we'll probably release an open source library and tools that will let Wii homebrew read information from a DVD-R on any Wii, modchip or not.

For anyone trying to draw parallels between the PSP and the Wii, I suggest this article. As for the PSP emulator, I'll believe it when I see more than a single screenshot.

It can't, unless you have a modchip and are willing to develop a DVD-playing application. There's rampant misinformation on this, as usual.

Let's set a few things straight:

• Currently, there is no public method for reading DVD-Rs on an unmodded Wii.
• This isn't the first "Custom Firmware" (I hate that word) for the Wii. Not even close. Not even the first public one. Or, alternately, this isn't and there has never been a true wii Custom Firmware, depending on how you look at it.
• The "Custom Firmware" is only a small patch to the firmware that does two things: disable signature checks and disable a certain read restriction on the DVD code. What this does is let you use standard-format DVD-Rs (i.e. ISO9660 or Video DVDs) with the DVD drive on the Wii, but you still need a modchip.
• The difference between this firmware and the original is exactly 5 bytes. 4 for the DVD maximum read restriction (an unsigned int), and one code byte patch for the signature disable. Hardly earth-shattering.

We released a legal open source firmware patcher some time ago. Approximately three days before this purpoted "custom firmware" came out, svpe had added the DVD restriction removal patch to it (this was in response to an outright modification to an older firmware, released with the original code and hence illegally, by nitrotux, which he distributed with a disc dumper, but our patcher patches all of the recent versions of the firmware which use a completely different subroutine for the check, so the patch is different even though the result is the same). The first revision of Waninkoko's "custom firmware" was so hastily done that it was basically a PPF patch over the original firmware. Except it's encrypted. And he even changed the key. Hence, the patch was useless and he ended up distributing the entire patched-and-reencrypted file in the form of the patch (the entire patcher was 2MB, which is the size of the entire firmware). The fact that he made this trivial mistake makes me think that he did this very quickly and stole the patches from the open source patchmii (the DVD patch is identical except for the actual number involved in the restriction, and the signature check disable patch, which is relatively hard to find and there are several ways of doing it, is exactly the same). He later released a newer version without the blatant patch fuckup which is presumably legal to distribute now, although it still requires people to rip the original firmware from a recent game (whereas our open source patcher automatically downloads it from Nintendo's servers).

Now onto the news. Recently, we actually did figure out a way of reading DVD-Rs without a modchip (!). Since this can be used for piracy (and could potentially cause quite an increase in it, since a free simple non-warranty-voiding pirate-game-playing hack is very appealing compared to the current modchip situation), we have tried to contact Nintendo about it (privately and publicly). If they ignore us, then we'll probably release an open source library and tools that will let Wii homebrew read information from a DVD-R on any Wii, modchip or not.

For anyone trying to draw parallels between the PSP and the Wii, I suggest this article. As for the PSP emulator, I'll believe it when I see more than a single screenshot.

... as usual.

Let's set a few things straight:

• Currently, there is no public method for reading DVD-Rs on an unmodded Wii.
• This isn't the first "Custom Firmware" (I hate that word) for the Wii. Not even close. Not even the first public one. Or, alternately, this isn't and there has never been a true wii Custom Firmware, depending on how you look at it.
• The "Custom Firmware" is only a small patch to the firmware that does two things: disable signature checks and disable a certain read restriction on the DVD code. What this does is let you use standard-format DVD-Rs (i.e. ISO9660 or Video DVDs) with the DVD drive on the Wii, but you still need a modchip.
• The difference between this firmware and the original is exactly 5 bytes. 4 for the DVD maximum read restriction (an unsigned int), and one code byte patch for the signature disable. Hardly earth-shattering.

We released a legal open source firmware patcher some time ago. Approximately three days before this purpoted "custom firmware" came out, svpe had added the DVD restriction removal patch to it (this was in response to an outright modification to an older firmware, released with the original code and hence illegally, by nitrotux, which he distributed with a disc dumper, but our patcher patches all of the recent versions of the firmware which use a completely different subroutine for the check, so the patch is different even though the result is the same). The first revision of Waninkoko's "custom firmware" was so hastily done that it was basically a PPF patch over the original firmware. Except it's encrypted. And he even changed the key. Hence, the patch was useless and he ended up distributing the entire patched-and-reencrypted file in the form of the patch (the entire patcher was 2MB, which is the size of the entire firmware). The fact that he made this trivial mistake makes me think that he did this very quickly and stole the patches from the open source patchmii (the DVD patch is identical except for the actual number involved in the restriction, and the signature check disable patch, which is relatively hard to find and there are several ways of doing it, is exactly the same). He later released a newer version without the blatant patch fuckup which is presumably legal to distribute now, although it still requires people to rip the original firmware from a recent game (whereas our open source patcher automatically downloads it from Nintendo's servers).

Now onto the news. Recently, we actually did figure out a way of reading DVD-Rs without a modchip. Since this can be used for piracy (and could potentially cause quite an increase in it, since a free simple non-warranty-voiding pirate-game-playing hack is very appealing compared to the current modchip situation), we have tried to contact Nintendo about it (privately and publicly). If they ignore us, then we'll probably release an open source library and tools that will let Wii homebrew read information from a DVD-R on any Wii, modchip or not.

For anyone trying to draw parallels between the PSP and the Wii, I suggest this article. As for the PSP emulator, I'll believe it when I see more than a single screenshot.