Toggle sidebar

Hacking IOS Version patched 002 games(hopefully soon)

  • Thread starter Thread starter WiiPower
  • Start date Start date
  • Views Views 9,666
  • Replies Replies 37
W

WiiPower

Well-Known Member
Member
Level 3
Joined
Oct 17, 2008
Messages
8,165
Reaction score
75
Trophies
1
XP
355
Country
Gambia, The
Note: This is only relevant to disc loading, on usb loading you have additional problems! The point of all this is to get these games to work from disc without overwriting regular IOS.

With NeoGamma R8 beta 17/RC1 i did my best to fix 002 error even if the game was IOS version patched and there's an IOS Reload. As you still get 002 error on starting one of the Metroid games with an IOS Version patched Metroid Prime Triology disc, i think we reached the point where it is safe to say there there isn't an easy solution for this from the loader side.

Let's gather the info we have about this problem:
- The 002 error is a check if the IOS version stored at 0x80003140 is higher than the IOS version at 0x80003188. The value 0x80003140 is written by the IOS reload and the value at 0x80003188 is written by the apploader.
- If an IOS Reload is done, the value at 0x80003140 is updated with the version & revision of the loaded IOS
- The value at 0x80003188 has no connection to the IOS to use value inside the tmd. The value inside the tmd is the one that is used by the disc channel and patched with the IOS Version patcher. This explains the 002 errors on IOS Version patched discs on disc channel.

NeoGamma now writes this to fix 002 error if the value at 0x80003188 and inside the tmd do not match:
*(u8 *)0x80003141 = ios;
*(u8 *)0x80003189 = ios;
*(u16 *)0x80003142 = 0xffff;
*(u16 *)0x8000318A = 0x0001;
ios == ios requested inside the tmd. Basically it says that the IOS to expect is the IOS that is specified in the tmd with revision 1. When the IOS Reload happens, exactly that IOS is loaded and it should be safe to assume it's revision is >= 1.

But we still get 002 error, this leads to one of the following conclusions:
- The memory at 0x80003140 gets overwritten with other info as expected(very unlikely)
- The memory at 0x80003188 gets overwritten with the "correct" info(very likely and bad)
- The 002 error works differently as expected(hopefully not)



Long story short:
Somewhere on the disc there's the info stored which IOS to expect and we need to patch that along with the tmd. It's IOS Version and IOS Revision, it should look like this(in theory as that's what gets written to 0x8003188):
0x004D1E61 for IOS77 revision 7777
If we patch that to 0x00F90001, the disc patched to use IOS249 shouldn't throw any 002 errors anymore.
 
I want to know what this means too. Have you opened the disk up in a hex editor and tried it? Are we supposed to try it? Or is there something that makes this harder than it sounds.
 
Sorry if I'm wrong, but I would like to understand :
shouldn't it be :

if the value at 0x80003188 and inside the tmd do not match:
*(u8 *)0x80003188 = ios;
*(u16 *)0x80003189 = 0x0001;

to overwrite the 88 with the tmd's IOS, and 89 with the version ?
why 89 and 8A, if 88 doesn't match ?
wasn't 88 which is expected to have the IOS version?
same for 40/41/42 ?
 
alexcalibur said:
I want to know what this means too. Have you opened the disk up in a hex editor and tried it? Are we supposed to try it? Or is there something that makes this harder than it sounds.

We just need to find the place where the apploader takes the info which IOS is requested.

QUOTE(Cyan @ Jan 17 2010, 11:25 PM) Sorry if I'm wrong, but I would like to understand :
shouldn't it be :

if the value at 0x80003188 and inside the tmd do not match:
*(u8 *)0x80003188 = ios;
*(u16 *)0x80003189 = 0x0001;

to overwrite the 88 with the tmd's IOS, and 89 with the version ?
why 89 and 8A, if 88 doesn't match ?
wasn't 88 which is expected to have the IOS version?
same for 40/41/42 ?
Click to expand...

Nope. It's 4 bytes, 2 bytes IOS version, 2 bytes IOS revision.
 
longtom1 said:
Can you not just contact the people who made GWP for the first round of #001 and #002 protection
Click to expand...

Sorry you don't understand anything. 1. 001 and 002 error are not connected to each other. 2. I have the code to patch the (old) 001 and 002 error out of games.
I want a solution that fixes 002 error on any possible upcoming (IOS Reloading) game without the need to mess with the real IOS. I don't like patching .isos to get them to work, but i like messing with real IOS less.
 
i don't have any of these games on dvd so i cant try for myself. but what happens if you set a breakpoint in WiiRD at the memory addresses? will it not pause the game and tell you what was trying to write to that address?

or can you just make a WiiRD code that keeps writing the expected IOS version to that address?
something like this
04003188 00F90001
 
giantpune said:
i don't have any of these games on dvd so i cant try for myself. but what happens if you set a breakpoint in WiiRD at the memory addresses? will it not pause the game and tell you what was trying to write to that address?

or can you just make a WiiRD code that keeps writing the expected IOS version to that address?
something like this
04003188 00F90001
Click to expand...

Hmm, i think now i have something to try. And the info should be on every disc, as even Wii Sports knows which IOS to expect. And i guess every IOS Reloading game will write at that memory address, just the 002 games check for it.
 
WiiPower said:
i think we reached the point where it is safe to say there there isn't an easy solution for this from the loader side.
Click to expand...

What would be nice is a patch in CIOS for reload, which actually loads the requested IOS except the DIP loader and whatever is needed for loading.
That way you would only need one & not merged with 37/38/60 etc.

It's probably less effort than has been expended trying to do it from the loader, although it's probably harder work.
 
that really wont work out too well. you can only have 1 IOS running. if the cIOS loads say IOS37 because a games wants it, then the cIOS cannot be running anymore to work whatever magic you want it to work with the dip. you would need a app running on the PPC to do that, not the ARM.
 
Easy peasy:

appldrios.jpg


Whatever sort of patching you do, the value at 0x80003140 should always be the "true" IOS version currently running - the IOS can get very confused if it isn't.
 
giantpune said:
that really wont work out too well. you can only have 1 IOS running. if the cIOS loads say IOS37 because a games wants it, then the cIOS cannot be running anymore to work whatever magic you want it to work with the dip. you would need a app running on the PPC to do that, not the ARM.
Click to expand...

You won't have more than 1 running, the ARM has access to the modules for each IOS. It can load up the relevant ones and then patch the DIP & IOS reload patch in.
The next time an IOS is loaded, then it will do the same thing again & again.

The PPC doesn't have to know anything has changed. It would give you free rebooter support, for games that need to be run from the disc channel.
 
When you do a reload, the old IOS isn't responsible for loading the modules of the new IOS. It only loads the new main module (kernel+es+ffs) and boots into it.
 
tueidj said:
When you do a reload, the old IOS isn't responsible for loading the modules of the new IOS. It only loads the new main module (kernel+es+ffs) and boots into it.
Click to expand...

Thats why you'd patch ios_reload to first load the new kernel and then patch it with the ios_reload patch, inject the DIP etc.
 
Smf: did you actually do something like this or are you just saying how you want it to be without even knowing how it works?
 
mousex said:
Smf: did you actually do something like this or are you just saying how you want it to be without even knowing how it works?
Click to expand...

So you don't think it's possible?
 
patch the check bytes to be the same as the ios you want to use , then it can compare all it want's as it will allways return true. to get the check routine breakpoint memory where it stores the ios pointer then run the game.
 
Can we get back to the topic? Whithout people being capable of changing the IOS code to survive IOS reloads, the discussion is next to pointless. At least i don't want it in *this* thread.

If we were able to patch games to really use another IOS slot, that might help with that what we all really want. And finding this only requires some wii knowledge, wii scrubber, time and a hexeditor.
 

Site & Scene News

Go to forum More news

Popular threads in this forum

Hacking Homebrew Homebrew app  USB Loader GX loading channels slow and not showing all covers (Some other issues I will touch on aswell)

Homebrew  Half-Life (Xash3D FWGS) - Wii port

Hacking Project  Documenting an Obscure Japanese Wii Game – And-Kensaku

softmodded wii unable to play modded games

Usb loader gx freezes when HDD is plugged on USB

Sonic 3 A.I.R. on Wii???

Hacking  Trying to revive an old bricked Wii | Any help appreciated!

Hacking  USB LoaderGX Autoboot?