[HTC Wildfire S] no.human.being:
Much of the complexity of our exploit (the "inject" utility) stems from the fact that we don't ship an HBOOT image with the exploit for copyright reasons. We take the HBOOT that's already on the device and patch a few instructions in it so that it "thinks" it's S-OFF. That's why we "fopen(...)" the mtd device for the HBOOT partition for binary reading ("rb" flags), then "fread(...)" the entire HBOOT into a buffer in RAM (it's only 512 KiB in size). Then we have an algorithm that finds where to patch. This is where most of the "intelligence" resides, as there are different HBOOTs floating around and our exploit has the ability to "adapt" to certain changes and variations. After that step, we basically have an HBOOT image in RAM that always reports S-OFF.

Then we call "flash_erase" from the "mtdutils" to erase the NAND blocks where HBOOT resides. Currently this fails due to restrictions imposed on us by the kernel we're running on. After the call to the "flash_erase" utility, we "fopen(...)" the mtd device again for binary writing ("wb" flags) and "fwrite(...)" the (patched) image that is residing in our buffer back to NAND.

For a simpler exploit, you can skip this entire procedure and instead just ship a "hacked" HBOOT image that you have "prepared". It's just that we wanted to do it this way so that we can ship the exploit without including any code that's copyright by HTC to avoid a lot of legal issues.

Well we kind of have to pass it, since the HBOOT is not at a fixed address on our device. There are at least two different memory layouts and depending on the layout the "hboot" partition (where we patch) has to start at a different physical address. That's why we can't "hardcode" it into the kernel.

Sounds like you're actually facing the same problem we're currently stuck at. It's a kernel-level restriction. The kernel checks lots of flags ("bad", "locked", ... however they're called) that reside in the "out of band" area of the NAND and are stored for each individual memory page. As long as you have a kernel that successfully builds from source, you should be able to remove these checks from the mtd driver, making the kernel erase the pages even if they're flagged "bad" or "locked" or whatever. As soon as you have that, you can erase the pages. Erasure will also clear all flags from that page, so once you get the pages erased, writing to them is trivial.

Our problem is that we're currently having no kernel for our device that successfully builds from source. Because of that, we can't remove the checks from the mtd driver so we can't erase the "protected" NAND. It's most likely the only thing that's still preventing us from S-OFFing the WFS.

Well, actually it takes the device file as a parameter. You can make it patch the HBOOT on whatever partition there is an HBOOT on. You can also make it patch an HBOOT image that resides inside a file. In this case the patching actually succeeds, as the file system allows "in-place overwriting" (or rather hides the fact that the overwriting is actually not in-place :D ) while the actual mtd device must be explicitely erased before it can be written to again and this erasure is still failing due to kernel-level restrictions.