LU64+ Anti-Downgrading theory

Discussion in 'Wii - Hacking' started by damysteryman, Jun 25, 2009.

Jun 25, 2009
  1. damysteryman
    OP

    Member damysteryman I am too busy IRL these days...

    Joined:
    Oct 4, 2007
    Messages:
    1,182
    Country:
    Antarctica
    I think I have figured out why LU64+ Wiis die when downgrading their firmware.

    I found it while looking at waninkoko's cIOS249 versions 10 and 13b, as I was trying to make my own cIOSCORP (but that's another story). As I was doing this, I found 2 bytes in the ticket that I thought were unused. These 2 bytes are located at offset 0x01E6 in a wad's ticket. In cIOS249 rev10 (Based on IOS36-v1042), these 2 bytes had the value 0x0000, but in cIOS249 rev13b (Based on IOS38-v3610, the latest one), the value of these 2 bytes was 0x0E1A. Convert this to decimal and you get... 3610! Despite cIOS249 rev13b's tmd version number (which lives at offset 0x01DC within the tmd) saying 0x000D (13 dec), this new version number found in the ticket says version 3610, which is the very version of IOS38 that cIOS249 rev13b was based on! So after seeing this, I looked at the tickets of System Menu Titles to find out their "secret" version numbers, and I found this:

    System Menu v418 (4.0E) ticket:
    Warning: Spoilers inside!

    0x01E6 = 0x01A2. Convert to decimal = 418!

    System Menu v386 (3.4E) ticket:
    Warning: Spoilers inside!

    0x01E6 = 0x0182. Convert to decimal = 386!

    It looks like this "secret" version number has been present in every System memu and IOS

    version released from System Menu version 3.3 onwards...

    System Menu v354 (3.3E) ticket:
    Warning: Spoilers inside!

    0x01E6 = 0x0162. Convert to decimal = 354!

    ...but not present in any wad released earlier than System Menu 3.3! Look:

    System Menu v290 (3.2E) ticket:
    Warning: Spoilers inside!

    0x01E6 = 0x0000! Zero!

    So, my theory is...
    That LU64+ Wiis check this "secret" version number on certain installed titles, and if the check fails (i.e. "secret" version number = 0, or (maybe, not sure yet) "secret" version number < what it is overriding), it will refuse to boot that title NO MATTER WHAT. Now some of you may be wondering why all the "secret" version numbers in the above examples are equal to their actual version numbers, except for cIOS249 rev13b, which has 3610 instead of 13 (or 0). Well, I guess that the value of the "secret" version number doesn't have to be exact, but rather something as high as, or higher than, the latest version of that title currently available.

    But not all types of titles are checked. Here is what is checked and what is not:

    00000001 - System Titles (IOS) - CHECKED, to avoid modification or downgrading (e.g. System Menu 3.2 etc.)
    00010000 - Disc Titles - unchecked, as tickets are not installed on Wii, and probably to retain compatibility with older titles.
    00010001 - Wii Game Channels - unchecked, to retain compatibility with older titles.
    00010002 - Wii System Channels - CHECKED, to avoid modification or downgrading (e.g. Photo Channel 1.0 etc.)
    00010004 - Wii Game Channels that are linked to Disc Titles - unchecked, to retain compatibility with older titles.
    00010005 - Downloadable Content (DLC) - unchecked, these 2 bytes in the DLC's ticket seem to serve a different purpose in these titles, probably to point to the channel that uses them. Also unchecked to retain compatibility with older titles.
    00010008 - Hidden System Channels - CHECKED, to avoid modification or custom channels (e.g. DVDX etc.)

    So...
    Titles with a TitleID of:
    00000001xxxxxxxx
    00010002xxxxxxxx
    00010008xxxxxxxx
    are checked.

    Even look at DVDX's latest ticket:
    Warning: Spoilers inside!

    0x01E6 = 0x0002 = 2 decimal. That wasn't there last time. Looks like Team Twiizers just copied the "secret" version number from the hidden eula and rgnsel channels (They're currently both version 2). Look at the Title Key Team Twiizers left us. "One Damn Stupid byte". This must be referring to the 0x02 at offset 0x01E7, which is part of the 2 byte "secret" version number found at offset 0x01E6.

    Long story short:
    LU64+ Wiis check for a 2 byte "secret" version number found at offset 0x01E6 within tickets of system titles. If this number = 0, then that particular title will refuse to boot. (I'm not sure what would happen if this "secret" version number is greater than 0 but lower than the latest available version, though.) So, to make it LU64+ compatible, change this "secret" version number (which is most likely 0) to a really, really high number, pack the wad, and install it and see if it works.

    Now this is only a theory, and still needs more testing. But I can't fully test it as my Wii is not LU64+. I have made a basic proof-of-concept test for anyone who has an LU64+ Wii and is willing to take the extremely huge brick risk.

    WARNING! THIS TEST HAS A HUGE BRICK RISK! I WILL NOT BE HELD RESPONSIBLE FOR ANY WIIS THAT ARE BRICKED FROM PERFORMING THIS TEST. IF YOU PERFORM THIS TEST AND YOUR WII BECOMES BRICKED, IT IS YOUR OWN FAULT FOR NOT HEEDING THIS WARNING! IF YOU DO NOT UNDERSTAND THE TEST BELOW, THEN DO NOT PERFORM IT!

    Experimental LU64+ Downgrade Theory POC Test:
    Items Needed:
    An LU64+ Wii (That either has Bootmii installed as boot2 (if possible) with a NAND backup, and/or the willingness to take the extremely huge brick risk)
    Ability to boot homebrew
    Ability to install Trucha signed wads on your LU64+ Wii
    Ability to run Trucha signed discs on your LU64+ Wii (e.g. Gecko OS)
    An old version of IOS9 (Get it off the Zelda:TP Update partition, or Google)
    A modchip
    An ISO of Zelda:TP
    Ability to burn ISOs to DVDs
    A Hex Editor
    Wad unpacking and packing utilities
    Some way of patching which IOS Zelda:TP runs under (e.g. changing partition.bin etc.)

    Steps:
    Step 1: Acquire a copy of an old version of IOS9 and unpack it.
    Step 2: Open IOS9's tmd (the 0000000100000009.tmd file) in a hex editor
    Step 3: At offset 0x0193, replace the value 0x09 with the value 0x7B (which is 123 decimal). Save.
    Step 4: Open IOS9's ticket (the 0000000100000009.tik file) in a hex editor
    Step 5: At offset 0x01E3, replace the value 0x09 with the value 0x7B (which is 123 decimal). This will make it install as IOS123 so it doesn't override anything. Save.
    Step 6: Change the "secret" version number at offset 0x01E6 from value 0x0000 to the value 0x9999 (39321 decimal). Save.
    Step 7: Repack the newly made IOS123 (remember to trucha sign the ticket and tmd)
    Step 8: Install this wad (using something like Wad Manager 1.4 running under IOS249)
    Step 9: Patch your Zelda:TP ISO to run under IOS123 and burn it to disc
    Step 10: Run your IOS123-patched Zelda:TP disc

    Hopefully this should have Zelda:TP running under an old, downgraded IOS9 (installed as IOS123) on an LU64+ Wii.
    And if this theory works, then we should be able to downgrade on LU64+ Wiis!

    If you do perform this test, could you please post your results/observations in this thread, so we can determine if this theory becomes fact or not.
     
  2. kavid

    Member kavid GBAtemp Advanced Fan

    Joined:
    Sep 28, 2008
    Messages:
    519
    Country:
    China
    Do anybody try it.
     
  3. techboy

    Member techboy GBAtemp Advanced Maniac

    Joined:
    Mar 15, 2009
    Messages:
    1,720
    Location:
    Pennsylvania
    Country:
    United States
    Hm, interesting theory...Don't got an LU64, so can help you out.

    Also, why do you say there's a brick risk for your test? As long as you do not overwrite good IOSes, there is virtually no brick risk at all. Installing a modified IOS9 as IOS123 will not brick the wii. Worst that happens is the patched Zelda doesn't boot, and the DVD you burnt is now a coaster...
     
  4. SoraK05

    Member SoraK05 GBAtemp Regular

    Joined:
    Aug 24, 2007
    Messages:
    148
    Country:
    Kenya
  5. damysteryman
    OP

    Member damysteryman I am too busy IRL these days...

    Joined:
    Oct 4, 2007
    Messages:
    1,182
    Country:
    Antarctica
    I just put that warning in for disclaimer reasons. Say if somebody didnt have a modchip and derived their own test based on this information, and decided to modify important IOS and System Menu instead of the safer POC test that I posted, and bricked, it's their own fault.

    But you're right techboy. That POC test I posted should be brick free. (Hopefully it works too.)

    Oh and thanks for linking to that other post you made, SoraK05. I was also thinking hardware (or similar) differences when I was working this out.

    Well hopefully this is it.

    And a little off topic but...
    I have made a cIOSCORP using the latest (or close to it) versions of IOS currently available (for my own personal use). I used the 00000001.app file out of waninkoko's cIOS249 rev13b and this info I figured out to make it. I've tested this cIOSCORP on my Wii and it works fine, except for a few games, which give #001 error, of all errors. (I have no clue why they give #001 error). It just needs testing on an LU64+ Wii now, but with it being copyrighted WADs and whatnot, I can't post it...
     
  6. WiiPower

    Member WiiPower GBAtemp Guru

    Joined:
    Oct 17, 2008
    Messages:
    8,165
    Country:
    Germany
    A POC should much more safe to implement. I'm thinking of just installing an IOS35v1040 with the "secret" revision number of the latest IOS35. Maybe with both revision numbers at the latest revision. If you can use WAD Manager with this IOS35 to install channels on a boot2v4 Wii, your theory was proven.

    Oh, about boo2v4, bushing told at #wiidev that he thinks that's the reason why some IOS can't be launched. Boot2 is involved in starting IOS, and he never heard of anybody having v3 and the problems, or having v4 and not having the problems.

    I would try the 00000001.app files from the different cIOS, it might be that Waninkoko moved the 001 patch into another module or whatever. The 000000001.app from rev7 should be fine for all single layer discs and have the same compatiblity as cioscorp v1 then.(well in theory)
     
  7. joda

    Member joda GBAtemp Fan

    Joined:
    Jul 12, 2007
    Messages:
    436
    Location:
    UmeƄ
    Country:
    Sweden
    Release a script that does all the repacking with for example wwunpacker, and sha1-sums of all wads you've used. Even better if the script checked the sha1-sums as well. The patching could be done automatically since the address is always the same.

    This way, people could try it out, and you could distribute it.

    But on they other hand, since people in general seem to be able to manage to fuck up how ever idiot proof you make anything, you'd probably have a whole lot of "You (yes YOU) bricked my Wii; you SUCK!"-posts in just a few days. It's all up to you.

    Looks promising though ...
     
  8. mtb-bfh

    Newcomer mtb-bfh Advanced Member

    Joined:
    Apr 8, 2009
    Messages:
    97
    Country:
    United States
    Exactly...why would anybody in their right mind if want to downgrade the entire firmware itself, or futz with IOS9? As far as I know, all anybody with an LU64 wants is a working preloader.

    I don't have the time to try this with IOS35 right this moment (just got a new puppy today, and she's running me ragged) but if somebody else has a moment and wants to pack up a WAD for me, I'd be happy to guinea-pig it.
     
  9. svpe

    Newcomer svpe Member

    Joined:
    Mar 15, 2007
    Messages:
    44
    Country:
    Germany
    I'm sorry to spoil your 'great' theory, but this "OneDamnStupidByte" title key was used since the very first DVDX version because one little bit in the TMD is enough to enabled DVD Video mode.
     
  10. Det1re

    Member Det1re det1re.de

    Joined:
    Oct 28, 2008
    Messages:
    1,272
    Location:
    Germany
    Country:
    Germany
    This is simply the version number of IOS38, on which it's based on [IOS38-64-v3610.wad].
     
  11. Scarfish

    Member Scarfish GBAtemp Regular

    Joined:
    Jan 5, 2009
    Messages:
    101
    Country:
    Netherlands
    I can confirm that this isnt working:
    * Only changed the sort of secret version number and repacked the stuff
    * Tested on my Wii with Preloader if it would brick my console, it wouldnt
    * On the LU64 Wii I first ran IOS 35 downgrader which sets the version to 0
    * Used the cboot2 method to run Wad Manager
    * Installed the IOS35 v1040 with the secret version number fixed
    * Started Wad Manager and told it to load from IOS35 --> it hangs
     
  12. chunan

    Newcomer chunan Member

    Joined:
    May 17, 2009
    Messages:
    37
    Country:
    Taiwan
    interested, i would test it on my LU64+ and will update here then
     
  13. fogbank

    Member fogbank GBAtemp Fan

    Joined:
    Oct 28, 2008
    Messages:
    413
    Country:
    United States
    Just a comment on your proposed "test":

    It is my understanding that the rule "LU64+ Wiis cannot run older IOS versions" only applies to the later modular IOS versions, not the monolithic versions like IOS9. This is presumably why IOS16 runs correctly on them.

    For a proper test you would need to use a different (higher number) IOS version.
    I think IOS35 has already been mentioned in this thread.

    EDIT: spelling
     

Share This Page