Lpc2000

This posting reports results of a quick investigation into the boot 
loader and CRP (Code Read Protection). It will enable you to confirm 
a factual error by another person asserting supposed evidence to 
contradict claims by Philips. The supposed evidence is not even 
worthy of the label circumstantial evidence.

It is a trivial exercise to step through the boot loader with a 
debugger, but only of course after booting is complete. It is not 
necessary to write or adapt code to dump the bootloader, it is far 
easier to simply step through the bootloader using trivial techniques 
below, which I would have thought would have been worthy of mention 
by anyone with an interest in the bootloader. As to the question can 
you look at the bootloader, certainly you can. It is like asking can 
you look at a naked a woman, yes if you have eyes. As to the question 
can you make independent use or publish in detail what the bootloader 
does, that is a legal question I am unable to answer.

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 decided to conduct my quick investigation using tools on hand after 
reading through another bizarre posting announcing web site updates 
concerned with the boot loader and noticing that the updates failed 
to include possible credible explanations I have made that answers a 
question that is posed in the site. This is really irritating and not 
worthy of resources provided by a publicly funded educational 
institution (see below). I have discovered a factual error on the web 
site also. 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?

The web site domain address used is set aside for a university level 
Australian educational institution publicly funded by tax payers. How 
disappointing. 

The tools I have on hand are a JTAGjet-ARM with its Chameleon 
debugger and an LPC2148 microcontroller. A cheap parallel port 
debugger with GDB would also work. I suspect IAR, Keil and Rowley 
toolsets can also be used.

The LPC2148 user manual informs us the LPC2128 bootloader is 12K long 
and starts at address 0x7FFF D000, although it is remapped. So after 
booting I halted the device, looked at an ARM code disassembly at 
this address, assigned the PC to this address and started stepping. 
There is no reason to assume this is not the remapped start address.

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.

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.

There is nothing in any of this sequence that justifies reasonable 
doubt about Philips claims. My own explanations I expressed 
previously still stacks up as possible, namely that if CRP is enabled 
then some possible GPIO pins will not be disabled due to pin P1.26 
being kept low during a reset. In addition just because JTAG may 
potentially get a few cycles before disconnection does not mean an 
internal debug signal JTAG may be asserting will be allowed to act, 
since a write to the CSPR would determine if internal debug signals 
are allowed to act.

It is worth noting that each non sequential bus access adds an extra 
wait state and that if the access involves the VPB then an additional 
three wait states appears to be required.

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.  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.

I really don't have time for this. I simply decided to conducted a 
small investigation to check out for myself. It is not worthy to 
discredit claims by Philips using the supposed evidence provided. In 
addition claims that the supposed evidence is the 'first thing' done 
is false.

In addition claims about stack overruns etc in the bootloader are 
irrelevant as all such claims involve using the bootloader outside 
the published specifications. 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?

John Heenan

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

Hi, Many Thanks on that bootloader stepping,

I switched over to LPC2103, after being frightened by those tons
of questions/posts on the LPC2124/3x/4x's CRP.
People are claiming CRP could be broken with:
- External JTAG control breaking in before Booloader could 
 disables the JTAG port fast enough (Some 30-70 clocks thing)..??
- Philips planted a Trojan horse inside the bootloader..??
- Crashing of bootloader by some undocumented ISP commands..??
I wouldn't have changed to LPC2103, if no such posts..  :(

I'm on LPC2103 now and more interested in LPC2103. Any idea:
- If the LPC2103 bootloader on ROM or is still on Flash memory?
- Even if the bootloader is on ROM, Did Philips default the JTAG
  debug port to OFF or they leave it as ON after reset?

=> I'm hoping someone will tell me JTAG is default as OFF after 
   reset (for the LPC2103).  Anybody??

BTW:
If someone willing to put up some US$5000 rewards for hacking the 
LPC2124/3x/4x CRP (Supposed to be Philips, but I don't think they 
dare to).  We will be very sure if that CRP could be hacked...,,
...or NOT....     :)

Regards



--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
>
> This posting reports results of a quick investigation into the 
boot 
> loader and CRP (Code Read Protection). It will enable you to 
confirm 
> a factual error by another person asserting supposed evidence to 
> contradict claims by Philips. The supposed evidence is not even 
> worthy of the label circumstantial evidence.
> 
> It is a trivial exercise to step through the boot loader with a 
> debugger, but only of course after booting is complete. It is not 
> necessary to write or adapt code to dump the bootloader, it is far 
> easier to simply step through the bootloader using trivial 
techniques 
> below, which I would have thought would have been worthy of 
mention 
> by anyone with an interest in the bootloader. As to the question 
can 
> you look at the bootloader, certainly you can. It is like asking 
can 
> you look at a naked a woman, yes if you have eyes. As to the 
question 
> can you make independent use or publish in detail what the 
bootloader 
> does, that is a legal question I am unable to answer.
> 
> 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 decided to conduct my quick investigation using tools on hand 
after 
> reading through another bizarre posting announcing web site 
updates 
> concerned with the boot loader and noticing that the updates 
failed 
> to include possible credible explanations I have made that answers 
a 
> question that is posed in the site. This is really irritating and 
not 
> worthy of resources provided by a publicly funded educational 
> institution (see below). I have discovered a factual error on the 
web 
> site also. 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?
> 
> The web site domain address used is set aside for a university 
level 
> Australian educational institution publicly funded by tax payers. 
How 
> disappointing. 
> 
> The tools I have on hand are a JTAGjet-ARM with its Chameleon 
> debugger and an LPC2148 microcontroller. A cheap parallel port 
> debugger with GDB would also work. I suspect IAR, Keil and Rowley 
> toolsets can also be used.
> 
> The LPC2148 user manual informs us the LPC2128 bootloader is 12K 
long 
> and starts at address 0x7FFF D000, although it is remapped. So 
after 
> booting I halted the device, looked at an ARM code disassembly at 
> this address, assigned the PC to this address and started 
stepping. 
> There is no reason to assume this is not the remapped start 
address.
> 
> 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.
> 
> 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.
> 
> There is nothing in any of this sequence that justifies reasonable 
> doubt about Philips claims. My own explanations I expressed 
> previously still stacks up as possible, namely that if CRP is 
enabled 
> then some possible GPIO pins will not be disabled due to pin P1.26 
> being kept low during a reset. In addition just because JTAG may 
> potentially get a few cycles before disconnection does not mean an 
> internal debug signal JTAG may be asserting will be allowed to 
act, 
> since a write to the CSPR would determine if internal debug 
signals 
> are allowed to act.
> 
> It is worth noting that each non sequential bus access adds an 
extra 
> wait state and that if the access involves the VPB then an 
additional 
> three wait states appears to be required.
> 
> 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.  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.
> 
> I really don't have time for this. I simply decided to conducted a 
> small investigation to check out for myself. It is not worthy to 
> discredit claims by Philips using the supposed evidence provided. 
In 
> addition claims that the supposed evidence is the 'first thing' 
done 

> is false.
> 
> In addition claims about stack overruns etc in the bootloader are 
> irrelevant as all such claims involve using the bootloader outside 
> the published specifications. 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?
> 
> John Heenan
>

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:

> I switched over to LPC2103, after being frightened by those tons
> of questions/posts on the LPC2124/3x/4x's CRP.

How is LPC2103 is any different in relation to CRP?  I had a look at
the user manual and could not find anything that suggests CRP
implementation is any different.

I did find one reference to Code Security Protection Register (CSPR)
as a read-only register at 0xe01fc180 -- see page 16 of user manual. 
There seems to be no other information about this register elsewhere
though.

You may want to look at the startup code in your boot loader either by
disassembly or using debugging method to see if it is any different.

Jaya

Hi,
It does not matter whether there are any differences between 
LPC2103 and LPC2124/3x/4x.   Important point is I did NOT need 
to switch parts if there were NO such tons of CRP posts at all.

OK,   Now I remember you are the one who claims CRP of  
LPC2124/3x/4x could be broken by:
- External JTAG breaking in before Booloader could disables the
  JTAG port fast enough (Some 30-70 clocks thing)..??
- Philips planted a Trojan horse inside the bootloader..??
- Crashing of bootloader by some undocumented ISP commands..??

Since you are so expert in LPC21xx, could you help to disassemble
few lines of the LPC2103 startup code??
(I'm some guy who could only write a few lines of C-codes for
simple 8-bit applications.    No capability of reverse engineering 
but know how to do few DWords code dump to serial port)
Give me the address of code segment to be dumped to UART0
if you want to disassemble.

Regards



--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@> wrote:
> 
> > I switched over to LPC2103, after being frightened by those tons
> > of questions/posts on the LPC2124/3x/4x's CRP.
> 
> How is LPC2103 is any different in relation to CRP?  I had a look 
at
> the user manual and could not find anything that suggests CRP
> implementation is any different.
> 
> I did find one reference to Code Security Protection Register 
(CSPR)
> as a read-only register at 0xe01fc180 -- see page 16 of user 
manual. 
> There seems to be no other information about this register 
elsewhere
> though.
> 
> You may want to look at the startup code in your boot loader 
either by
> disassembly or using debugging method to see if it is any 
different.

> 
> Jaya
>

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:
>
> Hi,
> It does not matter whether there are any differences between 
> LPC2103 and LPC2124/3x/4x.   Important point is I did NOT need 
> to switch parts if there were NO such tons of CRP posts at all.

I understood you as saying because you thought LPC2124/3x/4x was not
safe, you switched to LPC2103.  If LPC2103 is no different with
respect to CRP, it does not make sense to switch to LPC2103 on account
of CRP discussion.  

> Since you are so expert in LPC21xx, could you help to disassemble
> few lines of the LPC2103 startup code??

For the record do not consider myself an expert on LPC21xx.  It so
happens that since I got involved with it, I did find a number of
anomalies that it appears has not been reported in this forum or
elsewhere.

If you can provide me (by direct email) with the dump of your boot
loader code following the steps outlined in

  http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

I will see what I can do for you.  You need to use e000.hex (not
d000.hex) to dump the boot sector contents.

Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
> I understood you as saying because you thought LPC2124/3x/4x was 
> not safe, you switched to LPC2103.  If LPC2103 is no different 
> with respect to CRP, it does not make sense to switch to LPC2103 
> on account of CRP discussion.  




No, switch to LPC2103 by mistake, due to someone set off some
false alarm on LPC2124/3x/4x, claiming:
- External JTAG breaking in before Booloader could disables the
  JTAG port fast enough (Some 30-70 clocks thing)..??
- Philips planted a Trojan horse inside the bootloader..??
- Crashing of bootloader by some undocumented ISP commands..??
And that expert never said anything about LPC2103. So implying 
LPC2103 OK??

Don't know how to use your complex utility.   I only need to know
if JTAG is default as OFF for LPC2103.  Following is the few 
DWORDS from bootloader (Cut and paste from hyperterminal, pls
use any C-compiler to generate to Bin if needed):

   // unsigned long	*p,i;
   // p=(unsigned long *)0x7fffe000;
   // for (i=0;i<32;i++) DumpDWords(*p++);

Location: 0x7fff e000
0xE59F4034,           
0xE3A05002,           
0xE5845000,           
0xE3A05003,           
0xE5845004,           
0xE59F201C,           
0xE3A03000,           
0xE1020093,           
0xE2822028,           
0xE1021093,
0xE3C03007,
0xE5023028,
0xE51FF004,
0x7FFFE174,
0xE002C014,
0xE01FC000,
0x0004FF11,
0x00000202,
0x40000000,
0x40001FFF,
0x00000007,
0x00000001,
0x00000190,
0x000000C8,
0x00000000,
0x00007FFF,
0x00000000,
0x00001000,
0x00002000,
0x00003000,
0x00004000,
0x00005000,

If you want full 8Kbytes, I can do it at some other time.
Regards

> Don't know how to use your complex utility.   I only need to know
> if JTAG is default as OFF for LPC2103.  Following is the few 
> DWORDS from bootloader (Cut and paste from hyperterminal, pls
> use any C-compiler to generate to Bin if needed):

The way I read the User Manual (Section 19.7) seems to agree with
every other piece of information I have read re: CRP and JTAG.  By
default, JTAG is enabled.  If CRP is enabled, JTAG is disabled by the
boot code at startup.

According to Philips, this occurs in the first few instructions while
it may take many instructions for JTAG to get control.  So, by the
time JTAG can stop the processor, it is already disabled.  That's the
theory and there isn't one single shred of PROOF that it doesn't work
exactly that way.  NOBODY has EVER posted PROOF that the protected
code can be accessed.  PROOF as in "here's the code, test it yourself"
or "here's the procedure using this specific JTAG device and this
specific piece of software".  Something that can be duplicated by
anyone so inclined.  Everything that has been posted is just wild
speculation and innuendo.

But, hey, if you are unconvinced, and given that you have just jumped
from one processor to another, take this opportunity to change
manufacturers.  There are many...  Maybe some have a better way to do
CRP, maybe not.

Richard

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@...> wrote:
> > Don't know how to use your complex utility.   I only need to know
> > if JTAG is default as OFF for LPC2103.  Following is the few 
> > DWORDS from bootloader (Cut and paste from hyperterminal, pls
> > use any C-compiler to generate to Bin if needed):
> 
> The way I read the User Manual (Section 19.7) seems to agree with
> every other piece of information I have read re: CRP and JTAG.  By
> default, JTAG is enabled.  If CRP is enabled, JTAG is disabled by 
> the boot code at startup.
> 
> According to Philips, this occurs in the first few instructions 
> while it may take many instructions for JTAG to get control.  So,
> by the time JTAG can stop the processor, it is already disabled. 
> That's the theory and there isn't one single shred of PROOF that 
> it doesn't work exactly that way.  NOBODY has EVER posted PROOF 
> that the protected code can be accessed.  PROOF as in "here's the
> code, test it yourself"
> or "here's the procedure using this specific JTAG device and this
> specific piece of software".  Something that can be duplicated by
> anyone so inclined.  Everything that has been posted is just wild
> speculation and innuendo.
> 
> But, hey, if you are unconvinced, and given that you have just
> jumped from one processor to another, take this opportunity to
> change manufacturers.  There are many...  Maybe some have a better 
> way to do CRP, maybe not.
> 
> Richard
>

Hi, Completely agree with you those chips' CRP are robust and
cannot be hacked. And I never claim or seen any proven way that
chips' CRP can be bypassed.
 
I'm only curious to find out if the JTAG is default as Enabled 
for the ROM based LPC2103.  (Since bootloader is on ROM and they
can default the JTAG to OFF).  Is that OK for you??
Regards

At 03:22 PM 4/23/06 +0000, unity0724 wrote:
>I'm only curious to find out if the JTAG is default as Enabled
>for the ROM based LPC2103.  (Since bootloader is on ROM and they
>can default the JTAG to OFF).

Whether the bootloader is in ROM or FLASH makes little practical difference 
to what it can do.  If it's in ROM the only real difference is that it 
can't be written over.  Which means it can't use that same memory area to 
store parameters and it can't be updated in place.

That does mean it's more difficult to trash the bootloader, which is a good 
thing.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

> Hi, Completely agree with you those chips' CRP are robust and
> cannot be hacked. And I never claim or seen any proven way that
> chips' CRP can be bypassed.
>  
> I'm only curious to find out if the JTAG is default as Enabled 
> for the ROM based LPC2103.  (Since bootloader is on ROM and they
> can default the JTAG to OFF).  Is that OK for you??
> Regards
>

Perhaps Section 20.8.1 of the User Manual will help.  "The Debug mode
is enabled through the use oa the DBGSEL and RTCK pins."  Actually, if
you look at the default pin connect configuration, following reset all
pins are defined as I/O.  

However, if DBGSEL is high during and after the CPU is reset, the JTAG
pins are configured for JTAG and the pin connect block settings have
no effect.

Section 20.8.2 is quite specific about how JTAG gets enabled.

So, by default JTAG is enabled if DBGSEL is high during and after the
time the CPU is reset.  Since you have no control over DBGSEL after
the device reaches a customer, you must rely on the CRP as implemented
in the bootloader.

Richard

Hi Robert,

IMHO the LPC2xxx* should be regarded as safe until someone
claims to have _broken_ copy protection, not just come up with
a theoretical line of attack. And let's hope they say which line of
attack was vulnerable.
*excluding LPC2104/5/6

But I think ROM/FLASH might make a difference.
Because Philips must somehow get the bootloader into FLASH.
 - It might be that the JTAG is enabled at reset and the bootloader _must_
turn off protection before a JTAG attack can take place.
And a blank flash bootloader does not do this.
 - It might be that Philips put in an extra probing pad (not bonded out)
that controls whether the JTAG is enabled or disabled at reset (and it
is merely a matter of belt-and-braces as to why the bootloader
explicitly re-disables it).

 = With a substitute bootloader, one could omit that disabling
test the state of JTAG at hard reset before the bootloader has touched it.

With bootloader in ROM, as unity said, the Philips trap-door (which
might or might not be exploitable by an attacker) is not necessary.
But I have no way of knowing if Philips would remove such a
trap-door assuming one exists.

Regards,
Danish
--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:

>
> At 03:22 PM 4/23/06 +0000, unity0724 wrote:
> >I'm only curious to find out if the JTAG is default as Enabled
> >for the ROM based LPC2103.  (Since bootloader is on ROM and they
> >can default the JTAG to OFF).
> 
> Whether the bootloader is in ROM or FLASH makes little practical difference 
> to what it can do.  If it's in ROM the only real difference is that it 
> can't be written over.  Which means it can't use that same memory area to 
> store parameters and it can't be updated in place.
> 
> That does mean it's more difficult to trash the bootloader, which is a good 
> thing.
> 
> Robert

Good point. You are right that they could have changed something else along 
with the flash and removing the need to program the flash could have opened 
up an avenue that didn't exist before.

As far as any security scheme goes, it's less a matter of if they can be 
circumvented then how much effort it takes.  At the very least the human 
factor limits how secure any mechanism is.  And I agree there has yet to be 
any demonstrated exploit of the LPC2000 protection.  It's not clear how 
much effort has gone into trying to find one though.

At 08:15 PM 4/23/2006 +0000, Danish Ali wrote:
>But I think ROM/FLASH might make a difference.
>Because Philips must somehow get the bootloader into FLASH.
>  - It might be that the JTAG is enabled at reset and the bootloader _must_
>turn off protection before a JTAG attack can take place.
>And a blank flash bootloader does not do this.

That appears to be a high probability given the reverse engineering 
published so far.

>  - It might be that Philips put in an extra probing pad (not bonded out)
>that controls whether the JTAG is enabled or disabled at reset (and it
>is merely a matter of belt-and-braces as to why the bootloader
>explicitly re-disables it).

 From an earlier Philips post

>3) How is Bootloader programmed for the first time?
>
>Via JTAG on a tester. JTAG is accessible in virgin devices. Once
>bootloader is programmed and CRP is enabled the tester can't access
>the JTAG.

That suggests to me that there isn't an extra bond pad and suggests that 
the test at this stage might even be in package.

Note that this fits very nicely with the reverse engineering published so far.

The disagreement between antagonist comes from whether it is possible 
hijack the JTAG control of the CPU before the CPU van be turned off.  So 
far, AFAIK, no one has demonstrated the possibility.  I'm not sure anyone 
has even tried.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, "Danish Ali" <danish@...> wrote:

> IMHO the LPC2xxx* should be regarded as safe until someone
> claims to have _broken_ copy protection, not just come up with
> a theoretical line of attack.

I do not doubt that this is a reasonable assumption in many cases.

> And let's hope they say which line of
> attack was vulnerable.
> *excluding LPC2104/5/6

LPC2104/5/6 do not have CRP.  So there is no "attack" concept.

The vulnerabilities that I found based on looking at implementation of
boot loader version 1.64 on LPC2292:

V1:  JTAG disable window on startup;

V2:  defect in exception handler code;

V3:  defect in CSI implementation; and

V4:  undocumented commands and methods.

The above list supersedes earlier discussion in this forum in bits and
pieces.

Until we know the above issues are addressed by the boot loader
implementors, I would not consider the CRP feature safe for the kind
of requirements I have seen.

> But I think ROM/FLASH might make a difference.

Only as far as accidental erasure which was my first gripe with LPC
family.

> Because Philips must somehow get the bootloader into FLASH.
>  - It might be that the JTAG is enabled at reset and the bootloader
_must_
> turn off protection before a JTAG attack can take place.
> And a blank flash bootloader does not do this.

I think I lost you here :)  Did you mean to say "that the boot loader
must turn off in order prevent JTAG attack"?

>  - It might be that Philips put in an extra probing pad (not bonded out)
> that controls whether the JTAG is enabled or disabled at reset (and it
> is merely a matter of belt-and-braces as to why the bootloader
> explicitly re-disables it).

I do not see any evidence of this in the LPC family.  This concept of
"fuses" used by other manufactures works this way, and I have not seen
any reference to such a feature by Philips.

>   = With a substitute bootloader, one could omit that disabling
> test the state of JTAG at hard reset before the bootloader has
touched it.

Given the assumption above is not likely to be true, I would not
accept this.

> With bootloader in ROM, as unity said, the Philips trap-door (which
> might or might not be exploitable by an attacker) is not necessary.

The "trap-door" issue is one thing, (which I am sure Philips would
have made the decision to delete from its boot loader) but the
stability of the CSI (command string interpreter) is an issue.

One other poster said that it is irrelevant of the CSI can be made to
crash by supplying erroneous input.  I think it matter, because this
vulnerability is a resource that hackers use to exploit.  This is one
of the most commonly used methods if you look at history.

> But I have no way of knowing if Philips would remove such a
> trap-door assuming one exists.

It would be a win-win for both Philips and LPC community if Philips would:

a)  open a channel to acknowledge bugs as and when they are reported;
b)  provide information as to what versions and parts these apply to; and
c)  indicate when they plan to fix them and how users can check this out;

Jaya

Hello!
Thanks to all responses but could we change the subject to:
"For LPC2103, is JTAG default as OFF or ON after reset"
Just a simple question and treat it as non-related to CRP.

I do not want to be the next person starting another long
debate on CRP, and pls help sticking to the narrow topic.

Startup code of bootloader already pulled out. And Mr Jaya 
who is the bootloader expert here pls help to disassemble the 
first few lines.   Many Thanks!
Regards

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> --- In lpc2000@yahoogroups.com, "Danish Ali" <danish@> wrote:
> 
> > IMHO the LPC2xxx* should be regarded as safe until someone
> > claims to have _broken_ copy protection, not just come up with
> > a theoretical line of attack.
> 
> I do not doubt that this is a reasonable assumption in many cases.
> 
> > And let's hope they say which line of
> > attack was vulnerable.
> > *excluding LPC2104/5/6
> 
> LPC2104/5/6 do not have CRP.  So there is no "attack" concept.
> 
> The vulnerabilities that I found based on looking at 
implementation of
> boot loader version 1.64 on LPC2292:
> 
> V1:  JTAG disable window on startup;
> 
> V2:  defect in exception handler code;
> 
> V3:  defect in CSI implementation; and
> 
> V4:  undocumented commands and methods.
> 
> The above list supersedes earlier discussion in this forum in bits 
and
> pieces.
> 
> Until we know the above issues are addressed by the boot loader
> implementors, I would not consider the CRP feature safe for the 
kind
> of requirements I have seen.
> 
> > But I think ROM/FLASH might make a difference.
> 
> Only as far as accidental erasure which was my first gripe with LPC
> family.
> 
> > Because Philips must somehow get the bootloader into FLASH.
> >  - It might be that the JTAG is enabled at reset and the 
bootloader
> _must_
> > turn off protection before a JTAG attack can take place.
> > And a blank flash bootloader does not do this.
> 
> I think I lost you here :)  Did you mean to say "that the boot 
loader
> must turn off in order prevent JTAG attack"?
> 
> >  - It might be that Philips put in an extra probing pad (not 
bonded out)
> > that controls whether the JTAG is enabled or disabled at reset 
(and it
> > is merely a matter of belt-and-braces as to why the bootloader
> > explicitly re-disables it).
> 
> I do not see any evidence of this in the LPC family.  This concept 
of
> "fuses" used by other manufactures works this way, and I have not 
seen
> any reference to such a feature by Philips.
> 
> >   = With a substitute bootloader, one could omit that disabling
> > test the state of JTAG at hard reset before the bootloader has
> touched it.
> 
> Given the assumption above is not likely to be true, I would not
> accept this.
> 
> > With bootloader in ROM, as unity said, the Philips trap-door 
(which
> > might or might not be exploitable by an attacker) is not 
necessary.
> 
> The "trap-door" issue is one thing, (which I am sure Philips would
> have made the decision to delete from its boot loader) but the
> stability of the CSI (command string interpreter) is an issue.
> 
> One other poster said that it is irrelevant of the CSI can be made 
to
> crash by supplying erroneous input.  I think it matter, because 
this
> vulnerability is a resource that hackers use to exploit.  This is 
one
> of the most commonly used methods if you look at history.
> 
> > But I have no way of knowing if Philips would remove such a
> > trap-door assuming one exists.
> 
> It would be a win-win for both Philips and LPC community if 
Philips would:
> 
> a)  open a channel to acknowledge bugs as and when they are 
reported;
> b)  provide information as to what versions and parts these apply 
to; and
> c)  indicate when they plan to fix them and how users can check 
this out;

> 
> Jaya
>

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:
>
> Hello!
> Thanks to all responses but could we change the subject to:
> "For LPC2103, is JTAG default as OFF or ON after reset"
> Just a simple question and treat it as non-related to CRP.
>

Why do you still have a question?  The User Manual in Section 20.8.2
is very specific.  If both DBGSEL and RTCK are HIGH at reset, JTAG is
enabled at some point following reset.  If either signal is low coming
out of reset, JTAG is disabled and can not be enabled later.

What it doesn't say is WHEN JTAG is enabled relative to reset.  It
could be done in hardware and happen immediately.  Or, it could be
done by the bootloader firmware.

But the User Manual is quite specific about whether it is enabled or not.

Richard

> > 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"?

To quote from the web site at address 
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

"However the first thing the boot loader in LPC2148 does (in a quite 
hasty fashion as if to minimise the window of opportunity) is to 
disable JTAG debug port.  This code is executed for both hardware and 
watchdog resets.  Why disable JTAG debug port if  is indeed already 
disabled on reset?"

The 'first thing', as falsely claimed on the web site, has to wait 
eight ARM instructions to complete after reset with additional wait 
states imposed by accessing the VPB. If it was genuinely the 'first 
thing' it would only require three ARM instructions to complete! 
Facts like this cannot be twisted out of. It has nothing to do with 
the issue of accessing SRAM with MAM disabled as no SRAM is accessed 
during the first eight insrtructions.

I have provivded one credible and practical possible answer, that is 
to allow access to GPIO ports irrespective of reset condition. I can 
think of at least one other. I am sure experts can suggest others.

> 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.

This is just so bizarre. 

ATMEL fuse bits are nothing more than non volatile storage bits, 
which guess what, so is address 0x1FC where the CRP value is held!

MSP430 microcontrollers use a real fuse that can be blown to disable 
JTAG. MSP430 microcontrollers also have a boot loader, called a BSL 
(Boot Strap Loader). Blowing the JTAG fuse on an MSP430 has no effect 
on the BSL.

> 
> > 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?

What by overclocking and/or running the micrcontroller at marginal or 
execssive voltages? These are issues that have nothing to do with 
claims about the CRP and it far more likely the microcontroller will 
be fried rather than broken into.

You might as well state it is obvious you can huff and puff and blow 
my house down! While it is obvious you can try it is not obvious you 
will succeed, particularly if my house is not made of paper!

> 
> > 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.

You have misrepresented my points, which I understand is a reocurring 
complaint.

ADDITIONALLY WHAT IS YOUR PROBLEM WITH ACCEPTING MY CENTRAL POINT 
THAT AN ENABLED JTAG DOES NOT MEAN  NECESSARILY INTERNAL DEBUG 
SIGNALS JTAG MAY BE ATTEMPTING TO ASSERT WILL BE ALLOWED TO ACT? THIS 
IS OBVIOUS TO ANYONE WITH EVEN A MODEST COMPETENT KNOWLEDGE OF 
ELECTONICS AND MICROCONTROLLER ARCHITECTURE.

A Ph.D. does not certify even a modest level of basic competence.

> 
> > 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.

Round and round again in an endless miserable merry go round we are 
not allowed to get off. Issue addressed in capitals above.

> > 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.

Facts are facts. Five is not the same as zero. It is false to imply 
five glaringly obvious and highly visible ARM instructions can be 
whisked away into nothingness to justify a false 'first thing' claim.
 
> > 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. 

Again nothing solid or concrete, which I have complained about 
before. You know very well there are no relevant operations that can 
make such exploits if CRP works as specified, so why mislead us?

> 
> > 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.

Mixed bunch??

> 
> 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
>

I think any approach that can help guard against endian issues with 
trivial additional resources is to be welcomed and praised, rather 
than sneered and laughed at.

If programmers are forced to convert addresses to decimal then there 
is no confusion about the endianess of the information. This is a 
solution to a very practical and real problem, particularly on 
devices that can move between 16 bit Thumb and 32 bit ARM endian 
formats.

Since when does a Ph.D. and responsbilities in a big city university 
grant you a licence to treat us with such intellectual contempt that 
you just will not listen and acknowledge valid points? 

John heenan

On Monday 24 April 2006 09:54, John Heenan wrote:
> The 'first thing', as falsely claimed on the web site, has to wait
> eight ARM instructions to complete after reset with additional wait
> states imposed by accessing the VPB. If it was genuinely the 'first
> thing' it would only require three ARM instructions to complete!
It's likely that you're talking about different versions of the bootloader. 
Bootloader version 1.63 on a LPC2294 does what Jaya describes on his page. It 
swaps the content of PINSEL2 with a 0x0 in the first three instructions.

Anyway, I don't think that it matters if it's done in the first three or eight 
instructions - the window is too small for the necessary number of JTAG 
cycles. I said it before, and I'm happy to repeat it: CRP is safe in that 
regard.

> ATMEL fuse bits are nothing more than non volatile storage bits, 
> which guess what, so is address 0x1FC where the CRP value is held!
One difference is that a "fuse" could be evaluated by the hardware itself, 
without relying on software (e.g. use the fuse value to force nTRST). This is 
more complicated with flash, which could be the reason why Philips made CRP 
at least partly a software feature.

> ADDITIONALLY WHAT IS YOUR PROBLEM WITH ACCEPTING MY CENTRAL POINT
> THAT AN ENABLED JTAG DOES NOT MEAN  NECESSARILY INTERNAL DEBUG
> SIGNALS JTAG MAY BE ATTEMPTING TO ASSERT WILL BE ALLOWED TO ACT? THIS
> IS OBVIOUS TO ANYONE WITH EVEN A MODEST COMPETENT KNOWLEDGE OF
> ELECTONICS AND MICROCONTROLLER ARCHITECTURE.

I don't understand why you're repeating this claim again and again. At least I 
haven't seen any evidence that suggests that what you're saying is true - at 
least not for the LPC2294. There's nothing in the code path that would 
enable "internal debug signals" after the bootloader determined that CRP 
isn't enabled, so they have to be enabled right out of reset.
The LPC2294 lacks the CSPR register, but maybe you could test this:
Attach your debugger to the target, halt it, read the CSPR and write 
0x87654321 to the CSPR location. Would be interesting to see if this has any 
effect on the debug functionality.

Regards,

Dominic Rath

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
>
> On Monday 24 April 2006 09:54, John Heenan wrote:
> > The 'first thing', as falsely claimed on the web site, has to wait
> > eight ARM instructions to complete after reset with additional 
wait
> > states imposed by accessing the VPB. If it was genuinely 
the 'first
> > thing' it would only require three ARM instructions to complete!

> It's likely that you're talking about different versions of the 
bootloader. 
> Bootloader version 1.63 on a LPC2294 does what Jaya describes on 
his page. It 
> swaps the content of PINSEL2 with a 0x0 in the first three 
instructions.
> 

Here is the bizarre claim by Jaya again.

"However the first thing the boot loader in LPC2148 does (in a quite 
hasty fashion as if to minimise the window of opportunity) is to 
disable JTAG debug port.  This code is executed for both hardware and 
watchdog resets.  Why disable JTAG debug port if  is indeed already 
disabled on reset?."

Here are the first eight instructions on my LPC2148, including the 
first five which have nothing to do with disconnecting the JTAG port.

LDR       R4,[PC,#+0x34]
MOV       R5,#0x2
STR       R5,[R4,#+0]   ;stores 2 to VPB register MAMCR
MOV       R5,#0x3     
STR       R5,[R4,#+0x4] ;stores 3 to VPB register MAMTIM
LDR       R2,[PC,#+0x1c]
MOV       R3,#0
SWP       R0,R3,[R2]    ;exchange 0 with contents of PINSEL2 into R3


> Anyway, I don't think that it matters if it's done in the first 
three or eight 
> instructions - the window is too small for the necessary number of 
JTAG 
> cycles. I said it before, and I'm happy to repeat it: CRP is safe 
in that 
> regard.

Sounds like an indirect assertion Jaya has no idea what he is talking 
about.

> 
> > ATMEL fuse bits are nothing more than non volatile storage bits, 
> > which guess what, so is address 0x1FC where the CRP value is held!


> One difference is that a "fuse" could be evaluated by the hardware 
itself, 
> without relying on software (e.g. use the fuse value to force 
nTRST). This is 
> more complicated with flash, which could be the reason why Philips 
made CRP 
> at least partly a software feature.

There is no difference in this context. A fuse is just a label. The 
fuse still represents non volatile memory storage. Ultimately all 
memory storage have their contents grabbed by hardware after setting 
up bus signals, be that by software or hardware.

> 
> > ADDITIONALLY WHAT IS YOUR PROBLEM WITH ACCEPTING MY CENTRAL POINT
> > THAT AN ENABLED JTAG DOES NOT MEAN  NECESSARILY INTERNAL DEBUG
> > SIGNALS JTAG MAY BE ATTEMPTING TO ASSERT WILL BE ALLOWED TO ACT? 
THIS
> > IS OBVIOUS TO ANYONE WITH EVEN A MODEST COMPETENT KNOWLEDGE OF
> > ELECTONICS AND MICROCONTROLLER ARCHITECTURE.
> 
> I don't understand why you're repeating this claim again and again. 
At least I 
> haven't seen any evidence that suggests that what you're saying is 
true - at 
> least not for the LPC2294. 

In the context of the speculative nature of the postings, I don't 
understand why you have a problem with this statement. Lack of 
concrete evidence has never been a problem for Jaya, so why can't I 
present a sensible and obvious credible possibility that I have no 
concrete evidence for, while accepting it is just a possibility. It 
is not normal for semiconductor companies to publicly document the 
entire internal bus workings of their products, least of all security 
mechanisms.

I am not able to confirm your statements about the LPC2294.

John Heenan

> Regards,
> 
> Dominic Rath
>

On Monday 24 April 2006 11:16, John Heenan wrote:
> Here are the first eight instructions on my LPC2148, including the
> first five which have nothing to do with disconnecting the JTAG port.
>
Exactly - either because of different bootloader versions, or because Jaya 
mixed up LPC2148 and LPC229x bootloader code. But as it really doesn't matter 
if disabling JTAG is the first or the third thing, I don't think it's worth 
discussing this any further.

> Sounds like an indirect assertion Jaya has no idea what he is talking
> about.
>
I'd prefer not to make this personal, but yes, I don't think it's a good idea 
when he keeps asserting that CRP could be broken using JTAG before the 
bootloader had a chance to disable it.

> There is no difference in this context. A fuse is just a label. The
> fuse still represents non volatile memory storage. Ultimately all
> memory storage have their contents grabbed by hardware after setting
> up bus signals, be that by software or hardware.
>
Wouldn't it be possible to have non-volatile memory bits that can be "read" 
without requiring address decoding logic and timing requirements necessary 
with flash memory? Of course everything is ultimately grabbed by hardware, 
but having the decision in hardware would harden security in my opinion.

> > I don't understand why you're repeating this claim again and again.
> > At least I haven't seen any evidence that suggests that what you're 
> > saying is true - at least not for the LPC2294.
>
> In the context of the speculative nature of the postings, I don't
> understand why you have a problem with this statement. Lack of
> concrete evidence has never been a problem for Jaya, so why can't I
> present a sensible and obvious credible possibility that I have no
> concrete evidence for, while accepting it is just a possibility. It
> is not normal for semiconductor companies to publicly document the
> entire internal bus workings of their products, least of all security
> mechanisms.
>
I have a problem with your statement because of evidence that it is wrong for 
the LPC2294 (which is the only one I have), and serious doubts that the 
LPC2148 is different.
One thing that could change my mind would be a positive effect of writing 
0x87654321 to the CSPR. Of course this remains hypothetical if the CSPR turns 
out to be a write-once register (it obviously isn't read-only, as the 
bootloader writes it at least once).

> I am not able to confirm your statements about the LPC2294.
>
Okay, you can't confirm it, but do you agree that:
If there's nothing (on a LPC2294) enabling debug bus signals to act, they've 
been enabled since the beginning?

> John Heenan

Regards,

Dominic Rath

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
>
> On Monday 24 April 2006 11:16, John Heenan wrote:
> > Here are the first eight instructions on my LPC2148, including the
> > first five which have nothing to do with disconnecting the JTAG port.
> >
> Exactly - either because of different bootloader versions, or
because Jaya 
> mixed up LPC2148 and LPC229x bootloader code. But as it really
doesn't matter 
> if disabling JTAG is the first or the third thing, I don't think
it's worth 
> discussing this any further.

The information I presented relates to boot loader version 2.1 and
which had the part identifier in ROM coded as 0x0002ff25.

The sender claimed that this dump was from 2148 part but that it
responds as 2138 part, and that this behaviour is well documented in
the Keil web site.

I agree it does not matter which particular part is.

> I'd prefer not to make this personal, but yes, I don't think it's a
good idea 
> when he keeps asserting that CRP could be broken using JTAG before the 
> bootloader had a chance to disable it.

I try to refrain from responding when an expressed opinion is taken so
personally.  In this case I wanted to take this opportunity to thank
for chipping in to clarify matters the way you have.

Jaya

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@...> wrote:
>
> On Monday 24 April 2006 11:16, John Heenan wrote:

> I have a problem with your statement because of evidence that it is 
wrong for 
> the LPC2294 (which is the only one I have), and serious doubts that 
the 
> LPC2148 is different.
> One thing that could change my mind would be a positive effect of 
writing 
> 0x87654321 to the CSPR. Of course this remains hypothetical if the 
CSPR turns 
> out to be a write-once register (it obviously isn't read-only, as the 
> bootloader writes it at least once).

First there is no public information one way or the other that it is 
correct or incorrect. I have never asserted it is true, only possible.

Second you are missing the point. In the context of the postings it 
does not have to be true. It only has to be possible!

Third it is not worth arguing the point in isolation.

John Heenan

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
> The 'first thing', as falsely claimed on the web site, has to wait 
> eight ARM instructions to complete after reset with additional wait 
> states imposed by accessing the VPB. If it was genuinely the 'first 
> thing' it would only require three ARM instructions to complete!

It does look like your boot loader is different.  The three
instructions I was referring to in boot loader 2.1 on LPC2148 (which
has its part ID coded as that for LPC2138) are as follows:

>	ldr	r2, =PINSEL2				@d000
>	mov	r3, #0					@d004
>	swp	r0, r3, [r2]				@d008

I said it does "one thing" simply because the first two instructions
prepare the registers and the third instruction is the one that
actually carries out the operation of disabling JTAG interface.

Indeed in a later post, you find the same sequence in your boot
loader, but with 5 instructions preceding it.

The purpose of these five instructions appears to be the work around
for the MAM.1 bug.  Without this work around, a write to SRAM followed
by a read of SRAM will yield corrupt data.

> Facts like this cannot be twisted out of. It has nothing to do with 
> the issue of accessing SRAM with MAM disabled as no SRAM is accessed 
> during the first eight insrtructions.

You have alluded us to another property of the LPC boot loaders.  It
looks like the boot loader implementors have no reservations about
writing code in the area that is reserved for interrupt vectors.

This is not good practice IMHO and I would not include boot loader
code in my trust domain, which I must do if I were to rely on CRP that
is implemented by  the boot loader.

I have not seen any developments by way of improvements to boot
loader, or by way of how Philips handles bug reports relating to the
boot loader that would prompt me to reconsider.

You are entitled to form your own opinion no doubt.

> ATMEL fuse bits are nothing more than non volatile storage bits, 
> which guess what, so is address 0x1FC where the CRP value is held!
> 
> MSP430 microcontrollers use a real fuse that can be blown to disable 
> JTAG.

ATMEL fuse bits behave like "real" fuse bits you refer to in that once
you blow it you cannot mend it back, except when you want to recover
the chip while losing all software loaded onto it.

This recovery option IMHO this useful feature, that you "mend" the
blown fuse bit *after* (and only after) the entire on-chip flash
memory is erased.

If for any reason the on-chip flash was not completely erased (for
example if  it was interrupted by novel means), the fuse bits will not
mend.  This makes it protection far more robust and the LPC scheme has
no comparision.

> What by overclocking and/or running the micrcontroller at marginal or 
> execssive voltages?

No, but by operating the boot loader "beyond specifications" as you
put it.  It would be naive to assume that would-be attackers will not
feed CSI with data that the programmers had not anticipated.  I have
explained how I was able to crash the CSI.

> Facts are facts. Five is not the same as zero. It is false to imply 
> five glaringly obvious and highly visible ARM instructions can be 
> whisked away into nothingness to justify a false 'first thing' claim.

I think you started on the wrong premise by narrowly defining "thing"
as an instruction.

In the boot loader I looked into, the implementors thought it was
necessary to turn of JTAG in minimum of three instruction cycles. 
They could have made it four and avoid trading off exception handling
but they did not.

Now from your findings, it appears that they have added five
instructions to this window of opportunity.  This begs the question as
to why?

Are adding instructions in area reserved for vectors without
consideration of its impact when boot loader triggers an exception? 
Could it be that they are trading off pressing need to fix MAM.1 bug
with a further increase in the window of opportunity?

You an I cannot answer these questions and there is little to be
served by emotionally charged speculations.  I am satisfied I do not
know the answers, and I chose not to include the boot loader into my
trust domain until I know more.

> Again nothing solid or concrete, which I have complained about 
> before. You know very well there are no relevant operations that can 
> make such exploits if CRP works as specified, so why mislead us?

As I said, feel free to make any assumptions you want.  I have not
mislead you or anyone else.

I was provided with a set of assumptions and based on which to express
my opinion. I did just that..  You do not have to agree with it.

Raising the same issue over and over again just serves to solicits
rebuttals like this one where there is a component of repetition.

> I think any approach that can help guard against endian issues with 
> trivial additional resources is to be welcomed and praised, rather 
> than sneered and laughed at.
> 
> If programmers are forced to convert addresses to decimal then there 
> is no confusion about the endianess of the information. This is a 
> solution to a very practical and real problem, particularly on 
> devices that can move between 16 bit Thumb and 32 bit ARM endian 
> formats.

Eh?  When the manual specifies RAM as starting at 0x40000000 it would
be ludicrous to suggest that this address is dependent on endian-ness.

I see a red herring here.

Jaya

Hi,

And why would the person who has managed to break it tell the world?

Peter.

Danish Ali wrote:
> Hi Robert,
> 
> IMHO the LPC2xxx* should be regarded as safe until someone
> claims to have _broken_ copy protection, not just come up with
> a theoretical line of attack. 


-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

At 01:35 PM 4/25/06 +1000, Peter Homann wrote:
>And why would the person who has managed to break it tell the world?
>Danish Ali wrote:
> > Hi Robert,
> >
> > IMHO the LPC2xxx* should be regarded as safe until someone
> > claims to have _broken_ copy protection, not just come up with
> > a theoretical line of attack.

As a warning to users who rely on it (to some extent or other).  And to 
ensure it gets fixed.  The world is full of examples of security holes that 
get glossed over until someone shows that they can be used.

Any yes, there are people who do publish with that intent.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

At 12:49 AM 4/24/2006 +0000, jayasooriah wrote:
>One other poster said that it is irrelevant of the CSI can be made to
>crash by supplying erroneous input.  I think it matter, because this
>vulnerability is a resource that hackers use to exploit.  This is one
>of the most commonly used methods if you look at history.

I agree with you with the caveat that the vulnerability still exists with 
CRP turned on.  Actually as a potential method of breaking security this 
strikes me as being the bigger hole,  Fortunately it should be the easier 
to fix.


>It would be a win-win for both Philips and LPC community if Philips would:
>
>a)  open a channel to acknowledge bugs as and when they are reported;
>b)  provide information as to what versions and parts these apply to; and
>c)  indicate when they plan to fix them and how users can check this out;

Agreed, although to be fair to Philips they are far from unique in this regard.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:

> >It would be a win-win for both Philips and LPC community if Philips
would:
> >
> >a)  open a channel to acknowledge bugs as and when they are reported;
> >b)  provide information as to what versions and parts these apply
to; and
> >c)  indicate when they plan to fix them and how users can check
this out;
> 
> Agreed, although to be fair to Philips they are far from unique in
this regard.

I am not sure.  I do not know of any other manufacturer offering
security using similar methods.

Set aside security for the moment.  Suppose the boot loader upgrade
process failed and one ended up with 2000 parts all assembled and in
perfect working order except for startup code that disables JTAG and
then loops in bad code without any means of invoking ISP.

The design of piece of hardware that can be destroyed in this manner
says a lot.

Jaya

Hi, Mr Jaya,
Had eMail you the 8KB LPC2103 bootloader image.
Please help to disassemble the first few line to find out if JTAG
is default as ON or OFF, on the LPC2103.

Please do NOT use any new things like CSPR to confuse me. I do
NOT have the type of your brain power and could only analyze
hardware bit-by-bit. I'm only interested in the question of
*** On LPC2103, Is JTAG default as OFF or ON ***. 
I do NOT care what's CSPR.

Main purpose is to find a new philips chip capable of shoot
down all your theories:
1) External JTAG breaking in before Booloader could disables the
   JTAG port fast enough (Some 30-70 clocks thing)..??
2) Philips planted a Trojan horse inside the bootloader..??
3) Crashing of bootloader by some undocumented ISP commands..??
4) Exception interrupts are not handled correctly by the
   bootloader..??

To me, Only item 1 is critical.   Items 2,3,4 are software problems
only and the best you could do is crashing the bootloader.  There
are tons of other ways to hang up the CPU at any time, any board.
But what you get would be some <0.0000001% chances of reading
out the protected code.

I trust you for not cheating by modifying the rom image....  :)
Regards

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@...> wrote:

> Had eMail you the 8KB LPC2103 bootloader image.
> Please help to disassemble the first few line to find out if JTAG
> is default as ON or OFF, on the LPC2103.

I am not sure what I can do given it is documented in the manual (as
has been pointed out by another poster) that JTAG is ON by default on
the LPC2103.

I have responded to you email as to why I cannot work on the files you
have submitted.

Regards,

Jaya

unity0724 schrieb:

> I'm on LPC2103 now and more interested in LPC2103. Any idea:

As long as the attacker can get an unprotected chip and a chip
with your code in, your code can be read.
The question is always: How fast and with what effort.

IMHO the current CRP method is good enough for - let's say
curious - competitors.

And even w/o breaking CRP, there are many ways to compromise
SW (Dr.Dobbs had some nice columns about such).

-- 
42Bastian

Quoting jayasooriah <jayasooriah@...>:

> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>
>> >It would be a win-win for both Philips and LPC community if Philips
> would:
>> >
>> >a)  open a channel to acknowledge bugs as and when they are reported;
>> >b)  provide information as to what versions and parts these apply
> to; and
>> >c)  indicate when they plan to fix them and how users can check
> this out;
>>
>> Agreed, although to be fair to Philips they are far from unique in
> this regard.
>
> I am not sure.  I do not know of any other manufacturer offering
> security using similar methods.
>
Sorry  Jaya, I was referring to the defect reporting and fixing process 
not the
security setup.

Robert