I have few LPC2138/LPC2292 samples. I got them in Setember last year.
The bootloader versions are 2.11 and 1.65 respectively. I don't see
CSI (Command String Interpreter) bug as claimed by Jaya. No matter how
many extra characters/parameters are sent in ISP mode, the bootloader
does not crash.
Jaya could you please repeat the test on bootloader versions 2.11 and
1.65 or publish the ascii string you used to crash the bootloader.
Tom
Flash Code Protection
Started by ●August 6, 2006
Reply by ●August 7, 20062006-08-07
Reply by ●August 7, 20062006-08-07
--- In l..., "lpc2100" wrote:
> Jaya could you please repeat the test on bootloader versions
> 2.11 and 1.65 or publish the ascii string you used to crash
> the bootloader.
>
> Tom
Tom, as per my earlier post, on LPC2292 with boot loader version 1.64,
the test string is:
> Synchronized
> OK
> 10000
> OK
> U 23130
> 0
> U [digits]
Keep entering the digits 123467890 repeatedly (to facilate counting)
and you will find it stops echoing after the 69th character.
As I have only this one board that I have set aside (on advice) in the
event I am required to prove my findings for any reason, I am hesitant
to upgrade it at the moment.
As I do not have any on-going LPC projects I do not have any other
boards to play with. A few chips but not loaded.
If someone wants me to verify the status of my findings on their
current versions, I am happy to run the same tests and report the
outcomes on my Boot Loader page if I have a board to do the tests.
The other alternative is for you to send me copy of the boot loader
(dumped using SILL) and I may be able to tell what defect has been fixed.
Bear in mind running tests or analysing code and reporting on them
takes time and there is a limit to what I can do gratis.
Regards,
Jaya
> Jaya could you please repeat the test on bootloader versions
> 2.11 and 1.65 or publish the ascii string you used to crash
> the bootloader.
>
> Tom
Tom, as per my earlier post, on LPC2292 with boot loader version 1.64,
the test string is:
> Synchronized
> OK
> 10000
> OK
> U 23130
> 0
> U [digits]
Keep entering the digits 123467890 repeatedly (to facilate counting)
and you will find it stops echoing after the 69th character.
As I have only this one board that I have set aside (on advice) in the
event I am required to prove my findings for any reason, I am hesitant
to upgrade it at the moment.
As I do not have any on-going LPC projects I do not have any other
boards to play with. A few chips but not loaded.
If someone wants me to verify the status of my findings on their
current versions, I am happy to run the same tests and report the
outcomes on my Boot Loader page if I have a board to do the tests.
The other alternative is for you to send me copy of the boot loader
(dumped using SILL) and I may be able to tell what defect has been fixed.
Bear in mind running tests or analysing code and reporting on them
takes time and there is a limit to what I can do gratis.
Regards,
Jaya
Reply by ●August 8, 20062006-08-08
> >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)
I am sorry but,
How to create such file?
Best Regards,
Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746
>
> Sure
> - Create application Hex file
> - Create Hex file with protection signature (only has to be done once)
I am sorry but,
How to create such file?
Best Regards,
Mukund Deshmukh.
Beta Computronics Pvt Ltd
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746
Reply by ●August 8, 20062006-08-08
--- In l..., Dominic Rath
wrote:
>
> 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.
>
I agree. This is exactly my point: making the leap from saying
because there are possible bugs in the bootloader command
interpreter to claiming that this somehow compromises CRP is not
credible without either evidence of the same (i.e. proof that it has
been compromised) or a description of even a theoretical mechanism
of how it might be compromised.
I've no problem acknowledging there may be bugs in (some versions
of) the loader that become apparent when error conditions are
introduced. I don't think it unreasonable to ask how these same bugs
compromise CRP. However, since I know I won't an answer to this
(only the usual abuse), I won't press the point further.
Brendan.
wrote:
>
> 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.
>
I agree. This is exactly my point: making the leap from saying
because there are possible bugs in the bootloader command
interpreter to claiming that this somehow compromises CRP is not
credible without either evidence of the same (i.e. proof that it has
been compromised) or a description of even a theoretical mechanism
of how it might be compromised.
I've no problem acknowledging there may be bugs in (some versions
of) the loader that become apparent when error conditions are
introduced. I don't think it unreasonable to ask how these same bugs
compromise CRP. However, since I know I won't an answer to this
(only the usual abuse), I won't press the point further.
Brendan.
Reply by ●August 8, 20062006-08-08
Original Message:
-----------------
>From: Mukund Deshmukh
>> >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)
>I am sorry but,
>How to create such file?
I don't know what tools you have and I don't have my references handy in
any case but the general idea is to create a file with just that location
specified. Check your compilers startup code for some insights into how to
do in assembly. Some C compilers might be able to handle it as well but yo
would have to trick them into genrating code w/o startup. IT's probably
easier to use assembly.
If someone were sufficiently ambitious you could probably develop the hex
by hand since it's a constant at a fixed location.
Robert
-----------------
>From: Mukund Deshmukh
>> >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)
>I am sorry but,
>How to create such file?
I don't know what tools you have and I don't have my references handy in
any case but the general idea is to create a file with just that location
specified. Check your compilers startup code for some insights into how to
do in assembly. Some C compilers might be able to handle it as well but yo
would have to trick them into genrating code w/o startup. IT's probably
easier to use assembly.
If someone were sufficiently ambitious you could probably develop the hex
by hand since it's a constant at a fixed location.
Robert
Reply by ●August 8, 20062006-08-08
Hi Robert
I have created a HEX file.
What do you mean by "Create Hex file with protection signature (only
has to be done once)",make it read only?
I have created a HEX file.
What do you mean by "Create Hex file with protection signature (only
has to be done once)",make it read only?
Reply by ●August 8, 20062006-08-08
>Original Message:
>-----------------
>From: levy_ariel
>I have created a HEX file.
>What do you mean by "Create Hex file with protection signature (only
>has to be done once)",make it read only?
I mean once it's been done you don't have to ever re-do it for chips that
use the same protection scheme. You can file a copy of the source away for
reference and just use the resulting hex file when you wish.
Robert
>-----------------
>From: levy_ariel
>I have created a HEX file.
>What do you mean by "Create Hex file with protection signature (only
>has to be done once)",make it read only?
I mean once it's been done you don't have to ever re-do it for chips that
use the same protection scheme. You can file a copy of the source away for
reference and just use the resulting hex file when you wish.
Robert
Reply by ●August 8, 20062006-08-08
Hi, here the example for lpc2106-ROM.ld that I made by
http://www.ashling.com/support/lpc2000/knowledge_base.html
usng WinARM
Without protection:
-------------------
/* first section is .text which is used for code */
.text :
{
*crt0.o (.text) /* Startup code */
*(.text) /* remaining code */
*(.rodata) /* read-only data (constants) */
*(.rodata*)
*(.glue_7)
*(.glue_7t)
} > ROM
-------------------
With protection:
-------------------
/* first section is .text which is used for code */
.text :
{
_ftext = ABSOLUTE(.); /* FLASH LOCK NEEDED */
*crt0.o (.text) /* Startup code */
. = 0x1FC ; /* FLASH LOCK NEEDED*/
LONG(0x87654321) /* FLASH LOCK NEEDED*/
*(.text) /* remaining code */
*(.rodata) /* read-only data (constants) */
*(.rodata*)
*(.glue_7)
*(.glue_7t)
} > ROM
-------------------
Ready for comments,
Aryeh
http://www.ashling.com/support/lpc2000/knowledge_base.html
usng WinARM
Without protection:
-------------------
/* first section is .text which is used for code */
.text :
{
*crt0.o (.text) /* Startup code */
*(.text) /* remaining code */
*(.rodata) /* read-only data (constants) */
*(.rodata*)
*(.glue_7)
*(.glue_7t)
} > ROM
-------------------
With protection:
-------------------
/* first section is .text which is used for code */
.text :
{
_ftext = ABSOLUTE(.); /* FLASH LOCK NEEDED */
*crt0.o (.text) /* Startup code */
. = 0x1FC ; /* FLASH LOCK NEEDED*/
LONG(0x87654321) /* FLASH LOCK NEEDED*/
*(.text) /* remaining code */
*(.rodata) /* read-only data (constants) */
*(.rodata*)
*(.glue_7)
*(.glue_7t)
} > ROM
-------------------
Ready for comments,
Aryeh
Reply by ●August 10, 20062006-08-10
