Lpc2000

Reasonable questions.  Here are my answers.

a)  No.  The documentation is quite clear on what you cannot do to
defeat code security for ATMEL AVR.  AVR has the notion of "fuses"
while LPC does not seem to.

b)  IMHO you have too many provisoes to your "quite" safe critiera. 
Lets wait till Philips tells us what the "T" command does.

c)  Client will not include Philips (employees, partners, contractors,
cleaners, etc) in its trust domain.  If code is available in a form
the client can certify, client will use the loader AS-IS.  Otherwise
client will replace it assuming hardware supports security, without
any need for secrecy or obsfucation of code in boot loader code.

d)  What "it can be" is a lot of things, including methods to bypass CRP.

e)  Not sure what you on about.  We need CRP for security.  Nothing
said about OS or MMU requirements.  (BASIC is secure!?! :))

f)  It is a well established theory that you cannot build security
using software alone if the there is no support for it in hardware. 
Based on what I have seen so far, Philips had not included CRP goal in
the hardware design, and it is just a software afterthought.

Regards,

Jaya

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
>
> 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
> > >
> >
>