[HTC Wildfire S] no.human.being:
During bootup sequence, the software is executed in the following order.

1. PBL (primary bootloader) from 0xffff0000 (physical address, so not an offset into an mtd)

2. DBL (device bootloader)

3. OSBL (operating system bootloader)

4. REX (radio executable)

5. AMSS (advanced mobile subscriber software)

6. APSBL (application processor secondary bootloader) aka HBOOT

7. Android kernel

1 - 3 are firmware components created by the processor designers (ARM Ltd. with modifications by Quallcomm) and are designed to verify each other's signature so that a modification to one of these components will interrupt the boot sequence. This performs low-level stuff like initialization of processor registers and is something I really don't want to tamper with.

4 and 5 are designed by NICTA (an Australian research corporation) and probably licensed by Google. Android contains bindings for talking to these software components so they are probably part of every Android installation deployed to a physical device.

6 is HTC's proprietary version of the Android "reference design" bootloader by Google.

7 is GPLed software by Google.

When our exploit takes control, we're already beyond step 7, but what we have to influence is probably either step 4 or step 6 and these are already through. So we'll have to reboot and you can expect the contents of volatile memory to get lost while rebooting, so we'll have to do it in the NAND. Even when HBOOT gets decompressed into RAM, we'd have to modify it before it gets executed. We have no chance of getting any code executed at this stage other than writing to the NAND.

Another complication is that Android, as a POSIX system, makes use of memory protection, so you can't read/write from everywhere in the RAM. Instead, you are quite restricted to the virtual address space of your own process. In fact there's also memory protection on the ROM, which is why Revolutionary probably couldn't directly write to the Radio, but it is much less fine-grained and leaves a lot exposed (e. g. the entire compressed HBOOT code).

---------- Post added at 12:45 AM ---------- Previous post was at 12:10 AM ----------

Well we'll have to find the code that checks for the Goldcard and special SIM and disables the security. When disabling the security via xtc-clip, HBOOT will output something like:

"Jumping to DIAG..." (directly after it was booted with the xtc flex inserted)

"Get SW Version" (this output stays for ~ 1 minute 30 seconds)

"Get OEMSBL fail!"

"Pls chk SECU-Flag on/off"

"Press PWR to exit" (this output stays until you press the power button)

"Waiting for GSM ready..."

"Power *) Reflash"

"Volume *) DIAG" (this output stays until you press the volume down button)

"Clear S58" (this output stays until you press the power button)

"Unlock SimLock and SECU_FLAG by SmartCard OK" (the phone is S-OFF at this point)

So the special SIM is probably queried before "Jumping to DIAG..." (because it won't enter into this at all without the xtc-clip connected to the phone) and also after pressing the power button after "Clear S58" was printed out, as the LED on the xtc-clip will blink when you press the power button, so there is probably some action going on at this point. If you can find where this is output, we might also be able to find the routines that query for the special SIM.

@*se-nsei.: I don't agree that the main problem with unlocking via HTCdev is losing the warrenty. I think it's pretty common for a manufacturer to drop support once you start using its products out of specification (and bugs or "tweaks" in custom firmware can really damage the hardware on embedded systems). The main problem is that HTC won't unlock the bootloader on SIM-locked devices.