boot1 checksum algorithm

If we could make BootMii checksum made entirely of zeroes, it would be RSA-decoded to itself. So, my questions are:
1) do boot1 use ECC or RSA for boot2 signature decoding, and
2) what checksum algorithm does boot1 use (a link to understandable example code would be helpful)
3) overall, is it possible to "make" the checksum fixed.

Quote
stan423321
If we could make BootMii checksum made entirely of zeroes, it would be RSA-decoded to itself.

I'm not sure this would be useful, but I'm not sure I understand what you're getting at.

Quote

So, my questions are:
1) do boot1 use ECC or RSA for boot2 signature decoding, and

RSA

Quote

2) what checksum algorithm does boot1 use (a link to understandable example code would be helpful)

It's the same that the rest of IOS uses. boot2 has a TMD that contains a SHA1 of the decrypted content of boot2; that TMD is then hashed (again with SHA1). The RSA signature on the TMD is decrypted to produce the expected SHA1 hash of the TMD; in early versions of IOS/boot1, the comparison of expected vs calculated hash was done using strncmp and some padding was ignored. The check is now more robust and seems properly implemented.

However, if you are still reading this far and are truly interested (in perhaps finding another bug in their verification algorithm), I can give you a disassembly of the code and we can start trying to convert it back to C.

Quote

3) overall, is it possible to "make" the checksum fixed.

No, that would require a first preimage attack, which is not considered feasible for SHA1.

The big issue is that we cannot crack RSA or SHA-1 in a comprehensible amount of time.

The only attack I can even think of is finding some way to replace the OTP in the ARM core with empty memory. boot0 doesn't check the hash of boot1 if OTP is empty, so by doing this we could then replace boot1 with one that either has Trucha or doesn't verify signatures at all, and then we are free.



Edited 1 time(s). Last edit at 11/09/2009 11:43PM by WikiFSX.

Yeah, but the whole point of OTP is its OTP (One Time Programmable).

Hence replace, which I know is practically, if not totally, impossible.

We haven't even been able to pinpoint where exactly the OTP is, even with die shots. :(

There is an attack against a weakened version of SHA1 that could be used to create our own boot1 or boot2 if extended to the full version of SHA1. (Important to note, not yet possible to do this for the full SHA1, so can't do yet make the boot1 or boot2 with whatever has we like)

[www.h-online.com]

Nice part of this attack you can put whatever you want at the start then get the hash you want by appending suitable garbage so if it does get extended to the full SHA1 it's basically perfect for making a boot1 or boot2 replacement

Quote
SifJar
Yeah, but the whole point of OTP is its OTP (One Time Programmable).

Ah, yes. But some OTP ROMs start out as all 1 and you can 'burn' the 1 to 0. So you might be change the 'OTP' boot0 after all.

Just looking at: [wiibrew.org], at "FFFF0474" there is the instruction "BNE hash_fail" and BNE translates to the hex code: "1A", while "BEQ" (just the opposite) is hex code "0A" so just burning out that 1 bit could in theory flip the boot0 from only booting valid boot1 code to only booting invalid boot1 code.

Quote
Daid

Quote
SifJar
Yeah, but the whole point of OTP is its OTP (One Time Programmable).

Ah, yes. But some OTP ROMs start out as all 1 and you can 'burn' the 1 to 0. So you might be change the 'OTP' boot0 after all.

Just looking at: [wiibrew.org], at "FFFF0474" there is the instruction "BNE hash_fail" and BNE translates to the hex code: "1A", while "BEQ" (just the opposite) is hex code "0A" so just burning out that 1 bit could in theory flip the boot0 from only booting valid boot1 code to only booting invalid boot1 code.

1A is 00011010 in binary and 0A is 00001010 so yeah, I guess that may be possible, but it would surely require expensive specialist hardware to "burn" a bit.

Quote
SifJar

Quote
Daid

Quote
SifJar
Yeah, but the whole point of OTP is its OTP (One Time Programmable).

Ah, yes. But some OTP ROMs start out as all 1 and you can 'burn' the 1 to 0. So you might be change the 'OTP' boot0 after all.

Just looking at: [wiibrew.org], at "FFFF0474" there is the instruction "BNE hash_fail" and BNE translates to the hex code: "1A", while "BEQ" (just the opposite) is hex code "0A" so just burning out that 1 bit could in theory flip the boot0 from only booting valid boot1 code to only booting invalid boot1 code.

1A is 00011010 in binary and 0A is 00001010 so yeah, I guess that may be possible, but it would surely require expensive specialist hardware to "burn" a bit.

On old fasion OTP roms it's just "set the address lines, apply 15V on data line for X miliseconds", the hardware around it is just to easily do that for every address. But until we know where the OTP ROM is, there is no way to know if this can really be done. You might fry other hardware in the process.

Or the OTP boot0 rom is not a real ROM at all, but just a bunch of logic gates, just a whole bunch of AND gates to build a the right minterms with the address lines as inputs and the data as outputs. If I would have to build some custom unhackable chip then that would be the way I would try to do it.