Modify and Re-sign Wii isos

[Kasoz]

hi all

to those of you who have worked on smg

back when smg came out i decided to sidestep the whole issue of failing wiikeys and 1.9g and miss out on the game
so far my wii firmware has only updated to 2.1E (i have cut legs wii and have never updated wiikey firmware although only installed 6 months ago so could be anything up to 1.6b)

so now i've followed the tutorials and altered my iso and signed it
the disc produced still wants to update my firmware

my question is it 100% 1.9g that risked messing up your wiikey
or is 3.1E risky too

and does brickblocking the trucha signed iso undo trucha's work

any help would be great

thanks

just update the damn thing. My wii is running perfectly normal with wiikey 1.9g and firmware 3.2E. Just make sure you update your wii with the same region firmware and your 100% risk free

 

[bailli]

@professa
Brickblocking the disc would undo the patched __update.inf (the game would just be like a directly brickblocked game).
It is quite correct that the game still wants to update because we want it to udpate the IOS updates. Otherwise the game will not work.
On the other hand I would not try the patched update.inf on a console that isn't at least updated to v3.1.

@everybody working on NMH

I tried to disassemble the main.dol from SSBB and NMH.
(I used IDA Pro Advanced - has anybody some suggestions how to configure IDA to better handle the .dols? It doesn't find a starting point
to disassemble so you have to jump somewhere in the code and just go from there...)
Changing 0x0C to 0x04 will propably never for work for the region check. The 001-fix changes a jump address and skips that way one line of code.
It is a better idea (although still a bad idea if you do it "blind") to change 0x40 to 0x41 or the other way around. That changes "not-equal-jumps" to "equal-jumps".

But after seeing disassembled code once again I must once again pass at understanding the deeper meaning of it...

 

[FoxMcClaud]

unfortunatly the region block could be anywhere, in any file at any bit!

But actually i think it's more of a "failure" not a real block. Why should some games have it and some not? Why don't all the new games have it, just a few...

Actually you would have to compare each working title and each non working title to see a pattern. And it's not 100% sure it lies in the main.dol, though it's probable...

 

[waninkoko]

anyone got a documantation on fst.bin?
I figured some of it:
they are in 0xC sectors followed by filenames after 0xC(# of files)

(type) 00 00 (filename offset) (unknown 4Byte) (File/dir size 4Byte)

type: 00 = file, 01 = dir

Anyone knows what the unknown 4 Bytes are?
I tried to compare it with truncha signer offset but they doesn't match

The file entries in the fst.bin have this struct:

Type - 1 bytes - 0x00 = file, 0x01 = directory
String offset - 3 bytes - It specifies where the name of this file/directory is located in the string table at the end of the fst.
File offset - 4 bytes (value

 

[SleepyPrince]

@professa
Brickblocking the disc would undo the patched __update.inf (the game would just be like a directly brickblocked game).
It is quite correct that the game still wants to update because we want it to udpate the IOS updates. Otherwise the game will not work.
On the other hand I would not try the patched update.inf on a console that isn't at least updated to v3.1.

@everybody working on NMH

I tried to disassemble the main.dol from SSBB and NMH.
(I used IDA Pro Advanced - has anybody some suggestions how to configure IDA to better handle the .dols? It doesn't find a starting point
to disassemble so you have to jump somewhere in the code and just go from there...)
Changing 0x0C to 0x04 will propably never for work for the region check. The 001-fix changes a jump address and skips that way one line of code.
It is a better idea (although still a bad idea if you do it "blind") to change 0x40 to 0x41 or the other way around. That changes "not-equal-jumps" to "equal-jumps".

But after seeing disassembled code once again I must once again pass at understanding the deeper meaning of it...
There is a dol plugin here
http://hitmen.c02.at/html/tools_ida.html

QUOTE(waninkoko @ Mar 4 2008, 09:12 PM) The file entries in the fst.bin have this struct:

Type - 1 bytes - 0x00 = file, 0x01 = directory
String offset - 3 bytes - It specifies where the name of this file/directory is located in the string table at the end of the fst.
File offset - 4 bytes (value

 

[waninkoko]

Oh yeah.

I forgot to specify that the "File offset" field in a directory is always 0x00000000 and "File size" field indicates the number of files(+1?) in the directory.

 

[mwaddoups]

By the way, for those of you comparing hex, the tool available at http://www.exeicon.com/hex-comparison/ is incredibly useful imo, and it also functions as a rudimentary hex editor. You do need the full version to make use of the diffing function though.

Also, I've been looking at the disassembler, and that's flying way over my head ^^.

I have found a small piece of information - the specific game data in the main.dol file seems to start at 0x0025ED so I expect the region stuff will be before there (if the main.dol is the correct file to be looking at.

 

[SleepyPrince]

Just tried another way to mod MySims
I change the values directly in the fst.bin file
so that the jap resources now points to eng resources
it seems to be working fine

I think this can be one of the methods to "replace" files which is larger than the original
but you have to find a file which is large enough to hold your file
at the same time wont be in use (maybe another language resources)
then point your original file to it

 

[SleepyPrince]

Oh yeah.

I forgot to specify that the "File offset" field in a directory is always 0x00000000 and "File size" field indicates the number of files(+1?) in the directory.

Just realize that the "File size" field isn't that simple
I have seen directories under the same parent folder with different number of files
having the same "File size" value

Still trying to figure it out...
If that's not the number of files, then what does it use to indicate end of folder?

 

[waninkoko]

A new way to rip SSBB to a DVD5

This new method modifies the file table "fst.bin" to relink all the videos from the second layer.

1. Download this modified "fst.bin" (http://www.megaupload.com/?d=5AM4JJZ4).
2. Replace the "fst.bin" from "PARTITION (RSBJ01)/SYSFILES" with the modified one. Sign the partition.
3. If you are modifying the DVD9 ISO, then you can use this little app (http://www.megaupload.com/?d=3U8DXPFM) to generate a valid DVD5 ISO (just drag the ISO onto the executable).
3. Burn and play

 

[gjac1]

waninkoko, i just tried your new SSBB DVD5 method and it DOES work, i just forgot to do the swap.....

 

[bailli]

Hm the NMH main.dol even contains some german strings like "Karte", "Daten Laden",... Did somebody a compare of the JPN and US main.dol of NMH?
Maybe they are "almost" identical expect the region check part...

At offset 0x4C5919 there are some "country strings" with a number following. (JPN01USA02EUR03...). If you look at these strings with a disassembler they are actually referenced two times. Maybe messing around with some jumps in that region might help?!

BTW: Does a game with 001 fix work on modchips that support "001 protected" games natively?

EDIT: Hm I patched a conditional jump at 0x37D674 from 0x40 to 0x41. I have absolutly no idea if this is a step towards region free or not.
But feel free to try and burn a patched main.dol. I will propably test this myself tomorrow afternoon. (I have to get the full NMH ISO first and
some DVD-RWs

)

 

[alucard_xs]

does the adventure mode work ?

 

[SleepyPrince]

A new way to rip SSBB to a DVD5

This new method modifies the file table "fst.bin" to relink all the videos from the second layer.

1. Download this modified "fst.bin" (http://www.megaupload.com/?d=5AM4JJZ4).
2. Replace the "fst.bin" from "PARTITION (RSBJ01)/SYSFILES" with the modified one. Sign the partition.
3. If you are modifying the DVD9 ISO, then you can use this little app (http://www.megaupload.com/?d=3U8DXPFM) to generate a valid DVD5 ISO (just drag the ISO onto the executable).
3. Burn and play

just as what I expect after what I found a few post above
can someone share it somewhere else other than megaupload?

 

[gjac1]

EDIT: Hm I patched a conditional jump at 0x37D674 from 0x40 to 0x41. I have absolutly no idea if this is a step towards region free or not.
But feel free to try and burn a patched main.dol. I will propably test this myself tomorrow afternoon. (I have to get the full NMH ISO first and
some DVD-RWs

)

Dont you mean you changed it from 41 to 40 ??

EDIT : well either way, on mine it was 41 and i have just changed it to 40 , it is now burning and i will let you know shortly if it boots or not

EDIT 2 : nope it didnt work

boots to a black screen.....

 

[light_kun]

A new way to rip SSBB to a DVD5

This new method modifies the file table "fst.bin" to relink all the videos from the second layer.

1. Download this modified "fst.bin" (http://www.megaupload.com/?d=5AM4JJZ4).
2. Replace the "fst.bin" from "PARTITION (RSBJ01)/SYSFILES" with the modified one. Sign the partition.
3. If you are modifying the DVD9 ISO, then you can use this little app (http://www.megaupload.com/?d=3U8DXPFM) to generate a valid DVD5 ISO (just drag the ISO onto the executable).
3. Burn and play

Does adventure mode work? (subspace emissary)

 

[stormyuan]

A new way to rip SSBB to a DVD5

This new method modifies the file table "fst.bin" to relink all the videos from the second layer.

1. Download this modified "fst.bin" (http://www.megaupload.com/?d=5AM4JJZ4).
2. Replace the "fst.bin" from "PARTITION (RSBJ01)/SYSFILES" with the modified one. Sign the partition.
3. If you are modifying the DVD9 ISO, then you can use this little app (http://www.megaupload.com/?d=3U8DXPFM) to generate a valid DVD5 ISO (just drag the ISO onto the executable).
3. Burn and play

RS share

http://rapidshare.com/files/97119169/fst_ssbb.zip
http://rapidshare.com/files/97119191/ssbb_dvd5_tool.zip

 

[SleepyPrince]

Finally figured out what's the "Size" field for directory in the fst.bin
it marks the end of the folder by counting the # of entries so far from ROOT

but still haven't figured out the "offset" field for directories

edit: seems like it's the parent folder entry #, verifying...

edit2: I am right about that...

 

[Edgedancer]

I know tha I may be flamed for this but what do I do to get the key.bin. have typed "download key.bin" in google but I am unsure what to do with the results.

 

[SleepyPrince]

I know tha I may be flamed for this but what do I do to get the key.bin. have typed "download key.bin" in google but I am unsure what to do with the results.

http://gbatemp.net/index.php?showtopic=76657