[HTC Wildfire S] no.human.being:
The "exploit" and the "inject program" is the same. :D

Hehe, this one makes me laugh! It's probably one of the greatest understatements I've ever heard. :D

It's not a theory pal, it's work in progress and so far it has turned out to work astonishingly well. It's just that it's not finished yet, but we basically know what we have to get done in order to get it finished, we're just not completely through with it yet.

We managed to find out how the security works. We managed to find out the partitioning of the device. We managed to find out how to provide an alternate partitioning via Fastboot in order to map the Radio partition. We dumped the Radio partition from lots of devices and analyzed its contents to find where HBOOT resides. We reverse-engineered different HBOOT images so that we know which subprocedure checks the security. We created a replacement for that subprocedure that will make the HBOOT "believe" that it's S-OFF. We created an exploit that can automatically analyze an HBOOT image and patch it in memory. We tested this exploit on HBOOT images residing on a file system (the file system will provide you with the impression that you can overwrite in-place, while it internally handles all the physical nitty gritty) and it works. We built a custom set of "mtdutils" for our device. Another "subdivision" of us is working on getting the HTCdev bootloader unlocked (we need that for using Fastboot on the device) without the token from HTCdev by patching around in the device's "misc" partition.

All of this works. The thing we're stuck at is a restriction that resides in the mtd driver of the kernel we're booting (currently we're using CWM recovery). What we need now is a kernel developer that can help us get a custom kernel built for our devices. Once we got that, boot it, take the exploit, run it. Chances are your phone's gonna be S-OFF afterwards. We're 95 % done and we basically know how the final 5 % look like that are still missing. It's far from being "theoretical". It's just that one piece of key knowledge (the expertise of a kernel dev) is still missing.

So far I didn't manage to build CyanogenMod kernel from source and get it running on the device. Part of the problem might be that CyanogenMod is designed to run off the device's NAND, so it might try to map NAND partitions, loading kernel modules from there etc. What we need is an operating system that is fully self-contained (only consists of kernel + initrd and requires nothing else). CWM is such an operating system, but CWM is not open-source.

I invested a lot of time building a "self-contained" operating system based on a Linux 3.2 kernel with a minimal GNU system in the initrd, but it always locked up the device with a white screen when booted via Fastboot, so I eventually gave up. Might try it again with the Linux 3.3 sources, but it takes time, lots of time. Download kernel sources from kernel.org and they're ALWAYS faulty and NEVER compile out of the box. You literally have to skim through dozens of source files modifying hundreds of lines of code until the source is finally in a state that it successfully compiles. Quality control at kernel.org seems to be

extremely

bad. I've read lines like the following in official Linux sources from kernel.org.

int, a, =, 5, ;

Well of course it generates a compile error. It's clear that what's really meant is.

int a = 5;

Change it to that and the error resolves. There are

hundreds

of errors like this (and unfortunately also some that don't have such an easy fix and require more time or sometimes aren't resolvable at all, then you just have to grab another kernel release and start over again) in a release from kernel.org. This is why it's an

astronomous

amount of work to build a kernel for the device from source. I've done it once with Linux 3.2, thoroughly resolving all the errors, configuring it for our device, building an initrd for it, integrating it all into a boot image but it always locks up the device with a white screen. The device won't react to anything. All you can do is pull the battery.

We really need more expertise in here. "Trial and error" will not bring us forward, as the amount of work for each try is extremely high and the chances of success are probably rather small as long as you're not absolutely sure where the problems reside.