No need to get emotional. This is not the right forum for posting hacks
I raised a number of questions that Philips could dismiss with
authority. It has chosen not to and to fans here to guess, and double
guess, question the intent, engage in politics and other forms of rhetoric.
You asked me what my agenda is. I want Philips to authoritatively address
questions I raised that casts doubts in my mind and others in this industry
who understand risk assessment and management.
In case these got buried in distractions, here they are again:
1) What is the reason for saving one instruction in boot loader start up
code to disable JTAG debugging at the expense of making the boot loader
less unsafe by removing UND, ABT and PRE exception handling?
2) When will the undocumented and hidden 'T' command and 'tEsT' features
be removed from the boot loader?
3) When will Philips acknowledge the bug in boot loader command string
interpreter, and release the status of this bug in versions of boot loader
3) What other test/debug Trojans are there in the boot loader?
While I responded to you in the post, as the title of this thread says,
these are questions to Philips, or anyone with authoritative information.
Rhetorics, please refrain from hijacking the agenda.
--- In lpc2000@lpc2..., "John Heenan" <l10@...> wrote:
> Still nothing concrete or specific.
> It is irresponsible to carry on a thread implying there are CRP
> exploits using JTAG
> For those with an elementary knowledge of microcontroller
> architecture it is easy to understand that on reset a signal can be
> raised that blocks debug break signals from JTAG and that this
> blocking action will require a specific action to clear. This might
> be called a very effective 'child proof' lock.
> It is extraordinarily bad form to imply in a title that CRP exploits
> with JTAG exist. Many will not read beyond the subject title.
> I have said this before and I will say it again. What is the real
> John Heenan
Send instant messages to your online friends http://au.messenger.yahoo.com