Runtime/Seamless Retail Disc "Customs"

I'm wondering how feasible it would be to emulate the functionality of custom discs without the need for modchips or even ripping/burning games at all. The simple goal is to replace any given file from a Wii disc's filesystem while a game is running with your own custom file, from an SD card (will that raise read speed issues?).

So, would it be possible to, say, patch / write your own DIP module that redirects read operations as necessary? The thing is that I have limited knowledge here, and so the possibility of this approach depends on a couple things...
How is the Wii disc filesystem set up? Would it be difficult to patch your own file data into, or would it be a matter of simply hooking into one function and sending different data depending on what offset is being requested? Are discs encrypted, and if so, are they decrypted behind IOS read calls or is the game/SDK responsible for doing this?
Also, as I mentioned, how would SD/USB read speeds compare to the DVD drive? Would accessing the SD card when a game is too result in conflicts?

Or would you instead want to patch the game binary in memory and hack at the SDK functions instead?

So, I'm just asking for some direction, and for a measure of the feasibility of this plan from those who have some experience in hacking at these things.
- Aaron

The WiiDisc contains an unencrypted partition description at the start of the disc. There's usually only 1 or 2 partitions (one for the game, the other for Nintendo's update WADs).

I must admit, when I used DVD_LowRead (or whatever it's called) to read all the unencrypted data, I got nothing like what was on the Wiki about the discs. Maybe I did something wrong

Some info about the discs [www.wiibrew.org]

The IOS is responsible for the decryption (I believe, somebody correct me if I'm wrong). cIOS and PatchMii are two examples that download an IOS install, patch the Unencrypted read limit off the disc reading functions.

I'm not really sure which functions you would need to hook though.

You'd actually probably want to peer around inside a game executable, and see what function it uses to read other files from the disc. You'd most likely want to hook into that function, inject your own bit of code to check for certain files, and load those off the SD card instead (via another function in the executable). The only partially easy part to do is putting the hook in the function. Everything else you probably have to write specifically for each version and put in exact memory locations of functions (not fun)
Your injected code would most likely have to be assembly as well, so have fun loading the registers and calling functions via jumps to (seemingly) random numbers.
Definitely possible, and a good idea too.

Maybe someone more knowledgable about hooks and assembly can correct any mistakes I made (I probably did =/) and clarify what is needed.

Also, there is a chance everything I just said is bullshit. If so, don't blame me, it's the internet's fault.

Quote
SquidMan
You'd actually probably want to peer around inside a game executable, and see what function it uses to read other files from the disc. You'd most likely want to hook into that function, inject your own bit of code to check for certain files, and load those off the SD card instead (via another function in the executable). The only partially easy part to do is putting the hook in the function. Everything else you probably have to write specifically for each version and put in exact memory locations of functions (not fun)
Your injected code would most likely have to be assembly as well, so have fun loading the registers and calling functions via jumps to (seemingly) random numbers.
Definitely possible, and a good idea too.

Maybe someone more knowledgable about hooks and assembly can correct any mistakes I made (I probably did =/) and clarify what is needed.

Also, there is a chance everything I just said is bullshit. If so, don't blame me, it's the internet's fault.

Actually the need for using assembly would be 1 instruction. A technique called code caving would be best.
You basically write a C function with the same prototype as the one you're hooking, load it to memory and copy the address down.
You then replace the first instruction in the hooked function with 'b my_func' the stack and registers are all the same so it works as if the parent called it directly.

Is that reliable? Can you be sure an unofficial compiler/devkit will do everything compatible with the official one (e.g. use registers and handle parameters the same way)?
Also I would expect them to use an IOS function to read files from the disc? Or does IOS just provide sector-level access?

HyperHacker, you could probably just use that same technique, code caving, to find the location of the function for reading files from the disc (which should be in the Nintendo SDK, which all games use, so you just need to scour the DOL for the name of it) and then just use a branch to it so you can read your files. Also, I'm not sure if you can write C code for this (or at least it'd probably be better to do assembly, because you know EXACTLY what it will be doing, so you won't run into problems related to that.)