Lpc2000

Hi Richard,

My understanding is that like in other such devices, the GPIO pins are
sampled and copied on to relevant enable/disable bits during the reset
cycle before any code gets executed.

This is the method by which you can configure "virgin" devices to boot
for external memory, or enable JTAG even if the default behaviour is
that out of reset, external memory interface and JTAG are disabled.

This suggest the code to force these bits low is there to try and
mitigate security risks under these circumstances.  So unless have
information about these techniques (which Philips no doubt has) it
would not be easy for just anyone to do this.

If Philips had the fuse concept (like in ATMEL AVRs), this would have
been stated in the manuals (like ATMEL did) and that would make the
LPC part a candidate for security devices.

I do not mean to cast doubts on the ability of this audience.  However
the fact that nobody has defeated the security features says nothing
at all in the security context if methods are kept secret.

In other words, to trust LPC for security needs, one also has to trust
not only Philips but the many employes (and contractors) engaged by
Philips, past and present, who have access to this secret.  This is
the core argument against security by obscurity.

Jaya

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:
> The other possibility is that they blow a fuse 
> after programming the bootloader into the virgin device.
> I don't think they would leave a backdoor when they go
> to all the trouble of implementing the CRP.

> According a past thread, nobody succeeded in starting 
> debugging directly after reset. The answer from
> philips_apps was that this was to implement the CRP.
> I have seen enough evidence to trust philips when
> they say there are no backdoors.
>