[HTC Wildfire S] no.human.being:
Nope. The JTAG is required for locating the secu_flag in memory only and it works on hardware level so firmware is totally irrelevant. Disabling the device security will NOT be done via JTAG but via software only. We want a software S-OFF, S-OFF via hardware is already possible using xtc-clip and a JTAG interface is at least as expensive as an xtc-clip, so this would not be of any use.

However, when a stock Android kernel boots, it "unmaps" some memory areas that are to be protected. The secu_flag resides in the Radio firmware and this is an area which has very high protection so the first thing Android does while booting is crafting a "copy" of the secu_flag in volatile memory (RAM), then mapping the Radio area in the persistent memory (Flash) out using the processor's MMU. This means that as soon as Android is booted, we can no longer access the persistent memory area where the secu_flag resides and therefore flipping the flag in persistent memory from a process running on top of Android is impossible (or at least extremely difficult, one could try to somehow perform an exploit that maps the memory back in, but ... just forget about that, it's impractical, as we have a much better solution on which we've settled now). We could only flip the copy in volatile memory but this would not be of any use as it would not persist reboots and S-OFF is only useful for booting into HBOOT so "temporary S-OFF" is not something that's useful. :D

Because of this, I decided to build an alternative kernel and settled on a Linux kernel (why should I use an Android kernel for it? by using a Linux kernel we can be sure that there are no artificial restrictions in place that Google might have put into their kernels). I've managed to load custom kernels and initrds into the device's volatile memory (RAM) via USB while the device is booting and get these kernels executed. (LOADING A KERNEL THIS WAY DOES NOT REQUIRE S-OFF!) So the plan is building a Linux kernel for the device and an initrd which contains the program which flicks the secu_flag and possibly some libraries and a script which executes that program and then reboots the device back to stock firmware when done.

This will be a really "self contained" experience. All the user will have to do is connect the device via USB to its host computer, load the kernel/initrd into the device's RAM (we might even create a script that automates this) and then our firmware takes over the handset and disables security. This will be at least as simple and convenient as S-OFF via Revolutionary.

EDIT: Ok, I got a Linux 3.2.5 kernel built for our phone. It took lots and lots of tweaks to get it through, but now I have it. I can also boot it on an S-ON device. The device will just lock up when I do this and display a white screen.

EDIT2: What I've tried so far ...

$ make distclean
$ make ARCH=arm menuconfig

General setup --> Cross-compiler tool prefix: "arm-none-linux-gnueabi-"

System Type --> ARM system type --> Qualcomm MSM

Boot options --> Auto calculation of the decompressed kernel image address

Device Drivers --> Input device support --> Touchscreens --> EETI touch panel support (DISABLE!)

Device Drivers --> SCSI device support --> DISABLE EVERYTHING HERE!

Device Drivers --> USB support --> EHCI HCD (USB 2.0) support (DISABLE!!)

Floating point emulation --> NWFPE math emulation --> Support extended precision

Security options --> NSA SELinux Support (DISABLE!!)

Enable loadable module support (DISABLE!!)

I've configured lots of other stuff. Mostly disabled things that one will never need on an embedded system and moved stuff from modules directly into the kernel.

$ gedit arch/arm/mach-msm/vreg.c

Add: "#include <linux/export.h>"

$ gedit include/linux/mtd/map.h

Comment out the call to "BUG()" function in line 408, so "BUG();" --> "/*BUG();*/;" (note the trailing semicolon!).

$ gedit drivers/net/ethernet/stmicro/stmmac/mmc_core.c

Comment out the call to "pr_debug(..)" function in lines 142, 143.

$ make ARCH=arm uImage

If will return error: "mkimage" command not found - U-Boot images will not be built <<< THIS IS NORMAL!

Kernel image is now under "arch/arm/boot/zImage". Make modules.

$ make ARCH=arm modules

In our case this should return an error because we don't have statically compiled everything and didn't make use of modules. Prepare the initrd, then make boot image.

$ mkbootimg --kernel arch/arm/boot/zImage --ramdisk ramdisk.gz --cmdline "init=/init mtdparts=msm_nand:0x20000000@0x00000000" -o kernel.img
$ fastboot boot kernel.img

Device will lock up. The "/init" process contains code doing a "printf(...);" call and the output isn't shown either. Don't even know if the phone gets that far, as I'm simply not seeing anything.

Might be a real breakthrough or might be not.