Open neagix opened 7 years ago
I don't think that will work. The Wii's SHA-1 engine isn't sane. It generates a completely different SHA-1 hash for a file than normal. It also sometimes generates a hash less than 40 bits long somehow.
Um, no, that's not the case. I have no idea where you've gotten that info from. The SHA-1 engine is completely compliant (though it does not perform padding, you have to do that yourself) and it always generates a correct 160-bit hash. Generating a smaller hash doesn't even make sense because the hash registers are 160 bits.
@Jasjar42 if you check the Hextwelve POC, it actually just runs a SHA1 unit test that verifies it's compliant
@marcan Sorry I was wrong. Can you please tell me where my info is wrong? As wiibrew says boot0 loads boot1 and verifies its SHA1 hash against that stored in OTP. But the only boot1 OTP hash that is 40 bits long is the one for boot1d. Boot1b's OTP hash is: EF3EF781968D56DF5679A6F92E13F78BBDDFDF which is only 38 bits long. I wasn't able to match any SHA-1 hashes to the corresponding OTP hash in any way, even with encrypted or decrypted versions. I came to that conclusion because of that. Thanks.
You're mixing up bits and nybbles. A SHA-1 hash is 160 bits or 40 nybbles. The truncated hashes on Wiibrew are just typos, they're all supposed to be 160 bits.
It's true, however, that boot1 hashes are not standard SHA-1 hashes because boot0 does not apply the standard padding. This is the only part of Wii firmware that does not do this. With proper padding the hashes would correspond to standard SHA-1 hashes.
Likewise #10, it should be possible to implemented SHA-1 in-kernel hardware acceleration.
For reference: http://wiibrew.org/wiki/Hardware/SHA-1_Engine And: http://wiibrew.org/wiki/Hextwelve
Cc @marcan