[HTC Wildfire S] no.human.being:
Can we directly reset secu_flag in Radio partition? Remember that we can now run arbitrary code on aARM in SUPERVISOR MODE. Or does the Radio in fact prevent all access to it from aARM? Remember that the HBOOT can flash the Radio when installing an RUU. Unless the Radio can look inside aARMs RAM, it can never be sure whether "authentic" HBOOT is running there. So if HBOOT is really writing to Radio (not just passing the image to the Radio and Radio flashing itself) we should be able to write there too.

However, I don't know if this is actually neccessary. According to some sources, the Qualcomm bootloaders (PBL, DBL, SBL) verify each other and they verify the Radio, but they don't verify the OEMSBL. That's because this piece of firmware is coming from the OEM. Why should Qualcomm verify a firmware component that's supplied by an OEM? You verify software to ensure that it's trustworthy (e. g. doesn't do harmful stuff). If it's your own software, you can usually be quite confident that it won't do harmful stuff. However, OEMSBL is supplied by CUSTOMERS of Qualcomm. Why should Qualcomm consider customer code (e. g. HTC code) trustworthy? If they reviewed the boot code then this might make sense that they say it's "authorized", however they most likely won't review it.

Revolutionary MODIFIES HBOOT WITHOUT ACTUALLY DISABLING SECURITY. They explicitely stated that they did not manage to gain access to the Radio and the "actual secu_flag". (That means you cannot flash unsigned Radios on a device S-OFFed via Revolutionary? If you could, you should be able to achieve S-OFF by flashing a "hacked" Radio. Or is it that they couldn't flash the Radio because SBL verifies Radio? If this is so, why did munjenji manage to S-OFF a device by modifying the Radio via JTAG?) The signature is just for authentication with the HBOOT currently on the phone. It never gets written to NAND. HBOOT strips it off after successfully verifying it and doesn't write the image to flash at all when signature is invalid.

The only thing that will check these hashes will be the HBOOT itself (the one we chainload, not the one that's on the phone, since the one on the phone thinks that we load a kernel and kernels are not signed) so even if it verifies its own code against a signature, that could be bypassed by modifying the "self-signature verification routine" (provided there really is such a thing) inside the HBOOT image. We can load arbitrary code by this exploit (provided it works), which means we can modify anything. We could even load a bootloader that isn't based on HBOOT at all. We've reached a point where the only thing that HTC could do is disable Fastboot support on the phones entirely. Other attempts to prevent the exploit we currently use will most likely also make booting a Linux kernel impossible and Android is based on Linux so that is not an option.

USB is only enabled AFTER HBOOT checks for PG76IMG.nbh. You can check that by booting to HBOOT with phone attached to computer. It says "HBOOT", then there comes "Checking for PG76IMG.nbh ..." (or something like that) and then "HBOOT" changes to "HBOOT USB". But when loaded via exploit, it restores "old" HBOOT from NAND after checking for PG76IMG.nbh. We need to find the code that causes this and remove it from the patched image. But without JTAG access we can basically forget that. We're going around in circles. We need a debug facility. Why does this MSM7227 have such a damn low I/O voltage? :(