Is it stored as it in NAND??? Why isn’t it stored in OTP of Hollywood chip?

I suppose it’s that key: 9258a75264960d82676f904456882a73

How did you find it?

I don’t have so much time to do it all by myself so , any help to find out if is there any real way to use the ZERO-hash back door will be apreciated very much

as soon as I have time i’ll have a look to boot0 first then to boot1 , looking for some clue wasn’t noticed yet , then maybe i’ll try it by myself
(or not
,if I finally feel it as too much risky as U say)

OTP is read by writing the address to one register OR 0×80000000 and reading another register which contains the read 32-bit word. The reading register seems to be read-only (not a holding register) so that’s probably not how you write to OTP.

this was +/- the answer was looking for …

don’t worry about my knowledge with OTP devices, I’m proud to be the designer of a board for ISA BUS tha only (ONLY) using OTP devices (PLA) (very old stuff hehe) can let you introduce hardware breakpoints in any x86 uP mounted in any ISA (old stuff as well ) compliant motherboard

as complement to my CV , I’m an ARM enthusiast ,which owns a Archimedes A310 since 1987 (wow 22 year ARM story ,shit i’m getting old)

and finally I do manage crypto stuff each day,so I know very well the math meaning of SHA-any

so my idea ,was not ,of course , to act as kamikaze and to go stright to change directly the SHA-1 hash
(BTW , why do they check correctly SHA1 in boot0 then use a flawed check in boot1 ?)

I saw in a wiki a list of locations which is suposed
they are in the OTP area, inside this list ther is at least 1 which maybe can allow you to check if OTP protection is really ON

(9 NG id , for example looks like a place where you can try to flip a bit without briking your wiii)

as you state , if the default of OTP looks like to be ZERO , then probably isn’t made of fuse and instead is a protected EE2 area, so if you try to flip an innocent BIT without risk of briking the wii then later you can write all ZERO in SHA1 hash ..

Ok, I know, looks like too much speculation, but also boot1 flaw to anybody knowing SHA1 looks like to be impossible , isn’it ?

so why do they can’t have also leaved de lock of OTP open

There’s a difference between OTP devices used for program storage, and OTP areas used for secure key storage. The latter tend to have security mechanisms like (gasp) a write protect fuse that when blown prevents further writes.

It is almost certain that the OTP is burned early during the manufacturing process and then a fuse is blown to lock it. But even IF you could flip bits from 0 to 1, it’s of no use because you’d still need to brute force half of the boot1 SHA-1 bits, which is infeasible.

If boot0 checks for an all-zero OTP hash then zero is almost certainly the blank state for this OTP.

Conclusion: maybe there’s a way to exploit this, but the chances are very slim. If someone wants to provide 5 or 6 Wiis to attempt to perform OTP write experiments, we’ll gladly try it out.

I don’t know how old you are .. so don’t take it wrong please .. and maybe just take it as a tip if you didn’t investigate already this way

I did write many times over and over to many OTP devices , then I got others OTP were that wasn’t possible but usually because an additional LOCK (fuse or whatever)

as background ..

first OTPs devices were PROMs
(guess you already know the meaning of)

then came the era of EPROMs then the one of EE2PROMs and EE2 devices in general (FLASH)

at least some years ago you could get as sort of PROM a OTP device, which in turns results in a lot of fuse pulled to a pullUp resistor giving to the corresponding BIT the meaning of 1 unless you blow the fuse …

today you can still get OTP as a lot of fuse to blow or as a EE2 chip with a lock to make the further writes impossible ,
but in any case if the OTP is made of a lot of fuse they use to be pulled up to 1 as default,
which in turns let you can blow their fuse unless all of their fuse are blowedup
(this was an usefull trik for developers of firmware stored in OTPs because in fact let u write many version of programs in the same OTP as long there is enaugh space free space to blow as 00 wich in many case result to be equivalent of a NOP opcode)

so my question in fact was
1) is the wii OTP made of fuse or what ?
2) theres a lock to block further writes to it
3) if yes , it’s really locked or not ?
4) anybody try to rewrite some bit of it ?

many thanks,

Reading here ‘n’ there about bootmii stuff,
I got the information (don’t know if it’s wrong) and where it came from (somebody got a boot zero dump ? can I have a look to it ?? )

Well, the point is ..
1) boot0 checks boot1 against the hash inside OTP
2)if hash in OTP is ZERO the check is skipped
3) and if theres no protection about write more than once the OTP (didn’t see anything about that)

then is just matter to write all zero in place of the OTP hash and is done.. easy isn’it ?

my assumption is .. standard OTP bits are default to 1 … (was common to leave some space as FF in early processors working only with OTP as ROM , so you can done changes later bay changing these virgins locations )

if theres no protection against write OTP more than once and the magic string is all ZERO then would be fantastic ..