Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: Code Read Protection Feature : Flash Security issue ?

2006-04-04 by jayasooriah

Hello,

--- In lpc2000@yahoogroups.com, "croquettegnu" <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

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.