[HTC Pico (Explorer)] no.human.being:
Wow wow wow, a lot of stuff going on here recently. Let me try to catch up. :D

The mtd devices are normally located under "/dev/mtd", not "/dev/block". They have names like "/dev/mtd/mtd0", "/dev/mtd/mtd1" and so on. There's also "/dev/mtd/mtd0ro", "/dev/mrd/mtd1ro" and so on. These are versions of the same device that discard all write access ("ro" for "read only"). The "/dev/block/mtdblock*" devices seem to be "bogus devices" under Android. They always return "I/O error" on anything you do. There's probably no real driver behind. The file systems are sometimes mounted on "/dev/block/mtdblock*" devices, but this is probably done internally by some "kernel hackery" that we (or at least I) don't quite understand. The actual "mtdblock" driver that handles the "/dev/block/mtdblock*" device nodes seems to be an entirely defunct "stub". If you want to handle an mtd, use the devices under "/dev/mtd". They are the devices that are designed to be used for the mtd driver. Even the Linux kernel devs said that "/dev/block/mtdblock*" was built more for "testing purposes" and is not designed for regular use (especially not for use with file systems that are designed for block devices as they will usually write a lot and also a lot to the same memory cells so they tend to wear out the NAND quickly - normal NAND does not have wear levelling and bad block replacement), so Google MIGHT have restricted acces to these devices so that people don't get crazy about "yeah I can use Ext2/3/4 (or even FAT lol) on my phone with NAND memory" and then kill their NAND when Ext4 writes to the journal area several thousand times per second and lose data by using a file system that is not designed to work with memory blocks that fail to hold their content because they are worn-out. ;)

Erasing and writing to "misc" does not require S-OFF. User theq from this forum built a bootloader control tool for HTC phones which allows the phone's bootloader to be put in a locked, unlocked or relocked state at will by setting appropriate flags in the "misc" partition. The tool actually reads the entire "misc" partition into RAM, then sets the flags accordingly, then erases the entire partition, then writes the modified contents of the partition back. You neither need S-OFF nor an unlocked bootloader, nor a valid "HTCdev unlocking key" for this to work. Temporary root (e. g. zergRush if your version of Android is vulnerable to that exploit) or a ROM that's perma-rooted (e. g. CM) is sufficient. You probably need a working build of "mtdutils" for the phone though. It's not trivial to build, but I have prebuilt binaries for the WFS that I built from source some time ago. They should work on Explorer too. The tool is also very handy for unlocking the bootloader without having the "userdata" partition formatted (which happens during a normal unlock with the HTC cryptographic token). I have never used the tool, but I know how it works and have successfully done the steps that the tool is designed to do automatically "by hand" (preparing "misc" partitions for locked/unlocked state with a hex editor and then flashing them) and this has always worked nicely.

Be careful when fiddling around with the "misc" partition though. On the Wildfire S there was a flag in "misc" that disabled the phone's USB controller. Needless to say when you flip that, you have a hard time of restoring it, since you can no longer use any fastboot, adb or file transfer on the phone since the USB controller is down. Someone coined the term "USB bricked" for this state since, unless the phone is rooted, you have no chance of restoring from that condition. And even if the phone is rooted, it's not fun to create a working "misc" image using only "Android terminal emulation" and stuff like that.