Lpc2000

I will try to respond to this post without repetition of issues
already discussed, and conclusions drawn some time ago when this
thread was hot.

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
> I have a commercial interest in ensuring my code is not stolen, hence 
> I am keen to determine if there is any basis for reasonable doubt of 
> the claims made by Philips with regard to CRP.

I did some poking around into the boot loader for completely different
reasons.  I have made no secret of the a few things that found in the
process that makes one doubt the veracity of the claims by Philips in
relation to CRP.

> The web site falsely claims the 'first thing' the LPC2148 
> bootloader does is to disable the JTAG debug port. The claim is false 
> because the boot loader does two 'other things' first. The 'third 
> thing' is to assign 0 to VPB register PINSEL2, which simply enables 
> port 1 pins solely for GPIO use and cuts off access to JTAG debug and 
> to trace. I will pose a question, why make false claims?

What does "thing" mean?  One instruction?  Could it be that the author
has a higher level view of the structure of the boot loader and refers
to all your three instructions as just one "thing"?

I certainly have disassembled version 1.62 boot loader on my LPC2292
and have a good idea of how it is organised.  I would (probably) have
said exactly the same thing.

> The first three ARM instructions assign 2 to VPB register MAMCR.
> The next two ARM instructions assign 3 to VPB register MAMTIM.
> The next three instructions assign 0 to PINSEL2 using a SWP command 
> and stores the prior value of PINSEL2 in R0
> 
> It is trivial to skip over the SWP command to avoid becoming 
> disconnected from the JTAG.

This is IMO the core weakness of the CRP method used by Philips
compared to other methods like fuse bits used by ATMEL.

> The next two instructions swaps 0 with the contents of undocumented 
> VPB register 0xE002 C03C into R1.
> 
> The first three bits of the old contents of PINSEL2 in R0 are cleared 
> when copying into R3 and R3 is stored back into PINSEL2. This 
> instruction can also be stepped over to avoid disconnecting the JTAG 
> port.
> 
> The next instruction jumps to address 0x00FF D1C0, which due to 
> remapping probably refers to address 0x0007 D1C0.
> 
> Instructions following read the contents of flash memory address 
> 0x1FC and store it to the read only register (as documented) CSPR 
> (Code Security Protection Register) with one exception. If the 
> contents of the memory address 0x1FC were 0x43128765 then 0x87654321 
> is stored instead. Hence for the LPC2148 there are at least two valid 
> code read protection values: 0x87654321 and 0x43218765.
> 
> I did not investigate any further, there is no need. The content of 
> R0 and R1 have been retained up until I stopped investigating.

It is worth investigating in further to understand why many (in my
position) would not rely on claim by Philips in relation to CRP.

> There is nothing in any of this sequence that justifies reasonable 
> doubt about Philips claims.

I can think of the obvious one -- what happens if the attacker is able
force and exception to be taken that forces the sequence to be entered
not at the top?

> While I could find out how many cycles are required to make JTAG 
> attempt to assert an internal debug signal, I know is not a trivially 
> small amount.

This is where your problem is.  You should find out exactly how many
cycles are required.  There are good reasons for doing this:

1/  There is no reason to execute the three instructions at the
locations reserved for vectors.  In doing so a vulnerability has been
introduced that could break CRP, namely that an attacker can force and
exception and jump to somewhere other than first instruction.

2/  Bootloader implementors could have moved this code to the real
start of the boot loader where it initialises LPC Limit Register (to
limit size of on-chip RAM and ROM) by leaving the vector as it is.

It appears that they chose not too do this for good reasons.  It is
quite plausible this reason has to do with how quickly JTAG interface
could be used to take control of the core.

> For the LPC2xxxx series only one JTAG cycle is allowed 
> for six processor clock cycles. Number of cycles required can be 
> assessed from examining open source JTAG code. Open source JTAG code 
> has its origins in code written by R Longo in 2000 for an Atmel ARM 
> processor. Atmel also has JTAG code (under NDA), which it is possible 
> to view without signing an NDA.
> 
> Even if there was no disablement of an internal debug bus signal 
> pending writing to CSPR, it is possible there are simply not enough 
> clock cycles avaialble to assert an internal debug signal.

Others argue that it is likely there are more than enough clock cycles
available, or the boot loader implementors would not have resorted to
trading off exception handling at the expense of a branch instruction.
 
> In 
> addition claims that the supposed evidence is the 'first thing' done 
> is false.

See above -- it looks like your interpretation of the claim is wrong.

> In addition claims about stack overruns etc in the bootloader are 
> irrelevant as all such claims involve using the bootloader outside 
> the published specifications.

Quite far from that IMHO. An attacker can use this to force the
exception that is needed to compromise the start up sequence. 

> Also there is little part of the 
> bootloader specification which states it is designed to have data 
> interpreted in human readable form, so why make bizarre snide 
> commments about the format of information?

Just last week I had the privilege of speaking to a mixed bunch of
embedded system programmers.  When discussing a requirement relating
to entering of memory addresses I suggested they to specify the format
as hexadecimal.

They looked at me in bewilderment and asked how else does one specify
memory addresses these days.  I said "octal" and one of them said I
was being picky.

When I said "decimal" they all burst into laughter!

Jaya