[HTC Wildfire S] no.human.being:
Yep this is great. This routine will definitely play a key part for our further investigation. The plan I have is the following ...

I'd like to dump the device's Flash memory (physically, via JTAG), disassemble its contents (e. g. with objdump, as I'm not familiar with IDA and it actually looks quite "advanced") and find where the ARM starts execution. This is probably a fixed address, might find it in the processor's datasheets. There are no datasheets available for the MSM7227, however, it is a replica of the ARM1136EJS for which there are no datasheets either, but there are extensive datasheets for the ARM1136JS, which is probably similar. Just search for the document "ARM DDI 0211K" on your favourite search engine. It's very extensive, so there's really not much that should be "undocumented" about this processor. :D

Once we know where execution starts, we should try to analyze the "initialization routine" of the processor's firmware, which initializes the uC, loads the vendor specific firmware (Radio, HBOOT) into memory and starts execution. This routine will load the firmware from persistent (Flash) into volatile (RAM) memory and it will probably "pull together" the RAM contents from different parts of the Flash. (Might it already set up some page tables for the MMU at this point?) This is probably why you don't see the "jump table" in the HBOOT image. It's probably not part of HBOOT at all, but from a section that just gets "loaded near HBOOT" into volatile memory during the controller's initialization. (Might it be part of the Radio?)

When we trace the code further through the "jump table" (I'd love to do this on the actual physical device so I really hope that the processor supports single-stepping), we'll hopefully find the actual physical address of the secu_flag. As soon as we have it, the most obvious thing to do is just flick it via JTAG and check whether the device is S-OFF afterwards.

Finally, when we know where the secu_flag resides on the WFS (which means we know its physical address), we can try to find a way to access it from within Android. There's almost certainly some more protection in place, possibly protection via MMU, so we might have to modify Android to set up different page tables during boot process, but once we got that far, this should not be what stops us.

If you have any questions/suggestions, just feel free to ask/propose them.

At least the...

fastboot -c "mtdparts=msm_nand:0x..." boot recovery.img

... works and it does not require S-OFF! However, the ...

fastboot oem listpartition

... fails ...

... INFO[ERR] Command error !!! OKAY [ 0.000s] finished. total time: 0.000s

So yes, we can change the mapping of memory to mtd devices, but we cannot find out how the partitions are laid out on the device (at least not via fastboot, can't we ask the operating system somehow?).

...

Now stop a moment and take a deep breath!

...

Wait! What have we just found out? We can load an arbitrary OS image (kernel + initrd) via fastboot into the device's RAM and execute it! This sounds like the key to total awesomeness, doesn't it? Can't we build an OS image that has just one purpose which is S-OFFing the device (either by asking the Radio to do it, remember it is OUR custom kernel we're executing here so WE can talk to the Radio, or by mapping the memory the way we need it, then doing it directly)?

This may turn out to be easier than we expected it to be. Any kernel hackers here that could aid us in building a kernel that maps the entire memory of the device (this will include the Radio where secu_flag resides) and sticking an initrd to it that does the S-OFF? Of course we'll still need to find the flag in memory, but at least we now have a concrete plan how we can map the memory in. This will also enable us to build a very "user friendly" utility for S-OFF. No more zergRush, no more privilege escalation. The S-OFF utility is a self-contained OS image. You boot it, it does all the work and reboots the phone when done. How cool is that? :D