[Android Software Development] no.human.being:
If he actually found a way to flash an HBOOT then it's at least a very important step to S-OFF. If you modify the right instructions inside HBOOT you can achieve S-OFF.

I really don't want to discredit your work, but this is probably far from "universal". In fact this will probably never work on most devices, will it?

The reason I want to know is that I'm part of a developer team that's on track of creating an S-OFF exploit for the HTC Wildfire S and I can tell you that you definitely cannot flash an HBOOT from within Android on this device (and probably most other devices), even if you are root. The bootloader is in a special Flash memory area that we call "unmapped memory". We call it "unmapped" since Android normally doesn't even know that this memory exists and it therefore has no "address" within Android's "address space", even though with some tricks you can assign one to it if you really want. I'm gonna explain this in a bit more detail.

Below Android (and in fact the bootloader) there's an entire other unixoid operating system called Iguana. It's unixoid but it's not Linux, even though it seems to share a great deal of code with it. On top of that runs a hypervisor and on top of that runs the bootloader and Android. Think of it as the entire firmware running inside "VMware", even though the virtualizer in Iguana is of course much more lightweight and specialized than a virtualization solution for a PC. In order to flash the bootloader, you have to "break out" of that virtual environment, which is what we currently try. The reason is that the bootloader itself when it's executed is only a "volatile copy" (so a copy in RAM) that the virtualization software loaded from a "file" (there's probably not actually a full blown "file system" though) in Iguana and moved into the virtual machine's "virtual RAM" before boot. Getting at the actual "persistent version" (the bootloader "file" in Iguana that resides in Flash memory) is extremely hard since it lives outside that virtual environment and is therefore "out of reach". In fact the persistent copy can be accessed through the "unmapped memory" region I mentioned. However, you can only read there. All write attempts to this memory region from within the virtual environment are trapped by the hypervisor.

The major weakness in that system is that all firmware updates are received from WITHIN the virtual environment and then somehow "transported out". This includes updates for Iguana itself. I'm convinced that we can use this fact for "breaking out" of the virtual environment. If we succeed, then we can probably even replace Iguana and the virtualization software itself, but I can tell you it's very hard, though probably not impossible. But it's definitely not an easy task. We're literally working on this for MONTHS. In fact we have seen the phone become S-OFF but the problem is that it always "falls back" to S-ON before you can do anything useful (like flash something). There's probably some component that recognizes the exploit and restores the virtual machine to a "known good state".

On which phones does your tool work? Do they lack this virtualization layer?