Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: lpc2100_fan's objection to CRP thread

2006-02-10 by brendanmurphy37

Two post-scripts to my previous post (eh?):

1. Apologies for the spelling mistakes.

2. In the interests of following my own advice, I will not be 
commenting further on this topic: I can only hope that others will 
follow the example.

Brendan

--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendan.murphy@...> wrote:
>
> 
> Hi,
> 
> I just know I'm going to regret adding to this - this thread 
should 
> have been killed off long ago - but I feel I have to add my voice 
to 
> the call "enough".
> 
> Out of interest, Jaya, have you even considered ths remotest 
> possibility that the reason Philips aren't replying to your 
> outstanding question is not becuase they have something to hide, 
but 
> they have absolutely no reason to? In fact, quite the contrary, 
> normal commercial practice would more or less dictate that they 
> don't. 
> 
> Think a bit harder: they've already explained with very reasonable 
> sounding logic why the boot loader is the way it is. It's totally 
> unreasonable to expect any company to open up details of internal 
> implementation details that are hidden for a very good reason. By 
> documenting the interface you can make changes without changing 
the 
> documentated interface. If you want to play with undocumented 
> features and interfaces, good luck to you. But expecting Philips 
to 
> tell you internal details of what you're reverse engineering is 
> bizarre to my way of thinking. Why would they? (The reason why 
they 
> wouldn't by the way, is that they'd have to put resources - as in 
> people and cash - into supporting whatever they document).
> 
> I can't imagine anyone in Philips wasting a nano-second of their 
> time in responding to why the coded the first few instructions of 
> the boot loader one way rather than another.
> 
> As an analogy:
> 
> Joe Engineer approaches Ford and says: you know what, some of 
those 
> cars you make and sell have the potential to spontaneously 
> explode. "Really?" says everyone listening: "that's kind of 
> interesting! Tell us more". Says Joe: "Well, they're powered by an 
> explosive fuel - there's gallons of it. There's plenty of ignition 
> sources all over the place. Now I'm sure if you play around enough 
> with the juxtonian gaskit, by getting it into the smudgy mode, the 
> whole thing might just blow!". "Er, sounds interesting", says the 
> others: "any evidence this might happen, Joe". Joe: "Not as such, 
> but Ford just won't respond when I ask them why the gaskit is red, 
> when I reacon it should be blue". And so it goes.....
> 
> Now answer me this: does any sane, non-paranoid, person out there 
> think Ford would respond in that cicumstance?
> 
> How about it Philips: are you going to answer the man's 
questions??? 
> 
> We wait with baited breath....
> 
> Brendan
> 
> -- In lpc2000@yahoogroups.com, "lpc2100_fan" <lpc2100_fan@> wrote:
> >
> > Your suspicious G and T commands got an answer in messages
> > http://groups.yahoo.com/group/lpc2000/message/12267 and
> > http://groups.yahoo.com/group/lpc2000/message/12234,
> > 
> > you complain Philips doesn't answer, once they answer you ignore 
> it or
> > doubt it.
> > 
> > I give them the benefit of a doubt, you obviously think you are 
the
> > only one here in the forum the REALLY understands what's going 
on. 
> Not
> > so! Far from it. I have been working with the LPCs for more than 
2
> > years and there were ups and downs and we were satisfied with 
the 
> CRP
> > and still are. The only thing you are achieving that others who
> > believe in an academic approach not sustained with results that 
> prove
> > it, get a little paranoid too. 
> > 
> > Commands that are outdated but not removed from programs might 
not 
> be
> > the nicest programming style but they are no trojans. A trojans 
is 
> a
> > part of a program that enables a backdoor to information. Show 
us 
> with
> > all the time you obviously have to spend on this subject that 
you 
> can
> > diassemble a one instruction program that is secured and then 
come
> > back and talk about it.
> > 
> > Well, as some other were speaking up against your longterm siege 
of
> > the forum, I had to let them know there are more that think as 
> they do. 
> > 
> > The posts are a little emotional because we have been quiet and
> > watching and quiet and watching for almost 8 weeks.
> > 
> > RIP
> > 
> > 
> > --- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@> wrote:
> > >
> > > While lpc2100_fan spoke like any fan would, I must correct a 
> flaw in
> > the 
> > > core premise based on which lpc2000_fan objects to CRP thread:
> > > 
> > > --- In lpc2000@...m, "lpc2100_fan" <lpc2100_fan@> 
> wrote:
> > >  > ... so far we got
> > >  > a memory dump of a LPC2104 bootloader, which be no means 
has 
> any
> > >  > security options according to Philips.
> > >  > This is about as irrelevant as it can be within the LPC2000 
> family
> > >  > because ALL other members do have a security option.
> > > 
> > > Check the favourite LPC device with CRP security for Trojans 
at 
> the ISP 
> > > level itself and experience it for yourself.
> > > 
> > > If there is any particular part that does not have these 
Trojans 
> in
> > them, 
> > > please post part number and code versions so that those 
relying 
> on
> > CRP can 
> > > be properly advised as to which part/versions they should be 
> weary of 
> > > rather than the entire family.
> > > 
> > > In my LPC2292 (which has CRP feature) revision 1.64:
> > > 
> > > 1/  "G tEsT A" crashes the boot loader.
> > > 
> > > 2/  "T" command does interesting things (Philips does not want 
> you
> > to know 
> > > about).
> > > 
> > > Is this not sufficient proof that what I found in 2105 applies 
> to other 
> > > part(s) with CRP as well.
> > > 
> > > Either someone is feeding my clients fake (or rigged) parts, or
> > lpc2000_fan 
> > > got facts wrong.
> > > 
> > > Jaya
> > > 
> > > Send instant messages to your online friends
> > http://au.messenger.yahoo.com
> > >
> >
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.