Dear Peter,
This response is for you, and like minded people here who are curious
as to where I am coming from with respect the LPC boot loader.
If those who are easily upset or offended when I challenge your esteem
of Philips or their LPC microcontroller, please read no further. With
due respect, I will however say to you that Philips can take care of
itself without you having to shoot down this thread.
No Peter, I do not have a bunch of students working on this. All I
found and said here is arises from work I did myself. Here is the
story of how I am involved with LPC and how I found out what I did.
As open as I like to be, you will appreciate my not discussing things
related to "client requirements" in this forum for obvious reasons.
I first looked at LPC2105 as a viable alternative to expose students
to the ARM architecture. The Intel StrongARM and XSCALE variants they
are now using is more expensive.
The very nature of ARM/THUMB interworking is that when (bad) code
fails, there is an added level of complexity because there are two
instruction sets involved that are intermixed.
My experience with students working on Intel StrongARM with AMD flash
was quite different to that for the LPC when such things happen.
In the StongArm/XSCALE platforms with AMD flash, there was never an
instance of flash corruption arising out of bad code. [Aside, even
when this happened, we simply used JTAG to re-flash and we were back
in business.]
In the case of LPC, I destroyed one prototype myself because (I think)
I missed out on linker warning that interworking call was incorrect.
Considering we already had three prototypes out of action, I decided
to contact Philips for help.
Philips offered to send me a hex file containing boot loader if I had
access to a parallel programmer. [After this parallel programming
method raised in this forum, Philips thought it fit to advice me that
its earlier advice was incorrect.]
I explained to Philips my requirement to replace the boot loader, and
asked if it would publish the flash architecture. Alternatively I
asked if it was expressed forbidden to reverse engineer the algorithm
by disassembly of the code in the boot sector or boot loader updates
it had published.
The response from Philips was that flash algorithms were not available
in a form that did not have proprietary information in it. Philips
also said that because there are timing requirements that may not be
met if I write my own algorithms, it will not guarantee the part.
I spent a good part of an entire week disassembling the boot loader.
I extracted on-chip flash algorithms quite easily. I was surprised to
learn that it would be possible to destroy on-chip flash by simply
trashing one or more locations in memory.
Unlike in the case of AMD flash in the earlier board which had feed
sequence requirements (0xaa followed by 0x55), the on-chip flash
controller for LPC had no such requirements.
This meant that even if I took away the flash programming code in the
boot loader for my students, they could still destroy the part by this
way quite easily. If it happened in three of five prototypes, that is
not a good sign
The other thing I found that was of academic interest initially, was
that it appears that charge pump timing parameters are required to be
set when flash is programmed.
I can see why Philips would not publish flash architecture: algorithm
is not protected, and charge pump timings have to be specified. It is
quite possible that the part could be fried (permanantly destroyed) by
incorrect timing parameters, and hence said it would not guarantee the
part.
Having looked at the boot loader, I could not help visually composing
the code myself such that GNU assembly of the equivalent source would
produce an identical binary image. I did this as an exercise to make
sure my interpretation was accurate at the binary image level.
I was less than impressed with the code. The CSI (command string
interpreter that decodes and dispatches ISP commands) was broken. In
the context of CRP in the other LPC parts I was quite shocked at the
claims made in relation to how safe is CRP.
How can one be expected to rely on a CRP regime that requires boot
loader code to secure the device on reset, when the primary external
world interface to boot loader, CSI, on the 2105 part is broken.
Many have argued that I have to do the same for current code in other
LPC parts with CRP feature to prove my point. I beg to disagree. I
do not have access to any other part than 2105. More importantly I
dont have to prove to anyone CRP can be defeated. People in this
field can make up their own minds.
I have just stated on this forum what I found broken, and what I think
the consequences are for CRP, and so on. It would be simple matter
for Philips to comf forth and acknowledge the CSI problem in 1.51 boot
loader for 2105, and tell us if this exists for the other parts.
Philips has chosen not to acknowledge the CSI problem. This must mean
that either Philips does not know of this vulnerability, or that if it
does, it does not wish to discuss this to mitigate damages. By the
way, I use the term "damages" not in a legal sense, but damage to its
esteem in the eyes of its customers.
The more I look at my boot loader source the more I find out about
things like hidden "T" command that allows you to modify boot loader
state (where CRP information is kept) using GPIO pins to toggle the
data in, the "tEsT" argument that programmers thought no one will
discover because it is spelt in alternate case, and so on.
If this is the thought process of the boot loader programmers, there
is no way I would recommend anyone, be it my clients or not, to rely
on the boot loader for purposes of securing IP whether or not CRP is
enabled.
So why am I beating up dead horse? Well I have invested enough time
to and effort on LPC that is still useful in different circumstances.
Although 2105 does not have the CRP feature, IP can nonetheless be
protected in this part, and indeed on any of the other LPCs including
those with external memory interface, if you decided not to use the
supplied boot loader.
For those who seem bent on shooting down this thread with statements
like "you have not proven how to break CRP", ask yourself what would
be gained by publishing exploits on this forum.
As an academic I am committed to telling all I know so that others may
learn, but at the same time, I also recognise and accept that it is
not responsible to post vulnerabilities, especially if there are
already parts in the field with code that is "CRP protected".
Sorry this is a long answer to your short question, but I thought
telling the full story could help quench some of the anger coming from
a vocal few bent on shooting down discussion by abuse and insults.
I am off for two weeks starting next week. I am happy to address any
issues arising from this post on this forum or by email as appropriate
in the meanwhile.
Kind regards,
Jaya
--- In lpc2000@yahoogroups.com, Peter Jakacki <peterjak@t...> wrote:
Show quoted textHide quoted text
> I would be interested to hear more about bootloader corruption as
> I have not experienced this myself. Unlike you, I am "unfortunate"
> not to have a bunch of students invoking the uninvocable :) :)
>
> *Peter*