[HTC Wildfire S] no.human.being:
The "patched HBOOT" is like a Revolutionary HBOOT. We didn't find this by reverse engineering their HBOOT though. It just turned out this way. The HBOOT reverse-engineering was done by beci_mester, who, at some point, released a "patch" for the HBOOT which turns it S-OFF. Later he noticed that Revolutionary do in fact patch the same routine, so it appears to be the most obvious way of turning a phone S-OFF, since we started "from scratch", but came up with the same solution. Because of this, almost all you know about a phone that was turned S-OFF by Revolutionary, also applies to our method, as both perform the same changes to the phone's boot code.

What's different however is the way we execute the patched HBOOT code. Revolutionary temporarily roots Android via zergRush, then somehow makes the Radio memory accessible from within Android. There's a very obscure algorithm that appears in some repositories. It uses two pointers called "needle" and "haystack" to poke around in memory and probably somehow disable the MMU, but it's for the MSM8255, not the MSM7227. This is probably the reason why Revolutionary doesn't support the Wildfire S. Whatever weakness this algorithm exploits, they probably never got it working on the MSM7227 and they never looked for a radically different way, but gave up instead and said that the MSM7227 was crap (because it wasn't vulnerable to their exploit lol).

What we do is a different thing. We execute a little exploit code that writes a modified bootloader into page zero, then modifies the application processor's state so that it appear as if it was just coming out of reset. The bootloader will execute and display its version information and menu, but then restore the original bootloader from NAND. It has the routine modified that queries the Radio for the secu_flag status to always return zero immediately. The idea is that the bootloader performs all updates. This includes updates for the Radio and the bootloader itself. Signature checks are only performed when the secu_flag is set. So once we can load a bootloader on the phone that thinks that the Radio returns zero when queried for the secu_flag, we can install custom Radio and boot code.

Once we can prevent HBOOT from "falling back", you just perform the exploit on the phone and do nothing else, S-OFF will be completely temporary, which means you'll be back S-ON on reboot. However, you could boot the phone into the bootloader right after the exploit was performed by holding Vol-Down and then you could write the patched boot code to flash using fastboot command. S-OFF will then be "permanent" until you (or an RUU) flash(es) a "stock" HBOOT.

Remember that you cannot downgrade HBOOT below 1.03.0000? There's probably a routine that checks "is downgrade to this version allowed?" and then returns true or false. If we could modify this check to always fail, we could create an "indestructable" HBOOT that could (almost) never be overwritten (almost, since the Radio is more privileged than the APSBL so it may still overwrite it) so that S-OFF is actually very very "permanent". However, S-OFF is there to give the user total control over the system and in my opinion this definitely includes the right to modify boot code, even if this turns security back on or hardbricks the device. "Protecting" our own boot code is therefore probably not a good idea. Even though it's technically possible, it defeats a lot of the purpose of S-OFF.