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.

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.

June 21, 2010

Wii Menu 4.3

Unauthorized Modifications

Because unauthorized channels or firmware may impair game play or the Wii console, updating to Wii Menu version 4.3 will check for and automatically remove such unauthorized files. In addition, there are some behind the scenes enhancements that do not affect any prominently-used features or menus but will improve system performance.

If you are seeing “Error:004,” please click here.

What a disappointment… this is just a rehash of, well … every update in the past 2 years, except for the 4.0 update (which actually added some features). The only thing that will drive people to install this update will be the broken Shopping channel and hypothetical future games which will come with this update on disc.

Anyway, here’s the technical changelog — much of this can be seen in the last few Wiimpersonator reports.

IOS

• Fixes in all versions — the 2 exploits we were using in the HackMii Installer, as well as the /tmp bug that has existed forever and a half and been used by everyone else to downgrade IOS. Updated existing IOSes (9, 12, 13, 14, 15, 17, 21, 22, 28, 31, 33, 34, 35, 36, 37, 38, 53, 55, 56, 57, 61)
• Added two new IOSes — IOS80 and IOS58. IOS80 continues the trend of a new IOSx0 for each system menu, and IOS70 was stubbed out. IOS58 was previously only found on one disc, and is interesting because it contains an EHCI (USB2.0)
• Added a stub IOS that will finally overwrite BootMii/IOS with a higher version number.

System Menu

• Updated to block title IDs — HAXX, JODI, DISC, DISK
• Updated to *really* block Bannerbomb – shows Error 004 now

So there’s nothing interesting at all in this update. Just the usual bugfixes. They do get credit this time to actually block exploits. The Bannerbomb block seems to be stable this time and they didn’t leave our privilege escalation exploit unfixed like in the last update.

We’re currently working on new exploits and a new release of the HackMii installer but we’ll spend some more time to obfuscate our exploits this time to make it harder for ninty to find and fix them. It might therefore take some more time until our next release.
Just don’t update – there’s nothing interesting in this update anyway.

(tl;dr version: We tried to avoid helping pirates on the Wii, we had varying degrees of success. In the end, it doesn’t really seem to have mattered and with the way that Nintendo has treated us, I don’t have a lot of interest in trying anymore.)

So, go read the root labs post before reading the rest of this one, or else it won’t make much sense.

Putting a software exploit in a modchip is difficult to do, depending on the actual nature of the exploit — on the Wii, it made sense to use a device to bypass the drive authentication because you really were attacking a specific chip on the drive; in all cases, the exploits there involve injecting commands and code into one of a couple different serial ports on the drive’s MN102 controller chip, optionally with some clock glitching.

We did what we could to limit the usefulness of the work we did on the Wii to pirates; as for “why”, I guess I’d say it was some combination of wanting to not contribute to the piracy problem that already existed a vain hope that Nintendo would see a difference between the homebrew work we did and what modchip makers were doing, and the desire to simply set a good example.

Our original release was the Twilight Hack, which was just a savegame exploit in Zelda. The Wii’s architecture is somewhat unique — leaving aside the processor in the drive, you have a PowerPC chip used to actually run the games, and an ARM core that actually implements security policy (encryption, authentication, etc). Our exploit merely let you run code on the PowerPC — this was enough to allow you to run whatever you want on the PowerPC (simple homebrew games, Linux, etc). It would have been difficult to use this to play pirated games, due to the fact that you would have had to reinitialize the ARM security context to get it to look “normal” for a retail game. We did not release the ARM exploit (strncmp bug) we had discovered at the time, but it was eventually independently rediscovered.

We eventually used that ARM exploit to develop a channel you could install without booting Zelda each time — the Homebrew Channel. For a while, we had plans of making some sort of “App Store” to go with it — much like the one present with Installer.app on the iPhone at the time — but those never made it off the ground. One thing that would go along with that would have been signature verification — one thing we could have done would have been to set up our own PKI and start signing “good” apps, but that would put us into the position of being a gatekeeper and deciding what was good and what wasn’t, and that wasn’t something I ever really wanted to be responsible for. (It was slightly amusing when, a year later, someone put up a troll blog and claimed we were going to do this.) Part of the problem there would have been deciding what we want to allow — sure, 100% homebrew games would have been pretty easy to allow and ISOloaders would have been easy to reject, but what of all of the things in between? There’s a whole gray area out there of software — emulators, WAD extraction / installation utilities, system file patchers, updaters — we have a hard enough time agreeing on what software we like, much less deciding what everyone else “should” be using. (It also goes a bit against the spirit of the whole thing.)

The strncmp() bug we used for installing our channel was eventually patched, and we eventually had to go and find new exploits to use to install our channel — this put us into the position where we would be the only ones able to install channels, and people would not be able to install pirated WiiWare content; this was just fine with us! We obfuscated our installer, partially to frustrate attempts by Nintendo to find our exploit and partially to prevent people from using our code to install arbitrary pirated content. As far as I know, only one person ever reversed it (The STM Release Exploit), and we believe Nintendo only found it using a hardware debugger. We eventually moved on to other exploits, and we continue to obfuscate them; pirates have had to make do with mix-and-match attacks by selectively upgrading their systems and some of them find different exploits to use.

Not much we do seems to really deter pirates, and Nintendo has generally moved to fix the exploits we use more quickly than anything else — trying to keep the moral high ground hasn’t really done us much good. It’s made our work harder, it’s cut down on the amount of code we might release (only to have others release their own versions…) and Nintendo never seemed to appreciate it. They’ve pretty much burned through all the good will they’ll ever get on my part, at least.

The timeline / situation was actually quite a bit more complicated:

• March: When IOS37 appeared on the Nintendo update server in March, marcan did some tests (using a menuloader) which indicated the system menu would probably choke and give a “System files are damaged. Contact technical support” message if it saw the HBC installed on a Wii — this was before we knew that the only time signatures are checked on a Wii is at install-time. I reproduced this result, and upon advice of Michael Steil, reached out to Nintendo by emailing a contact at Nintendo’s 3rd-party developer licensing group that someone with contacts in the industry gave me. I emailed them under my real name and actually sent them a copy of the HBC — we hadn’t yet released it — and asked them to test it and make sure that the system menu would simply delete it (as it does now!) instead of throwing an error and “bricking”. I didn’t feel like I had anything to hide, and wanted to extend an olive branch by approaching them as a real person, not some anonymous leet hacker. I asked them to at least reply to let me know they had received my message and so that I wouldn’t have to go “door to door” to find someone who would understand the technical issue.
• No response from Nintendo. We do some more testing and realize that we had made a mistake in the test, and there was no actual issue — I felt dumb for having even approached them, so I didn’t bother trying to find anyone else to listen to me.
• Nintendo releases a new system menu that doesn’t use IOS37; we are confused.
• As more people start reversing IOS, interest in the drive interface module (DIP) starts increasing. Nitrotux releases the first patched IOS (“IOS5″), which allows you to dump a disc from Wii mode instead of using GC mode. Somebody notices some text about a “DVD Video” mode. Attempts to enable it fail.
• As we continued reversing the IOS kernel (to map the register space of the Hollywood, etc), we found a syscall that poked a magic register, and eventually discovered that that register gated the ability to send DVD Video commands — meaning that someone just needed to patch IOS and they’d be able to send that command. We groan and brace ourselves for the impact of a dozen warezloaders.
• While looking for new vulnerabilities in TMD signature verification, we discovered that you could set a bit in the Access Rights field that would cause the DVD Video enable syscall to be invoked; this was apparently to support a DVD-player channel that never made it out the door. (There was another bit in that field which poked at another register; we’d later realize that bit was used in the factory, and would set HW_AHBPROT to disable all hardware protection.)
• June-July: We tried to decide what to do about this — Michael suggested that Nintendo probably just hadn’t received my email in March and we should try again. The DVD Video exploit seemed like the best possible choice for a bug to get their attention, since we could clearly frame it in terms of piracy and we wouldn’t be too sad if they fixed. I realized I had perhaps made a tactical error before — by putting everything we knew into one email, we had no way of knowing if anyone ever read it. If we were to just email them and ask to speak to an engineer, that way I’d be sure we found someone who would be able to understand the issue, and I would also have positive confirmation they’d gotten my message. The only place I could find to contact Nintendo was this form, which ends up asking you a lot of personal information for what they should view as a favor to them. I decided that using my real name wouldn’t do much good, because the credibility of my position (“I have something you might be interested in and I want to discuss it with an engineer”) was based on my reputation, so I submit the form as “bushing”.
• I wait a week; no response. I start looking for an actual email address, and the only thing I can find is piracyscene@noa.nintendo.com. I send them an email on July 12th saying:

Subject: Wii firmware security issue
Dear Nintendo,

As part of our efforts to understand how the Wii works, we believe we
have found a security issue that could allow pirated Wii games to be
played on an unmodified Wii console — that is to say, without
requiring any hardware modification or patches to IOS. I would like
to speak to an engineer about this; can you please point me in the
right direction?

Sincerely,
bushing

• No response to this either. I decide that maybe I need to email a specific person, so on July 15th I send an email to support@noa.com, and to Jodi Daugherty (who I had found via Google as working in their antipiracy group):

This is my second attempt to contact Nintendo about this issue; please note that I am trying to follow the guidelines for Responsible Disclosure laid forth in this document, so your timely response to my request is important. Thank you for your attention.

• No luck with that, either. Maybe email just isn’t their style. I decide that my last-ditch effort would be to post an open letter, which I did on July 17th. Shit starts raining down on me as a thousand trolls accuse me of trying to get a job from Nintendo; in reality, I was more trying to give them one last chance of actually talking with me on a mature and professional level.
• Two days later (July 19th), I get a reply to my email from Jodi saying “We have received your e-mail and will reply shortly.” A couple of things are worth nothing here:
• 1. The email was a reply to my email from July 15th, so they had received my emails, but didn’t feel like responding until I had publicly pushed them to.
  2. The email was actually addressed to me by my real name, which meant that not only had they received my emails earlier this month — they had actually received my email back in March, and it made it all the way to the desk of a VP at NOA who was now trying to intimidate me by pointing out that she knew who I was. I was not amused.
• Time passes. Someone suggests that maybe they’re taking a while trying to figure out what to make of me; nobody else seems to have understood why I was emailing them, so maybe they had the same fears. Shortly after midnight, July 24th, I wrote back with this:

I am still looking forward to hearing from you (or from one of your engineers); in the mean time, maybe I should be more explicit about my motivation in bringing this bug to your attention. I am not looking for any sort of compensation (a job, free games, etc), nor am I trying to make any sort of quid-pro-quo “deal”. I’m not even looking for any information beyond a confirmation that I have clearly explained this technical issue in a way that is useful.

We love the Wii as a platform and work hard to avoid contributing to the piracy problem, so it seems that the ethical thing to do is to inform you when we have found something that would only be harmful to our favorite console. Also, I understand that you have a finite amount of engineering resources available for security issues. I believe that if we can show you some of the bugs that we consider to be dangerous, you will agree that they would be a much better use of those resources than fixing what are essentially disposable save-game exploits.

So, at best we will be able to share some info with you that will help you prioritize your bug-fixing in a way that lessens its impact on us; at worst, we’ve merely told you about a bug that we hope to see fixed sooner rather than later, and everything else will continue as before.

• This seems to have worked. 12 hours later, I get a reply saying “We would like to call you at 11am tomorrow. What is a good number to
  reach you?“. I am not amused — someone who is a lawyer and who already seems like she is trying to intimidate me is now trying to get me on the phone so that she can avoid leaving a paper trail, and she’s trying to do it on her terms — weeks had gone by and suddently they want to talk in 24 hours? Yes, I get it, but I don’t have to like it — especially given that I was the one who approached them with info and expected nothing in return. I write back saying that I would rather not use the phone because I have other collaborators on other timezones who I would like to involve.

I never heard back from her; this wasn’t entirely surprising, since the two replies I had gotten over email were like pulling teeth. We tell ourselves “we did all we could”, and I felt like they had treated me in bad faith; a couple of days later we posted DVD Access Library (no modchip required).

Yes, yes, I know — what about the fact that she left me voicemail? About a month later, while moving between offices I decided to check my voicemail at work — something I never use, but I needed to make sure the phone had been properly moved. To my horror, I discovered that she had found a way to reach me at work and had in fact called me at 11 am that next day, using a number I didn’t give her, after I had explicitly declined a phone call. She followed up with another call a week later, but at this point it was too late for any of it to matter, and I didn’t even find out about either call for another month.

I didn’t write much about this at the time because I was pretty annoyed by how it turned out, and I knew that telling the story would open us (me?) up to criticism and second-guessing our decisions. So be it; someone else who had been in my position may have made different decisions. I did what I thought was right, and although I now understand their motivation — they just wanted me to stop calling them out publicly — I still believe they behaved inappropriately.

Head over to his site, horriblefanfare.com, to read the article.

After they received the Wii, they wrote him back and said that because he had unauthorized software installed (something they could not fix themselves — but more on this later), it would cost $200 for them to do any repair.  He had them just send him back the Wii, they would not work on it. They sent him back his Wii, and then he reinstalled BootMii/boot2 and dumped the NAND and sent it to us to figure out what he had missed and anything else we could gain from the image.

I have a few theories as to what they detected, based on what things he did not manage to delete — and for a while, that’s all we had to go on, and it wasn’t going to make for a very interesting article.  However, several hours with 0xED and grep and xxd paid off, and I found some traces of the disc they ran to detect “Illegal software”.   Unfortunately, I was only able to find part of the data section of the main DOL of the disc, and not the code, so I don’t have actual screenshots to share — you’ll have to use your imagination this time.  (If anyone has sent a Wii in to Nintendo for repair in the past few months, and received the same Wii back — no refurbs! — I’d love to see a NAND dump, especially if you took one right after you received it back.  I may be able to reconstruct the rest of the disc.)

Here is the raw output of ’strings’ on the relevant part of the data section:

*******************************************************
Check Disk for Pre-Repair Process
Disc TitleId    : 0x%08x(Hi) 0x%08x(Lo)
Num of Checking : %d
This running is "First Running".
Start Region Address : 0x%08x
End Region Address   : 0x%08x
main.cpp
*** EndSaveRegionAddr has been over rang ***
This running is "Restarted running".
Using language is Japanese.
Using language is English.
NRChecker is not inserted at SI port %d.
Waiting ejecting disk.
InitSD is failed.
Error. Line=%d
Start Checking Process.
Restart Disc...
Reset...
Shutdown...
End of Application
Unknown
Item %d : Load data from 0x%08x
Item %d : Save data to 0x%08x
Deleting the save data of SetPersonalData.wad...
Deleting the save data of DigicamPrintChannel...
/title/%08x/%08x/data/nocopy
NANDPrivateDelete : delete %s : %d
/title/%08x/%08x/data
/title/%08x/%08x/data/banner.bin
Searching unauthorized rewritten savedata...
/title/%08x/%08x/data/%s
zeldaTp.dat
/title/%08x/%08x/data
Checking %s
NANDOpen : %s(%d)
CheckSavedataZD : return false. This save data is unauthorized rewittern data.
Searching unauthorized title...
Unauthorized title num with checking ticket: %d
Unauthorized title num with checking TMD: %d
*** SearchUnauthCh_CheckTickets ***
Found ticket file num is %d
Result code of checking 0x%016llx is %d
*** SearchUnauthCh_CheckTMDs ***
Number of Home Directory is %d,
[%03d]Getting information about title id "0x%016llx"
- Title Name : %s
- TitleID    : 0x%016llx
- Type       : %d
- Visible    : %d
- Status     : %d
AnalyzeTitle : OSGetTitleStatus failed(%d).
/title/%08x/%08x/content/%08x.app
             Pre-repair Check Disk ver%s
         Pre-repair Check Disk ver%s - Detail
         Pre-repair Check Disk ver%s - Delete
     Pre-repair Check Disk ver%s - Launch Mode
     Pre-repair Check Disk ver%s - Output File
------------------------------------------
----------------------------------------------
Serial Number: %s
Waiting to Start
Processing
Complete
%d.??? >%s
%d.Altered Save Data Detection >%s
%d.Illegal Channel(s) Detection >%s
%d.Use of Copy Disk Detection >%s
Checking the following item(s)...(%d/%d)
Check is complete.
Press A Button to display detail screen.
Delete All Altered Save Data and Illegal Channel(s)/Firmware?
Detected %d pieces of data
No Data
Detected illegal channel(s) >
Press A Button to restart.
Automatic restart begins after %d seconds.
%2d/%2d      [Title ID/Name]
%s%2d  0x%016llx(%s)
    "%s"
[Type]   [Visible]   [Status]
%s %s    %s   %s
Detected %d title(s)
Press Button B to return to previous screen.
Deleting data...
Altered Save Data Deletion >%s
Illegal Channel/Firmware Deletion >%s
If you want to launch Wii illegal channel,
    Select the channel and push A button.
Launch the following title?
Title ID: 0x%016llx(%s)
Title Name: "%s"
ID: 0x%016llx(%s)
Push DOWN Button to display next page.
<>
<>
<>
<>
Serial Number
Device Id
Wii Menu
Wireless MAC
Bluetooth MAC
BT MAC
WC24 Count
WC24 Stage
WC24
Shopping
Not Used
(No File)
(Initial)
(Generated)
(Registered)
(Unknown)
 %d. %s
    (DiscNum. %d   GameVer. %d)
 %d. %s
    (DiscNum. %d  GameVer. %d)
%d. TitleName: %s
   DiscNum: %d GameVer: %d
   Error: 0x%08x(%d)
   DateTime: 0x%08x(%d)
   Status: 0x%08x(%d)
   Control: 0x%08x(%d)
   NextOffset: 0x%08x(%d)
%d. TitleName:%s
   DiscNum:%d GameVer:%d
   Error:0x%08x(%d)
   DateTime:0x%08x(%d)
   Status:0x%08x(%d)
   Control:0x%08x(%d)
   NextOffset:0x%08x(%d)
%d DVD error record(s) has been logged.
Output the DVD error logs to SD card?
Output the meta-data of illegal channel(s)?
Insert SD card.
                  [%s]           %s
(Deleted)
UNKNOWN
INSTALLED
NOEXISTS
DELETED
SAVEONLY
NORIGHTS
PARTIAL
FATAL
    File does not exist.
    File was deleted. 
    Error occurred during processing(%d:%d)
    There is no problem with this console.
    Problematic save data was detected.
    Illegal channel(s)/firmware was detected.
    Disc needs to be restarted.
    Deleted all.
    Use of copy disk was detected. 
Finished to output the file.
Controller
[Main View]
  UP: Back page
  DOWN: Next page
  A: Show the details
Controller
[Common]
  LEFT: Back
  RIGHT: Next
  B: Back to main view
[Illegal Channels Detection]
  UP/DOWN: Scroll list
  1+2(GC:X+Y): Launch channel
  A+2(GC:L+R): Delete illegal channels
[Use of Copy Disk]
  UP/DOWN: Scroll list
  1+2(GC:X+Y): Output DVD error log
[DVD Error Log]
  UP/DOWN: Scroll list
  1+2(GC:X+Y): Output DVD error log
InitChangeUid : NANDInit Error(%d)
InitChangeUid : ES_InitLib Error(%d)
InitChangeUid : ES_GetTitleId Error(%d)
Changing uid to %016llx
ChangeUid : ES_SetUid Error(%d)
ChangeUid : ISFS_CloseLib Error(%d)
ChangeUid : ISFS_OpenLib Error(%d)
/title/%08x/%08x/data
ChangeToGameSaveDir : NANDPrivateChangeDir Error(%d)

/ticket/%08x/%08x.tik
/title/%08x/%08x
/meta/%08x/%08x
Delete all files in %s.
NANDPrivateReadDir : %s(%d) num = %d
Returned DELETEFILES_ERR_OK_NOEXIST.
Returned DELETEFILES_ERR_FAILED.
memory allocate is failed.
NANDPrivateDelete : %s(%d)
Returned DELETEFILES_ERR_OK.
Running "DeleteProcess".
Start to delete unauthorized channels and save datas.
ATTENTION!! : current groupId is not 0.
ChangeUid to 0x%016llx : %d
NANDPrivateDelete : %s has been deleted.
/title/%08x/%08x/data/banner.bin
Running "LauchTitle".
Can not launch because target channel is not installed.
Can not launch because target module is not a channel application.
SaveResultFunc_SearchCopyDisc
LoadResultFunc_SearchCopyDisc
/shared2/test2/dvderror.dat
: Ver.%d(TMD)
: %02x:%02x:%02x:%02x:%02x:%02x
: %s %s %s %s
: %d %s
ES_InitLib is failed : %d
ES_GetTmdView is failed : %d
Memory Allocation is failed.
ES_GetDeviceId is failed : %d
NCDiGetWirelessMacAddress is failed : %d
/shared2/succession/shop.log
NANDPrivateGetStatus is failed : %d
/shared2/wc24/nwc24msg.cfg
NANDPrivateOpen is failed : %d
NANDRead is failed : %d
Running "FileOutput".
/shared2/test2/dvderror.dat
InitSD is failed.
%s%s/%08x
%s%s/%08x/%08x
%s%s/%08x/%08x/%s
H4A should not be cleared because of Broadway errata.
<< RVL_SDK - OS         release build: Mar  5 2009 08:59:58 (0x4199_60831) >>

We have to do some reading between the lines here, but what we have is a disc with a fairly simple text-based UI (much like the “Wii Backup Disc” we looked at a couple of years ago) — but at least this time they’ve added colors (the BL, YE, RD tags presumably change the color of text displayed on the screen). There are a few different menus / screens you can traverse through, but the long and short of it is that they are looking for:

• Save data — they are looking to delete data from “SetPersonalData.wad” (?!) and from “DigicamPrintChannel” (which you might have if you had messed around with the regions on your Wii. They then run a check for “unauthorized rewittern data”, which seems to reuse the same old CheckSavedataZD function from the System Menu, after authenticating as RZDE/J/P.
• “Illegal Channel(s)/Firmware” — as far as I can tell, this isn’t some specific check for HBC / DVDX / whatever. This is a bit more clever — they seem to be enumerating all tickets and all TMDs on the system, and looking to see if any of them are fakesigned. This will catch pretty much anything that is, as they say, “unauthorized” that you have installed.
• “Use of Copy Disc” — I think this actually refers to their own Wii Backup Disc. It’s not entirely clear to me why they care about this. This check seems to be done by looking for the existence of /shared2/succession/shop.log. (In this context, “succession” seems to refer to the transfer of some identity info from one (presumably broken) Wii to another.)

Once they’ve done this scan, they can then do several things — most common is probably to generate a log file on an SD card. They can also launch any of the “Illegal Channels” they find, and output any of the TMD info to SD. They even have the option of deleting all of this stuff — but it seems that they’ve been told not to do this (remember, they claimed they can’t, and in fact, they didn’t before our friend got his Wii back).

In this case, what did they detect, and how? It continues to surprise me that Nintendo seems to not use any sort of special “hacked IOS” to make their lives easier — sure, the “Wii Backup Disc” came with its own (infamous) IOS16, but there wasn’t really anything special about it and we were never quite clear why they bothered. The disc runs as 1-2 and judging by its error messages, as group 0 — this means they can read and write most files in the filesystem directly, but they seem to use ES calls to do most of the work.

As for what they found — this Wii was bought second-hand, and it looks like there was a lot of “crap” on it at one point. Purely by looking for fakesigned tickets and TMDs, I found one each for 1-250 (IOS250) and 1-0 (“IOS0″ — this is a bogus ticket used to gain group 0 access, Waninkoko’s old FS dumper used this and I think that AnyTitle Deleter may does as well). Something that I found that Nintendo didn’t was a bunch of crap left over from a Preloader install — extra files in 1-2’s data directory, as well as some extra files in /shared2.

I can’t really give a great justification as to why this thing was so damned interesting to me, but it seemed weird and quirky and nobody really knew much about it. I thought it might be fun to try to emulate awesome games such as “Fry Egg” on the real Wii, but didn’t really know where to begin — aside from getting my hands on one. When it finally arrived in the mail from China, I opened it up to find myself faced with a couple of epoxy blobs:


This was a bit depressing; there’s not much you can do with these, absent any sort of descriptive markings. Fortunately for us, the makers of this “console” decided to add a cartridge port and a 9-pin joystick controller, and then include a “VC-1″ cartridge full of crappy games (“Virtual Console”, I suppose). It was here that we got lucky; the cartridge contained a standard NOR flash chip, which I was able to read out with a standard chip programmer.

Browsing through the contents of the flash chip, there was no recognizable text or known instruction set — but fortunately, we found this header:
0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
*
0000c00: 6368 6b73 756d 3a32 3441 3842 4339 4220 chksum:24A8BC9B
0000c10: 7665 723a 2275 276e 5350 2049 4445 5665 ver:"u'nSP IDEVe
0000c20: 7220 312e 362e 3222 2075 7365 723a 2273 r 1.6.2" user:"s
0000c30: 756e 706c 7573 2220 626f 6479 3a22 5350 unplus" body:"SP
0000c40: 4732 3433 2200 0000 0000 0000 0000 0000 G243"...........


u’nSP? sunplus? What is this crap? Searching on Google didn’t find much (at the time — there’s a lot more now, partially by coincidence and partially as a consequence of the work we’ve done which we’ll get to shortly). We started digging, and, well, to make a long story shorter — it turns out that there is one Chinese company with several names that makes chips that you could probably find in devices you already own.

SPG

The SPG2xx series use a custom instruction set (“u’nSP”), and are designed for something like the TV Plug-n-Play games; they are used in most (if not all) of those, as well as the Vii and the V.smile (if nothing else). Segher took our dumped ROM and scant documentation and built a disassembler, and then a mostly-working emulator for this architecture (more on this below). The top of the line SPG290 uses a different “s+core” architecture, and is used in the Mattel Hyperscan.

SPMP

The SPMP series chips are ARM-based SoCs that are used in cheap Chinese “Personal Media Players” that also generally come bundled with NES or GameBoy emulators; see Marcan’s work on these.

I/O interfaces

I’ve seen a lot of use of these chips in random USB I/O applications. The external hard drive I use to back up my laptop has a SunPlus USB-SATA bridge. They make USB-to-CCD interfaces (aka webcams!).

Everything else

They make chips that go into digital picture frames and portable DVD players, too. In China, they’re used for more general control applications — they make general MCUs under the “GeneralPlus” name, and it was actually here where we found the most info. Although the datasheets for the SunPlus chips are pretty hard to find, the general-purpose chips have freely-available documentation, and many of them use the same instruction set. On the GeneralplusSunplus MCU site (this all gets very confusing), you can find datasheets for other chips that use the u’nSP instruction set, and even an IDE based on an old, hacked up, GPL-violating version of GCC that supports u’nSP!

Based on the ROMs we extracted from the Vii and some experiments, Segher was able to write a disassembler and then eventually an SPG emulator:

I can now play Vii games on my computer, woohoo! Sadly, sound and “Viimote” support have yet to be implemented. Further research showed that most (all?) of the Jakks Pacific TV Plug’n'Play games also use SPG chips, so after some hardware hacking, we were able to play a couple of them, too:

Work lately has focused mostly on the V.tech V.smile, which has the advantage of being cheaply and widely available, and it takes cartridges which are just simple ROMs (or occasionally NOR flash chips) on a PCB … with any luck, we will soon have a SPG development kit for the masses, a need that I’m sure everyone will agree went unfulfilled for quite some time.

Not everything has to be cutting-edge to be fun.

Alas, it appears that in this odd ecosystem products and sites are routinely sold and bought, and people can wind up marketing scam unknowingly. I suspect that quite a few of those people will just turn a blind eye and keep making a profit off of scams after finding out about the nature of their “product”. However, at least one of them did the Right Thing. I had an interesting e-mail exchange with someone who recently purchased a site advertising a few of those scam products off of eBay. He agreed to remove the references to the scam products and replace them with an informational page that explains how other sellers are scamming their customers. Thank you for doing the right thing .

Click here to visit the site. Yes, I know that the information presented there isn’t 100% factually accurate, but the point is that there’s at least one seller who cares about these scams. I think he deserves being commended for his honesty and integrity.