Lpc2000

Hope this answers all the questions raised on Flash security. Many
thanks to the group users. We appreciate your feedback. Please keep it
coming. Most of us are out till Jan 2 due to year end shutdown.

Happy Holidays and a Happy New Year 

- Philips Microcontroller Team

1) Am I right in assuming LPC2000 CRP is a software fence implemented
in the supplied boot loader code?

Partially. It is a combination of Hardware and Software supplied in
the bootloader code. Application running in micro has full access to
the entire memory space.

2) I am going to replace the Philips bootloader. I have figured out
how to do it.

Replacing the Philips bootloader is not recommended. It hides the
underlying hardware and allows Philips to use new flash technologies
without impacting the end user. Philips Bootloader may reside in ROM
or write/erase protected flash making replacement impossible. In
LPC2101/2/3 the bootloader resides in on-chip ROM.

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.

4) CRP in devices with internal flash and external bus.

The bootloader prevents external boot if CRP is enabled. User
Application residing in on-chip flash which needs to be protected
should not execute code from external memory.

5) Can bootloader write/erase itself?

No.

6) Can bootloader get corrupted?

Very unlikely if IAP/ISP calls are used for flash programming.
Very likely if Flash programming interface registers are directly
accessed for flash programming.

7) Can Philips comment if Quick-Pulse parallel programming can void CRP?

First of all there is no Quick-Pulse parallel programming option for
ARM based micros. We are sorry for not making clear what is meant by
"Parallel Programming" for ARM based micros. Parallel programming for
ARM based micros just means that the device can be mass programmed in
a commercial programmer. Parallel programmers still use JTAG and/or
ISP and go through the bootloader IAP routines to program the on-chip
flash. It does not matter how a part is programmed. If CRP is enabled
it will remain enabled once the part is programmed. If CRP is enabled
a parallel programmer can't access the flash unless it erases the
whole flash. Same applies to the ISP utility and JTAG based debuggers.

8) Is CRP option available for 2104/05/06?

Not yet.

9) Devices with external memory bus can be forced to boot from
external memory?

ONLY if CRP is NOT enabled or NO internal flash present. Also see (4).

10) Can I tell client Philips has confirmed CRP is not voided by PP?

Yes. Also see (7).

11) How do I reprogram a CRP enabled part?

Erase all user sectors in one go via ISP. You can reprogram it after a
power cycle.
Please note that the protected code vanished and was not visible to a
"spy" or "preying eyes".

Thank you for confirming JTAG is enabled upon reset before any code is
executed in a "virgin" device.  This confirms what my client has been
telling me all along.

This means that unless boot loader code is executed after power on
reset, *and* CEP byte is enabled by writing the magic word in the
specific location in user flash, the code in on-chip flash can be
compromised by JTAG debugging.

To know how this can be done, you need to look what the boot loader
does on starting up.  For 2148 part (see code snippet below with my
annotation, thanks to Joel for providing me the memory dump), the
first thing bootloader does is to "hastily" disable JTAG debug port.

I say "hastily" because as quickly as possible, it clears PINSEL2
register which disables JTAG debug port.  Then after clearing what
appears to be a SPECIAL undocumented register 40 bytes away from
PINSEL2, it restores PINSEL2 with what was originally there, but with
the bits 0-3 cleared.

Bits 0 and 1 of PINSEL2 are not documented in the user manual.  But
setting Bit 2 to a 1 will enable the JTAG debug port.

According to Table 62 on page 80 of 214X user manual, upon reset, Bit
2 is 0.  If this is the case, why is it necessary for the boot loader
to clear this bit?

Jaya


>        @ r0 = PINSEL2
>        @ PINSEL2 = 0
>        ldr        r2, =0xe002c014        @d004
>        mov        r3, #0x0               @d004
>        swp        r0, r3, [r2]           @d008
>
>        @ r1 = SPECIAL
>        @ SPECIAL = 0
>        add        r2, r2, #40            @d00c
>        swp        r1, r3, [r2]           @d010
>
>        @ PINSEL2 = r0 & ~7
>        bic        r3, r0, #7             @d014
>        str        r3, [r2, #-40]         @d018
>
>        @ continue with reset
>        ldr        pc, 0x7fffd020         @d01c

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 

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

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
>
> Thank you for confirming JTAG is enabled upon reset before any code is
> executed in a "virgin" device.  This confirms what my client has been
> telling me all along.
> 

i think you're mixing 2 things --- JTAG after reset and JTAG on
"virgin" device.

1) according to user manual '0x00000000' is written into every
pinselect register when reset is low, thus switching JTAG/GPIO pins
into GPIO mode Inputs. 
2) i assume that "virgin" device behaves different with GPIO, this can
be done using simpliest 32 AND gate circuit.

3) How ever -- Philips did not comment on my previous statement --- 
IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
all sectors? (by using boot update procedure with patched boot)
  If there is such possibility -- then i consider this CRP unsecure,
and  not effective enough.
Dixi.

Hello,

On Friday 23 December 2005 15:43, Felix wrote:
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
> > Thank you for confirming JTAG is enabled upon reset before any code is
> > executed in a "virgin" device.  This confirms what my client has been
> > telling me all along.
>
> i think you're mixing 2 things --- JTAG after reset and JTAG on
> "virgin" device.
>
> 1) according to user manual '0x00000000' is written into every
> pinselect register when reset is low, thus switching JTAG/GPIO pins
> into GPIO mode Inputs.
The reset state of pinsel2 (the one responsible for jtag) is detailed in table 
62. Bit 2 is determined by the state of pin1.26/rtck on the rising edge of 
reset. If this pin is driven low when the device comes out of reset, the jtag 
port will start enabled. That's why they're setting it to zero as early as 
possible. The JTAG statemachine is held in reset while the system reset is 
driven low, which is why the lpcs can't be debugged out of reset. Depending 
on when the debug logic is released from reset, a criticial timing issue 
could enable an attacker to force the device into debug mode before the 
bootloader had a chance to disable JTAG. Programming the debug control 
register to force the target into debug state takes 71 TCK cycles, or 24us at 
3MHz JTAG frequency. Of course, this is pure speculation, as the user manual 
is a bit unclear about the state of the test logic during reset. It is likely 
that because of the restrictions of -S arm cores (synchronize TCK with MCLK) 
this attack isn't possible.

> 2) i assume that "virgin" device behaves different with GPIO, this can
> be done using simpliest 32 AND gate circuit.
The virgin device has no bootloader which could disable the JTAG port, so JTAG 
comes up enabled, if RTCK is driven low.

>
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
>   If there is such possibility -- then i consider this CRP unsecure,
> and  not effective enough.
I haven't checked the bootloader updating mechanism yet - maybe the updates 
are digitally signed, and the IAP calls only accept updates with a valid 
signature?

> Dixi.
>

Regards,

Dominic

If I remember correctly the manual also says the pins are sampled a bit 
after the reset, which suggest that this is done by the bootloader code. 
If I would have to implement this myself in hardware, I would enable the 
jtag if the bootcode did not write to PINSEL register within the first 
few instructions executed. This way the JTAG is enabled if the device is 
virgin (no bootcode in the flash) and the device is protected if the 
right bootcode is present. The fact that the bootloader writes to the 
PINSEL register in the first instructions, may suggest that this is also 
what philips implemented. The other possibility is that they blow a fuse 
after programming the bootloader into the virgin device. I don't think 
they would leave a backdoor when they go to all the trouble of 
implementing the CRP.

Erasing the bootsector is also impossible because all ways to execute 
code other than the bootloader or the flashed program are disabled when 
CRP is enabled.

According a past thread, nobody succeeded in starting debugging directly 
after reset. The answer from philips_apps was that this was to implement 
the CRP. I have seen enough evidence to trust philips when they say 
there are no backdoors.

Richard.


Dominic Rath wrote:

> Hello,
>
> On Friday 23 December 2005 15:43, Felix wrote:
> > --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
> > > Thank you for confirming JTAG is enabled upon reset before any code is
> > > executed in a "virgin" device.  This confirms what my client has been
> > > telling me all along.
> >
> > i think you're mixing 2 things --- JTAG after reset and JTAG on
> > "virgin" device.
> >
> > 1) according to user manual '0x00000000' is written into every
> > pinselect register when reset is low, thus switching JTAG/GPIO pins
> > into GPIO mode Inputs.
> The reset state of pinsel2 (the one responsible for jtag) is detailed 
> in table
> 62. Bit 2 is determined by the state of pin1.26/rtck on the rising 
> edge of
> reset. If this pin is driven low when the device comes out of reset, 
> the jtag
> port will start enabled. That's why they're setting it to zero as 
> early as
> possible. The JTAG statemachine is held in reset while the system 
> reset is
> driven low, which is why the lpcs can't be debugged out of reset. 
> Depending
> on when the debug logic is released from reset, a criticial timing issue
> could enable an attacker to force the device into debug mode before the
> bootloader had a chance to disable JTAG. Programming the debug control
> register to force the target into debug state takes 71 TCK cycles, or 
> 24us at
> 3MHz JTAG frequency. Of course, this is pure speculation, as the user 
> manual
> is a bit unclear about the state of the test logic during reset. It is 
> likely
> that because of the restrictions of -S arm cores (synchronize TCK with 
> MCLK)
> this attack isn't possible.
>
> > 2) i assume that "virgin" device behaves different with GPIO, this can
> > be done using simpliest 32 AND gate circuit.
> The virgin device has no bootloader which could disable the JTAG port, 
> so JTAG
> comes up enabled, if RTCK is driven low.
>
> >
> > 3) How ever -- Philips did not comment on my previous statement ---
> > IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> > all sectors? (by using boot update procedure with patched boot)
> >   If there is such possibility -- then i consider this CRP unsecure,
> > and  not effective enough.
> I haven't checked the bootloader updating mechanism yet - maybe the 
> updates
> are digitally signed, and the IAP calls only accept updates with a valid
> signature?
>
> > Dixi.
> >
>
> Regards,
>
> Dominic
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>

On Friday 23 December 2005 15:43, Felix wrote:
> 3) How ever -- Philips did not comment on my previous statement ---
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
>   If there is such possibility -- then i consider this CRP unsecure,
> and  not effective enough.
> Dixi.
>
Bootloader update works by using ISP to load the supplied .hex file into RAM 
and executing it there. Because 'Write to RAM' is disabled when CRP is 
enabled, the bootloader can't be updated until the flash has been erased. 
When CRP is enabled, only all user sectors can be erased, so it isn't 
possible to erase sector 0 while preserving the content of the other sectors.
The LPCs are save in that regard.

Dominic

Hi Felix,

It is my guess (based on understanding of information on LPC devices
and history) that the two are the same.  In other words LPC comes out
of RESET with JTAG enabled (so you can recover when the on-chip flash
is NBG).  The only way to stop JTAG debugging is to actively disable
it on reset, and this is exactly what the boot loader is doing.

If this is true (and I say "if" becuase I have not got into further
disasesembling the rest of the boot loader on for the 2148 part) the
Boot Process Flow Chart on page 295 of the 214x user manual is flawed.

It would be untrue to claim that the Boot loader enables JTAG if CRP
is not enabled.  The boot loader disables JTAG first, and then enables
it if CRP is not enabled.

Dominic in later poster has explained how this can compromise CRP.

As to your last question, yes I have been told this is possible.  I
nave not done it, so I do not wish to comment on whether the method works.

Having got Philips to address the issue thus far was good, and I am
just hoping we can get more issues relating to CRP out in the open for
the benefit of all parties, including Philips.

I can see the LPC would fit well for use in security devices.  IMO, as
it stands using this in security context means Philips software team
is now in the trust domain.  This is an unecessary risk to take and
increases "attack surface area".

This is why I am looked at replacing the boot loader, but Philips will
not guarantee the part if this was done.  (You would expect Philips to
say this of course.)

One could work around this limitation by reloading the part with the
original boot loader should problems be found in any batch.

Jaya

--- In lpc2000@yahoogroups.com, "Felix" <felix_lazarev@y...> wrote:

>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
> >
> > Thank you for confirming JTAG is enabled upon reset before any code is
> > executed in a "virgin" device.  This confirms what my client has been
> > telling me all along.
> > 
> 
> i think you're mixing 2 things --- JTAG after reset and JTAG on
> "virgin" device.
> 
> 1) according to user manual '0x00000000' is written into every
> pinselect register when reset is low, thus switching JTAG/GPIO pins
> into GPIO mode Inputs. 
> 2) i assume that "virgin" device behaves different with GPIO, this can
> be done using simpliest 32 AND gate circuit.
> 
> 3) How ever -- Philips did not comment on my previous statement --- 
> IS THERE a way to reprogram BOOT on CPR enabled devices w/o erasing
> all sectors? (by using boot update procedure with patched boot)
>   If there is such possibility -- then i consider this CRP unsecure,
> and  not effective enough.
> Dixi.
>

Hi Richard,

My understanding is that like in other such devices, the GPIO pins are
sampled and copied on to relevant enable/disable bits during the reset
cycle before any code gets executed.

This is the method by which you can configure "virgin" devices to boot
for external memory, or enable JTAG even if the default behaviour is
that out of reset, external memory interface and JTAG are disabled.

This suggest the code to force these bits low is there to try and
mitigate security risks under these circumstances.  So unless have
information about these techniques (which Philips no doubt has) it
would not be easy for just anyone to do this.

If Philips had the fuse concept (like in ATMEL AVRs), this would have
been stated in the manuals (like ATMEL did) and that would make the
LPC part a candidate for security devices.

I do not mean to cast doubts on the ability of this audience.  However
the fact that nobody has defeated the security features says nothing
at all in the security context if methods are kept secret.

In other words, to trust LPC for security needs, one also has to trust
not only Philips but the many employes (and contractors) engaged by
Philips, past and present, who have access to this secret.  This is
the core argument against security by obscurity.

Jaya

--- In lpc2000@yahoogroups.com, Richard Duits <yahoo@r...> wrote:

> The other possibility is that they blow a fuse 
> after programming the bootloader into the virgin device.
> I don't think they would leave a backdoor when they go
> to all the trouble of implementing the CRP.

> According a past thread, nobody succeeded in starting 
> debugging directly after reset. The answer from
> philips_apps was that this was to implement the CRP.
> I have seen enough evidence to trust philips when
> they say there are no backdoors.
>

At 01:19 AM 12/23/05 +0000, philips_apps wrote:
>Hope this answers all the questions raised on Flash security. Many
>thanks to the group users. We appreciate your feedback. Please keep it
>coming. Most of us are out till Jan 2 due to year end shutdown.
>
>Happy Holidays and a Happy New Year
>
>- Philips Microcontroller Team

Nice summary.  With your permission I'll copy this to the FAQ (with 
appropriate credit of course).

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 01:19 AM 12/23/05 +0000, philips_apps wrote:
>11) How do I reprogram a CRP enabled part?
>
>Erase all user sectors in one go via ISP. You can reprogram it after a
>power cycle.
>Please note that the protected code vanished and was not visible to a
>"spy" or "preying eyes".

Or even prying eyes :)  Although the phrase preying eyes does have a 
certain appeal.

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/

Robert,

What does the ISP 'T' command do?  I found this command in version
1.51 of the boot loader for 2104/5/6 but it looks like it has been
omitted from Command Summary Table 142 on page 184 of the user manual.

Perhaps it would be useful also to to add such information to your FAQ.

Jaya

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> wrote:
>
> At 01:19 AM 12/23/05 +0000, philips_apps wrote:
> >Hope this answers all the questions raised on Flash security. Many
> >thanks to the group users. We appreciate your feedback. Please keep it
> >coming. Most of us are out till Jan 2 due to year end shutdown.
> >
> >Happy Holidays and a Happy New Year
> >
> >- Philips Microcontroller Team
> 
> Nice summary.  With your permission I'll copy this to the FAQ (with 
> appropriate credit of course).
> 
> 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/
>

Sorry for the typo error, version is 1.52, not 1.51.

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

>
> Robert,
> 
> What does the ISP 'T' command do?  I found this command in version
> 1.51 of the boot loader for 2104/5/6 but it looks like it has been
> omitted from Command Summary Table 142 on page 184 of the user manual.
> 
> Perhaps it would be useful also to to add such information to your FAQ.
> 
> Jaya

ok, i've tried couple experiments and done RE of the boot loader, and 
here are my findings:

1. JTAG pins are configured as GPIO inputs during reset, RTCK is 
sampled by the boot loader itself and GPIO are configured accordingly 
at latter stage
2. There is something, like CRP latch in the chip, the boot loader 
writes 0xFFFFFFFF there, if CRP is enabled
3. it is possible to rewrite the boot loader only, even on CRP 
protected devices.
4. it is possible to ENABLE the JTAG on CRP protected devices, using 
5 asm commands run from ram, however FLASH is still inaccessible from 
JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the less 
zeroing the CRP latch by means of JTAG enables full access to FLASH, 
provided, you stop CPU before that (zeroing CRP latch resets the cpu 
core. Only the core, not periferals)

This was tested on LPC2129, with latest bootloader.
tools :
IDA Pro Advanced,
philips on-field boot loader update utility
Olimex LPC2129 board.

--- In lpc2000@yahoogroups.com, "Felix" <felix_lazarev@y...> wrote:
>
> ok, i've tried couple experiments and done RE of the boot loader, 
and 
> here are my findings:
> 
> 1. JTAG pins are configured as GPIO inputs during reset, RTCK is 
> sampled by the boot loader itself and GPIO are configured 
accordingly 
> at latter stage
> 2. There is something, like CRP latch in the chip, the boot loader 
> writes 0xFFFFFFFF there, if CRP is enabled
> 3. it is possible to rewrite the boot loader only, even on CRP 
> protected devices.
> 4. it is possible to ENABLE the JTAG on CRP protected devices, 
using 
> 5 asm commands run from ram, however FLASH is still inaccessible 
from 
> JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the 
less 
> zeroing the CRP latch by means of JTAG enables full access to 
FLASH, 
> provided, you stop CPU before that (zeroing CRP latch resets the 
cpu 
> core. Only the core, not periferals)
> 
> This was tested on LPC2129, with latest bootloader.
> tools :
> IDA Pro Advanced,
> philips on-field boot loader update utility
> Olimex LPC2129 board.
>

Hi, Sorry, I do not understand a few points:
Item 3) How do you write to the boot loader??
        If CRP is ON.  JTAG should be disabled and user cannot
        load/execute to/from RAM (ISP Command also disabled)
Item 4) Same questions,  How do you put that few (5 ARM) 
        instructions onto the RAM and execute??  JTAG and ISP
        load/execute to/from RAM are disabled.

=> Is there another way to force load+run code from RAM when both
   JTAG and ISP command are disabled?? 
Thanks, and Regards  /MH

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
>

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

It is really hard to believe that any manufacturer of high volume
systems would buy a component with missing BSDL files!  That would
make tests costs and time too high.  Are you sure that major
manufacturers can not get BSDL files for LPC parts?  

-- Dave

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

Dave,

One poster on another forum says what client claims:

  http://www.embeddedrelated.com/groups/lpc2000/show/2534.php

Major manufactures surely can get them, but they may need the muscle
or sign NDAs.  I have always been able to obtain BSDL files using only
a Google search, but no hits for LPC except the above.

There is another hit but that is in a foreign language :(

Jaya

PS:  I can understand why Philips would not make BSDL files freely
available if it can be used to work out how to defeat CRP :)

--- In lpc2000@yahoogroups.com, "derbaier" <dershu@s...> wrote:

> It is really hard to believe that any manufacturer of high volume
> systems would buy a component with missing BSDL files!  That would
> make tests costs and time too high.  Are you sure that major
> manufacturers can not get BSDL files for LPC parts?  
> 
> -- Dave
>

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.

On Sunday 25 December 2005 02:35, Felix wrote:
> ok, i've tried couple experiments and done RE of the boot loader, and
> here are my findings:
>
> 1. JTAG pins are configured as GPIO inputs during reset, RTCK is
> sampled by the boot loader itself and GPIO are configured accordingly
> at latter stage
The manual says that PINSEL2 bit 2 is determined by the state of RTCK, and the 
bootloader behaves as if this is correct. It clears bits 0 to 2 very early, 
but saves PINSEL2's initial value. If 0x1fc isn't set to 0x87654321, the 
value of PINSEL2 is restored. I can't see where the bootloader samples RTCK, 
but even if it does, JTAG is reenabled before.

> 2. There is something, like CRP latch in the chip, the boot loader
> writes 0xFFFFFFFF there, if CRP is enabled
Where is that? It is written to the undocumented location 0x3fff8024 no matter 
if CRP is enabled or not.

> 3. it is possible to rewrite the boot loader only, even on CRP
> protected devices.
I don't see how that's possible. The bootloader-updater is first written to 
RAM, then rewrites Flash from there. You can't write to RAM using the ISP 
routines when CRP is enabled, nor can you use JTAG.

> 4. it is possible to ENABLE the JTAG on CRP protected devices, using
> 5 asm commands run from ram, however FLASH is still inaccessible from
> JTAG -- it's reading 0xFFFFFFFF once CRP latch is set. Never the less
> zeroing the CRP latch by means of JTAG enables full access to FLASH,
> provided, you stop CPU before that (zeroing CRP latch resets the cpu
> core. Only the core, not periferals)
How do you put these 5 asm commands into ram when CRP is enabled?
If flash is inaccessible "from JTAG" it is inaccessible from any code running. 
I guess you misinterpreted some things. What debugger did you use for your 
tests?

>
> This was tested on LPC2129, with latest bootloader.
> tools :
> IDA Pro Advanced,
> philips on-field boot loader update utility
> Olimex LPC2129 board.

Maybe you could provide more details? At what location is that "CRP latch"? I 
don't think that CRP is implemented in hardware. The manual says that CRP is 
available since bootloader version 1.61, which suggests that it was added 
after the silicon was finished. CRP seems to be implemented only in software 
(with the exception of non-standard JTAG handling, where nRESET keeps the 
test logic in reset, too, preventing debug out of reset).

Regards,

Dominic

Seems to me there is a whole lot of guessing going on with not one 
reproducible example of CRP failing for those versions in which CRP 
was implemented.

Philips has stated that CRP functions properly.  In my view, that is 
sufficient until someone PROVES with a documented, reproducible, 
example that it does not.  No guesswork, no suppositions, no what 
if's, just a documented, reproducible example.  No amount of testing 
can prove that it does work but it only takes one example to prove it 
doesn't.

Richard

Just because Philips says something doesn't mean that it's true - they may be 
holding information back, for whatever reason. This isn't a bad thing by 
itself. But the LPC's have undocumented functionality, and that's what makes 
people curious.

That said, I believe possible attacks on their CRP are very limited. Given the 
bootloader code is free of bugs there is no way of having the bootloader 
and/or sector 0 changed without destroying all the other flash content, too.

The JTAG comes up enabled, when the chip leaves reset, but it is disabled 
within a few microseconds. I've fed continous TCK cycles into the device (TMS 
high), and about 250us after the external reset was deasserted, the pulses 
are returned on RTCK. Another 2 us later, RTCK turns quiet again, until about 
30us have passed. This was on a device with CRP disabled, and fits to what is 
written in the user manual and the first few instructions of the bootloader 
code.

Regards,

Dominic

On Sunday 25 December 2005 19:10, rtstofer wrote:
> Seems to me there is a whole lot of guessing going on with not one
> reproducible example of CRP failing for those versions in which CRP
> was implemented.
>
> Philips has stated that CRP functions properly.  In my view, that is
> sufficient until someone PROVES with a documented, reproducible,
> example that it does not.  No guesswork, no suppositions, no what
> if's, just a documented, reproducible example.  No amount of testing
> can prove that it does work but it only takes one example to prove it
> doesn't.
>
> Richard

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@g...> 
wrote:
>
> Just because Philips says something doesn't mean that it's true - 
they may be 
> holding information back, for whatever reason. This isn't a bad 
thing by 
> itself. But the LPC's have undocumented functionality, and that's 
what makes 
> people curious.
> 
> That said, I believe possible attacks on their CRP are very 
limited. Given the 
> bootloader code is free of bugs there is no way of having the 
bootloader 
> and/or sector 0 changed without destroying all the other flash 
content, too.
> 
> The JTAG comes up enabled, when the chip leaves reset, but it is 
disabled 
> within a few microseconds. I've fed continous TCK cycles into the 
device (TMS 
> high), and about 250us after the external reset was deasserted, 
the pulses 
> are returned on RTCK. Another 2 us later, RTCK turns quiet again, 
until about 
> 30us have passed. This was on a device with CRP disabled, and fits 
to what is 
> written in the user manual and the first few instructions of the 
bootloader 
> code.
> 
> Regards,
> 
> Dominic

But you haven't proven that CRP doesn't work.  The only important 
result is when you successfully grab the code from a protected 
device and document the attack so it can be reproduced.

The questions have been asked and answered; CRP works.  The 
alternative to accepting that assertion is to choose another 
device.  There are a lot of them around.

But, every device has warts and every device can be attacked with an 
SEM if it is worth the effort.  Even when the flash is buried 
beneath an oxide layer (Microchip).  Sure, it's harder (impractical, 
even) but not impossible.  It just has to be worth the cost of the 
attack.

The only exception is an FPGA loaded from a removable boot loader.  
Lose power; lose configuration and crypto keys.  And even the boot 
loader uses encryption during configuration transfer.  Reference 
Xilinx re: crypto applications.

Richard

The location FMDEV[9] (at 0x3fff8024) contains the flash lock bits. 
Writing 0xffffffff to it locks all sectors from write or erase.

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@g...> 
> > 2. There is something, like CRP latch in the chip, the boot loader
> > writes 0xFFFFFFFF there, if CRP is enabled
> Where is that? It is written to the undocumented location 0x3fff8024
no matter 
> if CRP is enabled or not.

Dear Richard,

IMHO you are not being security conscious.  It would be wise check if
you boot loader has a 'T' command, and what it does.

Jaya

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:

>
> Seems to me there is a whole lot of guessing going on with not one 
> reproducible example of CRP failing for those versions in which CRP 
> was implemented.
> 
> Philips has stated that CRP functions properly.  In my view, that is 
> sufficient until someone PROVES with a documented, reproducible, 
> example that it does not.  No guesswork, no suppositions, no what 
> if's, just a documented, reproducible example.  No amount of testing 
> can prove that it does work but it only takes one example to prove it 
> doesn't.
> 
> Richard
>

Dear Dominic,

How do you know that the supplied boot loader is free of bugs?  Have
you inspected the source and/or tested the binaries?

IMHO you cannot say it is free of bugs even in a practical sense.  I
would like to see Philips tell us to what level it will certify boot
loader code.

Regards,

Jaya

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@g...> 
> That said, I believe possible attacks on their CRP are very limited.
Given the 
> bootloader code is free of bugs there is no way of having the
bootloader 
> and/or sector 0 changed without destroying all the other flash
content, too.
> 
> The JTAG comes up enabled, when the chip leaves reset, but it is
disabled 
> within a few microseconds. I've fed continous TCK cycles into the
device (TMS 
> high), and about 250us after the external reset was deasserted, the
pulses 
> are returned on RTCK. Another 2 us later, RTCK turns quiet again,
until about 
> 30us have passed. This was on a device with CRP disabled, and fits
to what is 
> written in the user manual and the first few instructions of the
bootloader 

> code.
> 
> Regards,
> 
> Dominic

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

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

Stipulated that LPC won't meet your needs.  Now are we done?

Richard

Dear Richard,

The discussion on CRP is for all in this forum who are interested in
this feature

It is not unreasonable to question the veracity of CRP claims.

As there are outstanding issues still unresolved, the answer is no.

Kind regards,

Jaya

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:

>
>  
> > 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. 
> 
> Stipulated that LPC won't meet your needs.  Now are we done?
> 
> Richard
>

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
>
> Dear Richard,
> 
> The discussion on CRP is for all in this forum who are interested in
> this feature

This is a lightweight forum, hardly the place to get definitive 
answers.  Just a bunch of guys, hanging around on Yahoo! sharing 
experiences.  Some stuff will be right on, some will be completely 
wrong.  Or perhaps right for the wrong reasons.

Get on an airplane and go see the engineers.  If your silicon 
requirement is large enough, have them come see you.

Or get your customer representative involved.  Hand them a list of 
issues and ask for written responses, soonest.  If they don't respond, 
choose another supplier.

There are formal channels for resolving these kinds of things.  But, I 
doubt that Yahoo is one of them.  In fact, this is one of the only 
forums where reps of a major manufacturer even bother to reply.  Most 
ignore these forums entirely.  I would...

Richard

Robert, what I am doing is exactly that -- sharing experiences.  Not
sure why you seem to want to quench the discussion on CRP and security.

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:

> This is a lightweight forum, hardly the place to get definitive 
> answers.  Just a bunch of guys, hanging around on Yahoo! sharing 
> experiences.  Some stuff will be right on, some will be completely 
> wrong.  Or perhaps right for the wrong reasons.

Exactly, that's my point. If you accept that the bootloader is free of bugs, 
you can be reasonably sure that there are no holes left. At least there are 
no conceptual holes.
If you take possible bugs into account, there is no safe CRP. But that's a 
choice that is up to you.

Regards,

Dominic

On Sunday 25 December 2005 23:21, jayasooriah wrote:
> Dear Dominic,
>
> How do you know that the supplied boot loader is free of bugs?  Have
> you inspected the source and/or tested the binaries?
>
> IMHO you cannot say it is free of bugs even in a practical sense.  I
> would like to see Philips tell us to what level it will certify boot
> loader code.
>
> Regards,
>
> Jaya

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
>
> Robert, what I am doing is exactly that -- sharing experiences.  Not
> sure why you seem to want to quench the discussion on CRP and 
security.

I guess I am just bored of the month long harangue of Philips.  This 
isn't a discussion, it is a prolonged attack without one shred of 
proof that Philips is either incorrect or hiding something.

I just read through the section in the LPC2292 datasheet (3d paragraph 
of section 6.2) - it seems pretty clear to me.

JTAG doesn't talk to the hardware for programming, it uses IAP which 
is implemented in the boot code.  This from Errata IPA1, 14 NOV 2005.  
One can suppose that the boot code knows what to do about JTAG access 
to flash given that the boot code does that actual programming as well 
as implementing CRP.  If Philips says JTAG is disabled if CRP is 
enabled, where is the proof that they are wrong?

Go to the source, get the answers in writing, share the results, if 
they aren't covered by an NDA.  Again, there are formal channels for 
this.

Richard

> 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

Current CRP implementated by Philips should be secure enough.

Please look at the CHIP from TOP-DOWN, the bigger picture:
If only programming method is through Serial Port, why using
software CRP is not safe??
- Assuming JTAG port is locked down properly, and the is no
  undocumented parallel port programming.
What is the problem of using software CRP??

The other Atmel/Pic chip are having parallel, Serial-SPI
and etc types of programming, hence they need extra CRP locking
hardware.  All these are hardware flash programming state machines.

Regards   /MH

On Monday 26 December 2005 02:37, rtstofer wrote:
> I guess I am just bored of the month long harangue of Philips.  This
> isn't a discussion, it is a prolonged attack without one shred of
> proof that Philips is either incorrect or hiding something.
Sorry, but please ignore the remainder of this thread. Seems there are more 
people interested in this discussion than those that want to see it stopped.

> I just read through the section in the LPC2292 datasheet (3d paragraph
> of section 6.2) - it seems pretty clear to me.
>
> JTAG doesn't talk to the hardware for programming, it uses IAP which
> is implemented in the boot code.  This from Errata IPA1, 14 NOV 2005.
> One can suppose that the boot code knows what to do about JTAG access
> to flash given that the boot code does that actual programming as well
> as implementing CRP.  If Philips says JTAG is disabled if CRP is
> enabled, where is the proof that they are wrong?
If you're able to access JTAG on the device, you're done. This isn't Philips' 
fault, nor is there anything (reasonable) they could do against it. I doubt 
ARM lets them modify the ARM7TDMI-S macrocell to that extent. JTAG allows you 
to control the core, and is only bound by the limits that apply to any code 
that runs on the device. The manual is unclear regarding when JTAG is enabled 
and disabled - that's why I've tested it myself. I believe the LPCs are safe 
in that regard.

> Go to the source, get the answers in writing, share the results, if
> they aren't covered by an NDA.  Again, there are formal channels for
> this.
If any information regarding CPR was available only under an NDA that would 
make me even more suspicious. Guess we're from two different worlds.

>
> Richard

Regards,

Dominic

> > IMHO you cannot say it is free of bugs even in a practical 
sense.  I
> > would like to see Philips tell us to what level it will certify 
boot
> > loader code.
> >
> > Regards,
> >
> > Jaya
>

Agreed, when you place the purchase order, ask for a guarantee that 
the boot loader will provide adequate protection as you define it.  
If they won't provide such a guarantee, pick another supplier.

But, you might as well start new vendor selection now.  Nobody is 
going to guarantee that anything is 'perfect'.

Look at the disclaimers for medical or nuclear use.  Nobody wants 
their commercial product in life support or hazardous applications.

There are enough chips to sell without having to provide custom 
guarantees.

Richard

> If any information regarding CPR was available only under an NDA 
that would 
> make me even more suspicious. Guess we're from two different 
worlds.
>
> Regards,
> 
> Dominic
>

I guess so...  Everything that a competitor would find useful in 
upgrading their product will be covered by an NDA.  I would find it 
more suspicious if it were fully disclosed.  That would mean that 
protecting the ideas is meaningless hence the ideas themselves have 
no competitive value.

Protecting information is not the same as concealing a defect.

Richard

Richard,

Perhaps if I give you a hint of what is in the T command does, I hope
you will change your mind as to what this CRP and security discussion
is really about.

If we are to trust the boot loader, and that all we need to know about
it has been disclosed by Philips, then what is this 'T' command that
is exists in boot loader 1.52 for LPC 21/4/5/6?

The T command accepts arguments like the other commands. It prints
things and for the casual user, exits and does notthing more.

However, if you twiddled GPIO pins 0-7 when the T command is invoked,
something a different piece of code is called.  This only happens if
GPIO pins are non-zero when the T command is invoked.

Would you not be interested to know what this undocumented 'T' command
in the boot loader version 1.52 for LPC2104/5/6 does, that has hidden
functions?

Does it also exist on the boot loader for parts which support CRP?  Is
the T command disabled when CRP is enabled?  If not, can it be used to
read memory that is otherwise protected?

I am not suggesting there is a conspiracy theory.  I do not see any
point in tring to double guess its functionality until Philips comes
back to work and tells us about this.

However, the existence of the T command (irrespective of whatever it
does) it is enough reason point out that boot loader holds more than
what we think it holds.

Therefore, CRP enabled or not, it would not be a good idea to include
LPC in your trust domain if you do not want your code to be exposed to
preying eyes.

I am sure you would agree many in this forum would like to know what
this T command does, even if does not do anything harmful.

Jaya

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
> Protecting information is not the same as concealing a defect.

Richard,

Perhaps if I give you a hint of what is in the T command does, I hope
you will change your mind as to what this CRP and security discussion
is really about.

If we are to trust the boot loader, and that all we need to know about
it has been disclosed by Philips, then what is this 'T' command that
is exists in boot loader 1.52 for LPC 21/4/5/6?

The T command accepts arguments like the other commands. It prints
things and for the casual user, exits and does notthing more.

However, if you twiddled GPIO pins 0-7 when the T command is invoked,
something a different piece of code is called.  This only happens if
GPIO pins are non-zero when the T command is invoked.

Would you not be interested to know what this undocumented 'T' command
in the boot loader version 1.52 for LPC2104/5/6 does, that has hidden
functions?

Does it also exist on the boot loader for parts which support CRP?  Is
the T command disabled when CRP is enabled?  If not, can it be used to
read memory that is otherwise protected?

I am not suggesting there is a conspiracy theory.  I do not see any
point in tring to double guess its functionality until Philips comes
back to work and tells us about this.

However, the existence of the T command (irrespective of whatever it
does) it is enough reason point out that boot loader holds more than
what we think it holds.

Therefore, CRP enabled or not, it would not be a good idea to include
LPC in your trust domain if you do not want your code to be exposed to
preying eyes.

I am sure you would agree many in this forum would like to know what
this T command does, even if does not do anything harmful.

Jaya

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
> Protecting information is not the same as concealing a defect.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
>
> Richard,
> 
> Perhaps if I give you a hint of what is in the T command does, I 
hope
> you will change your mind as to what this CRP and security 
discussion
> is really about.

I would be more interested if the question was related to CRP or 
Flash Security as the subject reads.  Your issue is with a version 
of the boot code that runs on a device that doesn't support CRP.  By 
the way, it is the version in my 2106, as well.  I can't say I much 
care how the boot code works, as long as I can load the flash with 
the factory provided utility.  I know I don't have CRP and don't 
care.

For the 2294, the current boot code is at least ver 1.63 and CRP 
wasn't implemented until ver 1.60.  Is there a T command in the 
latest version of the boot code for the 2294?  If not, the question 
above is irrelevant.  And that is the issue - there is not one shred 
of evidence that the boot code, as implemented, doesn't work as 
described in the datasheet and errata.

You have stated that a software approach to security was not 
acceptable for your application.  If this is your position, you will 
never be satisfied with Philips.  Why pursue it?

Richard

Hi All,

If somebody with 2294 and version 1.63 of the boot loader can confirm
the T command exists, please do tell me and I am happy to RE the code
and to find out if T commmand does anything like that in version 1.52
boot loader for 2104/5/6.

Richard,

As to your "shred of evidence" comment, the document clearly states
that on RESET, JTAG is DISABLED, and that it is only enabled BY
SOFTWARE when CRP is not enabled.

The very first three instructions of the start up code code on a CRP
supported device demonstrates otherwise.  I am puzzled why you still
believe there is not a shred of evidence that the hardware does not do
what Philips would want us to believe it does.

As another poster pointed out, CEP appears to be something Philips
came up as an afterthought well after hardware implentation in
silicon.  So I am interested in how well such a CRP regime will work
as I am sure many others would.

I am curioius why you sound so rattled when I question if CRP really
does what it was intended to do, and why you are so keen on quenching
this discussion.

I promise ... wont engage in bilateral discussion with you through
this forum any more.  We really should wait untill Philips is back
from hols.  I am happy to take it off this forum onto direct email. 
You know how to reach me :)

Regards,

Jaya

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:

> I would be more interested if the question was related to CRP or 
> For the 2294, the current boot code is at least ver 1.63 and CRP 
> wasn't implemented until ver 1.60.  Is there a T command in the 
> latest version of the boot code for the 2294?

> If not, the question 
> above is irrelevant.  And that is the issue - there is not one shred 
> of evidence that the boot code, as implemented, doesn't work as 
> described in the datasheet and errata.
> 
> You have stated that a software approach to security was not 
> acceptable for your application.  If this is your position, you will 
> never be satisfied with Philips.  Why pursue it?
> 
> Richard

On Monday 26 December 2005 04:32, rtstofer wrote:
> For the 2294, the current boot code is at least ver 1.63 and CRP
> wasn't implemented until ver 1.60.  Is there a T command in the
> latest version of the boot code for the 2294?  If not, the question
> above is irrelevant.  And that is the issue - there is not one shred
> of evidence that the boot code, as implemented, doesn't work as
> described in the datasheet and errata.
I have a LPC2294 with boot code version 1.63, and it implements the 'T' 
command. I've quickly checked through the corresponding code, and it does 
access a GPIO register (E0028000), as Jaya said. Haven't had time to look 
further into it.

Regards,

Dominic

Thanks Dominic,

This command also exists boot code version 2.1 for LPC 2194.  If
someone with a CRP enabled can drop me an email, I can give you more
information about what arguments are needed so you can tell us all
what you find.

Jaya

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@g...> wrote:
> I have a LPC2294 with boot code version 1.63, and it implements the 'T' 
> command. I've quickly checked through the corresponding code, and it
does 
> access a GPIO register (E0028000), as Jaya said. Haven't had time to
look 

> further into it.
> 
> Regards,
> 
> Dominic
>

I meant LPC 2148 (damn fingers!)

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

>
> Thanks Dominic,
> 
> This command also exists boot code version 2.1 for LPC 2194.  If
> someone with a CRP enabled can drop me an email, I can give you more
> information about what arguments are needed so you can tell us all
> what you find.
> 
> Jaya

I do not wish to comment on what the T command is there for, except to
say it most will be surprised to know what it does, let alone that it
exists.  I would like to give Philips an opportunity to respond to my
original question first.

Meanwhile, could those interested in checking out CRP feature to do
the following and post the results:

1/  Enable CRP on a device (blank one will do).

2/  Verify CRP is enabled by Entering "G 0 A" and noting the result.

3/  Enter "G tEsT A" and observe what happens.

4/  Enter "T 1073741824 4 8 0" and observe the result code.

I like to use these results to confirm that I have understood the boot
loader code correctly.  I am not able to do these tests myself because
my board will not arrive for another couple of weeks.

I will follow up with a reference to my documentation of boot loader
internals when this is ready, hopefully very soon.

Many thanks.

Jaya

--- In lpc2000@yahoogroups.com, Dominic Rath <Dominic.Rath@g...> wrote:
>
> On Monday 26 December 2005 04:32, rtstofer wrote:
> > For the 2294, the current boot code is at least ver 1.63 and CRP
> > wasn't implemented until ver 1.60.  Is there a T command in the
> > latest version of the boot code for the 2294?  If not, the question
> > above is irrelevant.  And that is the issue - there is not one shred
> > of evidence that the boot code, as implemented, doesn't work as
> > described in the datasheet and errata.
> I have a LPC2294 with boot code version 1.63, and it implements the 'T' 
> command. I've quickly checked through the corresponding code, and it
does 
> access a GPIO register (E0028000), as Jaya said. Haven't had time to
look 

> further into it.
> 
> Regards,
> 
> Dominic
>

Hello,

I've put a small program that blinks the LED of my Olimx H2294 board into the 
on-chip flash, with 0x1fc set to 0x87654321. Bootloader is version 1.63.
JTAG doesn't work anymore.

Here are the results you wanted:
190 A	(entered G 0 A)
19tEsT A (entered G tEsT A)
191073741824 4 8 0 (entered T 1073741824 4 8 0)

The reply was '19' (CODE_READ_PROTECTION_ENABLED) each time, indicating that 
the CRP works as promised.

Regards,

Dominic

On Sunday 01 January 2006 15:45, jayasooriah wrote:
> I do not wish to comment on what the T command is there for, except to
> say it most will be surprised to know what it does, let alone that it
> exists.  I would like to give Philips an opportunity to respond to my
> original question first.
>
> Meanwhile, could those interested in checking out CRP feature to do
> the following and post the results:
>
> 1/  Enable CRP on a device (blank one will do).
>
> 2/  Verify CRP is enabled by Entering "G 0 A" and noting the result.
>
> 3/  Enter "G tEsT A" and observe what happens.
>
> 4/  Enter "T 1073741824 4 8 0" and observe the result code.
>
> I like to use these results to confirm that I have understood the boot
> loader code correctly.  I am not able to do these tests myself because
> my board will not arrive for another couple of weeks.
>
> I will follow up with a reference to my documentation of boot loader
> internals when this is ready, hopefully very soon.
>
> Many thanks.
>
> Jaya

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

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

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

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

As sure as the people in Philips who specified the boot loader.

OK, If you are so sure then...
- You should be able to reverse the code easily...
- Forget about JTAG boundary scan, control the ARM7 CPU directly
- And ...Don't worry about the small timing window (The small 
time slot before ARM7 CPU disables JTAG after reset) => may be 
you can simply "ENLARGE" it by clocking the CPU at lower freq of 
few 10KHz...

Try that when you have your new LPC2194 board.
And may be later you can lead a class action suit.... Hee...

Have fun and HAPPY NEW YEAR....



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

>
> --- 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??  
> 
> As sure as the people in Philips who specified the boot loader.
>