Lpc2000

OK, Following is my thinking about the security of CRP....(all
guessing only...)

a) JTAG not enabled when power up
- The 2 control bits on Reg PINSEL2 are '1' to enable. Meaning they
should be disabled when power up. (I guess all registers are reset
to zero upon power up)
- As long as BootLoader does not enable the JTAG port when CRP
enable, there is no way to read out code from JTAG port.

b) Undocumented commands in boot loader (e.g. 'T')
- Safe As long as Boot Loader disable all commands and only allows
Chip Erase when CRP enabled

c) Undocumented flash programming mode
- I believe there is some "undocumented programming mode" (like
parallel programming) in the manufacturing process.
- JTAG seems to be disabled when power up, so Philips must
have "some way" to program the boot loader onto the chip when chip
is just manufactured (or fresh from oven). Parallel programming
also saves manufacturing test time.
- => As long as philips keep secret of this programming mode. Who
cares....
- BTW, where is this chip fabricated, TSMC or MXIC?? Anybody knows??

d) Reversing the code when CRP enable...
Pls, You really cannot expect what hackers will do to your chip when
reversing it.... it is not something simple of just cracking the
flash programming method.... Following might be some possible way in
reading the code out:

i) Issue a chip erase to bootloader and timed power off (or reset)
 the chip half-way. Might ended up first sectors (with 0x87654321)
 erased only...
ii) Find out the exact few clock cycles (from reset) that BootLoader
 reads 0x87654321, pulse the few clock cycles to >100Mhz (ARM CPU
 seems can take >100Mhz but not the Flash+ECC). The CPU could read
 garbage from location 0x1FC (supposed to be 0x87654321)
iii) On LPC2103, where SRAM and RTC are powered by VBAT. Short VBAT
 to ground for 100uS when BootLoader running, Try lots of times
 and there could be chances that BootLoader does not hangup but CRP
 unlocked.

Overall, I still think the CRP protection mechanism is
reasonable "SECURE AND SAFE"..... Though some "screw up" of did not
put in "Hardware protection" in original design....
It is much better than the AT89C52 (date code before year 2000)
which is having 20+ ways of cracking it...

Have fun....and HAPPY NEW YEAR...
--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
>
> Oops!...  Back to same old question again...  
> How are you so sure that the JTAG port is not locked 
> up properly when CRP enabled??  
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
> wrote:
> >
> > Robert,
> > 
> > Boundary scan *is* implemented according to section 22.3 of the 
> user
> > manual for LPC214x parts.
> > 
> > "The scan chains that are around the core for production test are
> > reused in the debug state to capture information from the data 
bus 
> and
> > to insert new information into the core or the memory."
> > 
> > Disabling debug by actively executing instruction simply 
disables 
> the
> > reuse of these scan chains for debugging purposes through ETM.
> > 
> > The chains are however accessible long before the processor 
comes 
> out
> > of reset, and software security on LPC series is only as safe as 
> how
> > safely boundary scan specifications can be kept secret.
> > 
> > Leaving boundary scaning methods aside, there are other methods 
of
> > stalling the processor using ETM before it reaches third 
> instruction,
> > for example by manually clocking as it the processor out of 
reset.
> > 
> > Reducing the window of opportunity by disabling debug port 
quickly
> > serves only increases the effort it takes to sneak in.  It does 
not
> > prevent it.
> > 
> > I would urge anyone who depends on code in the CEP enabled device
> > being secure from preying eyes to seriosly look at issues as a 
> whole,
> > especially informatino that is not disclosed in the LPC scheme 
> where
> > CEP is dependent on execution of instructions in the boot loader 
> after
> > the procesor comes out of reset.
> > 
> > Jaya
> > 
> > --- In lpc2000@yahoogroups.com, "philips_apps" 
<philips_apps@y...> 
> wrote:
> > >
> > > Boundary Scan is not just a technique, it needs to be 
> implemented in 
> > > hardware as such AND IT IS NOT IMPLEMENTED on the devices on 
the 
> > > market so far.
> > > 
> > > Robert
> > > 
> > > --- 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.
> > >
> >
>