Lpc2000

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
>