Forgot your password?
typodupeerror
Hardware Hacking Wii Build

Unofficial Homebrew Channel For the Wii 150

Posted by kdawson
from the hacking-twilight dept.
marcan writes "The Homebrew Channel is a tool that can be installed on any Wii (no hardware mods required) that lets you run unsigned homebrew software from an SD card, or upload executables via WiFi or a USBGecko. We've tried to make it friendly for users with a simple GUI, and powerful for developers with direct upload features and reloading which we hope will make testing less painful. The channel can be installed using a DVD if you have a modchip, or using an exploit in Zelda: Twilight Princess which only requires an SD card (or any future hack or booting method). Once installed, it simply shows up as a Channel on the Wii Menu, just like any official channel. Hopefully, this and other recent developments (such as the upcoming devkitPPC r15 toolchain, much improved and with many bugs fixed) will help make the Wii an appealing platform for DIY software. And yes, it also runs Linux."
This discussion has been archived. No new comments can be posted.

Unofficial Homebrew Channel For the Wii

Comments Filter:
  • Re:Oy vey (Score:5, Informative)

    by KingArthur10 (679328) <arthur.bogardNO@SPAMgmail.com> on Sunday May 25, 2008 @07:27PM (#23539169)
    No hardware mods necessary, but one of the avenues of attack is by using a hardhack and modding the DVD drive.
  • Re:And so it begins. (Score:5, Informative)

    by LiENUS (207736) <slashdotNO@SPAMvetmanage.com> on Sunday May 25, 2008 @07:39PM (#23539235) Homepage
    This mod certainly allows you access to free games, however it does not make it easy to run commercial games for free. It merely allows access to home brew games without a modchip. Modchips do not make Nintendo any additional money over the cost of the console anyway.
  • Re:And so it begins. (Score:5, Informative)

    by Xebikr (591462) on Sunday May 25, 2008 @07:40PM (#23539237)
    Except Nintendo actually (gasp) sells the Wii at a profit: [wikipedia.org]

    While Microsoft and Sony have experienced losses producing their consoles in the hopes of making a long-term profit on software sales, Nintendo reportedly has optimized production costs to obtain a significant profit margin with each Wii unit sold. According to the Financial Times, this direct profit per Wii sold may vary from $13 in Japan to $49 in the United States and $79 in Europe.
  • Very polished (Score:5, Informative)

    by i.of.the.storm (907783) on Sunday May 25, 2008 @08:01PM (#23539397) Homepage
    Installed it this morning and it's very polished, looks and feels like a real Nintendo made channel. A few bits and pieces aren't fully there (no vibration when going over buttons) but it's really well done overall, and has auto-update support and loads .elfs over LAN. Also, Team Twiizers is pretty sure that it's safe currently, and they're working on a fix for bricked Wiis. They've already got a fix for semi-bricked Wiis, which is pretty cool. If you want to read up on some of the background of Wii hacking, check out their site: http://hackmii.com/ [hackmii.com]
  • Re:And so it begins. (Score:5, Informative)

    by marcansoft (727665) <hector@marcans[ ].com ['oft' in gap]> on Sunday May 25, 2008 @08:04PM (#23539413) Homepage
    Unsigned software != pirated commercial software.

    While, of course, this ability implies that you *can* run pirated software, with the right modifications, in practice I have yet to see a plausible black-hat group with the expertise needed to develop such a hack. And we're sure as heck not going to do it ourselves. All that people have been doing is Virtual Console piracy, which is quite easy once a few details got released / leaked, due to nintendo's multiple mistakes on their DRM. But patching commercial games to read their data from SD or USB is not at all trivial.
  • The website he linked to is a joke (whether the op is aware of this I do not know) but try clicking the buy this now link
  • Re:Very polished (Score:5, Informative)

    by marcansoft (727665) <hector@marcans[ ].com ['oft' in gap]> on Sunday May 25, 2008 @08:33PM (#23539573) Homepage
    For what it's worth, fixing a bricked wii is going to require a hardware programmer and some soldering, because it's bricked and as far as we know there's no backdoor to fix it (we're *gasp* using the proper term 'brick' here). However, hopefully we'll be able to develop a firmware modification that will insert a backdoor early into the boot process to provide a way of restoring if needed, assuming your Wii isn't bricked yet. Unfortunately, with the official software, the Wii is quite prone to permanent bricking. Even something as simple as a malformed channel banner file can cause it.

    For those that do not know, "semibricked" (no, we did not invent the term) means that you've installed a version of the System Menu from another region (usually by using a game from another region that contains an update, with a modchip). The results are that you cannot access the Settings menu, as the internal inconsistency means that it tries to load the wrong files and ends up at an Opera 404 screen. Surprise! The Wii Settings menus are just HTML files. This can be easily fixed by running a game with an update for the right region that's newer than the installed one. The "fixes" up on our site are just the latest versions packaged as updates inside ISO images.

  • I'm amazed (Score:5, Informative)

    by jessecurry (820286) <jesse@jessecurry.net> on Sunday May 25, 2008 @08:37PM (#23539595) Homepage Journal
    I'm amazed every time I see these Wii homebrew projects. As an actual DS/Wii developer I see the time that is involved setting up our official development environment and can't believe how dedicated the homebrew community is.
  • They don't seem very worried either. Virtual Console piracy is relatively popular recently, due to several massive flaws in their DRM, which also happen to enable our homebrew software (in part). They've had a fixed piece of security software install itself as part of the newest update, but they haven't flipped the right bit to enable it yet. It's been a long while. The big bug? A terribly, horribly, completely broken RSA implementation with an effective security of 8 bits - because they used strcmp() instead of memcmp() when testing signatures!

    As for us, we'll still be able to run homebrew after they fix the security software. There are plenty of other bugs that we can use (most of which are not public yet, so chances are Nintendo doesn't know about them), and most do not enable VC piracy as directly as the one major bug that they "fixed".
  • by Anonymous Coward on Sunday May 25, 2008 @09:26PM (#23539921)
    This is the most informative post I have ever read on Slashdot.
  • Re:DVD Player? (Score:3, Informative)

    by LiENUS (207736) <slashdotNO@SPAMvetmanage.com> on Sunday May 25, 2008 @09:31PM (#23539937) Homepage
    From what I understand all dvd access must go through IOS which is a kernel that handles IO (for more than just the DVD drive) running on an ARM processor. The IOS normally does not allow the kind of access necessary for a DVD player. There is apparently an enable dvd video system call but it is not known exactly what it does/how it functions.
  • by Anonymous Coward on Sunday May 25, 2008 @09:52PM (#23540039)
    This is simply rewriting history.

    The Dreamcast was already close to death by the time these hacks came out. It was a combination of Sega's insufficient capital to continue advertising the Dreamcast past the 9/9/99 launch, and a steady drumbeat from Sony about how the PS2 would be a generation ahead. Sega was simply outmatched from the start.

    The Dreamcast was a great console with perhaps the most interesting lineup of games, but it was always going to be a poor cousin to the PS2.

    Besides, if piracy kills consoles, the PS2 would have faded about 18 months after it came out.

  • Re:And so it begins. (Score:5, Informative)

    by Orange Crush (934731) * on Sunday May 25, 2008 @10:11PM (#23540165)
    Currencies fluctuate in value relative to each other, taxes and logistical considerations vary from region to region, there are different marketing expenses and the comparative "value" of the system will vary along with the disposable incomes of consumers across different regions as well. Why in the world shoudn't Nintendo charge different prices in different regions when there are so many other fluctuating variables across different markets?
  • by FrangoAssado (561740) on Sunday May 25, 2008 @10:17PM (#23540205)

    I'm speaking here as an amateur Nintendo DS developer with some experience with DevkitPro, the "toolchain" made by some guys to run stuff on Gameboy Advance, Nintendo DS, Gamecube and recently Wii, among others. I have no direct experience with Wii developing, but I think I can help you a little...

    * Which programming language can I use? I am guessing C/C++ is supported?

    The "toolchain" is called "DevkitPPC" (a part of DevkitPro, which is available here [devkitpro.org]) consists of GCC and some other utilities (many from GNU) and libraries to generate ELF executables that the Wii can run. So, basically, C and C++ are supported.

    I don't know about the last version, but they're working daily on the CVS mainly with Wii updates, so expect the next version (r15) to be very nice. All this is available as a Windows installer, or you can get binaries (or the source) for Linux. I remember seeing something for OSX, but I don't know how it is nowadays.

    * Which UI library exist? Is there support for input devices, can I also output text and images?

    * Which network library exist? Can I use internet/WLAN connection, can I use Berkeley sockets API?

    * Are there existing example applications? Not only "hello world"... maybe something more complex?

    The libraries for the NDS are very low-level stuff, with very recent additions towards higher-level stuff; so I'd imagine the Wii stuff is still very low-level.

    There are some Wii examples to get you started. I don't know if the main packages include them, you can grab them here [sourceforge.net] if not.

    Finally, if you start developing for the Wii, expect to visit forums, dig up information on IRC and generally learn *very* low-level stuff to do anything beyond a simple "hello world".

  • Re:And so it begins. (Score:3, Informative)

    by cduffy (652) <charles+slashdot@dyfis.net> on Sunday May 25, 2008 @10:25PM (#23540259)
    Have you read the documentation on this softmod discussing why it can't be used to pirate commercial games? There are substantial technical measures protecting commercial software for the Wii (excluding Virtual Console titles) which haven't been cracked, and which this particular team (like most of the Wii homebrew scene) will not assist any third party in cracking.

    Also, I haven't noticed any reduction in commercial properties being produced for the DS, despite the availability of toolage for pirating commercial games; the legitimate userbase is simply too large for the pirates to make the system unprofitable.
  • by LiENUS (207736) <slashdotNO@SPAMvetmanage.com> on Sunday May 25, 2008 @10:45PM (#23540373) Homepage

    Specially the Wii with its peculiar controllers just cries to see a vibrant community of homebrewer making clever use of the accelerometers & IR cam.
    Fortunately Nintendo didn't abandon us entirely. The Wii remote uses standard bluetooth. So even if Nintendo blocks homebrew by divine magic. Developers [arstechnica.com] will [thisisnotalabel.com] keep [sourceforge.net] developing [sourceforge.net].
  • Re:DVD Player? (Score:5, Informative)

    by Rathus (664608) on Monday May 26, 2008 @02:10AM (#23541477)

    It's not that Nintendo is worried about the platform being secure, it's that every console sold would incur a lisencing fee for DVD's Copy Protection (CSS), therefore increasing the cost of each Wii for Nintendo, and directly then for the consumer. Given this decision was made long before the Wii's success was known.

    There are also people who mention the Wii's DVD drive is not meant for continious access, and that DVD playing would cause the drives to wear out faster. Why ruin a $300 system instead of a $30 DVD player?

  • by Twintop (579924) <david@twintop-tahoe.com> on Monday May 26, 2008 @04:52AM (#23542305) Homepage Journal
    FrangoAssado summed most of the NDS development stuff up. One thing I'd like to point out that if anyone is looking in to NDS development, to check out the Programmer's Arsenal Library, PALib [palib.info]. It it a good framework that takes care of a lot of the low-level stuff and allows you to develop.
  • Re:And so it begins. (Score:3, Informative)

    by LordVader717 (888547) on Monday May 26, 2008 @05:29AM (#23542447)
    Just go buy a Freeloader [amazon.co.uk].
  • by marcansoft (727665) <hector@marcans[ ].com ['oft' in gap]> on Monday May 26, 2008 @06:15AM (#23542683) Homepage
    Yes, C/C++ is supported.

    There are no decent UI libraries yet. What you do get is direct access to the GPU with libOGC (the main homebrew library). The API is similar in spirit to OpenGL, though not directly compatible, and there is some setup needed. There's are a few examples on the devkitpro CVS (download the module 'examples'). Most are for GameCube, but don't be fooled - they can be compiled for Wii with no modifications, most of the time, by adding -mrvl to your CFLAGS and LDFLAGS. Graphics support is probably the least user-friendly part of libogc.

    Input devices are quite easy to use, both GC pads and the Wiimote, in the latest version of libOGC (which requires the latest CVS devkitPPC). Once r15 is out, you'll get all of this in easy to use precompiled packages. Things like inactivity timeouts and auto-connection work out of the box, and you pretty much just call one function to scan for pads, and one function to read the current state structure.

    SD filesystem support is also trivial. One init call, and then it's just stdio, using URL-ish paths: fat:/file, etc. With the Homebrew Channel, you also get your current directory set to the directory of your executable on the SD card (via argv[0]), so you can just open relative paths and they'll go to the right place on the SD card.

    Networking is supported (via wlan and USB adapter), through an API that is mostly Berkeley Sockets compatible. A few things are somewhat nonstandard, but we can't do much about them - in this case, the TCP/IP stack is implemented in the IO/Security coprocessor, so we're just wrapping that interface.

    Also, getting a USB Gecko [usbgecko.com] is recommended. It's basically an interface that looks like a USB serial port on one end and plugs into your GC memory card slot on the other. While you can have a text console on-screen, the Gecko lets you have easy stdin/out directly from a PC, which is very useful for debugging. You can also call DEBUG_Init() and get a gdb stub listening over gecko when you get an exception, so you can easily get a backtrace and all of those goodies. We'll probably come up with something better in the future (via wifi?), but it's still a very nice, simple low-level peripheral to have.

    Admittedly, the documentation now is very lacking, because most developers have been spending their time coding new features. Now that things are getting calmer and I have more time, I hope to start documenting things a lot better.
  • Re:And so it begins. (Score:3, Informative)

    by marcansoft (727665) <hector@marcans[ ].com ['oft' in gap]> on Monday May 26, 2008 @08:11AM (#23543313) Homepage
    Freeloader will die a certain death once nintendo updates their software. They use the same hack that we use (the RSA bug).

Are you having fun yet?

Working...