New Bootmii exploits?

[pm_41]

Hey all,

I have an old LU59 Wii that had a non-exploitable boot1/boot2 block for Bootmii back when I seriously gamed on it about 12-15 years ago. Has there been any newer exploits found that would allow Bootmii to be installed on "newer" Wiis like mine? Especially now that most of the Hackmii suite is open source (including Bootmii itself)? Or has anyone been successful in manually programming Bootmii (like de-soldering the right chip, wiring it to a chip programmer, and reprogramming it in something like Ida Pro)?

I'm really interested in better soft-brick protection beyond Priiloader as the console ages.

 

[SylverReZ]

Has there been any newer exploits found that would allow Bootmii to be installed on "newer" Wiis like mine?

The latest Wii exploits can be found on Hacks.Guide. They don't require using a save exploit or hardmod such as a modchip.
https://wii.hacks.guide/get-started.html

 

[XFlak]

SylverReZ that's not what he's asking

@op, not really. The leaked sd boot is kinda related, but has drawbacks in that the wii won't boot anything if it doesn't find specific files on sd, or so I'm told

 

[KleinesSinchen]

Problem is there are no known exploits for newer boot1.

Boot process goes like this:

First stage is boot0. That one is true ROM. MASK ROM. You physically can't change this one. It loads the second stage: boot1, which sits on the first block of NAND.
Problem is we can't simply change boot1 (neither can Nintendo) since boot0 does a SHA1 check. If anything is changed the boot process will fail very early on.

Then boot1 loads the third stage: boot2. There is a signature check making sure boot2 is signed by Nintendo. On older consoles this signature check is broken (and can not be updated as mentioned above). This allows fake signing a custom boot2 → BootMii.

To fully break the Wii security on newer units you need a chosen prefix SHA-1 collision for replacing boot1. This is technically possible but has not been done to my knowledge.

 

[pm_41]

On older consoles this signature check is broken (and can not be updated as mentioned above). This allows fake signing a custom boot2 → BootMii.

I'm well aware of that part. I was asking if anyone figured out a newer exploit since then. Or if anyone has had any luck manually/electrically reprogramming the chip at the binary level (electrical engineering stuff).

There's also this I found interesting from WiiBrew's page on the Signing Bug:

Instead of changing the code to use memcmp, the updated code manually compares the hash. Interestingly, the code continues to check the entire hash after a mismatch.

Going from that:
- Is the boot2 hash code the same on every Wii? Or does every Wii have a different hash code?
- If the hash changes for each Wii, then is it possible to extract the boot2 hash on-device using Homebrew code? Or does it have to be extracted manually (again using something like Ida Pro - cited by some of the old Hackmii blog posts)?

If it's possible to extract the boot2 hash somehow, that itself becomes possibly exploitable. Like either via rehashing Bootmii itself or by some kind of MITM (man in the middle) or adapter pattern attack. Especially since once the hash is extracted, we can pass off the actual rehashing stuff to a modern multicore computer (possibly even a modern GPU depending on the math needed).

 

[pm_41]

From Wiibrew:

A certain glitching pattern in boot0 allows any installed boot1 to load. An attack can be found here.

https://wiibrew.org/wiki/Wii_system_flaws#Hardware
https://github.com/shinyquagsire23/Wii-Glitching/

So, in theory, someone could flash a hacked boot1 that would disable the boot2 integrity check as long as it included that boot0 exploit in it?

I'm gonna look into this.

 

[Quadraxis_v2]

I'm well aware of that part. I was asking if anyone figured out a newer exploit since then. Or if anyone has had any luck manually/electrically reprogramming the chip at the binary level (electrical engineering stuff).

There's also this I found interesting from WiiBrew's page on the Signing Bug:

Going from that:
- Is the boot2 hash code the same on every Wii? Or does every Wii have a different hash code?
- If the hash changes for each Wii, then is it possible to extract the boot2 hash on-device using Homebrew code? Or does it have to be extracted manually (again using something like Ida Pro - cited by some of the old Hackmii blog posts)?

If it's possible to extract the boot2 hash somehow, that itself becomes possibly exploitable. Like either via rehashing Bootmii itself or by some kind of MITM (man in the middle) or adapter pattern attack. Especially since once the hash is extracted, we can pass off the actual rehashing stuff to a modern multicore computer (possibly even a modern GPU depending on the math needed).

You're mixing/confusing lots of things. There is no such thing in the Wii as a boot2 hash. A hash is a one-way function that generates a fixed-width value from some data. Getting the hash of boot2 is the same as getting the hash of a picture of your cat. If you're interested, the SHA1 hash of boot2v4 is 96c58cf009c5184405d85de8d51e458f1e36a8fb

boot2's signature is checked by boot1. Older versions of boot1 didn't do the check correctly and hence it's possible to install a different boot2. You can't just find any collision in the hash function because you need to collide with a specific hash (stored in the signature) and that's something that as far as I know has not even been possible to do with MD5 which is considered an insecure algorithm.
boot1 is, on the other hand, hashed at the factory and its hash is stored in OTP memory in which you can only write 1's with an electrical programmer. boot0 checks that hash.

IDA and MITM attacks have nothing to do with anything. IDA is a PC program for reverse engineering software and MITM are network-based attacks for sniffing traffic.

 

[KleinesSinchen]

You can't just find any collision in the hash function because you need to collide with a specific hash (stored in the signature) and that's something that as far as I know has not even been possible to do with MD5 which is considered an insecure algorithm.

MD5 is completely broken and unsuitable for any security applications.
https://www.mscs.dal.ca/~selinger/md5collision/

Even SHA1 is to some extent broken but the method is still not public as far as I know.
https://sha-mbles.github.io/

Replacing boot1 with a SHA1 "chosen-prefix collision" would be the clean way of controlling the Wii boot process very early on (opposed to leaked data containing copyrighted material in the form of a special signed boot2).

 

[Larsenv]

http://github.com/RedBeesRGD/rgdboot-installer/ will eventually be out which can let you install bootmii boot2 on any wii

 

[Aep]

You're mixing/confusing lots of things. There is no such thing in the Wii as a boot2 hash. A hash is a one-way function that generates a fixed-width value from some data. Getting the hash of boot2 is the same as getting the hash of a picture of your cat. If you're interested, the SHA1 hash of boot2v4 is 96c58cf009c5184405d85de8d51e458f1e36a8fb

boot2's signature is checked by boot1. Older versions of boot1 didn't do the check correctly and hence it's possible to install a different boot2. You can't just find any collision in the hash function because you need to collide with a specific hash (stored in the signature) and that's something that as far as I know has not even been possible to do with MD5 which is considered an insecure algorithm.
boot1 is, on the other hand, hashed at the factory and its hash is stored in OTP memory in which you can only write 1's with an electrical programmer. boot0 checks that hash.

IDA and MITM attacks have nothing to do with anything. IDA is a PC program for reverse engineering software and MITM are network-based attacks for sniffing traffic.

Is that hash the hash of the boot2 WAD, or how did you get that? What file in boot2?

 

[Quadraxis_v2]

Is that hash the hash of the boot2 WAD, or how did you get that? What file in boot2?

The TMD.