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

Thanks for asking Stuart.  Helps clarify things, and I welcome you post.

Trashing Memory
---------------

I use the word "trashing" to simply mean unintentional scribling of
memory, usually through a pointer that is not bounds checked.  Most
often this happens in strcpy() or memcpy() type of library calls.

If this happens to the flash control register (LPC[6]), this will be
execute as a command which could write or erase any sector that is
currently selected in sector select register (LPC[7]).

If the trashing included timing registers (LPC[10] and LPC[11]) then
this could potentially not only destroy contents of flash, but the
part itself.

When it happened to me, I had a missing "thumb_func" in my startup
code.  Also the version of boot loader was 1.03 from memory and there
was a statement in the errata sheets that for 10% of the parts with
boot loader prior to 1.52, IAP calls may not return.

With hindsight, it may well be that I looked into the boot loader for
all the wrong reasons.  However, as an academic, having found what I
have found, I am glad I went through this exercise.


Broken CSI
----------

On the 2105 loader version 1.51 (that which I put up the source and
that on which I can test readily), after "Syncrhonized", when you
enter "U 0 0 0 0 0", the CSI panics.  You get a series of CPSR and LR
output as decimal numbers.  It does not mattter what the command is. 
This is what I mean by CSI is broken.

What happens when CSI crashes is indeterminate.  Should this also
happen in your part with CRP, the same is true of security of CRP.

One of the first methods of hacking is using CSI exploits.  As a user
of the device, it is unlikely you will discover this vulnerability.  I
found this because I looked at the code.  This is one of the arguments
used both for and against security by obscurity.


Memory Loader
-------------

What you have done for uploading code is exactly what I did, because
the supplied loader from Philips would not open VCPs.  (We use FT232
for USB interface.)

I am in the process of making it available for all, in a form that you
can just load and play.  No setting of parameters required.

It auto-bauds (you just have to type the space bar once) and accepts
intel hex records from any terminal enulator.

As it coexists with the Philips supplied boot loader, and it does not
have any flash programming algorithm, you can just use it to download
and run programs using just a terminal emulator at speeds from 300 to
921600 baud.


JTAG Vulnerability
------------------

I feel most here find discussion of JTAG exploits too much.  It is
futile debating over carefully worded statements that do not address
the issues raised to the point.

Besides, the issues I have found with boot loader somewhat overshadow
JTAG vulnerabilities.

Given Philips has not been forthcoming with any comment at all on the
"T" command, I think talking about JTAG specifications is not going to
get us anywhere.

I have not personally exploited JTAG to void CRP, but if I have, I
would not admit to it either.  An occupational hazard I guess.  Also,
it is possible to disable JTAG permanantly by electrical or mechanical
means.  The issue is the extra costs for doing this compared to the
price savings on the part itself.  The 2104/5/6 is cheap after all.

Jaya

--- In lpc2000@yahoogroups.com, Stuart Wallace <swallace@e...> wrote:
>
> 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
>

--- In lpc2000@yahoogroups.com, Stuart Wallace <swallace@e...> wrote:
> 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.

Oops!....  You got some good points and could be right....

Actually, I still do not think/believe CPU runs on JTAG clock,
during the time slot "after Reset and before the few instruction
disabling JTAG".  It should be running on XTALIN.
=> If there is no JTAG clock (Normal operation), which clock the CPU
is running on after reset??

If this is the case, open out/widen the hacking window by clocking
the  CPU at much lower frequency (at XTALIN) should get the chip
hacked.
- Pull P1.20/P1.26 low to enable JTAG
- JTAG enabled by hardware by default (after reset)
- CPU get out of reset (running on XTALIN)
- CPU trying to disable JTAG, but acts slower than external JTAG and
  get reset and control by external JTAG device.
- CPU controlled by JTAG, force into another reset by JTAG, CPU runs
  on JTAG clock now and controlled by JTAG.
- NOTE:  this will not work if chips need a higher frequency XTALIN 
  clock to synchronises JTAG clock/signals.  I do not have/use a
  LPC2xxx tools and not familiar with that JTAG interface.

Anyway, opening out the windows is NOT the only possible hacking...
The above description is NOT very important..
=======================================
LPC21xx looks "quite" defenseless to hacking (especially when all
operating parameters like voltages and clock speed are out of spec),
base on the observations:
- Problem is created by JTAG default as enabled and need CPU action
  to disable it. To hack the chip, just disabled/hang up the CPU
  before it could disables the JTAG during normal operation. 
- If JTAG is hardware enabled by default (if P1.20, P1.26 pulled
  low). and if there is no CPU action to disable JTAG.  The JTAG
  should be left enabled for hacking.
- If philips uses JTAG to program fresh chips (blank chips just
  manufactured and without any code inside), that would mean no code
  or initialization needed to get JTAG working properly after the
  reset.   To hack the chip, just create some "similar" condition...
  (Philips guys until now never say that they use the same JTAG for
   factory programming => Still high hope of robust CRP...)

=> "Possible" ways of hacking on LPC2114 to LPC2194
i) Normal supply voltage, Clock the CPU at very low freq, use JTAG
   to force in before CPU could disable it
ii) Normal supply voltage,  Clock the CPU at very high frequency, 
   hangup or screw up flash memory read for first few cycles.   
   change clock back to normal 10-20MHz and let JTAG breaking in.
iii) Power the CPU core voltage at very low voltage (i.e. <1V),
    either messy up the flash memory or even the CPU core.   Raise
    Core voltage to normal 1.8V after that and let JTAG breaking in.
iv) Chip somehow requires longer reset pulse immediately after power
    up. much shorter pulse after that (May be Internal flash is not
    running at 1.8V and need some charge pump??).   Power up the
    chip without (or very short) reset pulse might have the CPU not
    running properly.
v)  Normal supply Voltage & clock freq, when chip is getting out of
    reset, inject a very strong electromagnetic pulse externally to
    hangup the CPU.  

=> "Possible" way of hacking on LPC213x & LPC214x
Methods i,ii and v as above

=> "Possible" way of hacking LPC2103
Cannot think of ...
(JTAG is DISABLED by default after reset, right??)
CRP is much more robust here as JTAG is default as <<OFF>>.

Note:
- Hackers only need 0.001% chances of breaking in, all hacking can 
  be automated.
- I made the assumption that the debug interface has lower chances
  of hanging up than the CPU core
- I'm not familiar with LPC2xxx JTAG.   I do not have/use JTAG tools
- All are NOT proven hacking methods. Unable to prove chips are
  immune to those hackings either.  I hope chips are immune to all
  those hackings else I've great pain of changing all designs.
- Sorry for throwing in a small bomb on LPC2xxx CRP... Hope it does
  not explode...

Regards