The procedure for obtaining the new DSiWareHax and the updated Sudokuhax is identical to the original Sudokuhax, as described in the Sudokuhax post and the client software README. The client software was updated as well, updating to this version is required since the server doesn’t support client sw v1.0 anymore.

Hence the title and the 1.4.2 post, this is the last new DSiWareHax that will ever be released, since there’s no way to copy DSiWare exploits to DSi “internal memory” on 1.4.2+ without your system certs.

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.

DSi system update 1.4.2 blocks copying all current and future DSiWare exploits to “internal memory”. Most of you won’t have the final DSiWareHax target, but don’t update for now anyway. Only people who already have the target game, and stay on system version 1.4.1(or below) until exploit release could copy the exploit to “internal memory”. DSiWare savedata exploits are dead with system update 1.4.2, after the release of this exploit later, there will be no more DSiWare savedata exploits.

The EC certificate APCert in the DSiWare on SD card signs the hashes stored in the DSiWare on SD card, this includes hashes of savedata among other things. This APCert is signed by the console-unique TWCert, this cert is signed by Nintendo. This TWCert is stored in NAND.

The initial system settings title verified the APCert with the TWCert contained in the DSiWare stored on SD card. This allowed us to modify DSiWare savedata, since we could resign the APCert with any TWCert from other systems. The new 1.4.2 system settings title verifies the APCert with TWCert stored in NAND. This stops us from modifying DSiWare savedata for arbitrary systems, as the only way to get those system certs is from NAND. When you don’t already have DSiWareHax, it’s impossible to obtain your system certs without soldering NAND. The new system settings will not allow any DSiWare on SD card signed by other systems to copy to “internal memory”.

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

Update: 02/02/2011 USA Sudoku was removed from NUS, EUR Sudoku is still available on NUS but both aren’t available from any of the DSi Shop regions. None of the Sudoku regions were updated on NUS yet. And at this time when trying access the Sudoku page from DSi Shop “Account activity”, it displays an error saying this software was removed due to certain circumstances.

Update: 03/24/2011 USA Sudoku was updated and is now available on DSi shop again. EUR/AU Sudoku was not yet updated. On roughly 03/30/11, EUR/AU Sudoku was updated and is now available on DSi Shop. This update fixes all the Sudoku string bugs, and the game will check for Sudokuhax and delete it when detected. Sudokuhax is dead for this updated Sudoku version.

As you may remember we started looking at the DSi about two years ago. Despite some early attempts using savegame hacks for hybrid card games we eventually resorted to more complex attacks that involved soldering many wires to tiny points on the PCB to be able to trace and modify the RAM. However, doing this is not feasible for the average homebrew user so we used the knowledge we gained through these complicated attacks to get more information about the whole system which allowed us to experiment with DSiWare games in the end. We also learned how to create savegames so we can now do what we did three years ago with the Wii: Savegame hacks!

In early December we managed to get DSi mode code execution by exploiting the DSiWare application ‘Sudoku’ by EA. Sudoku is only available for regions USA and EUR/AU. Exploiting DSiWare is interesting because in DSi mode the DSi SD card slot is accessible, the whole 16MB RAM is available, and the CPU is clocked 2x higher than DS-mode. The max size of the embedded code that can be loaded directly via this exploit is limited so a small payload was needed to chain load to another application. Initially a wifi loader was used, but this was switched to load from the DSi SD card slot. The SD card loader boots /boot.nds from the SD card directly from Sudokuhax.

DSiWare exploits can’t access gamecard slot1, it’s likely that only launcher/sysmenu can access slot1. The main advantage of DSiWare exploits over hybrid card EEPROM savedata exploits is SD card access, *and* the exploit supports SDHC.

Usage of the exploit is described below:

1. Export Sudoku to SD card via the data management menu.
2. Sudokuhax will then be injected into the Sudoku application via client software. The client software uploads DSi-specific data from the Sudoku application to a web server, then injects the retrieved data into the Sudoku application.
3. Copy the output binary to SD card with the same filename as the original.
4. Copy Sudokuhax from SD card to “internal memory” via the data management menu.
5. Launch Sudoku, then press button A or touch screen at the Sudoku title screen.
6. Now boot.nds on SD card will be run.

The data uploaded by the client software includes the anonymous DSi-unique console ID, and other data required for modifying the Sudoku binary on SD card. This data is used for logging unique web server requests.

The client software is available here. The tracker for the client software and Sudokuhax is available here. Client software source code licensed under GNU GPLv2 is available here.

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.