Lpc2000

Dominic, I do not think this is the threat the designers were defending.

>    Date: Mon, 6 Feb 2006 21:21:04 +0100
>    From: Dominic Rath <Dominic.Rath@...>
>Subject: Re: Re: CRP exploits using JTAG
>
>On Monday 06 February 2006 21:01, dr_danish_ali wrote:
> > Hi Dominic,
> > If the clocks are unrelated / asynchronous and you rely on RTCK, then sure
> > the fastest you can run the TCK at is 1/6 of the core frequency. But if you
> > control the core frequency (i.e. generate it and feed it into the
> > oscillator pin) and also generate TCK, I reckon that you might be able to
> > push TCK up to 1/2 of the core frequency and get it through the
> > synchronizer.

For what it is worth, I think you should be able to push it to core 
frequency itself as the TDMI-S TRM seems to imply in "Clocks and Resets" 
section.

> > ...
> > But the MAM is fully disabled so you'll need seven core ticks
> > for each FLASH memory access.

I am interested to know how to use this information to work out exactly how 
many cycles it takes to carry out each of the three instructions below:

>         ldr     r2, =PINSEL2                                    @e000
>         mov     r3, #0                                          @e004
>         swp     r0, r3, [r2]                                    @e008

There are four flash memory accesses and three execute cycles.  I am 
guessing it is something like 4*7 (flash) + 3*3 (execute) - 3 (pipeline) = 
34 TCKs.

Now if we add one more instruction (to retain exception handler code), it 
will add another two flash memory accesses and one execute cycle, making 
the total 49 TCKs.

So if someone can come up with a calculation to the effect that JTAG can be 
used to exploit within 49 ticks, but not within 34 ticks, then we can say 
an exploit has been blocked and losing exception handler in the process was 
worth it.

>You can't access the JTAG port while the device is in reset, because the 
>LPCs keep the test logic in reset, too.

I am curious if this is stated anywhere or if you determined this by 
experiment.  Note, besides ETM chain, there is also a processor chain that 
can be accessed.

>Test logic comes out of reset in Test-Logic-Reset. From there, you have to 
>go to Shift-IR to select the SCAN_N instruction, that's 5 TCK cycles. The 
>IR register is 4 bits long, but the last bit is scanned when moving out of 
>Shift-IR, so you spend 3 ticks shifting bits into the IR reg. From there, 
>you have to move to Shift-DR to select the EmbeddedICE scan chain. This 
>takes 7 TCK cycles. The SCAN_N register is 4 bits long, so you shift 3 
>bits. Back to
>Shift-IR to select INTEST takes 8 ticks. 3 ticks for the instruction. 7 
>Ticks back to Shift-DR. The EmbeddedICE scan chain is 38 bits long, 
>requiring a shift of 37 cycles. The synchronization latches only open in 
>Run-Test/Idle, so you have to move there in 5 ticks, plus one tick in 
>R-T-I for the debug request to register.
>5 + 3 + 7 + 3 + 8 + 3 + 7 + 37 + 5 + 1 = 79 TCK cycles.

I can  follow your logic here, but 79 ticks seems too far off the mark 
compared to 34 and 49 above.  Have out missed out something?

Jaya


Send instant messages to your online friends http://au.messenger.yahoo.com