[HTC Wildfire S] no.human.being:
The inability to modify the Radio code on the MSM7227 (ARM11) is not a kernel-level restriction. It's below that. All code on what you think is the processor (including the boot code itself) in fact runs as a "guest" inside a virtual environment ("class zero hypervisor") on top of another Unix-like operating system that's called Iguana, which is the "host". All transceiver (Radio) functionality is provided by the host (Iguana) and therefore inaccessible to all "vendor-specific" code, including APSBL, which all run as a guest. We don't know how the APSBL manages to flash the Radio, but it's probably an "indirect" mechanism, which means that the APSBL has a "communication channel" to give the update to the hypervisor, which then gives it to Iguana and Iguana installs it. The "weak spot" is that the APSBL is most likely doing all the authentication (signature checking updates), so if you can modify the APSBL to always "pass" signature verification, you can give "unsigned updates" to Iguana, which will then install it without further checks, since the APSBL, which is a lot like a "root of trust", has already commissioned it.

An encrypted archive containing the exploit's source code (yes, it's actually assembly, we had to go THAT low :D ) is attached to this post. The key comes to you via PM.

I assume that you are building on a Linux host (procedure should be easy to adapt to Windows if neccessary, but concatenating binary files, etc. is a very quick and simple task on a Linux shell) and have a working "arm-none-eabi" toolchain for supervisor-level code. Do NOT use any toolchain which has "linux" in it, e. g. "arm-none-linux-gnueabi", as these produce user-level code that runs on top of a Linux kernel. We want to produce supervisor mode code here, which runs without an operating system underneath.

The "mkbootimg_wfs" that's mentioned in the exploit code's comments is a modified version of the "mkbootimg" utility from the Android SDK that produces valid boot images for the Wildfire S, where the memory layout generated by the standard "mkbootimg" utility doesn't work. The standard "mkbootimg" utility from the SDK takes more parameters. Ask a dev who develops kernels for your phone for "safe" values.

The value "load_addr" is the physical memory address where the shell code lies when the exploit starts executing. It's the value of the "kernel_addr" field in the boot image that's used to boot the combined exploit and shell code PLUS the size of the exploit code itself (which is 0x88 or 136 bytes if you do not modify it). The "kernel_addr" is usually not the same as the kernel image's "base address". Inspect the boot image with a hex editor to find the correct value. It's a 32-bit value starting at offset 0xc. Remember that all values are little-endian so you have to read the bytes from the highest to the lowest addresses but the digits inside the bytes are in correct order, so the bytes "01 ab cd ef" represent a value of 0xefcdab01.

The value "execute_addr" is the physical memory address where the boot code lies. It's a physical address of zero for the MSM7227 and this probably applies to all ARM processors, so leave it at zero unless you have good reason not to.

The value "length" must be set to the size of the payload you want to execute. It's usually 0x80000, which is exactly 524.288 bytes, which is the size of the WFS HBOOT partition. The size must be a multiple of four, which is ARMs native word size (4 bytes = 32 bits). It it's not, it's treated like it was rounded to the next multiple of four (so a value of 0x80001 will behave like 0x80004).

Good luck pal! For testing, you may try taking a known working HBOOT image (e. g. one extracted from an RUU), then modify some uncritical value (e. g. a version string that is displayed by HBOOT), stick it as shell code to the exploit, then use the combined exploit plus shell code as a "kernel" and use it, together with an empty (zero byte) ramdisk, to form an Android boot image. Put the device into Fastboot mode, connect it to the computer via USB, then execute the image using "fastboot boot ..." and check if the change appears in the device's boot menu. Hold Vol-Down quickly as soon as you issue the "fastboot boot ..." command to the device, otherwise the modified bootloader will just boot the device into the ROM like every bootloader does when the device appears to come out of a reset.

Please report back if it works.