even case2 is not unbreakable. the keys needed must be stored somewhere.
If the Radio does really intercept all NAND access, it's quite easy to make it unbreakable.
Radio (pseudo-)code:
Code:
#define FALSE 0
#define TRUE -1
char memory_controller_read_nand(int);
void memory_controller_write_nand(int, char);
int is_kernel_running;
__remote_callable char nand_read(int address)
{
return memory_controller_read_nand(address);
}
__remote_callable void nand_write(int address, char data)
{
if ((!is_kernel_running) | (!memory_controller_check_locked_flag(address))
memory_controller_write_nand(address, data);
}
__remote_callable void booting_kernel()
{
is_kernel_running = TRUE;
}
int main() /* This is the entry point to the Radio firmware, mARM begins executing here after powering up */
{
is_kernel_running = FALSE;
while (true)
sleep(5);
}
HBOOT (pseudo-)code:
Code:
extern "C" __remote_callable void booting_kernel(); // This is an RPC handle to the method in the Radio
void load_kernel();
int main()
{
if (flash_ruu) /* If we need to flash an RUU */
run_ruu_flash_process(); /* Actually flash the RUU */
else /* Otherwise */
{
booting_kernel(); /* Radio knows that at this point HBOOT is no longer running and will refuse all access to Radio area to aARM */
load_kernel(); /* This actually loads and executes the kernel */
}
}
Now let's assume aARM doesn't have direct NAND access, so all our kernel can do after it has been loaded by HBOOT is do a remote-call to the "nand_write(...)" method in the Radio to request it to write. Since the Radio knows that a kernel has been loaded, it will no longer pass write commands to pages that are flagged as "locked" to the NAND. Of course it will also intercept the calls for changing these flags. Now you tell me how to break the security even in this "easy" example (which doesn't even make use of cryptography). You can't alter the "booting_kernel()" function in the Radio and also not the call to it in the HBOOT, since both lie within the protected area. ;-)
to come back to the clip: it does no magic. it mimics a probably leaked htc service sim and flashs the diagnostics tool. that does s-off. once s-off you can write supercid.
And the diagnostics tool is original HTC software and therefore signed.
the most important thing is the sim emulator.
Right. The software will check for the service SIM and a SIM card is actually a small microprocessor that will usually talk a cryptographic protocol to authenticate. It will encrypt or decrypt data that is passed through it with keys stored in its internal storage. The keys themselves will not be revealed in this process and the data stream to be encrypted can be randomly generated each time by the diagnostics tool, so eavesdropping on an xtc-clip won't help.
Directly programming which chip? the MMU or mARM via Jtag?
The NAND.
Well, indirectly. With JTAG, you can drive all output pins of a chip in real-time. Manufacturers use this feature to perform what they call "boundary scans". It's basically a facility for testing whether the conductive paths on the PCBs are ok. We take whatever processor the NAND is connected to and use JTAG to drive that one's I/O pins in the right manner to talk the protocol that is used for NAND access (which is probably SPI).
Qualcomm make specific use of protecting access to areas mARM stores security so Jtag can only access 'indirectly' via authentic software or have the keys/signature (forcing use of Jtag blows remaining Q-Fuses making finding the original Q-Fuse sequences even harder)
Lol, they certainly won't block JTAG access. It's too important for repair. Say someone steals a manufacturer's signature keys (e. g. a former employee smuggles them out), then releases a "firmware update" that will always completely lock the NAND, no matter what. If they disabled JTAG access, even HTC's engineers wouldn't have a way of getting a different firmware onto the phone after such an incident. Same scenario if HTC releases an update that just doesn't boot and locks up the mARM. Thousands of "dead" phones with controllers that are fully functional, but have "bad firmware" on them and disabled JTAG access. Hehe! No, you never disable such a thing.
Also, why should they lock it up so much? Ok, you mentioned NFC. This may actually be a security-relevant thing to justify such a protection. However apart from NFC (which our phone doesn't support afaik), it's just protecting intellectual property. You protect intellectual property by preventing your competitors from
looking at it (since they could build a similar device and slap your firmware on), not from
modifying it (they won't buy your hardware, slap their firmware on and sell it again
). So if every NAND access actually had to go through mARM and aARM could not directly talk to NAND, they certainly would filter the reading requests as well on the NAND pages that aARM doesn't have to read (the HBOOT area it has to read, but not the other Radio stuff). The only thing that write-protecting is useful for is preventing accidental (bricking) or intentional (malware) modifications to the firmware. And since your virus-app that you downloaded from Android Market certainly won't have JTAG access, why would you disable the JTAG port? ;-)
Also remember that the mARM runs this Pistachio microkernel (which is basically just a scheduler) instead of a full-featured kernel like Linux. It does so because a complex operating-system kernel will usually do all sorts of stuff, e. g. processing interrupts, that could make it impossible to guarantee timing constraints that might be important to the network. Do you really think that they will "occupy" this processor with forwarding NAND requests for the aARM? (Remember that the NAND interface is quite wideband so there's gonna be
a lot of traffic from the aARM.)
You see it all doesn't really add up. We're probably wrong with our assumption that mARM has NAND access and aARM does not. And at least on the HTC Vision it has already been verified that aARM has direct and exclusive NAND access, while mARM has to RPC the Android kernel running on the aARM for every page access. So it's actually the other way round. Android can intercept Radio's NAND access, which also makes sense from an architectural point of view, since the mARM is a sort of co-processor to the aARM and co-processors usually don't have direct memory access, while the main processor, the aARM, has.
The problem we have is the section 'Block Lock Feature' (p42 of the NAND chip), essentially we can write to NAND with updates, the AMSS or Radio data is write protected on NAND (and I think n.h.b. may have read same things that say the S-OFF is in the Radio or mARM system data as I have) even at boot time whilst the APPS/kernel aARM is not write protected so we can freely install things to a certain degree, if we could find out what, where and how the NAND is 'inverting' the Block Lock we can write in whatever we wanted and possibly simply 'turn' S-ON to S-OFF.
The blocks can be unlocked simply by passing an "unlock" command to the NAND. If we can directly talk to the NAND and mARM is not somehow "intercepting" our communication (and then blocking these "unlock" commands), we will "just" have to implement a facility into the kernel's mtd driver to pass "unlock" commands to the NAND chip, just as it now passes ordinary "read" and "write" commands to the NAND chip. So as long as our aARM has direct I/O to NAND, it's definitely possible to overcome (even though it requires us to really customize that driver and remember we don't have a kernel dev here ;-) ). If mARM can intercept our I/O, well, then they can achieve some goddamn security level. See top of my post.