Today we are announcing a project that changes this completely and removes the requirement for an exploitable game.

In memory of BannerBomb, we present you with LetterBomb , a brand new System Menu exploit that will allow you to enable homebrew with the push of an envelope (no stamp licking involved)

This exploit reuses (and abuses) some of some Nintendo’s Wii Messageboard functionality.

You will need:

• A Wii running System Menu 4.3 (E/U/J/K)
• A SD(HC) card with some free space
• Your Wii’s WiFi MAC Address (available from your Wii’s system settings). This is needed because the Wii will only accept messages addressed to its specific MAC address.
• A few minutes of your time

For this very special occasion we have created an easy-peasy webpage that takes away some of the pain that is usually involved with getting homebrew onto your system:

http://please.hackmii.com

This webpage will ask you for some necessary information (such as your System Menu region and MAC address), and  will then return a nicely packaged ZIP file that is ready for extraction to the root of your SD card. Simple eh?

All that is missing from that point is a boot.elf/boot.dol file (that you will need to place in the root of your card), and you should be good to go. For your convenience we have an option to prepackage and bundle the HackMii Installer boot.elf (this is enabled by default).

So, how do I do this?

Simple…. once you’ve unzipped the file to your SD card (and inserted it) just navigate to the “messageboard” on your Wii and in the default view you should browse to “yesterday” (the place where you usually see yesterday’s messages) – sometimes this may be “today” or “two days ago” (this depends on the timezone you are in).

From this view you will be presented with a small envelope (that should obviously stand out against the rest of your plain old boring ones), click it, kick back, twiddle your thumbs (the Brits among you, go and make a cup of tea) cross your fingers and hope it worked.

DISCLAIMER: We are aware of a similar exploit by giantpune (good work!), but as of today this has not been released. In anticipation of its release we decided to reverse engineer, hack and implement something ourselves.

[UPDATED, at the bottom]

[Guest post by roto:]

Recently, news has spread of a Lego Star Wars exploit for the Wii. After last week’s Bathaxx release there wasn’t much rush to get our LSW exploit out there but it seems the cat is out of the bag. Releasing our own version now would make more sense than waiting or not releasing at all. No disrespect is meant towards the person who worked on the LSW exploit that has been making the rounds on news sites, but we figured it wouldn’t hurt to share what we’ve created.

This exploit works on the original Lego Star Wars game as well as the newer (1.01) release (NTSC and PAL) all through one masterfully crafted save.

Thanks goes out to lewurm for fine-tuning all code and testing the PAL region save and of course Team Twiizers for initial LIJ source.

[segher: And of course, thanks to roto for doing all the heavy lifting for this exploit! And to drmr for the awesome graphics.]

[UPDATE: New version, now properly supporting JPN region, with thanks to "Nekokabu" and "airline38"!]

Have a look at the source code, or download the binary.

As always, be sure to read the license before redistributing the binary: it’s GPL, you are not allowed to distribute without also giving out the source code. So please don’t.

Another year, another hack.

The Indiana Pwns hack is quite old, and it appears that people are selling that game for extortionist prices now (around EUR 100 on ebay, seriously). So, it would be good if there was some other game we could use.

lewurm has created a hack for the LEGO Batman game, thanks to the wonders of Free Software. I love it when I don’t have to do anything myself!

So head over to his page, and enjoy!

As always, be sure to read the license before redistributing the binary: it’s GPL, you are not allowed to distribute without also giving out the source code. So please don’t.

To build a decent USB 2.0 protocol analyser you don’t need that many things inside, and the designs aren’t all that much more complicated than the FPGA designs we worked with on the DSi. pytey and I have been discussing hardware USB 2.0 analysis on and off for 2+ years but we have never had the time (or funds) to create a gadget of our own. An opportunity arose when pytey showed me the absolutely fabulous Kickstarter site, where you can help fund fledgeling projects to get them off the ground.

Open-source hardware isn’t a new idea, but it’s not very easy to pull off designs of even modest complexity. Unlike open-source software (which can generally be made with free tools on any household computer, as long as you have the time to learn how to do so), hardware-hacking is … well … expensive, for lack of a better word, and slow. One attempt at making a board will generally take you from 5-500 hours of time to design it, and then a couple of weeks to have a prototyping house make you some PCBs. This will probably cost you $50-$200, and then you still have to buy the parts and assemble the board … assuming you have the right equipment to do so, this can take you another week (not including debugging!).

After you’ve done all that, if all goes well — you end up with one or two prototypes which you can then try to get working, usually involving some combination of firmware and client software on your computer. Unfortunately, you only have one or two boards, so it’s hard to do much collaboration online with people on one design.

pytey suggested that we might try to leverage Kickstarter to help us make the USB 2.0 analyzer a reality — and thus, OpenVizsla was born! This project has allowed us to collect enough funds ahead of time to have a factory make enough prototypes for all our colleagues to work on firmware, HDL and client software to make an open-source USB analyzer happen. We still have to put the work in to design the hardware, but we will have enough cash to be able to buy the parts for our boards in one chunk (achieving significant discounts with quantity), and we will be able to have enough prototypes made at once to justify a factory production run — no more hand-soldering for us! Once we’re done with this, we’ll end up with a design that people can tinker with and extend; there will be a project site that will soon host more details.

It seemed like a bit of a gamble, so we argued back and forth and picked a cash target high enough to ensure we would be able to make at least enough prototypes to have a decent chance of pulling the project off. I could never have expected the popular reaction to it; it seems like we really struck a nerve out there. We even got a couple of celebrities (Stephen Fry, DVDJon) on board, and our ploy to get some major backers (offering the right to directly participate in the early prototyping stages and a spot for a logo) paid off in spades. We even got support from Altium, who donated a couple of licenses of their lovely CAD/CAM software for us to use to speed up our design process.

Anyway, if you’re interested in the idea of playing with USB, I recommend you head over to the Kickstarter page; as of this writing, there’s still 3 days left for you to get in on the OpenVizsla production run.

On to CCC — our Console Hacking table at the Chaos Communication Congress in Berlin has become somewhat of a fixture there, so we’re trying to reserve some space this year. A few of you have already noticed that we have a “Console Hacking 2010″ wrapup presentation planned; the description’s still a bit vague because our presentation will depend on how much progress we make between now and then. There’s going to be a PS3 surprise though. No questions about the content, please — we’re still busy hacking away over here, so just come see us there or wait for the video!

We’ve always believed that the HBC is a valuable tool for development, especially with the convenience of being able to use Wiiload to load code over the network. Some of those 600K users out there have written us to say that they are Licensed Developers ™, and have reported that recent versions of the Hackmii Installer have been able to install the HBC on development hardware (NDEV, RVT-R and RVT-H) using e.g. Bannerbomb. We have taken pains to write code that can install in as many environments as possible, and to our knowledge, our code is generic enough to work on development hardware and to load binaries produced with Nintendo’s tools (on any hardware); if this isn’t the case, please file a bug (e.g. on our bug tracker).

We are once again planning to be at CCC with a table downstairs in the Hackcenter, and we hope many of you will stop by to say hello!

Well, we never found that, but occasionally some hint poke up. Nintendo has gone out of their way to call out a specific message — Insert Startup Disc — and has declared that there is a problem with the “operating system” and let it be known that they very badly want to replace it. As with things like the iOS “diagnostic mode”, this generally means that a unit escaped from the factory without having completed all testing and programming steps. This can give a rare glimpse into factory steps normally concealed from us.

Searching online for information about this has been rather frustrating. Occasional articles from late 2006 show in-store kiosks displaying a blurry “Insert startup disk” message. A few private conversations have alluded to the fact that the few thousand Wiis that were sent to game stores with this disc, but nobody has been able to cough up a disc for me to examine (or at least an image of one!).

Fortunately, an alert member of assemblergames caught an auction on eBay for a broken Wii displaying our mysterious error message. (Thanks Paul!) He bought it and sent it to me to look at, and here are my findings.

Background

Stepping back a moment, the reason that this is strange is that the very lowest levels of the system — boot1, boot2 — can’t even talk to the DVD drive or the video output. IOS can talk to the DVD drive, but only at a very low level, and only in response to IPC from the PPC — there’s no way for the system to bootstrap itself with a blank flash, or with boot1 and boot2. You absolutely need PPC code running, and if you have that running, you might as well have the whole system menu running. It also probably means you have to either have a boot2 that can read an unencrypted NAND filesystem, or it means you have to program each chip individually with a key from a database using a flash programmer before soldering it down — an expensive and complicated operation, in comparison to flashing one image to all chips or programming a unit with test pads.

The only possible reason I could imagine for doing this would be that the flashing process has a long lead time — longer than pressing DVDs — and Nintendo therefore was able to ship these kiosk Wiis earlier by including a stub of a system menu that could install updates, and then making a few thousand in this state and shipping them out with these discs. Let’s take a look at Paul’s Wii.

It was posted on eBay “as-is” with no warranty; when it showed up, it was in pretty poor physical shape — the case was scratched and scuffed, and it had “needs startup disk” (or something) written on it with a marker. This is not the launch-day Wii I expected to see, because if a Wii was in this state, there’s no way anybody could have ever used it … ever. There’s no way for a working Wii to fall into this state, so any Wii that displayed this message should look like it sat in someone’s closet and pristine! The serial number on the label was LU325049098, which was strange because the Wii drive serial number tracking sites report this as probably a D2C drive — meaning, the Wii came from some time in 2008. The battery had a date stamped on it of “05 – 08″ — probably May 2008. Again, this made no sense, but I had to open the thing up anyway to solder a modchip onto the drive so that I could burn discs in an attempt to make the thing boot.

I opened it up and removed the metal shield, and removed the drive — which ended up being a D2B drive. This still didn’t seem right — the launch day Wiis would have shipped with DMS drives — nor did it match the serial number on the outside. A couple of screws were missing inside the case. I decided to open it up all the way to see the date codes on the chips and PCB, and so that I’d be ready if I ended up needing to desolder the NAND flash chip from the bottom of the main board.

Once I finally got the main board out, it was clear that it was what I expected to see — a launch-day board. The PCB had a date-code of “3306″ below the SD card slot — this means the 33rd week of 2006, so, around August 15th. Similarly, the Hollywood & Broadway chips had date codes of “0632″ and “0631″ — all consistent with a launch-day Wii. More on this later.

I put the thing back together enough to power the thing on, and was faced with these screens — photos courtesy of Crediar, and more on that later:

Recovery

The first screen appeared a few seconds after I applied power to the unit; if you insert a disc, it would transition to the other two discs, no matter what valid discs I tried. I tried a SaveMii, but it wasn’t recognized (the red LED came on, but neither the yellow nor green LEDs followed).

At this point, crediar reminded me that there’s a suspicious bit of code in the normal Wii’s System Menu — see BS2 states 9/10 — where it checks for a disc with the special ID ‘RAAE’. If it finds it, it refuses to load the disc — but by all other indications, this would be a valid Wii disc. He suggested that this may have been the ID associated with the “Startup Disc”, and this check was placed in the final system menu to keep anyone from trying to use that disc a second time

Fortunately, back in the old days we could burn fakesigned discs, and boot them with no addition hacks (beyond a drivechip) — so I took the old Homebrew Channel Installer ISO and patched RealWnD into it, set the first 4 bytes of the image to ‘RAAE’, burned it, and tried booting it.

To my delight, the screen faded to black, and RealWnD started up. This turned to frustration when I realized that the only way to start the program dumping was to navigate its menu using a Wiimote, and I had no way of syncing a Wiimote to this Wii without a working System menu. I (too-) quickly hacked GC pad support into the RealWnD code, burned it, booted it, and then watched it crash because I forgot to call PAD_Init(). A third try ended up working, and an hour later I had a NAND dump of an almost-unmodified Wii on my SD card.

From there, it was fairly straightforward to proceed, though I probably did end up burning 10 discs trying to get the thing fully recovered to “normal” status. I burned the old “NTSC Semi-Brick Fix Disc” (with the first bytes changed to RAAE) to install system menu 3.2, then ran into problems trying to get the Hackmii Installer to work (it didn’t like the ancient versions of IOS installed on it) and I couldn’t get any games to play — even Zelda insisted on installing an update, which failed every time I tried! After using Bannerbomb to run Dop-MII to install a couple of newer versions of IOS and update boot2 (more later), I was able to install the rest of the standard channels with a normal Super Paper Mario disc, and then install BootMii as boot2 and dump the keys out so I could dump the keys to SD.

Analysis

With the keys, I could decrypt the original NAND dump I had made with RealWnD, which was the whole reason I wanted to see this Wii! Here’s what I found.

• Console ID: 0204cef9. Console IDs were issued (roughly) sequentially, beginning with 02000000 for retail Wiis — this would make this one the first 300,000 (or so) Wiis made. I suspect this may have been made towards the end of the first batch of pre-release Wiis as a spare main board and sent to a repair center to keep in stock as a replacement for any early returns.
• boot1 revision “a” — this is common for early Wiis, up to console ID 021e7bed or so
• boot2v1 — this has never been seen before, but doesn’t seem to be substantially different (in any interesting way) from the common boot2v2. All early Wii games came with boot2v2, so most people would have gotten that update with the first game they played if it wasn’t already installed at the factory. I had suspected that boot2v1 was a special factory boot2 that could handle an unencrypted NAND filesystem, but that doesn’t appear to be the case — it still may be true that there is a boot2v0 out there that serves that purpose.
• setting.txt indicates a serial number of LU100166385 (which matches neither the one printed on the case, or the revision of the drive!)
• Only five titles installed — 1-2, IOS4v3, IOS9v1, BCv0, MIOSv0. Four megabytes of content, total!
• A stub of a system menu installed as 1-2, version 1, using IOS4

The title installed as 1-2 is approximately 2 megabytes, and is the only thing I’ve ever seen that uses IOS4. Just like all 1-2 titles — including all system menus and the NDEV menu — it has a string identifying it as “NDEV BOOT PROGRAM v%X.%02X (SYSTEM MENU:”. Other strings indicate that there is some code to install updates off a disc and to boot a disc .. and that’s about it, the rest of the binary seems to be the graphics shown above. I packaged the files up and sent them off to Crediar, who was able to get it running under SNEEK and produce the screenshots featured above.

We were able to scrape unused parts of NAND and find fragments and evidence of even older content, and in some cases entire contents. IOS4v3 is 0x5f331 bytes, but there’s an IOS4v1 (with a strange cid of 35016B91) that is only 0x28e51 bytes. IOS9v1 is a healthy 0x19ed76 bytes, but there’s a bizarro IOS9v1 with the same cid (0) and version, but only 0x2a671 bytes long. The stub system menu (v1, 0×200500 bytes) shadows an older v0 that is only 0×80500 bytes long.

Conclusion

I think what happened was that a few thousand Wiis were made with this “skeleton” set of files on NAND. Of those, most were sent out to game stores for pre-launch kiosks — it’s not clear if the startup discs were sent along with the Wiis or shortly afterwards (which would explain the photos online of the kiosks showing the screen). Some were probably also set aside as replacement units in service centers, and apparently a few actually made it into the hands of customers — which is why Nintendo had to put up a web page pleading for people with those consoles to return them for a new system. Of all of these, most would have had the disc installed by the service center — and then maybe they had to return the disc? (I’m not sure why else I’d have such a hard time finding one). Of the rest, people would have sent them back to Nintendo to get working Wiis.

The only Wiis left out would be ones where the owners somehow wouldn’t (or couldn’t) send the Wii back to Nintendo for repair. This Wii that landed in my hands was assembled from spare parts — the case, main board and drive all came from different sources. I suspect that somebody “came across” a pile of main boards, and tried to assemble them all into working systems — when they were finished, they may have had 10 working Wiis and then this one, and then they probably put it in a box somewhere on a shelf and forgot about it, then sold it along with some other broken Wiis to someone else. Nobody would ever have been in a position to return this one to Nintendo, but whoever put it together must have hoped to fix it someday (which is why they didn’t just throw out the board).

More Analysis

Warning: this last part is going to be dry, technical, and isn’t finished … most people should skip it. I will update it if I ever come up with a clearer picture of the state of this system. I’m putting it here so that it has a place to live and in case anyone else can share some insights.

The big thing that’s missing is any definite answers about how this NAND came to be. The one thing I can say is that it looks like it is “fresh” enough that we can see most of the original contents of flash — many clusters have not yet been overwritten. There are a few different patterns we can see by looking at some files which appear to be created incrementally — it’s clear that clusters are allocated in scattered chunks of contiguous blocks.

testlog.txt:

• cluster 5382 — testlog.txt is created with the single line “BOARD_TEST=START,V1.0″
• cluster 7242 — testlog.txt updated with “BOARD_TEST=OK,V1.0″
• cluster 0210, 5302: testlog.txt updated with “FINAL_TEST=START,V1.0″
• cluster 01ab: testlog.txt updated with “FINAL_TEST=OK,V1.0″
• cluster 2782: testlog.txt updated with “WRITE_NAND_DATA1=START,1.1.0″
• cluster 2784: testlog.txt updated with “WRITE_NAND_DATA1=OK,1.1.0″
• cluster 027a, 5703: testlog.txt updated with “SERIAL_NO_REGISTER=OK,1.1.0″
• cluster 0602: testlog.txt updated with “WIRELESS_TEST=OK,RVL001.01″
• cluster 3c42: testlog.txt updated with “PRECHECK_DATA=START,1.2.0″
• cluster 02a2, 34c3: testlog.txt updated with “PRECHECK_DATA=OK,1.2.0″

cert.sys:

• cluster 032a: cert.sys with XS00000003 cert
• cluster 032b: cert.sys with XS00000003 and CA00000001 certs
• cluster 01e9, 0207, 0331: cert.sys with XS00000003, CA00000001 and CP00000004 certs

uid.sys:

• cluster 0328: uid.sys with one entry for 1-2
• cluster 0332: uid.sys with entries for 1-2 and 1-4
• cluster 0363: uid.sys with entries for 1-2, 1-4, 1-9
• cluster 2582: uid.sys with entries for 1-2, 1-4, 1-9, 123J
• cluster 4482: uid.sys with entries for 1-2, 1-4, 1-9, 123J, 10000-dead
• cluster 618f: uid.sys with entries for 1-2, 1-4, 1-9, 123J, 10000-dead, 1-100
• cluster 0178,6194: uid.sys with entries for 1-2, 1-4, 1-9, 123J, 10000-dead, 1-100, 1-101
• cluster 0200,4b02: uid.sys with entries for 1-2, 1-4, 1-9, 123J, 10000-dead, 1-100, 1-101, 121J
• cluster 63c3: uid.sys with entries for 1-2, 1-4, 1-9, 123J, 10000-dead, 1-100, 1-101, 121J, 122E, 0002
• cluster 0140, 0258, 02c9, 6542: uid.sys with entries for 1-2, 1-4, 1-9, 123J, 10000-dead, 1-100, 1-101, 121J, 122E, 0002, HAXX (my RealWnD disc)

I would expect the rest of flash … that which was never touched … to be all FF or 00, or something. However, it’s not. 441M of the decrypted flash is what looks like several copies of the same random garbage string — except, it’s garbage where all the bytes are 0..7F. Here’s a compressed form of all of the garbage from the flash, if anyone wants to try to figure out what it is: garbage.7z

Update:

Okay, I figured out what happened. Combining some of the information I dredged out of this flash with some of the stuff from my older factory post/research:

One of the titles listed above is “0002″ — specifically, that’s 00010000-30303032, and it’s installed into flash from a WAD, and then executed using IOS9 with the AHBPROT flag set. It reads a list of tests to perform from an SD card — all.ini, which we only had fragments of before. That file lists 8 sets of tests, and then a filename, arguments, and description for each. The DOL files listed there are read from the SD card and executed. One of the tests, NandIOS2.dol, ended up being left in NAND on the older “factory” Wii, and I scraped it out of flash 2 years back but didn’t look at it too closely. Going back to it, I see that it writes out a 25.6MB file, /tmp/nandTest.dat, with random data … which it then CRCs, reads back, and checks to make sure it was written and read correctly. Disassembling the random data function, it looks like this:

s32 seed = 1;
s16 rand(void) {
    seed *= 0x41C64E6D;
    seed += 12345;
    return (s16) seed >> 16;
}

u8 getRandomChar(void) {
   return rand() >> 8;
}

The fact that rand() returns a signed value means that when it is shifted right, the sign bit (which is always 0) will be extended, resulting a number that is always positive but within the range of a signed 8-bit integer (0 .. 127, or 0 .. 0x7F, which matches what we see). The file is 25.6MB long, which is almost identical to the compressed size of the data we saw — so that’s the sequence length (thanks segher for pointing that out!). I’m not quite sure why we see multiple copies of it — either the test gets run multiple times, or something is copying chunks of data around in flash.

Update: As promised. As of 2010-08-31 we have 266440 unique installations. System Menu 4.3 is catching up to 4.1 in the USA. 4.2 is still by far most popular.

Update 2: Comments closed for article. Too much OT/Other. For further discussion, start a thread in the forums. As of 2010-09-13 we have 339170 installations! 71% of all installs use 1.0.8.

Update 3: As of 2010-11-05 we had 593658 unique installations!

Since the release of HBC 1.0.7 (also covering 1.0.8) we have added anonymous usage statistics via your HBC’s User Agent header field. This allows us to more accurately see how many active Homebrew Channel installations exist in the wild. We would like to share these statistics with you.

To calm any potential fears from our users it’s important to note that we cannot use this information to track:

• Who you are
• What software you have installed (beyond the HBC and System Menu versions)
• Any kind of software / hardware modifications done
• … and so forth.

If you have any outstanding opinions about this, comment on this article.

During the first 24 days after the launch of the new hackmii installer we have counted 192708 unique installations! The number is probably slightly higher, as some Wiis are not configured to connect to the Internet.

Click the thumbnails below to enlarge the graphs.

Unique installations per day (in 1000s) for HBC 1.0.7 and 1.0.8:

We see a higher installation pace of HBC 1.0.8 than 1.0.7 on release.

Total installations per region:

Where you are (according to GeoIP):

Unsurprisingly, USA, France, Germany, Spain, and Great Britan dominate the list. So we have assembled another graph showing HBC installations per capita for the top 20 countries. We would like to do the same graph based on Wii sales per country, but we have not found good a good source for those statistics. If you know where to find those stats, please comment!

We find that most people still use System Menu 4.2, followed by 4.1 in all regions:

Looking at the same statistics for 1.0.8 alone we see about the same version distribution. Which means that people do not tend to upgrade to 4.3 in order to gain USB2 functionality — yet. This of course not counting users using other means of getting IOS58 such as Tantric’s IOS58 Installer.

Some other interesting statistics:

• Less than 6% of our HBC users have performed any kind of system change after installing HBC (System Menu update or Region sex change of their console).
• About 10% use System Menu 4.3 across all regions.
• We average 2.5 served requests per second from all Wiis checking for HBC updates. This means that 2.5 people boot up HBC while connected to the internet every second.
• Currently we’re serving a new unique HBC installation about every 14th second.

As the rate of new installations starts to decline I will update this post with more accurate statistics on the total size of the HBC userbase.

Finally a quick warning about the use of some region change tools: We have noticed that the use of region sex change tools on your console can in some cases set the region too literally.

We have only seen 4 valid region/area combinations set by Nintendo (even if you change your Area in System Menu Settings): EU-EUR, US-USA, JP-JAP, and KR-KOR. The first part is the actual console region, and the 2nd part is supposed to define the area you reside in. Nintendo has defined all the areas / countries, but they are apparently unused. Except when you use a region change tool.

For instance, if you’re located in Australia your region might end up as EU-AUS. We have seen some impossible regions such as US-EUR, EU-JPN, EU-USA, etc.

This is not a big issue, but you should be aware that Nintendo might detect this if you use any of their public services such as the Wii Shop Channel. We are currently unaware of any actions taken based on this.

The Wii game “Your Shape” changed this – it introduced a new IOS version: 58, and this is the first with an official USB2 module. Starting with the System Menu 4.3 update, IOS58 is available to every Wii.

Thanks to some serious work by tueidj, all homebrew applications can now utilize this USB2 module through libogc. The Homebrew Channel v1.0.8 is the first version supporting it.

IOS58 will be automatically installed when you update your Wii to System Menu 4.3. If you do not want to update, you can use Tantric’s clean IOS58 Installer.

The release notes:

HackMii Installer (v0.8):

• IOS58 is chosen for The Homebrew Channel when installed. This is required for USB2 support. Other IOS versions are of course still supported, but USB will be limited to version 1.

BootMii beta 6 (v1.3):

• Fixed the freeze when using the autoboot feature to load System Menu with a delay of zero.
• The NAND backup no longer crashes when stumbling on uncorrectable pages.
• A couple of fixes to the integrated SD browser.
• The autoboot feature is ignored when launching the IOS version of BootMii.

The Homebrew Channel (v1.0.8):

• General USB improvements for all IOS versions, this fixes the regression introduced in version 1.0.7.
• USB2 support through IOS58.

A note about unofficial IOS versions: There have been IOS hacks for USB2 support for a long time now. Those rip the USB1 module out of an IOS, and replace it with a USB2 module. You may not care about the uglyness of this approach, the code quality of the replacing modules, or the risks associated with replacing a vanilla IOS. But some coders (us included) do, and outright refuse to use it. On top of that, those nasty hacks are mostly used for warez loaders. IOS58 relieves us of that burden.

The AHBPROT feature, which we described one year ago, allows you to bypass IOS to access devices directly from the PPC, eliminating the need for any IOS patches. Starting now, we will remove all cIOS poisoned applications from the wiibrew.org wiki.

Either grab the new installer here, or use the HBC online update (a confirmation dialog should pop up when launching an older version of HBC).

As always: Please link to this post instead of mirroring the binary, thanks.

Enjoy.

While the reactions to HBC 1.0.7’s new default theme – dubbed “Dark Waters” – were generally positive, some complained about it being too dark, unfitting, or simply “exceedingly ugly.” We’re usually not the makers of elaborate plots (that you know of), but this was actually fully intentional to draw a bit of attention not only to the function but also to the looks of the Homebrew Channel.

Applying themes to the Homebrew Channel

There are two options for you to apply a theme to the Homebrew Channel.

The first way is to treat a theme file just like you would treat an application: A subfolder in the apps folder on the SD card or USB stick, only with the file theme.zip containing the theme files instead of boot.elf containing an application. The theme file will then show up in the application browser, loading it will apply it to the Homebrew Channel. This allows you to conveniently switch between themes as you can store them along each other on the media of your choice.

The second way is to simply wiiload the theme.zip to the Homebrew Channel, after which it will be immediately applied.

Once you apply a theme, it is permanently stored with the Homebrew Channel’s “savegame”.

How to revert the Homebrew Channel to the default theme

Currently, this only works by deleting the Homebrew Channel’s “savegame” via the System Menu’s data management. This, of course, also deletes the other preferences, so you will have to visit the Homebrew Channel’s options screen again. We may come up with a better way to remove a theme, but this is how it works for now.

Creating your own themes

Theming the Homebrew Channel is currently limited to skinning the user interface, i.e., replacing its graphics with same-sized ones. You can skin pretty much any graphical element of the Homebrew Channel, with the exception of the Wii remote pointer and the Homebrew Channel logo in the bottom right. (Yes, you can even insert your own bubble graphics. I propose: mice.)

Please take careful note that the graphics need to be the exact size of the ones they are replacing, there is no stretching/cropping mechanism in place. If the image dimensions mismatch, the image will be ignored and the default image will be used in its place. The same happens if you don’t include a file in the first place. This allows you to selectively skin the HBC. For example, if you only wanted to change the background image, your theme would only include the two background files.

Accompanying the image files is a small XML file named theme.xml. For now, it only includes a few color values and the name of the theme. The color values are in RGBA for the font (which is currently limited to one color GUI-wide) and the gradient to be used in the progress bar.

I believe I can leave you with the new HBC Classic theme as a template for both the sizes and the file naming. I trust you will be able to figure out the purpose of the various image files by their file name. You will notice that the Homebrew Channel’s GUI isn’t terribly complicated and re-uses many of its images in various places.

For theme publishing, I suggest you package theme files like an application. You can even include a screenshot or a cutout as icon.png and your name with the meta.xml file (note that you will still have to supply a theme.xml inside the theme.zip file).

Theme repository – or lack thereof

As with applications, we do not intend to create a repository for themes ourselves. Since Wiibrew.org has proven to be a great repository for applications, we think it is a great place to store the accompanying themes. As usual, with Wiibrew, please don’t upload copyrighted content. For themes, this means: No copyrighted imagery, neither of photographic nor illustrative nature. Also, I would think that it is rather pointless to upload background-only themes.

So, there you have it. We are very much looking forward to see how you feel the Homebrew Channel should look like.

The new Homebrew Channel themes page on Wiibrew, along with the HBC Classic theme, is here.

After more than four weeks we believe we’ve finally reached the point for the next public release of the HackMii Installer: v0.7.

A lot of changes and improvements went into this release. After quite some headaches and a few puzzles (thanks Erant!) we stockpiled over 250 commits since v0.6, increasing the compatibility with even more Wiis.

The installer now works completely differently, The Homebrew Channel got a few new features and a new look, and BootMii received a fair amount of minor improvements too.

Next to the usual minor fixes, these are the changes worth mentioning:

HackMii Installer (v0.7)

• New exploit to enable (un-) installation of all components on fully updated Wiis (up to, and including System Menu v4.3).
• Proper support for all regions, including KOR.
• General overhaul: the installer now requires BootMii/IOS to function. It will automatically be installed upon startup – either if BootMii/IOS is not installed or if it is older than the version this release comes with.
• DVDX died a horrible death. Rumor has it that someone dropped a snapple bottle on its head.
• Additional installer binary bootmini.elf, see the included README.txt for more infos.

BootMii beta 5 (v1.2):

• Compatible with more SD cards.
• New font, borrowed from the deceased Twilight Hack.
• The button combination when restoring a NAND backup with only BootMii/IOS was impossible to perform with some pads. It has been changed to the Konami Code.

The Homebrew Channel (v1.0.7):

• New title id to circumvent its deletion by System Menu v4.3.
• New look from our favorite pixel artist drmr.
• Both views now show five rows of application entries.
• On-NAND settings.
  The selected device, sort order, view and application are saved. Settings are restored when reentering HBC.
  The settings can be deleted via the System Menu’s Data Management.
• HBC now has the HW_AHBPROT flags set for direct hardware access, thus replacing DVDX.
• Ability to not reload IOS when launching an application.
  This effectively means that loaded applications inherit the title id, gaining direct hardware access via HW_AHBPROT.
  To use this feature, add  <no_ios_reload/> to the <app> node in your meta.xml file.
  wiiloaded binaries automatically gain direct hardware access.
  libogc SVN (starting with r4166) has been extended for this feature. DI_Init() will detect if an application has been launched this way, and DVD access should just work without any changes to your code.
• USB access is more stable, thanks to tueidj
• Fixed the retry mechanism for the network initialization.
• Fixed some rare hangs upon launch and exit (Hopefully all of them).
• A little surprise, to be announced soon. Refrain from bugging us about it, you’ll know soon enough

If you have installed HBC v1.0.7, it is safe to update your Wii to System Menu v4.3.

Please note that HBC’s update check now contains data in the referrer string unique to each Wii. Its sole purpose is for anonymous usage statistics.

Before asking questions, please read the included README files. You will also find information about how to report problems and encountered bugs.

Thanks to all the beta testers, it’s been a long ride.

Either grab the new installer here, or use the HBC online update (a confirmation dialog should pop up when launching an older version of HBC).

As always: Please link to this post instead of mirroring the binary, thanks.

Enjoy.