[HTC Wildfire S] no.human.being:
I think you're on the wrong path. We do not need any "keys". We do not need to "break" any more security measures. We just have to implement the full protocol for talking to the NAND chip.

By convention, the aARM (ARM11) has exclusive control over the NAND, while the mARM (ARM9) does not access the NAND at all after the Radio firmware has been loaded into volatile (RAM) memory. When the Radio wants to write to NAND, it needs to ask the Android kernel running on the aARM via an RPC mechanism to do so. So there is nothing in the Radio we need to "crack". The Radio is completely "dumb". It can't even access the NAND on its own. It relies on Android running alongside to access the NAND for it on request. All we have to do is pass the "unlock" command to the NAND and we have to do this from the aARM. A "stock" Linux kernel can't do it, since the mtd driver has no facilities for this ("flash_unlock" returns "Operation not supported"), so we will have to modify the mtd driver to build in support for this.

Of course, the NAND lock itself is a "security measure". However, it doesn't have "teeth". It merely prevents "accidental writes". It can be disabled at will by the aARM (remember HBOOT is also running on aARM) using a simple "unlock" command to the NAND chip. All we have to do is make the kernel set off this command. We will not need to authenticate with the Radio for doing this, as the locks are completely under aARM's control.

The NAND starts out completely locked and then the aARM must "unlock" pages that it wants to have write access to. All pages start out locked. This is the way the NAND chip operates. The Radio has nothing to do with this. It will never unlock any pages, since it never has to write to NAND. In fact, after initializing, in which it treats the NAND in a "read-only" fashion in order to load software into RAM, the Radio won't access the NAND anymore. What unlocks the NAND is HBOOT, which is running on the aARM, which is also where our kernel runs. HBOOT passes "unlock" commands to the NAND for all the pages that make up the "visible mtd partitions" (so mtd0 - mtd6) so that the Android kernel can write to them, since Android's (and Linux's) mtd subsystem does not have the facilities to unlock the NAND itself. Then the kernel is loaded into RAM and booted and it finds its partitions unlocked.

Now what I would do is build a custom kernel with a modified mtd subsystem, which can pass "unlock" commands to the NAND, just like HBOOT can. Remember that HBOOT will unlock the "visible" NAND area, then boot our kernel. The aARM (where the HBOOT and our kernel run) can always "unlock" more pages at a later point in time. So after our kernel has booted up, we will request our custom mtd subsystem to "unlock" the Radio area (or perhaps just the pages that are occupied by HBOOT). After this has happened, we will be able to pass an "erase" command for erasing these pages. After erasure, we will be able to write our modified HBOOT image back to NAND. We may then opt to pass a "lock" command to the NAND again to re-"lock" the pages we modified, just in case the Radio checks the pages' flags while booting. In no case will we have to authenticate with the Radio or even talk to it. We just need to have a custom kernel, which implements the entire protocol that the NAND chip talks, for unlocking the pages that HBOOT left locked.