[HTC Wildfire S] no.human.being:
Meh, we're turning in circles.

The "known good status" is very very likely the contents of the HBOOT partition in NAND. All partitions with a lower address than "boot" are under mARM's control. Remember that what you achieve by S-OFF is you disable signature checks so you can flash unsigned code to partitions that are under mARM's control. These partitions are protected by an MMU, which means they're protected on the hardware level. Only mARM can configure this protection. And mARM is fully trusted, so we can't tinker around with it, at least not by means of software. However, since all firmware updates (also those affecting mARM) are performed by aARM, aARM must have a way to request mARM to disable the MMU protection. We have absolutely no clue how this is done, but we know that APSBL can do it, so we let APSBL perform all firmware modifications.

Now to achieve S-OFF, we have created a patched APSBL binary that has signature checks disabled. We've discovered a vulnerability that lets us temporarily execute unsigned boot code on aARM. We use this vulnerability to run the patched APSBL. This basically means we're able to let aARM boot from untrusted code that's not even stored in NAND. The major weakness that we exploit is that the signature check itself is performed on aARM (where we can execute arbitrary code and which should therefore not be trusted).

When we run the exploit, the phone basically becomes S-OFF for a short period of time. But one of the first things that APSBL does is look into the HBOOT partition in NAND and compare its own code to the version that's stored in NAND. It recognizes that the two don't match and then "reverts" (either reads the version from NAND and overwrites itself with it, then jumps back to zero - or just invokes the SBL again - remember SBL loads APSBL from NAND into RAM and then jumps into it, so that would be a perfect fit). After this "revert", the original (signed) boot code is running on aARM again, which puts the SoC back into a secure (locked down) state.

From this point we can run the exploit again and again. It's still vulnerable. But it doesn't help. It always reverts before it lets us do anything useful.

Not a transformer, since it's not really "AC". It's not "DC" either though, it's a pulsed square wave. Logical high = 0.9 V, logical low = 0 V. You could do the level shifting by putting two inverters into each JTAG line. After the first inverter the signal is - well, you guessed it - inverted (this basically means all zeroes and ones are swapped) and the second inverter puts it back to normal.

I hear you asking why invert it only to invert it again? Well, the inverter is the most simple logical gate and logical gates shift logic level. Two inverters = two transistors (and two resistors). There's no circuit that will do it with less, so you use two inverters. ;)

Yes, exactly. Just that we're on the hardware level so it will "freeze" the "program" (well, actually the entire processor) at each machine instruction or each clock cycle. You can imagine single stepping a bit like manually turning the clock signal of the processor high and low. I'm pretty sure it's not how it is actually done, but it behaves a lot like if it were done this way. Actually it halts the processor in the instruction decode stage, which comes after the instruction fetch and before the execute stage. So this means it halts the processor when it already knows what to do, but before it has actually done it.