Notes from inside your Wii

HackMii header image 2

PatchMii (_core)

July 10th, 2008 by bushing · 50 Comments

Note: This is not a standalone, ready-to-use program — hence the name.  If you need to ask how to use this, you’re doing it wrong.

We’ve been pretty bad about releasing source code lately, so this is my attempt to atone.  I’ve been sitting on this code for a couple of months now — I wrote most of it a day or two after IOS37 was released — but I’ve been waiting for the mythical “right time” to release it in a useful form, and that hasn’t happened.  So, I’m releasing it as-is, because I think that many people will find this code useful in its current form, and it can be used as a building block for more sophisticated hacks.

The idea behind PatchMii is that we should be able to replace Nintendo’s update process with one of own.  The most straightforward way to do this would be to set up a “shadow” update server that would vend patched versions of Nintendo’s updates, and then patch the System Menu to talk to it instead of the official servers.  However, there are some serious copyright issues with doing this, so this is the next best thing.  This code should work with anything available on the Nintendo update server — IOS and channels (at least, the ones for which you can freely download a ticket).

In the example configuration provided, patchmii-core will do the following things:

  1. Download the ticket and TMD for IOS37 from the Nintendo Update Server
  2. Use the built-in key-management functions of IOS to decode the title key (no common key required!)
  3. Using the TMD, download all of the encrypted contents from NUS
  4. Verify the integrity of each content against the hashes contained in the TMD
  5. Decrypt each content individually, look for versioning tags inside the binaries and display them
  6. Look for the signature check, and patch it out.   (I have included code that will handle all versions of IOS.)
  7. Re-encrypt the contents.  If necessary, recompute the hashes, modify the TMD.
  8. Modify the title ID in the TMD and ticket to IOS5.
  9. Fakesign the TMD and ticket.
  10. Install this patched IOS37 as IOS5.
The output of this process looks like this:
IOS Version: 00240412
Downloading IOS37 metadata: . ..tmd. ..ticket..Title ID: 0000000100000025
Number of parts: 15.  Total size: 1868K
Downloading contents:
Downloading part 1/15 (0K): hash OK. Firmware version: firmware.64.0802290707      Builder: admin@FWPUBLISH
Downloading part 2/15 (33536K): hash OK. DIP ( 06/08/07 18:17:09 64M )
Downloading part 3/15 (26112K): hash OK. OH0 ( 07/12/07 14:30:33 64M )
Downloading part 4/15 (15104K): hash OK. OH1 ( 06/08/07 18:17:21 64M )
Downloading part 5/15 (10752K): hash OK. SDI ( 02/22/08 17:57:15 64M )
Downloading part 6/15 (171776K): hash OK. SO ( 06/28/07 02:37:15 64M Release/apricot-win/HEAD )
Downloading part 7/15 (360448K): hash OK. KD ( 08/30/07 04:58:02 64M Release/apricot-win/SDK_FW_30_4_13_branch )
Downloading part 8/15 (62720K): hash OK. WD ( 12/12/07 16:13:56 64M Release/apricot-win/SDK_FW_30_4_13_branch )
Downloading part 9/15 (447488K): hash OK. WL ( 12/12/07 16:14:06 64M Ver. )
Downloading part 10/15 (42496K): hash OK. NCD ( 06/28/07 02:37:17 64M Release/apricot-win/HEAD )
Downloading part 11/15 (30464K): hash OK. ETH ( 08/09/07 18:09:02 64M Release/apricot-win/SDK_FW_30_4_13_branch )
Downloading part 12/15 (18944K): hash OK. STM ( 06/28/07 02:37:18 64M Release/apricot-win/HEAD )
Downloading part 13/15 (9216K): hash OK. USB_HID ( 2008-01-30-15-59 64M )
Downloading part 14/15 (520960K): hash OK. SSL ( 02/27/08 19:26:09 64M Release/builder/HEAD )
Downloading part 15/15 (162048K): hash OK. FFS ( 02/22/08 17:56:15 64M )
ES ( 02/23/08 13:25:41 64M )
IOSP ( 02/23/08 13:29:22 64M )
Found new-school ES hash check @ 0x5aea, patching.
Updating TMD.
Changing titleid from 00000001-00000025 to 00000001-00000005
forging tmd sig
forging tik sig
Download complete. Installing:
Installing ticket...
Adding title...
Adding content ID 00000000 (cfd 0):   done! (0x40 bytes)
Adding content ID 00000001 (cfd 1):   done! (0x8350 bytes)
Adding content ID 00000002 (cfd 1):   done! (0x6630 bytes)
Adding content ID 00000003 (cfd 1):   done! (0x3c00 bytes)
Adding content ID 00000004 (cfd 1):   done! (0x2a30 bytes)
Adding content ID 00000005 (cfd 1):   done! (0x29f80 bytes)
Adding content ID 00000006 (cfd 1):   done! (0x58010 bytes)
Adding content ID 00000007 (cfd 1):   done! (0xf520 bytes)
Adding content ID 00000008 (cfd 1):   done! (0x6d4f0 bytes)
Adding content ID 00000009 (cfd 1):   done! (0xa650 bytes)
Adding content ID 0000000a (cfd 1):   done! (0x7780 bytes)
Adding content ID 0000000b (cfd 1):   done! (0x4aa0 bytes)
Adding content ID 0000000c (cfd 1):   done! (0x2490 bytes)
Adding content ID 0000000d (cfd 1):   done! (0x7f330 bytes)
Adding content ID 0000000e (cfd 1):   done! (0x27910 bytes)

I have gone to lengths to making this program safe. It will refuse to patch the System Menu or IOS30 (which the System Menu depends on).
So, as it stands, this program is not very useful. I’m putting it out there as an experiment. What I would like to see happen is:

  • People submit patches to PatchMii itself to make this core code more stable, fix the cosmetic bugs I already know about, and add new capability to the core patching mechanism
  • People submit patches for useful hacks to IOS
  • People come up with ideas (and code) to make this into a useful product for end-users — a custom-updater program, or whatever.  The license on this code (GPLv2) allows you to take this code and turn it into your own program under your own name, as long as you release the source code — but I would like to work with you to coordinate features and functionality.
I will be unhappy and disappointed if any of the following happens:
  • People ask me how to use this
  • People brick their systems by using this program without understanding the risks
  • People report stupid shit like cosmetic bugs, instead of submitting patches to me to fix them
  • People take this code, make a trivial change, slap their own name on it and take credit for it
So, have at it.  If this goes well, it will encourage us to more freely share source code in the future.  In any cases, individual parts of this code should be useful for anyone who wants to start experimenting with IOS.

Tags: Wii

50 responses so far ↓

  • 1 KA // Jul 10, 2008 at 4:04 pm

    oh thanks, it’s a great step for wii hacking, i hope i can soon say the wii he has 3.3e without updating, you are the best, thanks 😀

  • 2 linkinworm // Jul 10, 2008 at 4:35 pm

    once this is n00b proof we can finaly stop getting stupid kids asking dumb questions about stuff like this and there crazy ideas on “if you set your wii to connect to your pc then send the wad over you can install your own wad” but theres never really been a point befor because everyone got hyped over IOS37, its good to see how much you have done for the wii since the C23(i think it was that) convention, keep up the good work, just hope waninkoko doesnt get in on this eh? lol stealing you thunder with his piracy tools

  • 3 Zim // Jul 10, 2008 at 10:28 pm

    Great release, Bushing.

  • 4 Nuke // Jul 10, 2008 at 11:05 pm

    great work, as always

  • 5 crwys // Jul 10, 2008 at 11:34 pm

    Great release, i can’t wait to see what people will create now with this code! The homebrew kinda seemed quiet now since the “big” homebrew channel has been released. Hopefully this code will make things more interesting.

  • 6 blackprince97 // Jul 11, 2008 at 12:09 am

    Very cool. I wouldn’t be surprised if this is working in a few months. You people are so smart. There’s just something I wanted to note: so this program doesn’t actual doing anything yet? Is that what you meant when you said ‘it will refuse to patch the system menu’?

  • 7 uberushaximus // Jul 11, 2008 at 7:35 am


    Nah, it simply means that it won’t write to the Wii’s system memory at the location where 1-2 and IOS30 are, which if someone who didn’t know what they were doing, or someone who actually did accidentally wrote over, would have a very hard time recovering. It _does_ do something in that it installs IOS37 as IOS5. More info on IOS37 is here http://wiibrew.org/wiki/IOS37 .

  • 8 WhoDares // Jul 11, 2008 at 10:29 am

    @bushing: Lines 614 and 617 produce feedback errors, however they don’t break out of the code, so the installation will continue (possibly causing problems?). Was this intentional? or just something overlooked?

  • 9 BTaylor // Jul 11, 2008 at 1:14 pm

    I’m curious about something. As you’ve said the wii can swap the IOS it’s using on the fly, right? Well would it be possible for this code, in conjuction with the right app, to change the IOS then return to the system menu running the patched IOS37, letting trucha discs run again? Also, if the code works with future updates beyond IOS37, allow someone to run a game that needs an update without permanently updating their console?

  • 10 bushing // Jul 11, 2008 at 2:41 pm

    I’ve started pruning some comments; please try to stay on the subject of this code (or at within spitting distance of it).

    @WhoDares: Thanks, fixed.

    @BTaylor: Yes; Marcan has a program called “menuloader” which will let you reload the System Menu using any arbitrary version of IOS. I think that he’s been busy with some of the boot2 stuff, but feel free to bug him. 😉

    This code should work with all future updates, yes. It should work with all past, present, and future versions of IOS — it’s possible that Nintendo would change the signature check to break this program, but I doubt they would (since if we can patch IOS, they’ve already lost).

  • 11 BTaylor // Jul 11, 2008 at 3:01 pm

    @Bushing: Brilliant, I don’t want to upgrade past 3.2, but I wanna play future games. March on you crazy cats!

  • 12 Damion // Jul 11, 2008 at 3:14 pm

    How do we use the source code?

  • 13 Arm the Homeless // Jul 11, 2008 at 3:44 pm

    Did he not say in the post:
    I will be unhappy and disappointed if any of the following happens:

    * People ask me how to use this

    Short answer, you don’t.

  • 14 jepler // Jul 11, 2008 at 4:12 pm

    This looks like all kinds of awesome — I can’t wait to give it a try. Thanks so much for releasing the source to this under the GPL.

  • 15 crwys // Jul 11, 2008 at 6:15 pm

    Custom firmware being worked on thanks to this release? Read more here, very interesting.

  • 16 linkinworm // Jul 11, 2008 at 6:44 pm

    are any of team twiizer able to comment on this magical iso loading firmware? according to the person/team that made it, its just a .dol file that can access the nand and then do something with that, there was no mention of starlet at all in there, is there a possibility that this is real?

  • 17 marcan // Jul 11, 2008 at 7:03 pm

    Regarding that “custom firmware”:

    Smells like bullshit, looks like bullshit, chances are it’s bullshit.

    The fact that it’s a screenshot of the Photo Channel with a picture loaded onto it, that he shows the Disc Channel as a channel (it’s not), that he fucked up and used 1001 as a Title ID prefix instead of 10001, and that what he talks about doesn’t really make sense when you look at it closely just proves that it’s a massive fake.

  • 18 Matt // Jul 11, 2008 at 7:17 pm

    Is it possible to make the Wii load custom updates using a proxy, some software running on it, and the normal update process (on a version of IOS with the signing bug, at least)? I haven’t seen a full capture of the update process, but from the ancient info posted on mozy.org, it looks like everything is downloaded over unencrypted HTTP.

  • 19 9th Sage // Jul 11, 2008 at 7:25 pm

    I was wondering, can these hacked IOS versions (say, the IOS5 installed by the very neat hack you mentioned above, the disc dumper) be deleted, or uninstalled?

  • 20 crwys // Jul 11, 2008 at 7:34 pm

    Please ignore my comment (15) Marcan thinks that it is fake and i agree. I have a lot of respect for the people here at hackmii and i trust them. That was just something i found. Thanks for the comment Marcan.

  • 21 Matt // Jul 11, 2008 at 8:27 pm

    Regarding my previous comment: I see the files are downloadable via https as well as plain http now. I’m guessing newer system software versions use that? When did that start?
    And would it still be possible to do custom updates if someone could upload files to an Akamai secure server? Although that would be illegal, only doable by a few people (although more than just Nintendo itself), and deleted right away.

    Regarding the link to gbatemp with the IOS modified to remove the DVD unencrypted read restriction:
    Is it possible to overwrite one IOS5 with another?

    Lastly, is there a good, free disassembler that can handle IOS?

  • 22 SquidMan // Jul 11, 2008 at 11:30 pm

    Very nice bushing 😉
    Can’t wait to see what else comes from your brilliant mind!

    @Matt: Well, if you can stand reformatting every 30 days you could use a trial of IDA Pro (it’s what bushing uses, except he bought the full one)

  • 23 bushing // Jul 12, 2008 at 7:48 am

    @Matt: I specifically addressed this in the third paragraph of this post (“The most straightforward way…”). I think we can eventually do something that looks and feels like that, but doesn’t require a proxy.

    @9th Sage: Any IOS can be deleted with the right filesystem calls… but why bother?

    @Matt part 2: I’m not really sure why they allow both http and https now — they seem to be interchangeable. Yes, it’s possible to overwrite one IOS5 with another, but at some point we’re going to want to start coordinating this and merging patches…

    And unfortunately, I can’t recommend anything nearly as good as IDA Pro, which is admittedly not a cheap program.

  • 24 9th Sage // Jul 12, 2008 at 8:14 am

    @bushing: I was just wondering, in case such a thing caused an issue, but actually since it would be an IOS that doesn’t exist usually, it probably would not (and even if it did, no games would be using it anyway). 🙂 Good point.

  • 25 WhoDares // Jul 12, 2008 at 3:26 pm

    One thing I was wondering about. Rather than trying to patch an IOS to your needs. Would it be easier to write an IOS which actually loads it’s functionality from ELF’s stored on the NAND? Then you can update the elf’s to redirect the functionality either to another version of the IOS or to run custom code (ie, plugin architecture similar to Windows DLL files).

    I don’t know if I quite explained my thinking correctly, but it would mean you wouldn’t have to keep releasing full IOS’

  • 26 Kaer // Jul 12, 2008 at 4:19 pm

    “@Matt: Well, if you can stand reformatting every 30 days you could use a trial of IDA Pro (it’s what bushing uses, except he bought the full one)”

    You can always get VMWare and run the dissembler on a VM Machine and wipe the VM when the 30 days is up. Easier than starting new every time.

  • 27 bushing // Jul 13, 2008 at 6:11 am

    @WhoDares: Later versions of IOS (IOS30+) behave exactly like that — they are split into a “kernel” and 13 modules, each of which is in a separate ELF.

  • 28 WhoDares // Jul 13, 2008 at 6:47 am

    @bushing: Hmmm, I was going to ask was the output of your patcher those files, but there seems to be an extra download?

    Can you read/write the content using Homebrew on an unmodified Wii? I’ve also been wondering this about the boot2 file (Is it a file? Shows up on the device tree in WiiBrew wiki?)

  • 29 skawo96 // Jul 13, 2008 at 9:48 am

    Great Work

  • 30 ChucktheTekkie // Jul 13, 2008 at 9:39 pm

    If the purpose of this is to basically patch the signature check fix, how would you test if the patch worked

    @bushing: you said Marcan had a program called menuloader that can force the System Menu to reload with a different IOS. I assume it reloads it without actually modifying it, correct. Also the System Menu will still use IOS30 when you cycle power, correct.

    If so, where do I get this program?

    I have not updated my system to 3.3 yet, but I do have IOS37 installed and am just curious about a few things.

    I do agree that the System Menu should not be modified until an easy recovery method is established.

    Also how would affect Updates that are on Wii Game Discs. I assume if a game required an update you would first run this to update your wii, then you should be able to play the game. However if a game installed and IOS that was game specific, you would not have to worry if its patched or not, correct.

    Anyway lets keep the good work

  • 31 Link // Jul 13, 2008 at 11:49 pm

    Hm.. thinking about these new Wiis with a maybe new private key. In case their boot1 is still “bad” – would it work to get their data (common key and related) by faking an update server which would install the homebrew channel and then analyze the system using homebrew?

    Excuse me but it’s just a thought. If I am completely missing the concept, shoot me 😉 .

  • 32 Carder // Jul 14, 2008 at 5:21 am

    Would it make sense to make the actual
    patching more modular for example via an
    xml file located on a sd-card?
    So like a “search and replace” file.

    This is no feature request – it is a question if this
    is usefull because I’m not really sure about it.

  • 33 WhoDares // Jul 14, 2008 at 12:04 pm

    @Carder: Technically, yes, you could have a description file which consisted of offsets, lengths and bytes to replace with, and the patcher would seek to that point in the file and replace the bytes. CRC checks could easily be added to verify you were patching the correct file (and version).

  • 34 extreme83 // Jul 15, 2008 at 1:37 pm

    Would it be possible to patch the IOS in such a way so that it supports USB 2.0? Nintendo.com states the Wii includes 2 USB 2.0 ports. I could imagine the restriction lies in the IOS being programmed to use USB 1.1 instead of 2.0.

  • 35 bushing // Jul 15, 2008 at 2:41 pm

    @WhoDares/28: Can you please rephrase the first part of your question? Yes, this is all done on an unmodified Wii. boot2 is not a file; it’s the second-stage bootloader, which sits in NAND Flash before the start of the actual NAND Filesystem. See http://wiibrew.org/wiki/NAND_Flash_layout. The file /dev/boot2 is an interface that allows boot2 to be updated.

    @skawo96: <3

    @ ChuckTheTekkie: To test the sig-check patch, reload the patched IOS and then try to install any content with an altered (but not fakesigned) TMD or ticket.
    For menuloader: harass Marcan. 🙂
    About updating -- that's a complicated question, but let me try to answer what I think you're asking.
    There is only one possible reason you might need to update anything before playing a new game -- that game may require a new (major) version of IOS that you do not have installed. A good example is IOS36, which is required by SSBB (etc) but not available for download from the update server. (There's no need for anyone to download it, since it's not used by any downloadable channels.)

    So, to play SSBB, you must install IOS36. Installing IOS36 -- if you didn't have it before -- is, as you note, pretty harmless -- it will only affect SSBB. However, if you just run the whole update partition of a disc, for many games (at least, first-party games) the disc will also update other versions of IOS, your system menu, etc. We will soon see a major first-party game with an update partition that has "3.3", including the new IOS30. It might also include, say, an "IOS38" which the game requires to run -- and which you won't be able to download.

    I'd really like to see someone write a "WAD Manager" that actually just let you choose between WAD files on an update partition, (optionally) apply patches to them, and install them. Such a project could probably reuse parts of patchmii_core.

    @Carder: Yes, that would be a useful feature -- but also a fair bit of work. Right now, there are only 2 or 3 different patches, so it's not worth the effort. When we start getting into more -- 10, 20 patches, some of which may not be compatible with each other -- then it becomes more of an issue.

    Truth be told, a "full" PatchMii would have downloadable patch descriptions, a way for the user to select and apply specific patches, a way to see what patches have been installed, and a way to patch stuff from disc and / or SD card and / or NAND. It'd be neat if someone wrote this and gave it a nice interface.

    @WhoDares/33: I don't like the idea of CRC checks -- part of the point of this is to write patches that work on multiple versions, including future versions. (This requires some care, but is perfectly doable.)

    @extreme83: It's not quite as simple as "flipping a switch". A new driver must be written.

  • 36 WhoDares // Jul 15, 2008 at 11:46 pm

    My first question: You said there is a Kernel and 13 ELF drivers, that’s 14 files. However your PatchMii output above has downloaded 15 files. Are 14 of these 15 files the Kernel and ELFs? If so, what’s the 15th file?

    Also, I do understand boot2 is not a file. I think because I mixed two questions together, I made it unclear what I was trying to ask. So, I’ll hopefully clarify them here-

    1. Are the IOS Kernel and ELF files stored in the NAND FS? Are we able to read them easily?

    2. Can we use /dev/boot2 to read a copy of the current boot2? If not, is there any other way I can grab me a copy off my Wii?


  • 37 WhoDares // Jul 15, 2008 at 11:53 pm

    Also. on the file patching; With different versions of a file, the patching location may vary, which is why I thought use CRC to make sure you’re putting the patch in the correct place for that version of the file.

    I suppose you could always search the file looking for a specific block of code. The only reason I’m not completely for this approach though is in case there is another copy of the same code in the same file but for a different job, then if it’s patched incorrectly could cause other issues

  • 38 HCK // Jul 16, 2008 at 1:53 am


    WTF did Waninkoko do with his IOS installer, has he used your code or what?

  • 39 bushing // Jul 16, 2008 at 3:34 am

    I’m having to delete more comments that are irrelevant to PatchMii. Please try to stay on topic.

    @WhoDares: The first file is a 64-byte file that is just an identifier — PatchMii print it out when it downloads it. As in,

    Downloading part 1/15 (0K): hash OK. Firmware version: firmware.64.0802290707 Builder: admin@FWPUBLISH

    1. Yes. All IOS files are stored in NAND at /title/00000001/000000xx/content (and some files stored in /shared1). You have to have certain permissions to read them, though, and it’s usually easier just to decrypt them from a Wii Disc update partition or download them from the Nintendo update server, like PatchMii does.

    2) I don’t know; we don’t currently understand what /dev/boot2 does. It would probably be safe to try reading from it. Otherwise, do something like

    int fd = ISFS_Open("/dev/flash", ISFS_READ);
    int pageno;
    char buf[2048];
    for(pageno = 0x40; pageno < 0x8a; pageno++) {
                ISFS_Seek(fd, pageno, SEEK_SET);
                if (ISFS_Read(fd, buf, 2048) == 2048) {
                      // do your thing

    3) Please read the code for PatchMii; I'm searching for specific blocks of code. If you pick them carefully, you will not have false positives, and in any case we can check to make sure there was only one match and abort if that is not the case.

    @HCK: He should have used my code, and hopefully he will switch do to doing so in the future for anything he doesn't mind releasing under the GPL.

    Instead, you have to somehow "find" a copy of "IOS37-64-v2070.wad", copy it to SD, and then run his program. His program is 2285088 bytes long. That's an awfully large program, considering he's just slightly patching a file, which is itself only 1918336 bytes long.

    If you disassemble the installer, the source of the problem becomes apparent.

    .rodata:8003BCC0 ppf_size:       .long 2013497           # DATA XREF: ios_patch+1Co

    Why is this patch so big? (Hint: He's doing it wrong)

  • 40 WhoDares // Jul 16, 2008 at 4:28 am

    @bushing: Thanks for the info!

    I don’t remember seeing that patching table before in the code, but then I had probably just overlooked it

    Anyway, if I get chance later tonight, I’ll try to expand the code to look up patches from SD cards, then you could release new code patches without having to recompile PatchMii 🙂

  • 41 ChucktheTekkie // Jul 16, 2008 at 5:09 pm

    @bushing: Where do I go to harass Marcan?

  • 42 dude // Jul 17, 2008 at 1:21 pm

    Bushing, What do you think of Waninkoko’s attempt at a patched IOS?

  • 43 linkinworm // Jul 17, 2008 at 5:31 pm

    @ dude, im pretty sure bushing wasnt very impressed with it because of 1 copyright code 2 how big the patch was 3, how poorly it was made in the 1st place. the only real feature of it was the ability to read all of the wii disks data. am i right about this?(about bushing thinking this, i read something along these lines somewhere on here)

  • 44 ciper // Jul 19, 2008 at 12:30 am

    @bushing “I’d really like to see someone write a “WAD Manager” that actually just let you choose between WAD files on an update partition, (optionally) apply patches to them, and install them.”
    It seems the author of Wii Update Manager might be someone who would be interested in such a thing

  • 45 00Davo // Jul 20, 2008 at 2:27 am

    So, PatchMii will eventually run as a Wii Update Server, which updates the Wii with homebrew-enabling IOS? Clever. It doesn’t even require a game. Good luck!

  • 46 Xero // Jul 20, 2008 at 6:59 am

    Sorry for the doublepost, but what 00Davo said is indeed interesting. Maybe a DNS redirect from the real N update server to PatchMii? I’m probably wrong, but thats what it sounds like.

  • 47 bushing // Jul 20, 2008 at 9:44 pm

    @dude: Waninkoko’s release is more or less equivalent to PatchMii (using the same patches, no less — unless anyone else can give me a good reason to use IOS37 as opposed to anything else). The first release of cIOS was completely bungled, in terms of being legit. The second one was better, but still kinda sketchy because it requires you “find” some specific WAD file for it to patch, instead of downloading it from Nintendo like PatchMii does.

    The more frustrating part is the amount of attention cIOS has received. It does two things, both of which are fundamentally boring:
    1) Remove the signature check in IOS37. (This check is never used, anyway… the only reason that patch exists was that it was my Proof Of Concept for PatchMii, but note that I’m not going around telling people to actually use it!)
    2) Remove the limitation on unencrypted reads from Wii discs (or anything that the Wii thinks is a Wii disc).

    Then, he made this release, using the ‘c’ word. Somehow, this became
    1) Remove all signature checks on the Wiis
    2) Remove the limitation on unencrypted reads from DVDs/DVD-Rs, even on unmodded systems.

    I’m still not sure how that happened, because I never saw him say that. But that’s what the media reported.

    @00Davo, Xero: PLEASE READ ABOVE.

    The most straightforward way to do this would be to set up a “shadow” update server that would vend patched versions of Nintendo’s updates, and then patch the System Menu to talk to it instead of the official servers. However, there are some serious copyright issues with doing this, so this is the next best thing.

  • 48 Naamah31 // Jul 24, 2008 at 12:39 am

    @ciper : soyyr to annouce that my WUM is pretty primitive compare to new Wii stuff about IOS…
    BTW, I would like to spend some times on it, but I have no time now (have to get maried in a country 10000km far from mine…).
    But I think a good start point for your idea is the WUFE of Nuke… it’s functions should be integrated to Patchmii for people like me with a very very poor internet connection (in CHINA it is very filtered…)

  • 49 bAiLLi // Jul 26, 2008 at 5:45 pm

    Did I misunderstand the source or does the patched IOS get installed as v254 instead of v5 as mentioned in the post?

  • 50 bushing // Jul 26, 2008 at 7:21 pm

    At some point I switched it from v5 to v254, but it doesn’t really matter. It’s arbitrary.

You must log in to post a comment.