[HTC Wildfire S] no.human.being:
Well actually we haven't hit a wall, we just became a bit distracted. :D

The reason this has slowed down is probably that we (I?) got so "impressed" by the fact that there's lower-level firmware beneath the actual operating systems and wanted to find out what this is actually doing, that we "lost our actual target" a bit. :D

So basically we have to make a decision at this point. Do we want to find out how it works in all detail or do we just want to find a solution that works, even though this may mean we won't neccessarily know in all detail what's actually going on?

If we go on analyzing the processor's low-level firmware and trying to find security vulnerabilities in it (which will certainly be there - every software has its share of flaws :D ) this will be the first one. We will know in detail what is happening on the processor, which piece of code will be executed when and then we put some kind of "hook" into a piece of code and leverage that to disable security (and we'll probably stumble upon the "actual" secu_flag in the process, just because we analyzed it all and see all the nitty-gritty that's going on at the lowest level of the device).

The other option is to take a "higher level" approach that focuses on the major components of the system. The big big weakness in Qualcomm's security system is the fact that it relies on a third-party (and thus UNTRUSTED) component for enforcing security, namely the APSBL, HBOOT in our case. The firmware that loads HBOOT can never know whether it is "authentic" and HBOOT runs on aARM, which is "our" domain, where "we" can execute arbitrary code.

On the HTC Desire Z, HBOOT is loaded to 0x8d000000 virtual, 0x00000000 physical by a Qualcomm firmware component called SBL (secondary bootloader). Now the question is which of these two address spaces HBOOT will see. Probably the virtual one. Remember that HBOOT can load kernels into memory using Fastboot and execute them. The kernels are "untrusted" software images. They are not signed or otherwise secured, since the facility to load them is designed to be used by "third party" developers. Usually they will contain a Linux (Android) kernel and an initrd. Both will be loaded by HBOOT to an address that can be determined in the header of the boot image and then executed.

Remember that we already have a way of dumping the current HBOOT image off the device and patching it to S-OFF. Now what I would do is treat this HBOOT image as a "kernel" and combine it with an "empty" (0 byte) "initrd" using the "mkbootimg" utility from the Android SDK to form a bootable image. Remember that this HBOOT will act like S-OFF and remember that "all major security comes from HBOOT". I don't know who said that, but I think it is a very important fact to realize, since HBOOT is runninng on aARM, over which we have direct control, which is a very weak spot.

So, the boot images are normally designed for loading a Linux-based kernel and initrd into memory and passing execution to it. However, there's nothing that makes a Linux kernel unique. Basically, any code you will stick into a boot image will be executed on aARM in privileged (kernel) mode. Think again! We have the option of executing arbitrary code on the aARM, which means we can do anything that an arbitrary firmware component on aARM can do. HBOOT IS running on aARM, so we can do what HBOOT can do. HBOOT can update "itself" when flashing an RUU. Conclusion: We can "update" HBOOT.

So the process is as follows.

- Put our "inject" utility onto the SD card.

- Boot into CWM using Fastboot and custom kernel parameters that map the HBOOT as a partition.

- Run an "adb shell" session on the phone.

- Mount the SD card inside CWM.

- Dump the HBOOT from the phone to a file on the SD card.

- Patch the HBOOT image to S-OFF using the "inject" utility.

- Load the patched HBOOT image onto the computer using "adb pull".

- Create an empty "initrd" file.

- Combine the HBOOT image and the "initrd" using the "mkbootimg" utility from the Android SDK with "appropriate parametrization" (probably have to tinker around a bit at this point).

- (Modify some bits and pieces in the header of the boot image using hex editor if neccessary to ensure that it actually gets loaded to the appropriate addresses.)

- Boot the boot image using Fastboot. This will temporarily disable security on the device. Hold Volume-Down on the device while issuing the Fastboot command so that the bootloader shows its menu and does not proceed to booting Android.

- With the security disabled bootloader loaded, flash the modified HBOOT image using "fastboot flash hboot hboot.img" to make S-OFF permanent.

I'm gonna try this and see how it goes. We might need to load HBOOT to a different address on our phones though since the 0x8d000000 was for the Desire Z, not the Wildfire S. I think that BeciMester can tell us to which address HBOOT expects to be loaded. Who said we hit a wall? ;)