[HTC Wildfire S] no.human.being:
Yes, this is exactly how I'm feeling as well. :D

My goal is "chainloading" an HBOOT image as a "kernel" via Fastboot. If we can do this, we can "chainload" a patched HBOOT that will disregard security and use this "chainloaded" bootloader to write the modified HBOOT to NAND since the "chainloaded" bootloader won't check the signature of the image. HBOOT knows how to "authenticate" with the Radio to get the NAND unlocked.

So basically the strategy is as follows:

1. Boot the "original" HBOOT on the device into Fastboot mode.

No magic here.

2. Load a "patched" HBOOT that does not check signatures into the device RAM via Fastboot.

This is where the magic happens. Code that is loaded into RAM by an unlocked bootloader does not have to be signed and we already know how to unlock the bootloader. Bootloaders can load other bootloaders. This is known as "chainloading" and is perfectly legit. For example when you run Windows on a dual-boot system with both Linux and Windows installed, GRUB, the bootloader of Linux, is unable to directly load a Windows NT kernel. Therefore GRUB will "chainload" NTLDR, the bootloader of Windows, which will in turn load the Windows NT kernel. Of course once we have the "patched" HBOOT loaded, it will accept Fastboot commands. Since the bootloader we have just "chainloaded" will not check signatures, we will have something like a "temporary S-OFF".

3. Talk to the "patched" HBOOT we have just chainloaded via Fastboot and make it "flash itself" into NAND.

This will disable signature verification on the device until you decide to flash an HBOOT image with the signature verification intact (who would do such a thing?), effectively making the S-OFF permanent until you decide to "revoke" it. Basically once that step 2 is done, not too much magic here.

The problem is that when you try to "chainload" a patched HBOOT image via Fastboot, the phone will vibrate two times and then boot into your ROM. I suspect that the "chainloaded" HBOOT gets executed (first vibration), but somehow recognizes that there was already software executing before its invocation and then enters some kind of "fallback mode" where it issues a fresh reboot from NAND with the original HBOOT (second vibration) which in turn loads the ROM.

Now what we have to do is identify the code that does this recognition and modify it in a way that it no longer recognizes that we've tampered with it. So basically we have to modify the HBOOT code further so that it no longer prevents this kind of tampering, which means more reverse-engineering and an "inject" utility that performs more modifications to the HBOOT code. Our utility so far seems too "non-invasive". HBOOT is still "too aware". We have to "cripple its senses" a bit more than we already have to get where we want to go.

The problem is that, even though the bootloader code is definitely not too "sophisticated", reverse-engineering from raw disassembly is still very hard. It would be very helpful if we could "single step" through the boot code on the actual device using JTAG. "In theory" we could do it without JTAG access, but it's basically "brain surgery with a blindfold" and the way to remove the blindfold is to get JTAG access to the device. However, this requires custom hardware that is not easy to build. We need this just for development. Once the "inject" utility is working, we should be able to unlock devices without JTAG access (or any other hardware means).

Let's see how far sythe179 gets with the analysis of the HBOOT code. So far, the archive has not been downloaded which means he hasn't grabbed the code yet.