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

Which might tend to suggest that "upgrades" could be possible and the inability to reduce is a
deliberate hardware feature specifically to prevent users doing this....

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

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

That would be very interesting to investigate on smaller parts like the 2101, to replace some/all of
the bootloader function with your own code - you could double the available memory.....

..and investigate changing the value the bootloader writes to the 'available memory' register.... Start a New Thread

On Monday 07 August 2006 16:44, jayasooriah wrote:
> Philips supplies Boot Loader update program that will upgrade the Boot
> Loader and this is not possible if it is ROM.

I remember reading somewhere that the LPC210[123] have the bootloader in ROM,
and that it's therefor not upgradeable.

Regards,

Dominic Start a New Thread

--- In l..., Mike Harrison wrote:
> That would be very interesting to investigate on smaller parts
> like the 2101...

AFAIK 2101/2/3 (latest in the series) have ROM boot loaders.

I have had people report they were able to upgrade 2105 to 2106.

Jaya Start a New Thread

At 10:04 AM 8/7/06 +0530, Mukund Deshmukh wrote:
> > 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.

Sure
- Create application Hex file
- Create Hex file with protection signature (only has to be done once)
- start ISP application which accepts multiple input files

I had done the original mods so that application could be merged with
specific calibration/configuration files when programming. Haven't tested
it for turning on CRP but no reason it shouldn't work.

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

--- In l..., "jayasooriah"
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
>

Jaya,

Give us a break from spreading FUD, please.

If you have evidence of a problem, then let's hear about it: just
because you don't like the way certain features like CRP are
implemented doesn't mean they don't work.

Brendan

P.S. posting info on this forum is not "informing Philips": I doubt
they have the time to wade through everything here. If there's a
specific problem reported to them through normal support channels,
my experience is that they respond in a reasonable timeframe. Start a New Thread

Not wishing to open up another can of worms on this subject but has anyone
actually proved this comment to be the case by physically writing an
application to prove it empirically or is this still theoretical? If there
is such a program is it available for general release so as we can validate
it? (If it has been proven then surely Philips will have to comment?)

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

On Monday 07 August 2006 17:44, Brendan Murphy wrote:
> If you have evidence of a problem, then let's hear about it: just
> because you don't like the way certain features like CRP are
> implemented doesn't mean they don't work.

I guess it's more than a feeling that he doesn't like them. The bootloader
certainly isn't the best piece of code ever written.

To the best of my knowledge, the situation hasn't changed. The best one can
say about the bootloader is that it's written with "bad coding practice" (as
opposed to good coding practice), like the leftover tEsT command, the
exception vectors that don't point to exception handlers or bugs in the ISP
input handling, allowing you to crash the bootloader (iirc).

But so far, there's no evidence that these problems actually allow arbitrary
code execution, or that they might compromise the security of CRP protected
devices in any other way. Bugs that allow you to crash a system are found
regularly, but simple denial of service attacks aren't criticial for the LPC
bootloader.

The situation would be different if there was for example a stack overflow of
some kind that would allow an attacker to load code that reenables JTAG. This
might very well be possible, but until someone points out what is necessary
to achieve this kind of attack, CRP is safe enough for its purpose.

Regards,

Dominic Start a New Thread

> Give us a break from spreading FUD, please

You seem to have no qualms in making ludicrous accusations like this
without any substance whatsoever.

All I have to say about the Boot Loader well documented in my Boot
Loader page. There is nothing there that is false. Every experiment
I have conducted and reported on can be verified. Others have.

> If you have evidence of a problem, then let's hear about it: just
> because you don't like the way certain features like CRP are
> implemented doesn't mean they don't work.

I am sorry you feel threatened, or otherwise uncomfortable with my
findings for reasons best known to yourself. However, throwing flame
baits to let off steam does not serve any useful purpose.

Your displeasure with my findings does not alter the findings, and is
not a consideration for purposes of publishing these in the manner I
have for reasons I have explained clearly.

Kind regards,

Jaya Start a New Thread

--- In l..., "Andrew Berney" wrote:
>
> Not wishing to open up another can of worms on this subject but
> has anyone actually proved this comment to be the case by
> physically writing an application to prove it empirically
> or is this still theoretical? If there is such a program
> is it available for general release so as we can validate
> it? (If it has been proven then surely Philips will have
> to comment?)
>
> Andy

One example in my Boot Loader page for LPC2105:

> The Boot Loader code is prone to buffer overrun problems,
> the most common weakness that is used to void security
> features. Enter any of ISP commands with five 0 arguments,
> for example "U 0 0 0 0 0" and watch the loader break into
> an endless loop outputting status register and faulting
> address as decimal numbers.

On the LPC2292 that I now have on my desk, I got the following:

> Synchronized
> Synchronized
> OK
> 10000
> OK
> U 23130
> 0
> U 00000000000000000000...

Keep entering 0, till it stops echoing.

Use whatever means you have to find out what exactly is happening and
it will give you an idea as to how the Boot Loader can be compromised.

Jaya Start a New Thread

--- In l..., Dominic Rath wrote:
>
> The bootloader
> certainly isn't the best piece of code ever written.

Hi Dominic,

I am curious your grounds and capacity in which you make this assment.

Is this just a gut feeling or have do you have any metrics?

Jaya Start a New Thread