Hacking Unoffical -- USBloader_GX(S)

  • Thread starter Thread starter Sketter
  • Start date Start date
  • Views Views 68,139
  • Replies Replies 321
Sketter said:
There is a major change to all this.

pune's method will require all games to be decrypted.

: but you will probably need to convert the games to an unencrypted format for them to work like this
: you can make it work, but its a bunch of extra work that the data has to go through on its way to the PPC which doesnt need to happen
: i already made a game dumper that can dump any game that GX can load into its decrypted contents
: this format is the absolute smallest you can have a game and still have it 100% playable
: and its unencrpyted. if i want to play wbfs (encryped) games, i have to add decryption shit in the DI which im too lazy for
: this is smaller than wbfs

The encryption has a major benefit, it detects data corruption. Decrypted games is a major step backwards.
 
so you are saying that keeping decrypted IOS, game saves, chanels, etc for triiforce and sneek is a step backwards? because that how nand emulation works in every form of it we have. i have to disagree with you on this one.
 
Hold on, I'm missing something here. Do the games have to be a decrypted .iso / .wbfs / .w/e, or do they have to be extracted files? I remember on an earlier thread giantpune said it read the extracted game. Decrypted isos would be a pain for the end user while, in my opinion, extracted games would be kinda nice.

Also, do you think that it would be possible to code the module so that you can replace files in the extracted game without worrying about changing the file size or editing fst.bin?
 
currently it plays games from either a folder full of the extracted files or from a part.bin and part1.bin. the part.bin are just all the decrypted files truncated into 1 or 2 files so it is easier to deal with than a bunch of separate files.

and no, i will not make the module play files without updating the fst.bin. this is the list of file sizes and offsets that the game uses to decide what offset to ask from the dvd when it wants a certain file. the module just does the opposite of what the game is doing to turn the offset back into a filename. what you are asking is like having a treasure map and then moving the treasure without changing the spot of the big red X. it literally takes less than 1 second to create a fst.bin for 5000 files. i dont see the issue.
 
giantpune said:
and no, i will not make the module play files without updating the fst.bin. this is the list of file sizes and offsets that the game uses to decide what offset to ask from the dvd when it wants a certain file. the module just does the opposite of what the game is doing to turn the offset back into a filename. what you are asking is like having a treasure map and then moving the treasure without changing the spot of the big red X. it literally takes less than 1 second to create a fst.bin for 5000 files. i dont see the issue.
So this means basicly that we have an "Drag and Drop-Riivolution", right? Finaly it's confirmed
biggrin.gif
 
giantpune said:
so you are saying that keeping decrypted IOS, game saves, chanels, etc for triiforce and sneek is a step backwards? because that how nand emulation works in every form of it we have. i have to disagree with you on this one.

triiforce would be better if it could load ios/channels from wads. I'm not bothered about game saves.
Allowing game patches by merging in a seperate decrypted directory would be ok. Although I'd probably rebuild the fst at runtime, because that would be a really cool feature.

From a digital archivist point of view, anything that can be done to make sure games aren't distributed patched/badly dumped/corrupted can only be a good thing.

At the moment triiforce/sneek & this unofficial loader have small market share, so it hasn't caused any problems.

So far nobody has managed to create a good dump of the pal version of call of duty modern warfare reflex, but today we can tell. If you advocate decrypted games then there is a good chance people will start distributing games that way & preservation will become much harder.
 
What are you talking about corrupted files? Am i missing something?

TriiForce can't load wads, because loading from sd card is using the nand emu. And the nand emu is to 100% inside the cIOS, TriiForce can't do anything about it! When will people finally understand that?

And this loader(or a similar) will become very popular if Waninkoko and Hermes don't manage to get IOS Reloading games to work. Ok, since Waninkoko has an usb gecko now, and he can see the source of a loader that works, i expect that he will fix it soon.
 
WiiPower said:
And this loader(or a similar) will become very popular if Waninkoko and Hermes don't manage to get IOS Reloading games to work. Ok, since Waninkoko has an usb gecko now, and he can see the source of a loader that works, i expect that he will fix it soon.
This loader will become popular anyways, even if Waninkoko manages to fix the IOS Reload. It has 100% Compatibilty (with WiiGames AND VC/WiiWare), has much bigger space for the saves/dlc/etc., and is great for editing Games (new Levels/Tracks, etc.).

Not shure what rev20 will bring, but currently VC/Wiiware Loading is far away from 100% compatibility. NAND Emu for saves is already done, alright, but it's still buggy/slow. Not to mention that nearly no loader features this. And editing games (Riivolution for backups) will probably not come that fast too. Also, I think SNEEK is a bit more future-proof. because it uses Nintys original IOS, and the way it works. So: It has many points which cIOS (currently) hasn't. The only downside I see is that it may be slow to load (SNEEK is for some damm slow). Otheriwse I think it's perfect.

This doesn't mean that cIOS is obsolete, everyone can choose what he wants. But if my HD is fast enough, I'll switch to SNEEK/Loader
smile.gif
.
 
mousex said:
Blue-K said:
It has 100% Compatibility (with WiiGames AND VC/WiiWare)
How can you say this? Did you test every single Wii game and WW/VC? Games checking for a sane IOS (like this game that disabled menus when running on patched IOS) or requesting BCA other than the NSMBW BCA won't work right, or do they?
First: Any statements about compatibility are about the current situation/now. Should be clear. We don't know what Nintys next move will be, and what the future will look like.

Now:
-SNEEK should play every VC/WiiWare. Never saw any report that one didn't worked, and it played games which didn't worked on Triiforce. If you got a game that don't works with SNEEK, let me know, and I'll update my post
smile.gif
.
-Wii Games: Shure I didn't test every game right, and I'm sorry for not being clear here. Theoretical, every game should work. And again, there aren't any reports of games that don't work with SNEEK (right now). There could be one, but we don't know right now.
-Games checking for a sane IOS: Dindn't followed that one closely, but it's not the case that you can't patch/install a clean IOS.
-BCA: Yes, this is a flaw. But currently NSMBW works without any patching. And if you use a loader, they should be able to patch the game with the BCA (CFG, etc. can). And I guess it would be possible to update SNEEK with BCA-Support. But yes, currently you are right.

cios may have 100% compatibility in the future, too.
I think I pointed that out. That's why I said currently, etc. The only thing that I said about the future was that this loader will become popular. Anything other wasn't intended.
I apologize for not being clear at some points, and I hope everything is now right
wink.gif
.

-Blue-K
 
SNEEK handles the BCA protection check as good as it currently is required, NSMBW runs out of the box without any patching.
As soon as some game will do something new I'm sure SNEEK will be updated in no time.

As for the new sane IOS check let's think about that for more than two seconds here.
No game can access IOS content(aka the modules), the only thing they can is get the TMD, TMDView and TicketView.
The usual cIOS will probably have a fake signed TMD/Ticket and an oddly high version, games can check that and that rugby game DOES check the TMD for tempering.
SNEEK is not affected here since it will simply return the TMD/Ticket you got installed.
 
i dont know? i use sneek's di module right now (for some reason i couldnt get yours to compile) but yeah for NSMBW i just replace the files and edit the fst myself. That wouldn't be so easy if you were batch replacing files, but its easy enough to manually add the new file size info to the fst.
 
kyle007 said:
i dont know? i use sneek's di module right now (for some reason i couldnt get yours to compile) but yeah for NSMBW i just replace the files and edit the fst myself. That wouldn't be so easy if you were batch replacing files, but its easy enough to manually add the new file size info to the fst.
You could always create a bash/batch script to edit the fst for you...
 
heres everything you'll need to play games like in the videos, convert any usb loader to work with these modules, and create a new fst.bin and update the boot.bin with the new fst size if that has changed. while this code is definitely working, it has been tested on only 2 or 3 wiis and so far nothing has fucked up. there is also probably some memory leaks and lots of room to optimize the code.

some assembly required -
puneek modules http://www.multiupload.com/MY3S86W0TC
follow the same procedures used to build r72 of sneek to build this.
im building these with -u -v flags and the mini toolchain. devkitARM r24 should also work fine. follow the same procedures to set up games as in sneek. since this DI module loads games from whatever the nand is, this could (in theory) allow you to add the changes from this fs module into the fs-sd module and you will be able to load the complete wii from a sdhc card. games can either be extracted files using /sys/ and /files/ folders or part.bin and part1.bin. the part.bin can be split at whatever size you want. so a 500MB game can be split at 250MB into parts. all game files are loaded read-only from the di. for my HDD, CoD3 extracted into 505 small files is 3.5GB where the WBFS size is 4GB. SSBB is 6.7GB for the main game partition.

functions for usb loaders http://pastie.org/892737
this obviously isn't everything it will take to convert one, but this is everything it will take to get the loader to work with the above modules. the usb stuff should be removed and all the wbfs stuff and any cIOS specific IOS calls. then just set a game, change the IOS to the one in the TMD, and load it like a dvd

fst creator / boot.bin updater http://pastie.org/892752
tested and working on ubuntu amd64 9.10. the fst.bin created is not identical to the original one, but it works fine with these modules. if the fst.bin changes size, that new size needs to be written in the boot.bin.

i'm not going to help people figure out how to compile all this stuff. that is all part of the fun. and it's really fun when you figure it out on your own and it works. for more information, check the bigass sneek thread, the sneek wiki and FAQ, and google.
 
giantpune said:
puneek modules http://www.multiupload.com/MY3S86W0TC
follow the same procedures used to build r72 of sneek to build this.
im building these with -u -v flags and the mini toolchain. devkitARM r24 should also work fine. follow the same procedures to set up games as in sneek. since this DI module loads games from whatever the nand is, this could (in theory) allow you to add the changes from this fs module into the fs-sd module and you will be able to load the complete wii from a sdhc card. games can either be extracted files using /sys/ and /files/ folders or part.bin and part1.bin. the part.bin can be split at whatever size you want. so a 500MB game can be split at 250MB into parts. all game files are loaded read-only from the di. for my HDD, CoD3 extracted into 505 small files is 3.5GB where the WBFS size is 4GB. SSBB is 6.7GB for the main game partition.

Okay, let me see if I got this right. After building the modules, I'd run IOSKpatch like this to make the binary?

CODEIOSKpatch\IOSKPatch 0000000e.app 0000000E-TMP.app -u -v > NUL
ELFIns\elfins 0000000E-TMP.app boot2.bin es\esmodule.elf fs-usb\iosmodule.elf > NUL

EDIT: Wait, I just saw the part where you said you won't give more hints. But I went ahead with that and it seemed to compile just fine. =P Haven't tested it yet obviously
 

Site & Scene News

Popular threads in this forum