Lpc2000

Hi,


I'm interested to know exactly how you and your students have managed to 
trash the bootloader on LPC devices. Please don't read this as meaning 
that I'm denying that you've done it, or suggesting that it involves 
extraordinary effort -- I'm simply interested, as it sounds like you've 
managed to do it more than once. Apologies if it's all been made clear 
earlier in the thread: I think I've read through fairly carefully so 
far, but I haven't noticed anything definitive.

I've been working with LPC parts for about a year now and I haven't had 
the misfortune to write one off yet. I'll admit that I haven't poked 
around in the internals of the bootloader, but I have certainly uploaded 
a lot of bad code. My team (a rather grand term for the two of us) has 
written quite a bit of firmware which we've compiled and built using our 
own tools: my colleague has written an ARM assembler, disassembler and 
linker from scratch and ported lcc to generate ARM assembly language. I 
wrote an uploader to use instead of the Philips tool, and I've produced 
a simple C runtime library to support the rest of our firmware.

That wasn't meant to be a boastful statement: what I'm driving at is 
that we've uploaded and run some pretty malformed (i.e. mis-compiled / 
mis-linked) "code" during the course of our development and we've yet to 
run in to a problem. The LPC boards that I've built are still performing 
correctly.

I'm also interested, from a purely academic perspective, to learn more 
about the possible JTAG based attack (first three instruction cycles 
after boot). Someone really needs to try this kind of attack -- I'd do 
so, but I haven't got the equipment. It would be good to know either way 
whether this sort of thing can work. Based on the comments with respect 
to JTAG return-clock synchronisation posted earlier on in the thread, it 
sounds like it won't be possible but it would still be interesting to 
know whether the chip can become confused enough (at invalid clock 
rates) to allow CRP to be bypassed. I wonder whether such a test could 
be automated? It strikes me that the core's behaviour may not be 
deterministic at excessive clock rates -- maybe it won't even start up 
if the PLL can't synchronise to a clock input that's far too fast.

I'm fortunate: CRP isn't an issue for me, and if I blow up a board I'll 
just make another one. I guess my (perhaps overly generous) view is that 
no security system is ever likely to be perfect, and the architects of 
any such system are unlikely to want to spend too much time discussing 
its vulnerabilities in public. If code security is absolutely the most 
critical aspect of a project, and assuming that CRP circumvention is 
non-trivial, I guess the solution is simple: move to a different, 
better-protected platform and absorb any additional expense. My feeling 
is that any such forced migrations are unlikely to hit Philips Semis' 
bottom line too hard -- unless, of course, CRP circumvention turns out 
to be a trivial matter.

Anyway, enough of my ramblings. Please don't read any of the above as an 
attack -- that's not my intention. Apologies in advance for any 
inadvertent offence!


Stuart