Back

@Jhynjhiruu @marcan @Rairii @foone the OTP also had a very silly design flaw: they had their own AES engine as well so why not just hook that one up directly to the OTP and ensure their keys never even reach the CPU. It wouldn’t have saved them but it could’ve bought them time and made things much more annoying for us.

Then again, IOS hardcoded a fallback common key that was the same as their real common key

@Rairii @marcan@treehouse.systems @sven @foone As of a couple of weeks ago, yes! ...though, we managed to brick two more consoles in the process, since the kernel code that normally writes v2 is broken.

@Jhynjhiruu @Rairii @marcan @foone wait, they had a writable storage and pretended it was OTP and stored their first stage bootloader hash, etc there? lol

@sven @Jhynjhiruu @marcan @foone yes. I think broadon thought it actually was OTP, or meant to make it such in hardware and just *forgot* lol

@Rairii @sven @marcan@treehouse.systems @foone The intended factory setup procedure was write dummy image with jtag to get it to boot -> launch kernel -> kernel writes final image and locks out writing, I think. They forgot the last, and most important, step.

@Jhynjhiruu @sven @marcan @foone yeah i was about to mention there's also a space there for code jumped to by the bootrom in about the tenth instruction after reset (after verifying the checksum)

@Rairii @sven @marcan@treehouse.systems @foone There are two sets of rompatch code that get run, one before the kernel hashing code is bootstrapped and one after. The code that runs after is more useful, since you can add a single instruction into the delay slot of the jr $t0 that the kernel checks and nop out the panic() call when the hash fails, so it falls through and boots normally.