[HTC Wildfire S] no.human.being:
Ok, I've got some news. I've managed to build custom mtdutils for the device. Man, that was hard work, the mtdutils source is really bad and binds against a Linux glibc, which is not available on Android, I had to change a lot to get it to work. I booted the phone into CWM recovery with the appropriate partition mapping.

$ ./fastboot -c "mtdparts=msm_nand:0x00100000@0x1ff00000(misc),0x00500000@0x02fc0000(recovery),0x00340000@0x034c0000(boot),0x10400000@0x03800000(system),0x02300000@0x13c00000(cache),0x09600000@0x16900000(userdata),0x00a00000@0x15f00000(devlog),0x02fc0000@0x00000000(radio)" boot ~/Downloads/arm/CM/recovery-clockwork-5.0.2.8-marvel.img
downloading 'boot.img'...
OKAY [ 1.622s]
booting...
OKAY [ 0.000s]
finished. total time: 1.623s
$

Then I pushed my custom mtdutils onto the device.

$ ./adb push mtdutils /mtdutils
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
push: mtdutils/flash_lock -> /mtdutils/flash_lock
push: mtdutils/flash_otp_dump -> /mtdutils/flash_otp_dump
push: mtdutils/flash_erase -> /mtdutils/flash_erase
push: mtdutils/ftl_check -> /mtdutils/ftl_check
push: mtdutils/doc_loadbios -> /mtdutils/doc_loadbios
push: mtdutils/mtd_debug -> /mtdutils/mtd_debug
push: mtdutils/rfddump -> /mtdutils/rfddump
push: mtdutils/nftldump -> /mtdutils/nftldump
push: mtdutils/ftl_format -> /mtdutils/ftl_format
push: mtdutils/nandwrite -> /mtdutils/nandwrite
push: mtdutils/docfdisk -> /mtdutils/docfdisk
push: mtdutils/flash_unlock -> /mtdutils/flash_unlock
push: mtdutils/nanddump -> /mtdutils/nanddump
push: mtdutils/flashcp -> /mtdutils/flashcp
push: mtdutils/rfdformat -> /mtdutils/rfdformat
push: mtdutils/flash_otp_info -> /mtdutils/flash_otp_info
push: mtdutils/nftl_format -> /mtdutils/nftl_format
push: mtdutils/nandtest -> /mtdutils/nandtest
18 files pushed. 0 files skipped.
1321 KB/s (11954676 bytes in 8.832s)
$

Then I opened an adb shell.

$ ./adb shell
~ # ls
boot init sdcard
cache init.rc sys
data mtdutils system
datadata proc tmp
default.prop res ueventd.goldfish.rc
dev root ueventd.marvel.rc
emmc sbin ueventd.rc
etc sd-ext
~ # cd mtdutils
/mtdutils # ls -l
-rwxrwxrwx 1 root root 644931 Mar 4 19:11 doc_loadbios
-rwxrwxrwx 1 root root 656755 Mar 4 19:11 docfdisk
-rwxrwxrwx 1 root root 713828 Mar 4 19:11 flash_erase
-rwxrwxrwx 1 root root 643401 Mar 4 19:11 flash_lock
-rwxrwxrwx 1 root root 643640 Mar 4 19:11 flash_otp_dump
-rwxrwxrwx 1 root root 643746 Mar 4 19:11 flash_otp_info
-rwxrwxrwx 1 root root 643407 Mar 4 19:11 flash_unlock
-rwxrwxrwx 1 root root 658066 Mar 4 19:11 flashcp
-rwxrwxrwx 1 root root 655771 Mar 4 19:11 ftl_check
-rwxrwxrwx 1 root root 659100 Mar 4 19:11 ftl_format
-rwxrwxrwx 1 root root 653960 Mar 4 19:11 mtd_debug
-rwxrwxrwx 1 root root 723231 Mar 4 19:11 nanddump
-rwxrwxrwx 1 root root 659064 Mar 4 19:11 nandtest
-rwxrwxrwx 1 root root 725223 Mar 4 19:11 nandwrite
-rwxrwxrwx 1 root root 662469 Mar 4 19:11 nftl_format
-rwxrwxrwx 1 root root 651465 Mar 4 19:11 nftldump
-rwxrwxrwx 1 root root 661819 Mar 4 19:11 rfddump
-rwxrwxrwx 1 root root 654800 Mar 4 19:11 rfdformat
/mtdutils # ./flash_unlock
Usage: flash_unlock <mtd device> [offset] [block count]

If offset is not specified, it defaults to 0.
If block count is not specified, it defaults to all blocks.
/mtdutils #

Now obviously the build is ok. I tried to unlock the blocks of mtd7.

/mtdutils # ./flash_unlock /dev/mtd/mtd7
flash_unlock: error!: could not unlock device: /dev/mtd/mtd7

error 95 (Operation not supported)
/mtdutils #

Of course I thought it might be some special protection that's on the Radio, so I tried a "standard" partition.

/mtdutils # ./flash_unlock /dev/mtd/mtd6
flash_unlock: error!: could not unlock device: /dev/mtd/mtd6

error 95 (Operation not supported)
/mtdutils #

Nope, it doesn't work on any partition. I tried again with only the "mtd7", "radio" as parameter instead of "/dev/mtd/mtd7", but this gave me the following error:

flash_unlock: error!: could not open: mtd7
error 2 (No such file or directory)

Then I tried with "/dev/block/mtdblock7", but:

/mtdutils # ./flash_unlock /dev/block/mtdblock7
flash_unlock: error!: could not get mtd info: /dev/block/mtdblock7
error 25 (Inappropriate ioctl for device)
/mtdutils #

"flash_lock" does also not work.

/mtdutils # ./flash_lock /dev/mtd/mtd6
flash_lock: error!: could not lock device: /dev/mtd/mtd6

error 95 (Operation not supported)
/mtdutils #

Then I tried to "nanddump" the Radio.

/mtdutils # ./nanddump -p /dev/mtd/mtd7 | head
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 149
Number of bbt blocks: 0
Block size 262144, page size 4096, OOB size 128
Dumping data starting at 0x00000000 and ending at 0x02fc0000...
ECC: 1 uncorrectable bitflip(s) at offset 0x00000000
0x00000000: ff ab ff ff 34 10 d7 73 5a 43 0b 7d ff ff ff ff
0x00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00000090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

This works, however you get quite an amount of bad blocks. I don't think this is "protection", the NAND that's used on the device is really bad. It goes until 0x005fffff, then aborts with an error.

libmtd: error!: MEMGETBADBLOCK ioctl failed for eraseblock 24 (mtd7)
error 5 (Input/output error)
nanddump: error!: libmtd: mtd_is_bad

This on the other hand looks like a protective measure again. The memory becoming so bad that "nanddump" aborts exactly at 0x00600000 physical seems a bit too much of a coincidence.

Then I started dumping where the HBOOT begins, which is 0x02b00000 physical.

/mtdutils # ./nanddump -p -s 0x02b00000 /dev/mtd/mtd7

Then it reads again and it reads until the end (until 0x02fbffff physical).

So there's probably an area in the Radio starting at 0x00600000 physical that cannot be touched. On the other hand, the area where the HBOOT resides seems perfectly fine. So I think we make the partition smaller and let it start later, so that it only covers HBOOT (which is 256 KiB right?) and then we're ready to fire. This also gives us the advantage that we leave the Radio itself untouched. Of course the exploit will need some serious amount of rework for that, but it seems to be a reasonable way to go.

EDIT: I've attached the complete mtdutils build, in case someone wants to test. Be careful when writing though, if you don't want to damage your system and/or data.

EDIT2: Also note that "nanddump" claims "page size 4096". So my software writing in multiples of 4096 bytes seems reasonable.