Hacking Wii U Homebrew Wish List - Homebrew Idea Thread

[thekarter104]

I honestly don't know how that worked on the Wii, never been into the photo channel LOL.
Just viewing pictures like you do on PC or something.

 

[Mr. Mysterio]

I honestly don't know how that worked on the Wii, never been into the photo channel LOL.
Just viewing pictures like you do on PC or something.

Oh, it's more than that! It has a full-blown graphics editor that can keep a 5-year-old occupied for hours! Just put your pictures in the JPG format on the SD card root.

 

[TotalInsanity4]

Like the photo channel on the Wii? Good idea!

Actually, you can install some version of the Photo Channel as a .wad in vWii, if I recall correctly. But a HomebrU for that would be nice!

 

[Marionumber1]

External SD storage is probably impossible to get without hijacking a game that allows it, like Smash, but USB access is shaping up to be reasonably likely.

 

[TeamScriptKiddies]

External SD storage is probably impossible to get without hijacking a game that allows it, like Smash, but USB access is shaping up to be reasonably likely.

Wouldn't sd access also be possible with an IOSU exploit? No need for a game then. Just wondering if something drastic was discovered recently that I somehow missed. I am aware however of the progress you've made with USB access using only a Kernel exploit as you and NWP have been posting about it here and on WiiUbrew, very exciting stuff . Keep up the awesome work! Even if sd card access isn't possible without exploiting a game using kernel access, that's okay, USB would be perfect anyways . We could hook up an external hdd just for homebrew and fill that thing to the teeth if we want .

As for people reading that who are going to start begging for a backup loader, ITS NOT GOING TO HAPPEN WITHOUT AN IOSU EXPLOIT, FURTHERMORE MN1 ET AL AREN'T INTERESTED IN DEVELOPING BACKUP LOADERS ANYWAYS. I for one support the idea of a backup loader, but MN1 and NWP and all them have no interest in developing such things and I fully respect that. They are kind enough to dedicate their free time to this project and make homebrew a reality on the Wii U. I know that what I'm saying here will likely be blatantly ignored, but can we not have a flame war here requesting a backup loader resulting in a debate that's entirely off topic? Just for once?

 

[Marionumber1]

Wouldn't sd access also be possible with an IOSU exploit? No need for a game then. Just wondering if something drastic was discovered recently that I somehow missed.

What I meant was that without an IOSU exploit, you'd need to hijack a game with SD permissions. An IOSU exploit gives you full control of the entire system, so of course it will let you access the SD.

 

[stan423321]

So this is probably going to be extremely stupid.

Is my understanding of the following correct?

• IOSU guards USB HDD and eMMC in a reasonable way. It protects the system by refusing to decrypt unsigned stuff. That's why Caffiine thing works over network.
• IOSU has some sort of concept of PPC things going on, since SSBU is "needed" to access SD card usage privilege. It somehow keeps checking whether the SD card request comes from SSBU or from something else.
• Kernel access is enough to break into IOSU services protecting controllers, and also networking.
• Kernel access is enough to run cheats, both of variable and code patching variety.
• IOSU doesn't control GPU, and the only thing it can do to CPU against kernel is resetting.

I'd love to know more about inner workings of various fancy things like Wii eShop games if you know something already, but I understand that's not a priority.

I just wonder what Caffiiine can do, to be honest.

 

[Marionumber1]

IOSU guards USB HDD and eMMC in a reasonable way. It protects the system by refusing to decrypt unsigned stuff. That's why Caffiine thing works over network.

IOSU enforces file permissions on the internal storage and discs. External USB storage may actually be more accessible than initially thought; we're still looking into that, it seems promising.

IOSU has some sort of concept of PPC things going on, since SSBU is "needed" to access SD card usage privilege. It somehow keeps checking whether the SD card request comes from SSBU or from something else.

All titles have something with them called the Title Metadata (TMD), which specifies various access permissions. There's presumably a flag in the TMD somewhere that specifies whether an app has SD access. When IOSU loads a title, it parses the TMD, reads the access permissions, and sets a memory flag determining whether the app can use the SD. From that point on, all SD access is checked against the flag. (This is all speculation, but it makes sense)

Kernel access is enough to break into IOSU services protecting controllers, and also networking.

IOSU doesn't protect controllers or networking, it just implements the hardware support required to use them. We can actually use controllers and networking in userspace, without a kernel exploit.

Kernel access is enough to run cheats, both of variable and code patching variety. IOSU doesn't control GPU, and the only thing it can do to CPU against kernel is resetting.

Both of those are correct.

 

[Mr. Mysterio]

I just wonder what Caffiiine can do, to be honest.

You want to know what Cafiine can do? Take a look at this.

 

[NWPlayer123]

TMD being the two XMLs in the code folder.

I'd love to know more about inner workings of various fancy things like Wii eShop games if you know something already, but I understand that's not a priority.

Actually, I'm just waiting for the new Webkit exploit to be finished which doesn't look like it'll be any time soon at the rate we're going :<

 

[Mr. Mysterio]

Actually, I'm just waiting for the new Webkit exploit to be finished which doesn't look like it'll be any time soon at the rate we're going :<

A watched exploit never is released.

 

[stan423321]

All titles have something with them called the Title Metadata (TMD), which specifies various access permissions. There's presumably a flag in the TMD somewhere that specifies whether an app has SD access. When IOSU loads a title, it parses the TMD, reads the access permissions, and sets a memory flag determining whether the app can use the SD. From that point on, all SD access is checked against the flag. (This is all speculation, but it makes sense)

Okay, I honestly have a problem with this. It would make perfect sense on Wii. But Wii U uses simultaneous multiprocessing. Would, say, web browser, or notification checker, be a title, or is that reserved for games (and maybe DLC)? Regardless, how would IOSU distinguish which of running executables made a request to read something? Wouldn't all of these go through kernel anyway?

 

[Marionumber1]

Okay, I honestly have a problem with this. It would make perfect sense on Wii. But Wii U uses simultaneous multiprocessing. Would, say, web browser, or notification checker, be a title, or is that reserved for games (and maybe DLC)? Regardless, how would IOSU distinguish which of running executables made a request to read something? Wouldn't all of these go through kernel anyway?

I don't know that much about how IOSU and Cafe OS interrelate with regards to title switching. However, I do know that all IOSU requests (which can be done from userspace, by the way) contain something called the fixed process ID (PFID), which uniquely identifies which process sent the request. Games, the browser, the eShop, and even Cafe OS itself have these, and I think the kernel prevents you from forging a PFID. IOSU appears to have security profiles for each PFID; for example, code running in userspace but as part of the RPL loader can access OSv11's files, even though normal userspace code can't, as the loader likely runs under the Cafe OS PFID. The TMD specifies the security profile for Smash, so now that I think about it, it may be possible to load Smash, switch to the browser, run the kernel exploit, and forge the PFID as Smash's to get SD access.

 

[stan423321]

Thank you for the information, Mn1. I was thinking of tags, along other things.

In the random homebrew ideas, using USB ODD for movies/music/data could end up being hilarious.

 

[TotalInsanity4]

Thank you for the information, Mn1. I was thinking of tags, along other things.

In the random homebrew ideas, using USB ODD for movies/music/data could end up being hilarious.

ODD?

 

[Marionumber1]

ODD?

I assume he meant optical disc drive.

 

[TotalInsanity4]

I assume he meant optical disc drive.

Ah! I see. I'm used to just seeing that abbreviated as "OD", for "Optical Drive"

 

[Mr. Mysterio]

Ah! I see. I'm used to just seeing that abbreviated as "OD", for "Optical Drive"

ODD is a very odd abbreviation for optical disc drive.

 

[TotalInsanity4]

ODD is a very odd abbreviation for optical disc drive.

Spoiler: MEMES, for EVERYONE!!

 

[NWPlayer123]

[20:18:29] <endrift> I guess I could port mGBA
Check that one off the list, once we get proper graphics and an ELF loader