Lpc2000

Hello,

On Friday 23 December 2005 15:43, Felix wrote:
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
> > Thank you for confirming JTAG is enabled upon reset before any code is
> > executed in a "virgin" device.  This confirms what my client has been
> > telling me all along.
>
> i think you're mixing 2 things --- JTAG after reset and JTAG on
> "virgin" device.
>
> 1) according to user manual '0x00000000' is written into every
> pinselect register when reset is low, thus switching JTAG/GPIO pins
> into GPIO mode Inputs.
The reset state of pinsel2 (the one responsible for jtag) is detailed in table 
62. Bit 2 is determined by the state of pin1.26/rtck on the rising edge of 
reset. If this pin is driven low when the device comes out of reset, the jtag 
port will start enabled. That's why they're setting it to zero as early as 
possible. The JTAG statemachine is held in reset while the system reset is 
driven low, which is why the lpcs can't be debugged out of reset. Depending 
on when the debug logic is released from reset, a criticial timing issue 
could enable an attacker to force the device into debug mode before the 
bootloader had a chance to disable JTAG. Programming the debug control 
register to force the target into debug state takes 71 TCK cycles, or 24us at 
3MHz JTAG frequency. Of course, this is pure speculation, as the user manual 
is a bit unclear about the state of the test logic during reset. It is likely 
that because of the restrictions of -S arm cores (synchronize TCK with MCLK) 
this attack isn't possible.

> 2) i assume that "virgin" device behaves different with GPIO, this can
> be done using simpliest 32 AND gate circuit.
The virgin device has no bootloader which could disable the JTAG port, so JTAG 
comes up enabled, if RTCK is driven low.

>
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
>   If there is such possibility -- then i consider this CRP unsecure,
> and  not effective enough.
I haven't checked the bootloader updating mechanism yet - maybe the updates 
are digitally signed, and the IAP calls only accept updates with a valid 
signature?

> Dixi.
>

Regards,

Dominic