Hi all,

I would like to know what are the limitations of the CRP protection
because this kind of protection is controlled by the onchip bootloader
so by software and I think that it is perhaps less efficient than a
hardware code read protection feature ...

In fact, what are the solutions to access the flash code content even
if CRP is enabled ?

I have seen that ATMEL proposes a flash security bit which disables
the JTAG and prevents from flash access. This protection can not be
suppressed except by erasing the flash which is more secure to my mind
.. Am I worng ?

Thanks in advance

Yahoo! Groups Links Start a New Thread

All I can say to this, is "oh, no, not again....."

To the sender of the message below, I'd recommend you do a search
on "CRP" over the past few months: you'll find plenty there to keep you
busy for a while. You'll have to make your own mind up, though, as
consensus is a bit lacking, to say the least.

Brendan

--- In l..., "croquettegnu" wrote:
>
> Hi all,
>
> I would like to know what are the limitations of the CRP protection
> because this kind of protection is controlled by the onchip bootloader
> so by software and I think that it is perhaps less efficient than a
> hardware code read protection feature ...
>
> In fact, what are the solutions to access the flash code content even
> if CRP is enabled ?
>
> I have seen that ATMEL proposes a flash security bit which disables
> the JTAG and prevents from flash access. This protection can not be
> suppressed except by erasing the flash which is more secure to my mind
> .. Am I worng ?
>
> Thanks in advance
>

Yahoo! Groups Links Start a New Thread

croquettegnu wrote:

>Hi all,
>
>I would like to know what are the limitations of the CRP protection
>because this kind of protection is controlled by the onchip bootloader
>so by software and I think that it is perhaps less efficient than a
>hardware code read protection feature ...
>
>In fact, what are the solutions to access the flash code content even
>if CRP is enabled ?
>
>
>
Please search the message archive, please? This has been talked to
death on this forum! Try to do a little research before you ask a
question? ok?

TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------

Yahoo! Groups Links Start a New Thread

Hi, You might be right but the philips chip has sufficient
code read protect mechanism build in. This is some old topic..
There had been some heated discussions on this issue and so far
the flash read protection had been proven cannot be bypassed and
JTAG port can been locked up properly.

Umm.. Not advisable to re-start another round of endless debating..
Everybody please better stop here before it is too late... :)
Regards

--- In l..., "croquettegnu"
wrote:
>
> Hi all,
>
> I would like to know what are the limitations of the CRP protection
> because this kind of protection is controlled by the onchip
bootloader
> so by software and I think that it is perhaps less efficient than a
> hardware code read protection feature ...
>
> In fact, what are the solutions to access the flash code content
even
> if CRP is enabled ?
>
> I have seen that ATMEL proposes a flash security bit which disables
> the JTAG and prevents from flash access. This protection can not be
> suppressed except by erasing the flash which is more secure to my
mind
> .. Am I worng ?
>
> Thanks in advance
>

Yahoo! Groups Links Start a New Thread

Hello,

--- In l..., "croquettegnu" wrote:
>
> Hi all,
>
> I would like to know what are the limitations of the CRP protection
> because this kind of protection is controlled by the onchip bootloader
> so by software and I think that it is perhaps less efficient than a
> hardware code read protection feature ...

Not only less efficient but also not as safe.

> In fact, what are the solutions to access the flash code content even
> if CRP is enabled ?

I understand there are.

No one has posted one in this forum.

Posting such a solution would IMHO be breaking relevant laws in many
countries relating to disclosure of security circumventing measures.

> I have seen that ATMEL proposes a flash security bit which disables
> the JTAG and prevents from flash access. This protection can not be
> suppressed except by erasing the flash which is more secure to my mind
> .. Am I worng ?

I do not know which variant you are referring to, but in general you
have to look for evidence that indicates that security is supported at
the hardware level.

A software afterthought (as I characterises the LPC CRP feature) in
general only stops novices and gives a false sense of security IMO.

Example of hardware support in Mega32: "The Chip Erase will erase the
Flash and EEPROM memories plus Lock bits. The Lock bits are not reset
until the program memory has been completely erased."]

> Thanks in advance

You need to be aware that boot loader of LPC family mitigates (i.e.
tries to reduce the impact of) but not remove the window of
opportunity that exists between chip reset and when the boot loader
actually disables JTAG port.

You can read the original threads (complete with insults, emotions and
all). I thought this summary would be useful.

Jaya

Yahoo! Groups Links Start a New Thread

Thanks Jaya for your clear response. This is what I thought. I will
search for other topics since everybody advised me...

--- In l..., "jayasooriah" wrote:
>
> Hello,
>
> --- In l..., "croquettegnu" wrote:
> >
> > Hi all,
> >
> > I would like to know what are the limitations of the CRP protection
> > because this kind of protection is controlled by the onchip bootloader
> > so by software and I think that it is perhaps less efficient than a
> > hardware code read protection feature ...
>
> Not only less efficient but also not as safe.
>
> > In fact, what are the solutions to access the flash code content even
> > if CRP is enabled ?
>
> I understand there are.
>
> No one has posted one in this forum.
>
> Posting such a solution would IMHO be breaking relevant laws in many
> countries relating to disclosure of security circumventing measures.
>
> > I have seen that ATMEL proposes a flash security bit which disables
> > the JTAG and prevents from flash access. This protection can not be
> > suppressed except by erasing the flash which is more secure to my mind
> > .. Am I worng ?
>
> I do not know which variant you are referring to, but in general you
> have to look for evidence that indicates that security is supported at
> the hardware level.
>
> A software afterthought (as I characterises the LPC CRP feature) in
> general only stops novices and gives a false sense of security IMO.
>
> Example of hardware support in Mega32: "The Chip Erase will erase the
> Flash and EEPROM memories plus Lock bits. The Lock bits are not reset
> until the program memory has been completely erased."]
>
> > Thanks in advance
>
> You need to be aware that boot loader of LPC family mitigates (i.e.
> tries to reduce the impact of) but not remove the window of
> opportunity that exists between chip reset and when the boot loader
> actually disables JTAG port.
>
> You can read the original threads (complete with insults, emotions and
> all). I thought this summary would be useful.
>
> Jaya
>

Yahoo! Groups Links Start a New Thread

I have new information that may help tip the balance in forming a
consensus. Really I don't want to spend an extra millisecond on this.

The new information I have is that that Jayasooriah is publicly
asserting on a web site that Philips claims with regard to LPC2xxx
series microcontroller Code Read Protection (CRP) are not accurate
due to a single piece of claimed circumstantial evidence that happens
to be bogus as credible circumstantial evidence. The reason the
claimed circumstantial evidence is bogus is due to the following
credible explanations. The claimed evidence in fact enables the JTAG
pins to be used as normal GPIO pins under all reset circumstances if
CRP is enabled and because of a common engineering practice.

Even if the evidence was genuinely circumstantial it is not ethical
or accurate to imply or claim the evidence is authoritative proof of
inaccuracy.

I will try and present the argument in as few words as possible in as
relevant a form as possible. It is important to realise that meaning
of the words 'debug' and 'enable' is contextually driven.

1. JTAG hardware is peripheral hardware whose shared external pin
connections can be enabled (connected) or disabled (disconnected) by
ensuring a specific debug select pin is pulled low on reset. If the
pin is left alone then JTAG pins will not be externally connected by
default on the LPC2148 (due to internal pull-up resistors on Port 1).
JTAG pins can also be disconnected by setting a bit in a pin select
register after reset.

2. There is no theoretical reason why Philips LPC series CRP (Code
Read Protection) will not work as documented. While after reset JTAG
might be enabled and attempting to assert debug signals (a peripheral
engine is on and revving), the internal debug bus signals JTAG may be
attempting to assert may be disabled from acting (the peripheral
engine gears are not engaged). I will assume this is true for the
rest of this posting as it gives a possible concrete explanatory
framework. There is no proof it is not true. Other mechanisms also
have theoretical validity.

3. Quote from Philips manual UM10139 (Volume 1: LPC214x User Manual,
Rev. 01 15 August 2005) page 297:

"Code read protection is enabled by programming the flash address
location 0x1FC (User flash sector 0) with value 0x8765 4321
(2271560481 Decimal). Address 0x1FC is used to allow some room for
the FIQ exception handler. When the code read protection is enabled
the JTAG debug port, external memory boot and the following ISP
commands are
disabled:
Read Memory
Write to RAM
Go
Copy RAM to Flash"

End of quote

Clearly if CRP is enabled then we don't care any more about JTAG and
we want full access to the JTAG debug pins as GPIO pins EVEN IF THE
DEBUG SELECT PIN HAPPENED TO BE LOW ON RESET and so enabled the JTAG
debug PORT. I could hardly think of a simpler solution to get back
use of the pins as GPIO pins than disabling JTAG pins that may have
unintentionally enabled during reset. Hack attempts will just spin
JTAG uselessly during this time.

There is also another point, it is regarded as sound engineering
practice to disable peripherals that may be enabled and are not
required to save power.

It is important to realise that once CRP is enabled we can now we
don't have to ensure the debug select pin is not pulled low on reset.

I would say very clever Philips and well done.

With regard to actually enabling debug in its totality after deciding
CRP is not enabled, this may simply be a matter of writing to an
undocumented register. The important point is debug in its capacity
to act must be disabled on reset, rather than debug is enabled then
disabled then possibly enabled again. All we have seen is a claim of
evidence that in fact ensures pins can be used as GPIO pins. There is
no harm in partial enablement of debug if there is a missing piece
that prevents debug from acting.

4. Following are two paragraphs from
http://www.cast.com.au/esdk/lpc2/boot-loader.html#LPC[0]. At the end
of the page is a copyright statement "copyright (c) Jayasooriah 2002-
2006 ... updated 01 April 2006". The name Jayasooriah contains a link
to the CV of Jayasooriah: http://www.cast.com.au/jayasooriah/

Start of quote:

"Arising out of my investigation into the boot loader for the above
reasons, I found out that Philips is not accurate in relation to its
documentation of CRP (code read protection) features. For example,
the user manual for LPC2148 clearly states upon reset JTAG debugging
is disabled, and that this is enabled by the boot loader if CRP
feature is not enabled.

"However the first thing the boot loader in LPC2148 does (in a quite
hasty fashion as if to minimise the window of opportunity) is to
disable JTAG debug port. This code is executed for both hardware and
watchdog resets. Why disable JTAG debug port if is indeed already
disabled on reset?"

End of quote.

5. The question has already been answered: get back the GPIO ports.
The evidence is bogus. Jayasooriah appears to be trying to get cheap
shots at by asserting an old and well known vulnerability the
industry has learnt long ago to avoid in new designs.
John Heenan
--- In l..., "brendanmurphy37"
wrote:
>
>
> All I can say to this, is "oh, no, not again....."
>
> To the sender of the message below, I'd recommend you do a search
> on "CRP" over the past few months: you'll find plenty there to keep
you
> busy for a while. You'll have to make your own mind up, though, as
> consensus is a bit lacking, to say the least.
>
> Brendan
>
> --- In l..., "croquettegnu"
wrote:
> >
> > Hi all,
> >
> > I would like to know what are the limitations of the CRP
protection
> > because this kind of protection is controlled by the onchip
bootloader
> > so by software and I think that it is perhaps less efficient than
a
> > hardware code read protection feature ...
> >
> > In fact, what are the solutions to access the flash code content
even
> > if CRP is enabled ?
> >
> > I have seen that ATMEL proposes a flash security bit which
disables
> > the JTAG and prevents from flash access. This protection can not
be
> > suppressed except by erasing the flash which is more secure to my
mind
> > .. Am I worng ?
> >
> > Thanks in advance
>



Start a New Thread

John,

Thanks for your long and detailed contribution.

Unfortunately, I think you have to accept that consensus will not be
achieved in this case. If people making claims don't believe they
have to supply any evidence for those claims, no matter what counter-
evidence or alternative explanations you produce they will never
agree with you if they don't want to. Hence consensus is not
achievable.

Hence my suggestion for people to look back over the posts and make
their own minds up (based on the evidence presented).

>From experience, certain people also feel a need to have the last
say; I'd expect to see a reply to your post. This is another reason
for my suggestion: the arguments have been made. Rather than continue
with them indefinitely, just refer to anyone interested to the
existing posts.

Thanks anyway.

Brendan.

--- In l..., "John Heenan" wrote:
>
> I have new information that may help tip the balance in forming a
> consensus. Really I don't want to spend an extra millisecond on
this.
> Start a New Thread

Dear John, you cannot take a second bite at the same cherry...

--- In l..., "John Heenan" wrote:
>
> I have new information that may help tip the balance in forming a
> consensus.

This is old information, and predates the conclusion of the debate on
this forum.

> Really I don't want to spend an extra millisecond on this.

And then you did ... spend lots of time rehashing your old points that
were shot down to pieces when you first raised them.

What a pathetic attempt to reopen an old debate which we all agreed we
had enough of with a bogus "new information" claim!

Jaya Start a New Thread

--- In l..., "John Heenan" wrote:
>
> I have new information that may help tip the balance in forming a
> consensus. Really I don't want to spend an extra millisecond on
this.

> ensuring a specific debug select pin is pulled low on reset. If the
> pin is left alone then JTAG pins will not be externally connected
by
> default on the LPC2148 (due to internal pull-up resistors on Port 1

Before we even worry about CRP, have you tested the pull-up resistors
on Port 1. The data sheet says they are there but my 2148 doesnt seem
to have them.

see
http://groups.yahoo.com/group/lpc2000/message/13989

Cheers
Keith

P.S.

I switched over to the Realview compiler instead of the Keil Carm. My
code seems more stable than it ever has been. I will need to check
some more but so far Realview is looking really good. Start a New Thread