[HTC Wildfire S] no.human.being:
Our exploit is a "kernel" (from the bootloader's point of view). It moves the "shellcode" (patched HBOOT that's attached to it) over to physical page zero, then executes some "preparation code" (I tried to put some code in there for disabling the MMU and caches and stuff so that it's more like "processor coming out of reset" but it still falls back), then jumps to physical zero.

I'm actually very certain that there's such a thing in HBOOT and here's why.

If I overwrite the HBOOT in RAM with lots of no-operations and a jump to physical zero in the end (so basically a veeery large endless loop to make sure that HBOOT is completely overwritten) the endless loop will run forever, just as you'd expect, even though the boot code in RAM is "as damaged or modified as it gets".

So it's not that there's something that periodically checks whether a "proper HBOOT image" is in physical page zero and if not "stops the running code", restores it from NAND and executes it again. The only piece of firmware that could do this is the Radio or MicroP. It definitely cannot be anything running on aARM except HBOOT itself, since you cannot "preempt" the boot code to execute something else. And I doubt that the other processors periodically look into aARMs RAM. Also if there WAS such a thing, why would it regard a modified HBOOT as "unusual" and restore the original HBOOT from NAND while it would not regard "512 KiB of no-operations in physical page zero with a jump back at the end" as unusual?

EDIT: To clarify this a bit more, I'm not certain that it's actually "HBOOT restoring itself" (even though I find it very likely - I'm gonna explain why), but it's almost definitely HBOOT that "issues" the restore. Say it finds out "oh, my code is not how it's supposed to be" and then jumps into SPL and SPL loads HBOOT again. This is also a possibility. What we can always suppress is the "HBOOT finding out that it's modified". This way, it doesn't matter how the restore actually happens. However, the SPL-thing is more unlikely than the "HBOOT restoring itself" scenario. SPL is not running on aARM, so it's way more "out of reach" for HBOOT. HBOOT would have to call REX and then REX would have to go through SPL again. Sounds like a lot of unneccessary complexity and indirection. Think Occam's razor. The simpler the theory, the more likely it's to be true.

No almost certainly not. The MMU is disabled when a kernel is booted and even when I explicitely disable the MMU and caches again in the exploit code itself before running the shell code, it "falls back". HBOOT is run from the first instruction (physical zero) so it will set up the MMU again. Linux kernel does the same. When loaded MMU is disabled and then it sets up the MMU. Nothing special. Nothing that should look in any way "unusual" or "suspicious" from the point of view of any other firmware component.

There are two MMUs, one for RAM, one for NAND. They are different pieces of hardware on the chip. Our code is running in supervisor mode so we have control over the MMU. (Or does mARM control the MMU? That would mean that HBOOT would always have to RPC the Radio for permission to access something.)

EDIT: @BeciMester: Btw, this is the thread that mentions S-OFF for HBOOT-0.90.0000 via RUU (there were other threads about it as well but I didn't find all of them). You need to install the "Radio_special_MARVEL_MR_47.23b.35.3035_7.54.39.08M_Signed_20111208.img" ("rom_01.zip" from the RUU), but not the the corresponding HBOOT ("rom_02.zip" from the RUU). Of course I'd not suggest to interrupt the RUU by pulling the battery like the OP in the thread did, but just run the RUU, keep the window open but do not continue, then go into your Temp folder and look through the folders for a file called "rom_01.zip", then install it by renaming it to "PG76IMG.zip" and putting it onto the SD card (or via "fastboot oem rebootRUU" and "fastboot flash zip PG76IMG.zip" - no idea if HBOOT-0.90.0000 already supports this, probably not). Do NOT install "rom_02.zip" since that one (or for that matter any other HBOOT update) will make the phone S-ON again. This ONLY works on HBOOT-0.90.0000.