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@lpc2..., Peter Jakacki <peterjak@t...> wrote:
> 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*
LPC2148 identifyed as a LPC2138?
Started by ●January 7, 2006
Reply by ●January 9, 20062006-01-09
Reply by ●January 10, 20062006-01-10
At 01:19 AM 1/10/06 +0000, jayasooriah wrote:
>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.
Actually I consider that less a protective feed sequence and more the call
sequence for invoking the state machine in the flash. It ends up serving
the same purpose since the flash algorithm is essentially in a hidden
address space.
>I was less than impressed with the code. The CSI (command string
>interpreter that decodes and dispatches ISP commands) was broken.
How so? The obvious would be buffer overflows which cold conceivably open
it up quite far.
>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.
I would have thought that was obvious. It shows it can be done. There is
something to be said for the courtesy of informing Philips before doing so
but most security vulnerabilities appear to have only been addressed when
the holes are demonstrated, not just talked about. Until it is shown with
how much ease security can be bypassed claims about that ease are generally
disregarded by most people concerned.
Of course in some parts of the world it may now be questionable as to
whether it is legal to perform any research on this question so some people
may not want to take that risk...
>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".
If there is a security hole is it more responsible to expose it before more
people rely on it or to keep it hidden? See above if you are wondering why
I would consider the discussion so far to be one that leant towards keeping
it hidden.
BTW, it's of little concern to me. I don't have a lot of use for code
protection. For the stuff I've done, although the code is significant it
cannot stand alone.
Exploding flash on the other hand :)
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/
>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.
Actually I consider that less a protective feed sequence and more the call
sequence for invoking the state machine in the flash. It ends up serving
the same purpose since the flash algorithm is essentially in a hidden
address space.
>I was less than impressed with the code. The CSI (command string
>interpreter that decodes and dispatches ISP commands) was broken.
How so? The obvious would be buffer overflows which cold conceivably open
it up quite far.
>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.
I would have thought that was obvious. It shows it can be done. There is
something to be said for the courtesy of informing Philips before doing so
but most security vulnerabilities appear to have only been addressed when
the holes are demonstrated, not just talked about. Until it is shown with
how much ease security can be bypassed claims about that ease are generally
disregarded by most people concerned.
Of course in some parts of the world it may now be questionable as to
whether it is legal to perform any research on this question so some people
may not want to take that risk...
>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".
If there is a security hole is it more responsible to expose it before more
people rely on it or to keep it hidden? See above if you are wondering why
I would consider the discussion so far to be one that leant towards keeping
it hidden.
BTW, it's of little concern to me. I don't have a lot of use for code
protection. For the stuff I've done, although the code is significant it
cannot stand alone.
Exploding flash on the other hand :)
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/
Reply by ●January 10, 20062006-01-10
--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...> wrote:
> I would have thought that was obvious. It shows it can be
> done. There is something to be said for the courtesy of
> informing Philips before doing so but most security
> vulnerabilities appear to have only been addressed when
> the holes are demonstrated, not just talked about.
Things come out in the public domain when one party wants to take the
other party out (usually egged by a competitor) to manipulate the
market. The fact that this has not happened is an indication that
Philips is not a contender for the security market.
> Until it is shown with how much ease security can be
> bypassed claims about that ease are generally disregarded
> by most people concerned.
Not so by the people who make them, let me assure you. There are far
reaching consequences when claims are relied upon that are later
discovered to be false or misleading or even deceptive.
When the manufacturers goes quiet and do not comment on such issues,
it is usually a sign heads are rolling and finger pointing is going
inside the organisation that they do not want us to know.
> Of course in some parts of the world it may now be questionable
> as to whether it is legal to perform any research on this question
> so some people may not want to take that risk...
Precisely my point.
> If there is a security hole is it more responsible to expose
> it before more people rely on it or to keep it hidden? See
> above if you are wondering why I would consider the discussion
> so far to be one that leant towards keeping it hidden.
There are good arguments for and against. So it is a matter of ethics
really, and which side you lean on.
IMO it perfectly okay to discuss risks relating to is to putting the
front door key in the flower pot or under the floor rug but saying
so-and-so puts his key at such-and-such a place is just not on.
IMO it is NOT okay to fetch the encrypted password files for a bunch
of users without seeking their permission and and trying crack it for
academic purposes with the undertaking that any cracked password will
not be used.
This is akin to allowing someone to try a of keys on your front door
without your knowledge with the undertaking they will will not remove
anything from your house if they succeeded.
This is an area where there two people have three opinions.
If we come back to the topic, why 2148 identifies itself as 2138, it
can be as minor as slackness to as grave as systemic problems at the
organisation level.
Undocumented commands and hidden arguments is a serious breach of
security because this was a deliberate action on the part of the
programmers.
Watever the reasons are, these impact on the trust issue I spoke
about. When Philips will not admit to the existence of methods that
you know and can prove exist (by disassembling boot sector of your
part), I cannot why anone should admit boot loader code or Philips
into their trust domain.
Jaya
> I would have thought that was obvious. It shows it can be
> done. There is something to be said for the courtesy of
> informing Philips before doing so but most security
> vulnerabilities appear to have only been addressed when
> the holes are demonstrated, not just talked about.
Things come out in the public domain when one party wants to take the
other party out (usually egged by a competitor) to manipulate the
market. The fact that this has not happened is an indication that
Philips is not a contender for the security market.
> Until it is shown with how much ease security can be
> bypassed claims about that ease are generally disregarded
> by most people concerned.
Not so by the people who make them, let me assure you. There are far
reaching consequences when claims are relied upon that are later
discovered to be false or misleading or even deceptive.
When the manufacturers goes quiet and do not comment on such issues,
it is usually a sign heads are rolling and finger pointing is going
inside the organisation that they do not want us to know.
> Of course in some parts of the world it may now be questionable
> as to whether it is legal to perform any research on this question
> so some people may not want to take that risk...
Precisely my point.
> If there is a security hole is it more responsible to expose
> it before more people rely on it or to keep it hidden? See
> above if you are wondering why I would consider the discussion
> so far to be one that leant towards keeping it hidden.
There are good arguments for and against. So it is a matter of ethics
really, and which side you lean on.
IMO it perfectly okay to discuss risks relating to is to putting the
front door key in the flower pot or under the floor rug but saying
so-and-so puts his key at such-and-such a place is just not on.
IMO it is NOT okay to fetch the encrypted password files for a bunch
of users without seeking their permission and and trying crack it for
academic purposes with the undertaking that any cracked password will
not be used.
This is akin to allowing someone to try a of keys on your front door
without your knowledge with the undertaking they will will not remove
anything from your house if they succeeded.
This is an area where there two people have three opinions.
If we come back to the topic, why 2148 identifies itself as 2138, it
can be as minor as slackness to as grave as systemic problems at the
organisation level.
Undocumented commands and hidden arguments is a serious breach of
security because this was a deliberate action on the part of the
programmers.
Watever the reasons are, these impact on the trust issue I spoke
about. When Philips will not admit to the existence of methods that
you know and can prove exist (by disassembling boot sector of your
part), I cannot why anone should admit boot loader code or Philips
into their trust domain.
Jaya
Reply by ●January 10, 20062006-01-10
At 09:35 AM 1/10/06 +0000, jayasooriah wrote:
>--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...> wrote:
>
> > I would have thought that was obvious. It shows it can be
> > done. There is something to be said for the courtesy of
> > informing Philips before doing so but most security
> > vulnerabilities appear to have only been addressed when
> > the holes are demonstrated, not just talked about.
>
>Things come out in the public domain when one party wants to take the
>other party out (usually egged by a competitor) to manipulate the
>market.
Well, that's one motivation. Public service and reputation are others.
> > Of course in some parts of the world it may now be questionable
> > as to whether it is legal to perform any research on this question
> > so some people may not want to take that risk...
>
>Precisely my point.
It is? I missed that completely then. BTW, if it wasn't obvious I think
banning research on security flaws is somewhere between pointless and
self-defeating.
>
> > If there is a security hole is it more responsible to expose
> > it before more people rely on it or to keep it hidden? See
> > above if you are wondering why I would consider the discussion
> > so far to be one that leant towards keeping it hidden.
>
>There are good arguments for and against. So it is a matter of ethics
>really, and which side you lean on.
>
>IMO it perfectly okay to discuss risks relating to is to putting the
>front door key in the flower pot or under the floor rug but saying
>so-and-so puts his key at such-and-such a place is just not on.
Fair enough, but the analogy may be better put as showing whether a certain
brand of lock is easily bypassed. In that case I don't think there is an
ethical breach in demonstrating the flaw, indeed it strikes me more as a
consumer service. Now if you then go ahead and publish which neighbours
are using that as the front door lock you have another issue entirely.
>IMO it is NOT okay to fetch the encrypted password files for a bunch
>of users without seeking their permission and and trying crack it for
>academic purposes with the undertaking that any cracked password will
>not be used.
I won't disagree with you on that.
>If we come back to the topic, why 2148 identifies itself as 2138, it
>can be as minor as slackness to as grave as systemic problems at the
>organisation level.
Indeed.
>Undocumented commands and hidden arguments is a serious breach of
>security because this was a deliberate action on the part of the
>programmers.
Security yes, although in the case of the 2104/5/6 that's rather a moot
point. The question will be how much of that was redone and to what effect.
I also agree that security through obscurity isn't.
>Watever the reasons are, these impact on the trust issue I spoke
>about. When Philips will not admit to the existence of methods that
>you know and can prove exist (by disassembling boot sector of your
>part), I cannot why anone should admit boot loader code or Philips
>into their trust domain.
Maybe they are looking for the moral equivalent of a child lock? Not
something to protect against a concerted attempt, just something to
indicate that you consider the internals proprietary.
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/
>--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...> wrote:
>
> > I would have thought that was obvious. It shows it can be
> > done. There is something to be said for the courtesy of
> > informing Philips before doing so but most security
> > vulnerabilities appear to have only been addressed when
> > the holes are demonstrated, not just talked about.
>
>Things come out in the public domain when one party wants to take the
>other party out (usually egged by a competitor) to manipulate the
>market.
Well, that's one motivation. Public service and reputation are others.
> > Of course in some parts of the world it may now be questionable
> > as to whether it is legal to perform any research on this question
> > so some people may not want to take that risk...
>
>Precisely my point.
It is? I missed that completely then. BTW, if it wasn't obvious I think
banning research on security flaws is somewhere between pointless and
self-defeating.
>
> > If there is a security hole is it more responsible to expose
> > it before more people rely on it or to keep it hidden? See
> > above if you are wondering why I would consider the discussion
> > so far to be one that leant towards keeping it hidden.
>
>There are good arguments for and against. So it is a matter of ethics
>really, and which side you lean on.
>
>IMO it perfectly okay to discuss risks relating to is to putting the
>front door key in the flower pot or under the floor rug but saying
>so-and-so puts his key at such-and-such a place is just not on.
Fair enough, but the analogy may be better put as showing whether a certain
brand of lock is easily bypassed. In that case I don't think there is an
ethical breach in demonstrating the flaw, indeed it strikes me more as a
consumer service. Now if you then go ahead and publish which neighbours
are using that as the front door lock you have another issue entirely.
>IMO it is NOT okay to fetch the encrypted password files for a bunch
>of users without seeking their permission and and trying crack it for
>academic purposes with the undertaking that any cracked password will
>not be used.
I won't disagree with you on that.
>If we come back to the topic, why 2148 identifies itself as 2138, it
>can be as minor as slackness to as grave as systemic problems at the
>organisation level.
Indeed.
>Undocumented commands and hidden arguments is a serious breach of
>security because this was a deliberate action on the part of the
>programmers.
Security yes, although in the case of the 2104/5/6 that's rather a moot
point. The question will be how much of that was redone and to what effect.
I also agree that security through obscurity isn't.
>Watever the reasons are, these impact on the trust issue I spoke
>about. When Philips will not admit to the existence of methods that
>you know and can prove exist (by disassembling boot sector of your
>part), I cannot why anone should admit boot loader code or Philips
>into their trust domain.
Maybe they are looking for the moral equivalent of a child lock? Not
something to protect against a concerted attempt, just something to
indicate that you consider the internals proprietary.
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/
Reply by ●January 10, 20062006-01-10
[discussion mode -- please skip if you find this post long]
--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
> It is? I missed that completely then. BTW, if it wasn't obvious
> I think banning research on security flaws is somewhere between
> pointless and self-defeating.
Agreed. I do not believe there is any such ban in effect. If there
were, then there would not be umpteen textbooks and articles on these.
Simply put, it is not unlawful to be a locksmith by profession. It
may be to break the prefessional code of conduct.
> Maybe they are looking for the moral equivalent of a child
> lock? Not something to protect against a concerted attempt,
> just something to indicate that you consider the internals
> proprietary.
I do not think CEP security was meant as child's play or for child
proofing purposes. See the post with the term "preying eyes".
Look a the claims and the veracity with which Philips defended its CEP
on this forum before the flaws in the boot loader were exposed.
I am not a lawyer. I have dealt with many on such matters, IMO
a) The claims in the data sheets are at best inaccurate.
b) The claims made by Philips on this forum are misleading. I am not
sure if or how one would show intent.
It is now in the open that the boot loader CSI fails and that it has,
hidden commands and hidden arguments for known commands (trojans).
I would not be surprised if Philips is now frantically looking into
CSI vulnerabilities as we speak. It is quite obvious a freeze has
been put on discussoin of these issues between the engineering and
support teams within.
Should further claims be made without reference to the issues raised,
it may be quite possible to show "deceptive and misleading conduct"
that is unlawful in most countries.
Anyone who is has LPCs out in the field and relies on its CEP features
for protection of IP or for security purposes should seek profesional
opinion.
However, for the rest of us who are just using 2105 as a platform for
doing creative things and not concerned with CEP, there is nothing to
stop us from continue to enjoy this part, and the trend it has set in
terms of availability of cheap ARM cores.
Jaya
--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
> It is? I missed that completely then. BTW, if it wasn't obvious
> I think banning research on security flaws is somewhere between
> pointless and self-defeating.
Agreed. I do not believe there is any such ban in effect. If there
were, then there would not be umpteen textbooks and articles on these.
Simply put, it is not unlawful to be a locksmith by profession. It
may be to break the prefessional code of conduct.
> Maybe they are looking for the moral equivalent of a child
> lock? Not something to protect against a concerted attempt,
> just something to indicate that you consider the internals
> proprietary.
I do not think CEP security was meant as child's play or for child
proofing purposes. See the post with the term "preying eyes".
Look a the claims and the veracity with which Philips defended its CEP
on this forum before the flaws in the boot loader were exposed.
I am not a lawyer. I have dealt with many on such matters, IMO
a) The claims in the data sheets are at best inaccurate.
b) The claims made by Philips on this forum are misleading. I am not
sure if or how one would show intent.
It is now in the open that the boot loader CSI fails and that it has,
hidden commands and hidden arguments for known commands (trojans).
I would not be surprised if Philips is now frantically looking into
CSI vulnerabilities as we speak. It is quite obvious a freeze has
been put on discussoin of these issues between the engineering and
support teams within.
Should further claims be made without reference to the issues raised,
it may be quite possible to show "deceptive and misleading conduct"
that is unlawful in most countries.
Anyone who is has LPCs out in the field and relies on its CEP features
for protection of IP or for security purposes should seek profesional
opinion.
However, for the rest of us who are just using 2105 as a platform for
doing creative things and not concerned with CEP, there is nothing to
stop us from continue to enjoy this part, and the trend it has set in
terms of availability of cheap ARM cores.
Jaya
Reply by ●January 11, 20062006-01-11
At 10:43 PM 1/10/06 +0000, jayasooriah wrote:
>--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
> > It is? I missed that completely then. BTW, if it wasn't obvious
> > I think banning research on security flaws is somewhere between
> > pointless and self-defeating.
>
>Agreed. I do not believe there is any such ban in effect. If there
>were, then there would not be umpteen textbooks and articles on these.
>
>Simply put, it is not unlawful to be a locksmith by profession. It
>may be to break the prefessional code of conduct.
Nicely put. I was referring to the DMCA (on which there has been many
articles). Purely U.S. of course but I have heard rumors of some countries
considering it as a template for their own laws. I seem to recall that
there was one well known security researcher that left the field because of
it. And several from outside the US have expressed concerns about
attending conferences inside the US.
You can see
http://www.eff.org/IP/DMCA/20030102_dmca_unintended_consequences.html
http://www.eff.org/IP/DMCA/
to see some of the concern being expressed there.
>I would not be surprised if Philips is now frantically looking into
>CSI vulnerabilities as we speak. It is quite obvious a freeze has
>been put on discussoin of these issues between the engineering and
>support teams within.
>
>Should further claims be made without reference to the issues raised,
>it may be quite possible to show "deceptive and misleading conduct"
>that is unlawful in most countries.
You may be right.
Keep up the gadfly work. I think the back and forth here between you and
your critics has resulted in a firmer foundation for your questions.
>Anyone who is has LPCs out in the field and relies on its CEP features
>for protection of IP or for security purposes should seek profesional
>opinion.
>
>However, for the rest of us who are just using 2105 as a platform for
>doing creative things and not concerned with CEP, there is nothing to
>stop us from continue to enjoy this part, and the trend it has set in
>terms of availability of cheap ARM cores.
They are rather nice.
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/
>--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
> > It is? I missed that completely then. BTW, if it wasn't obvious
> > I think banning research on security flaws is somewhere between
> > pointless and self-defeating.
>
>Agreed. I do not believe there is any such ban in effect. If there
>were, then there would not be umpteen textbooks and articles on these.
>
>Simply put, it is not unlawful to be a locksmith by profession. It
>may be to break the prefessional code of conduct.
Nicely put. I was referring to the DMCA (on which there has been many
articles). Purely U.S. of course but I have heard rumors of some countries
considering it as a template for their own laws. I seem to recall that
there was one well known security researcher that left the field because of
it. And several from outside the US have expressed concerns about
attending conferences inside the US.
You can see
http://www.eff.org/IP/DMCA/20030102_dmca_unintended_consequences.html
http://www.eff.org/IP/DMCA/
to see some of the concern being expressed there.
>I would not be surprised if Philips is now frantically looking into
>CSI vulnerabilities as we speak. It is quite obvious a freeze has
>been put on discussoin of these issues between the engineering and
>support teams within.
>
>Should further claims be made without reference to the issues raised,
>it may be quite possible to show "deceptive and misleading conduct"
>that is unlawful in most countries.
You may be right.
Keep up the gadfly work. I think the back and forth here between you and
your critics has resulted in a firmer foundation for your questions.
>Anyone who is has LPCs out in the field and relies on its CEP features
>for protection of IP or for security purposes should seek profesional
>opinion.
>
>However, for the rest of us who are just using 2105 as a platform for
>doing creative things and not concerned with CEP, there is nothing to
>stop us from continue to enjoy this part, and the trend it has set in
>terms of availability of cheap ARM cores.
They are rather nice.
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/
Reply by ●January 11, 20062006-01-11
Hi,
Since appears that Philips guys read this forum, maybe they could answer
some questions:
When you will update all that <tbd> specifications in the datasheet ?
Is there any silicon bug in the USB ? Why do I have to put pulldown
resistors in that pins to lower the power requirements ?
I just can't set my power consumption lower than 450uA, no matter what i do.
Thanks, Mauricio
Since appears that Philips guys read this forum, maybe they could answer
some questions:
When you will update all that <tbd> specifications in the datasheet ?
Is there any silicon bug in the USB ? Why do I have to put pulldown
resistors in that pins to lower the power requirements ?
I just can't set my power consumption lower than 450uA, no matter what i do.
Thanks, Mauricio
Reply by ●January 11, 20062006-01-11
First I want to apologize for the delay in our involvement in this
posting thread. Many good points have been raised on either side of
the issue and this is indeed a complex issue with no easy answers.
When we first launched the LPC2148, a few hundred pieces were given
part ID's of LPC2138 and the flash was tested as LPC2138, since the
flash blocks are identical between the two families. We tried to
assure that these "LPC2138-identified" LPC2148 parts were only given
to our evaluation board suppliers. Unfortunately, it appears that a
few of these parts were either circulated to our users or some of
these parts were removed from evaluation boards. After the initial
batch of LPC2148 parts, all future parts were given correct LPC2148
ID's. I sincerely apologize for any confusion that we caused.
Philips Marketing --- In lpc2000@lpc2..., "tiltedkeyboard"
<tiltedkeyboard@y...> wrote:
>
> Is it normal for the Philips Flash Utility (2.2.3) to ID a LPC2148
as
> a LPC2138?
>
> I'm using a Olimex LPC-P2148 with a clearly marked and correcly
> identifyed LPC-2148 part (ID 196389).
> I know that they have equal amount of ROM & RAM, but since the
LPC2148
> *do exist* in the dropdown box *i assumed* it would be selected.
>
> One other thing.
> Why have a dropdown box if the only thing the user can do is to
> autodetect the part and watch the dropdownbox get 'locked' with
> whatever the program feels i correct?
> Back to the drawingboard guys! ;-)
>
> What else can i expect to be wierd in this utility?
> Is there anything i should know of that can
> render my part useless?
>
posting thread. Many good points have been raised on either side of
the issue and this is indeed a complex issue with no easy answers.
When we first launched the LPC2148, a few hundred pieces were given
part ID's of LPC2138 and the flash was tested as LPC2138, since the
flash blocks are identical between the two families. We tried to
assure that these "LPC2138-identified" LPC2148 parts were only given
to our evaluation board suppliers. Unfortunately, it appears that a
few of these parts were either circulated to our users or some of
these parts were removed from evaluation boards. After the initial
batch of LPC2148 parts, all future parts were given correct LPC2148
ID's. I sincerely apologize for any confusion that we caused.
Philips Marketing --- In lpc2000@lpc2..., "tiltedkeyboard"
<tiltedkeyboard@y...> wrote:
>
> Is it normal for the Philips Flash Utility (2.2.3) to ID a LPC2148
as
> a LPC2138?
>
> I'm using a Olimex LPC-P2148 with a clearly marked and correcly
> identifyed LPC-2148 part (ID 196389).
> I know that they have equal amount of ROM & RAM, but since the
LPC2148
> *do exist* in the dropdown box *i assumed* it would be selected.
>
> One other thing.
> Why have a dropdown box if the only thing the user can do is to
> autodetect the part and watch the dropdownbox get 'locked' with
> whatever the program feels i correct?
> Back to the drawingboard guys! ;-)
>
> What else can i expect to be wierd in this utility?
> Is there anything i should know of that can
> render my part useless?
>
