- Joined
- Jan 27, 2015
- Messages
- 4,999
- Trophies
- 1
- Location
- Behind a screen reading news
- XP
- 4,885
- Country
I am just posting a design idea. I don't care if it gets used or not. I am just showing what I want it to look like...
People are suggesting their ideas in the Loadiine thread already, it would be useful if you post yours there too, since Loadiine is gonna be ultimately used as our hombrew channel anyway.
So if you want to contribute, (yes with just sketchs), any design ideas are appreciated, and u can also give your toughts on the ones suggested already.
- Joined
- Jan 27, 2015
- Messages
- 4,999
- Trophies
- 1
- Location
- Behind a screen reading news
- XP
- 4,885
- Country
That's a bit wrong. We do not need more than IOSU (installing a channel has nothing to do with boot-keys). In the large picture you are still right though, in that we cannot have it the same way, we had it on the Wii.
IOSU checks title IDs, signatures and whatnot, so with IOSU access we can disable signature checks and install a homebrew channel. The difference between the Wii and Wii U though, is that the Wii only checked the signatures of applications, when they were installed and not when they were ran. The Wii U does both.
Hence, we can have Homebrew Channels etc, but we would still need to run the exploit, before we can use it.
And yes, that is where boot0/1 enters the pictures. Boot0 would be fantastic to find a vulnerability for, as its the hardcoded bootROM (that loads boot1) in the ARM processor, and thus cannot be changed by Ninty (they would need a new hardware revision of the Wii U for that).
Boot1 would be fantastic too, as it's the job of boot1 to decrypt the ancast image that contains the ARM's OS (= IOSU), even though it can be changed by Ninty.
So yea, boot1 exploitation would mean that we can disable the signature checks in IOSU, already when we load it into memory. Don't count on it though. To be honest, I am really surprised already that we have gotten this far
IOSU is already better than the wet dream I had last week (<-- sorry for that last line... Pls still like my post)
Last edited by oPolo,
Although something like themehax would still be the simplest way to patch things directly on boot without any user input. Too bad we don't have themes, and I don't think we'll get them in an update.
That's a bit wrong. We do not need more than IOSU (installing a channel has nothing to do with boot-keys). In the large picture you are still right though, in that we cannot have it the same way, we had it on the Wii.
IOSU checks title IDs, signatures and whatnot, so with IOSU access we can disable signature checks and install a homebrew channel. The difference between the Wii and Wii U though, is that the Wii only checked the signatures of applications, when they were installed and not when they were ran. The Wii U does both.
Hence, we can have Homebrew Channels etc, but we would still need to run the exploit, before we can use it.
And yes, that is where boot0/1 enters the pictures. Boot0 would be fantastic to find a vulnerability for, as its the hardcoded bootROM (that loads boot1) in the ARM processor, and thus cannot be changed by Ninty (they would need a new hardware revision of the Wii U for that).
Boot1 would be fantastic too, as it's the job of boot1 to decrypt the ancast image that contains the ARM's OS (= IOSU), even though it can be changed by Ninty.
So yea, boot1 exploitation would mean that we can disable the signature checks in IOSU, already when we load it into memory. Don't count on it though. To be honest, I am really surprised already that we have gotten this far
Your logic is sound and you do make good points, but the likelyhood of a bootX exploit ever being discovered is really small (and in the case of Boot0, it is infinitesimal, since this is a rom area, the code is made as short as possible and as secure as possible, since there is absolutely no way to change it on the current userbase). Thus, if we want the benefits of a Wii-grade homebrew channel, what we would need, more realisticly, would be an expoit in the boot sequence of the console, since the IOSU exploit only need Userland code execution, if we find a reliable exploit in the whole boot process that would be triggered without any user input, we could achieve Cold-Boot IOSU exploit (ala Menu-Hax for 3DS), which should allow for safe boot into "emunand", with only drawback the fact that full boot-time would be almost doubled, but in theory almost no chance of messing up the real nand.
This would be the most realistic (still unlikely, tho) way to achieve what most people really want, being able to access to homebrew/signature patching after a cold boot without any user input.
Last edited by capito27,
That's a bit wrong. We do not need more than IOSU (installing a channel has nothing to do with boot-keys). In the large picture you are still right though, in that we cannot have it the same way, we had it on the Wii.
IOSU checks title IDs, signatures and whatnot, so with IOSU access we can disable signature checks and install a homebrew channel. The difference between the Wii and Wii U though, is that the Wii only checked the signatures of applications, when they were installed and not when they were ran. The Wii U does both.
Hence, we can have Homebrew Channels etc, but we would still need to run the exploit, before we can use it.
And yes, that is where boot0/1 enters the pictures. Boot0 would be fantastic to find a vulnerability for, as its the hardcoded bootROM (that loads boot1) in the ARM processor, and thus cannot be changed by Ninty (they would need a new hardware revision of the Wii U for that).
Boot1 would be fantastic too, as it's the job of boot1 to decrypt the ancast image that contains the ARM's OS (= IOSU), even though it can be changed by Ninty.
So yea, boot1 exploitation would mean that we can disable the signature checks in IOSU, already when we load it into memory. Don't count on it though. To be honest, I am really surprised already that we have gotten this far
Yes, if you ran an IOSU exploit, you could install a working homebrew channel. Then as soon as you turned off the system, you would be left with a title that has an invalid signature, either rendering it useless or possibly causing a brick. Unless there actually is a boot IOSU exploit, installing one is pointless at best, and dangerous at worst.
That being said, a boot0/boot1 exploit is not strictly necessary for a boot-time exploit. For example, let's say that some data parsed by the PPC early in the boot process (like Mii data) can be corrupted in an exploitable way. We could get PPC code running very early on at boot, exploit IOSU then, and have signatures disabled from that point forward.
Sig Checking happens early in PPC startup... so... we don't have that early access... catch my drift?
Use wbfs2fat, it changes the format to Fat32 without deleting any game, you can play GC games on a Fat32 HDD, but not on a WBFS HDD, that's why I did it a long time ago.
You can load games Wii games on the FAT32 HDD with Wii Backup Manager and also GC games with DMToolbox.
PPC kernel access is access to the Cafe OS kernel's memory, while IOSU access is access to ARM memory. IOSU is responsible for checking signatures, and the PPC (at least as Nintendo intends) has no access to the ARM's memory.
While you are here, quick question.
Who or what is blocking OTP access after boot? .. Or why can't IOSU read the entire OTP?
I'm asking because of the boot1 key, which afaik is in there?
The OTP probably just has a register that causes it to block any requests to the region. Software can't get the keys if hardware refuses to give them.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
32GBs is the baseline for 4K video editing these days and lots of recommendations for 64GBs but for games 16,GBs is honestly plenty for a long time. -
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
Some sort of police thing going on near me lol "Get out of the car with your hands up and walk backwards towards us" over a loud speaker thing
-
-
like a 250 dollar kit back when DDR4 was Intel only
