Hacking A way to rip games without network/playing?

[Elliander]

@Elliander
We are already spoofing (somewhere in the kernel) some values in loadiine, but no one that help us with stuff like that. I know where in the XMLs the SD Access is stored, but you can't just modifiy the XML, they are loaded and handled by the iosu.

hmm. So it doesn't go to memory before going to the IOSU?

 

[Cyan]

maybe it tell the IOS (not ISOU) to load data from the game's TitleID, and the IOS is the one responsible for loading the file.
the game launcher doesn't send data to IOS nor load the value to memory for IOS to read it.
(that's just assumptions)

 

[Elliander]

maybe it tell the IOS (not ISOU) to load data from the game's TitleID, and the IOS is the one responsible for loading the file.
the game launcher doesn't send data to IOS nor load the value to memory for IOS to read it.
(that's just assumptions)

If that's the case wouldn't something have to go to memory somewhere in order to a save file size limit to be enforced?

This case kind of reminds me of something I went through when helping to mod Populous: The Beginning. We found the constants file, where the game rules were stored, and we figured out where everything was and how it worked, but no matter what we changed nothing actually changed. I suggested, but never personally found, that there was a second file somewhere that also had the constants values which was checking to make sure the constants were not changed and to change them back. Someone else eventually tracked that down and we got full game mods working.

So could something similar be going on here? Either some other file reinforcing the values which keep it from being changed, or perhaps some other memory value has more than one purpose? Given how badly the Wii was hacked it would make sense that they would do something like that to at least delay modding.

 

[Cyan]

if it's in a place where IOS is watching and preventing edition, you won't be able to edit that information without hacking the IOS first.
the IOS is your "second place where the value is checked".

people think "IOSU hack" (bad name, really) would open all doors, but the IOS is responsible for many things and has many functions which would need to be patched.
an IOS hack is not magical.
on Wii, IOS was responsible for few things, which got added little by little : signature check (trucha bug), NAND access, IOS install right (on vWii), etc.
"hacking" it can mean many different thing.

 

[Reecey]

What amazes me the WiiKey Team cracked the wiiu way back in the day and was releasing the actual product and a few tester models did go out to a few lucky people, cough, cough! Which then they could rip a full wiiu disc which is how the scene rippers have been doing ripping full wiiu titles with keys. They stopped production on the wiikeyu because they knew the homebew method was on the horizon and soon as that had been released, the very expensive wiikeyu would of been dead and took a massive nose dive in sales so no point really carrying on but tbh I'm not sure really why the team just didn't release some information on the actual drive, shame we might of moved on quite a lot if they had been a bit more open and not so greedy as if to say well were not going anywhere so neither is the homebrew side.

Ripping looked like this with the wiikeyu. The original wiikeyu board is down near the drive, you can just see it on the left connected>

 

[Elliander]

Maybe there was more to it than greed? In order to be profitable, it would need to use an exploit that later firmware can access. Is it possible that they didn't want to release too many to avoid an issue with an exploit being closed before they were ready for market?

If they have working prototypes already they could just do a limited batch production run and I am sure they would sell even if over priced.

 

[Maschell]

There a temp folder that can be used. I don't know how much data you can store there.
In theory, you could copy the disc data to this temp folder, and then (back in mii maker) copy the files to a SD Card. For big games that would be probably a pain in the ass (I don't think the folder can hold more than 1-2 GB). But that could be a "network-less" way of dumping

Today I started to work on it and I think I found a way to share data between Application with a temp folder. It seems like the size of the temp folder is your free space! Actually I dump the game to a 60Gb HDD via USB and then copy it to the sd card in mii maker.
I'm testing (currently dumping zombiU), but it seems to be "slow". Maybe a bit faster than the network dumping I'll report the result when the dump is finished!

Edit: It crashed after copying to the USB drive. meh. But it took 1868 seconds for 5969256448 byte, which gives transferrate of about 3 megabyte/second. So even with copying it twice (Disc/nand->usb->SD) it should be ~ 30% faster.

Edit: Trine 2 worked!.
2.076.623.457 byte.
Nand -> USB = 806 seconds
USB -> SD = 350 seconds
=> ~20 minutes instead of 33min wiht network @ 1megabyte/s

 

[Cyan]

you finally tested it
good to see it works, and that all the free space is available.

Why are you going to usb first?
You are doing Disc/nand->usb->SD
can't you do Disc->nand(temp)->SD ? or NAND->nand(temp)->SD ?
or it's better to use usb for the temp path ?

 

[Deleted User]

can't you do Disc->nand(temp)->SD ?

You probably could, I'm pretty sure that the TEMP folder will use any available storage medium. Don't quote me on this though, @brienj probably knows a little more about this, ask him, lol.

(Though if this is the case, those of us with 8GB Wii U consoles may need to do a few rounds to get a full dump, lol).

 

[Cyan]

ah you are right, that's probably because he didn't have enough space that he used USB.
maybe he didn't implement resume function yet. it's easier to test with full dump.

I thought it was something like "it's better to not write to flash too often". but it will probably need lot of dumps before the flash become bad.