[HTC Wildfire S] no.human.being:
It's not the secu_flag. Every single memory page that belongs to the "unmapped" (Radio) area is marked as "worn out" (being erased so often that another erase would "kill" it) and the mtd driver sees that marking and then refuses to erase the page in order to avoid physical damage to the memory. I'm sure that they did not really "wear the pages out", since HTC itself updates the Radio from time to time and sure they don't really make their memory bad, they just mark it as bad, so that the kernel no longer dares to erase it. The marking is done by setting bitflags in the "out of band area" of the pages ("out of band" doesn't mean that they're difficult to access, it just means that "normal" read/write calls are not affected by them so that the file system driver doesn't have to be aware of their presence). There are ioctl(...) calls for checking and modifying these flags for every single memory page. All we have to do is either ...

... make the mtd driver ignore these flags and erase the page nonetheless.

... make the mtd driver clear (reset) the flags before attempting to erase the page.

When we can do either of the two, we can write to the Radio area. The modification should not be "difficult" (perhaps we don't even have to modify the kernel-level mtd driver itself, but just the user space utilities), it's just that we have to dive into kernel development to understand what's going on beneath the hood.

Yes we got error messages trying to erase the unmapped area. The erase is skipping every single page since they are considered "bad". The "erase_image" utility told us that.

They either write the data and then mark the page as bad or all the pages are marked bad by HTC during manufacturing and "their utilities" write to bad pages, allowing them to program the NAND nonetheless. Remember they can't do too much corruption since both Radio and HBOOT (both stemming from the protected area) are loaded from persistent (NAND) into volatile (RAM) memory by processor-level firmware and this firmware must be able to understand the data that's written to NAND, load it into RAM and schedule the execution of both, "Radio" and "HBOOT/Android" kernels, since the two are supposed to run "in parallel" on the processor, communicating with each other via shared memory. So this all can't be "too custom". At least the processor-level firmware must understand what both "operating systems" are doing and both must adhere to some sort of "common protocol" for the communication.

Also remember that dumping the HBOOT via the mtd layer works just fine, so the data ain't really "corrupted". The pages are just marked as "Do not erase me!" and that's what the mtd driver and user space utilities do. Not erasing them. Everything else works fine. :D

Yes it is. The mtd driver can both set and clear the flags (one of the two operations will almost certainly require a complete erasure of the page though) and it seems to be the only instance (apart from the user space mtdutils) that checks (and therefore "enforces") them.

The protection measure is in the Android kernel and is by Google, not by HTC. HTC just "makes use" of the protection by setting some flags that Android checks. Every Android phone has this protection in place. Even the Nexus phones have it. HTC hasn't got anything to do with this, they're just "licensees" of the technology.