Hi All,

I am burning the internal flash of LPC2212 using PHILIPS LPC2000 flash
utility.
Is there a way to make the code protected? Start a New Thread

At 12:31 PM 8/6/06 +0000, levy_ariel wrote:
>I am burning the internal flash of LPC2212 using PHILIPS LPC2000 flash
>utility.
>Is there a way to make the code protected?

What do the user manual and data sheet say?

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/ Start a New Thread

At 11:11 AM 8/6/2006 -0400, Robert Adsett wrote:
>At 12:31 PM 8/6/06 +0000, levy_ariel wrote:
> >I am burning the internal flash of LPC2212 using PHILIPS LPC2000 flash
> >utility.
> >Is there a way to make the code protected?
>
>What do the user manual and data sheet say?

I think I mis-interpreted the original request. If you are asking if
Philips programming utility has a way of automatically turn protection on
then not as far as I know. I did do a beta version of LPC21ISP that would
merge input files that could be used to do this.

Robert

http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live.... we
currently have stock." Start a New Thread

> then not as far as I know. I did do a beta version of LPC21ISP that would
> merge input files that could be used to do this.

Can you explain, how this can be done.

Best Regards,

Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746 Start a New Thread

> Dominic, it is strictly not true flash contents cannot be revealed
> through the Boot Loader when CRP is enabled.
>
> The are defects in the Boot Loader implementation that allows anyone
> to easily trick it into executing code that it is not supposed to execute.
>
> Jaya

Hello Jaya,

Even IF it's possible to trick it into executing code that it is not supposed
to execute AND IF it's possible to have it execute code that in the end
reveals the flash content, it is just a bug. There wont be any software of
reasonable complexity that's going to be free of bugs, so that doesn't
invalidate Philip's approach, it just means they have to fix that bug.
Therefor, your remarks don't apply to "CRP" as such, but only to the CRP as
implemented in certain versions of the bootloader, probably including the
latest one.

I don't know if and how you've contacted Philips in the past (there are just
too many threads on that topic), but if you really want to improve the
situation, you could follow guidelines of responsible disclosure, i.e. notify
the vendor of the code/product, give them time to validate it's a real
problem and respond with a patch/workaround/errata. If they're not responding
to your requests notify them again, give them more time, but if they're just
ignoring you, disclose the security problem. Disclosing doesn't mean to carry
on with vague accusations, but describing what the problem is, and how it can
lead to a security corruption. Vague descriptions of the problem don't help
anyone, and so far I haven't seen an explanation of what one has to do to
retrieve the flash content of a CRP protected LPC device.

If you don't want to publically disclose this issue, I'd be interested in
getting more information on that topic in private.

Best regards,

Dominic Rath Start a New Thread

Hi Dominic,

Apologies for top posting because I do not want to drawn into another
debate. The following serves to clarify why I thought fit to raise
the issue of defects in the Boot Loader in relation to your comment
about CRP:

* Boot Loader bugs (eg buffer overrun) are real and I have reported
and/or documented these.

* Boot Loader quality is suspect (eg bad exception processing, CR-NL
handling, hidden commands and dubious arguments to commands) are all
real and again I have reported and/or documented these.

When one relies on CRP feature provided by such the Boot Loader, one
has to bear in mind the weakness of the foundation on which this CRP
mechanism is based on.

The fact that there appears to be no mechanism by which Philips can
acknowledge Boot Loader defects and that there are no release notes
for Boot Loader versions only makes matters worse.

Kind regards,

Jaya Start a New Thread

On Mon, 07 Aug 2006 13:34:46 -0000, you wrote:
>Hi Dominic,
>
>Apologies for top posting because I do not want to drawn into another
>debate. The following serves to clarify why I thought fit to raise
>the issue of defects in the Boot Loader in relation to your comment
>about CRP:
>
>* Boot Loader bugs (eg buffer overrun) are real and I have reported
>and/or documented these.
>
>* Boot Loader quality is suspect (eg bad exception processing, CR-NL
>handling, hidden commands and dubious arguments to commands) are all
>real and again I have reported and/or documented these.
>
>When one relies on CRP feature provided by such the Boot Loader, one
>has to bear in mind the weakness of the foundation on which this CRP
>mechanism is based on.
>
>The fact that there appears to be no mechanism by which Philips can
>acknowledge Boot Loader defects and that there are no release notes
>for Boot Loader versions only makes matters worse.
>
>Kind regards,
>
>Jaya

Just out of curiosity, is there any meachnism to stop app code reading the bootloader code?
If not, has anyone disassembled it..?

Another thought - is it actually in real ROM or in flash? If the latter then I wonder if maybe there
would be a way to rewrite it (having disassembled it to figure out the actual flash write mechanism)
e.g. to expand the available space on low-end parts like the 2101. Start a New Thread

--- In l..., Mike Harrison wrote:
> Just out of curiosity, is there any meachnism to stop app code reading the bootloader code?
> If not, has anyone disassembled it..?

See http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

> Another thought - is it actually in real ROM or in flash? If the latter then I wonder if maybe there
> would be a way to rewrite it (having disassembled it to figure out the actual flash write mechanism)
> e.g. to expand the available space on low-end parts like the 2101.

My own Serial Intel-Hex LPC Loader uses my own flash programming
algorithm that I am told works more reliably than the IAP calls.

http://www.cse.unsw.edu.au/~jayas/esdk/sill.html

Jaya Start a New Thread

>See http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/boot-loader.html

"It was discovered that writing the wrong part identifier to this register after Boot Loader has
initialised it has the the effect of reducing the total on-chip FLASH and/or RAM available on the
device. A system reset is required to recover lost memory.
It appears that bits 0-3 and 4-7 of the word written into this register determine the amount
on-chip ROM and RAM respectively, that is enabled, and that multiple writes has the effect of
bit-wise AND-ing of these bits.."

Which begs the question, what happens if you use this register to try to "upgrade" any of the
smaller parts....??

Has anyone tried writing to the bootloader area to see if it is really flash instead of ROM..? Start a New Thread

--- In l..., Mike Harrison wrote:
> ... what happens if you use this register to try to "upgrade"
> any of the smaller parts....??

Note that once you write a value to reduce the memory, you cannot go
back to the full memory unless you reset.

So to "upgrade", you have change the value the Boot Loader writes to
this location.

> Has anyone tried writing to the bootloader area to see if it
> is really flash instead of ROM..?

Philips supplies Boot Loader update program that will upgrade the Boot
Loader and this is not possible if it is ROM.

Jaya Start a New Thread