Lpc2000

Ummm.... So far... I've confidence that Philips CRP is secure and 
hack-proof.

a) Hacking LPC2xxx by JTAG boundary scan.
- Cannot answer your questions.  But would that be same problems for 
all other ARM chips from TI, Atmel and AD??

b) Current Philips Code locking 
"Quite" safe.  as long as..
- No secret alternate way of programming or chip testing.  for e.g. 
parallel programming
- Boot Loader programmer remembers to disable all commands and only 
allows Chip Erasing when CRP enabled
- Boot Loader programmer remembers to erase the sector containing 
0x87654321 last (Not first sector to erase)

c) Re-writing bootloader and replacing philips code
Why want to do that? Problems...
- Flash programming timing will be different if philips switches 
silicon foundry
- It seems like all the 64Pin and 144pin devices (2294, 2292, 2214, 
2114, 2124, 2129, 2194...) are same silicon.  May be the boot loader 
initialize chip to different parts.   Oops! You might accidentally 
enable a 64KB flash sector with lots of faulty bits, though your 
128KB part becomes 256KB part free of charge...
- Philips Bootloader might initialize some unknown hardware or 
memory mapping properly.

d) Undocumented commands in BootLoader.
- It can be extra commands for flash memory testing, peeping or etc. 
However, not too much for concern as long as the guys writing the 
boot loader remembers to disables all these commands when CRP is 
enabled.

e) Allowing Customer App Program
- The LPC2xxx is NOT the correct part for a product with build in 
O/S and customer could develop their own application program (and 
where CRP on O/S section is needed).   You need an ARM with MMU.
- OR: Change the design to include an interpreter (e.g. JAVA Run 
time or Basic Interpreter)
- BTW, anybody has good recommendation for a Open Source Basic 
interpreter to be ported onto LPC2124??   I'm looking for one 
(Thanks in Advance)

f) May be another way to hack the Chip (I don't know..)
- Find out the exact clock cycles from reset and bootloader reads 
0x87654321 (This is fixed no of clock cycles from reset as No 
Interrupt, PLL disabled, Mem Accelerator is off)
- Pulse that few clock cycles to >100Mhz.    The ARM CPU Core seems 
could take >100MHz but not the philips flash memory.   Hence the CPU 
will read some "garbage bits"...  May be 0x97654331 (even after the 
ECC)
- Slow down the clock cycles to normal speed... as you get what you 
want after that.... Yeah!!
- Philips could fix this by reading the 0x87654321 multiple times, 
at random intervals.

=> To summarize, is it just whether you trust Philips or NOT....   

Finally, Merry X'Mas....
Have fun hacking the chip over the holidays....
Let me know the outcome... THANKS!!

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
>
> There is a technique called JTAG boundary scanning.  From memory, 
(I
> did this some years ago) boundary scanning does not require the 
target
> to come out of reset.  In such a system, the "ememy" is all over 
the
> code long before the processor even wakes up, and thus how quickly 
it
> takes to secure flash becomes irrelevant.
> 
> Incidentally, the unavailablity of BSDL files (for LPC devices) 
does
> not prevent this type of attack.  There are methods by which one 
can
> "discover" boundary architecture by blind scanning.
> 
> Philips needs to release a lot more information relating to its CRP
> implementation and be more forthcoming with describing thing as 
they
> are, not as they like us to believe (referring to "enabling" JTAG 
in
> the boot loader) before I would consider CRP as anything more than
> just a marketting gimmic.
> 
> Having said this, the issue with boot loader is that because 
Philips
> will not publish its boot loader code, we never know what is 
hidden in
> there that can be explioted by any would be attacker to void 
security
> features.
> 
> The 'T' command that exists in 2104/5/6 boot loader that Philips 
has
> not documented in any of the user manuals is one example.  What 
*is*
> this command there for and why is Philips not telling us about it?
> 
> I prefer not to say more about the 'T' command until Philips has 
had
> an opportunity to respond to my question in the new year.
> 
> Meanwhile, may your holiday break be happy and safe, and may the 
new
> year bring you more happiness and even more prosperity.
> 
> Best wishes to all ...
> 
> Jaya
> 
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
> > => Is there another way to force load+run code from RAM when both
> >    JTAG and ISP command are disabled?? 
> > Thanks, and Regards  /MH
> >
>