OK, If you are so sure then... - You should be able to reverse the code easily... - Forget about JTAG boundary scan, control the ARM7 CPU directly - And ...Don't worry about the small timing window (The small time slot before ARM7 CPU disables JTAG after reset) => may be you can simply "ENLARGE" it by clocking the CPU at lower freq of few 10KHz... Try that when you have your new LPC2194 board. And may be later you can lead a class action suit.... Hee... Have fun and HAPPY NEW YEAR.... --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote: > > --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote: > > Oops!... Back to same old question again... > > How are you so sure that the JTAG port is not locked > > up properly when CRP enabled?? > > As sure as the people in Philips who specified the boot loader. >

An Engineer's Guide to the LPC2100 Series

OK, If you are so sure then... - You should be able to reverse the code easily... - And ...Don't worry about the small timing window => may be you can "ENLARGE" it by clocking the CPU at lower freq of few 10KHz... Try that when you have your new LPC2194 board. And may be later you can lead a class action suit.... Hee... Have fun and HAPPY NEW YEAR.... --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote: > > --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote: > > Oops!... Back to same old question again... > > How are you so sure that the JTAG port is not locked > > up properly when CRP enabled?? > > As sure as the people in Philips who specified the boot loader. >

--- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote: > Oops!... Back to same old question again... > How are you so sure that the JTAG port is not locked > up properly when CRP enabled?? As sure as the people in Philips who specified the boot loader.

OK, Following is my thinking about the security of CRP....(all guessing only...) a) JTAG not enabled when power up - The 2 control bits on Reg PINSEL2 are '1' to enable. Meaning they should be disabled when power up. (I guess all registers are reset to zero upon power up) - As long as BootLoader does not enable the JTAG port when CRP enable, there is no way to read out code from JTAG port. b) Undocumented commands in boot loader (e.g. 'T') - Safe As long as Boot Loader disable all commands and only allows Chip Erase when CRP enabled c) Undocumented flash programming mode - I believe there is some "undocumented programming mode" (like parallel programming) in the manufacturing process. - JTAG seems to be disabled when power up, so Philips must have "some way" to program the boot loader onto the chip when chip is just manufactured (or fresh from oven). Parallel programming also saves manufacturing test time. - => As long as philips keep secret of this programming mode. Who cares.... - BTW, where is this chip fabricated, TSMC or MXIC?? Anybody knows?? d) Reversing the code when CRP enable... Pls, You really cannot expect what hackers will do to your chip when reversing it.... it is not something simple of just cracking the flash programming method.... Following might be some possible way in reading the code out: i) Issue a chip erase to bootloader and timed power off (or reset) the chip half-way. Might ended up first sectors (with 0x87654321) erased only... ii) Find out the exact few clock cycles (from reset) that BootLoader reads 0x87654321, pulse the few clock cycles to >100Mhz (ARM CPU seems can take >100Mhz but not the Flash+ECC). The CPU could read garbage from location 0x1FC (supposed to be 0x87654321) iii) On LPC2103, where SRAM and RTC are powered by VBAT. Short VBAT to ground for 100uS when BootLoader running, Try lots of times and there could be chances that BootLoader does not hangup but CRP unlocked. Overall, I still think the CRP protection mechanism is reasonable "SECURE AND SAFE"..... Though some "screw up" of did not put in "Hardware protection" in original design.... It is much better than the AT89C52 (date code before year 2000) which is having 20+ ways of cracking it... Have fun....and HAPPY NEW YEAR... --- In lpc2000@lpc2..., "unity0724" <unity0724@y...> wrote: > > Oops!... Back to same old question again... > How are you so sure that the JTAG port is not locked > up properly when CRP enabled?? > > --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> > wrote: > > > > Robert, > > > > Boundary scan *is* implemented according to section 22.3 of the > user > > manual for LPC214x parts. > > > > "The scan chains that are around the core for production test are > > reused in the debug state to capture information from the data bus > and > > to insert new information into the core or the memory." > > > > Disabling debug by actively executing instruction simply disables > the > > reuse of these scan chains for debugging purposes through ETM. > > > > The chains are however accessible long before the processor comes > out > > of reset, and software security on LPC series is only as safe as > how > > safely boundary scan specifications can be kept secret. > > > > Leaving boundary scaning methods aside, there are other methods of > > stalling the processor using ETM before it reaches third > instruction, > > for example by manually clocking as it the processor out of reset. > > > > Reducing the window of opportunity by disabling debug port quickly > > serves only increases the effort it takes to sneak in. It does not > > prevent it. > > > > I would urge anyone who depends on code in the CEP enabled device > > being secure from preying eyes to seriosly look at issues as a > whole, > > especially informatino that is not disclosed in the LPC scheme > where > > CEP is dependent on execution of instructions in the boot loader > after > > the procesor comes out of reset. > > > > Jaya > > > > --- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...> > wrote: > > > > > > Boundary Scan is not just a technique, it needs to be > implemented in > > > hardware as such AND IT IS NOT IMPLEMENTED on the devices on the > > > market so far. > > > > > > Robert > > > > > > --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> > wrote: > > > > > > > > There is a technique called JTAG boundary scanning. From > memory, (I > > > > did this some years ago) boundary scanning does not require > the > > > target > > > > to come out of reset. In such a system, the "ememy" is all > over the > > > > code long before the processor even wakes up, and thus how > quickly it > > > > takes to secure flash becomes irrelevant. > > > > > >

Oops!... Back to same old question again... How are you so sure that the JTAG port is not locked up properly when CRP enabled?? --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote: > > Robert, > > Boundary scan *is* implemented according to section 22.3 of the user > manual for LPC214x parts. > > "The scan chains that are around the core for production test are > reused in the debug state to capture information from the data bus and > to insert new information into the core or the memory." > > Disabling debug by actively executing instruction simply disables the > reuse of these scan chains for debugging purposes through ETM. > > The chains are however accessible long before the processor comes out > of reset, and software security on LPC series is only as safe as how > safely boundary scan specifications can be kept secret. > > Leaving boundary scaning methods aside, there are other methods of > stalling the processor using ETM before it reaches third instruction, > for example by manually clocking as it the processor out of reset. > > Reducing the window of opportunity by disabling debug port quickly > serves only increases the effort it takes to sneak in. It does not > prevent it. > > I would urge anyone who depends on code in the CEP enabled device > being secure from preying eyes to seriosly look at issues as a whole, > especially informatino that is not disclosed in the LPC scheme where > CEP is dependent on execution of instructions in the boot loader after > the procesor comes out of reset. > > Jaya > > --- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...> wrote: > > > > Boundary Scan is not just a technique, it needs to be implemented in > > hardware as such AND IT IS NOT IMPLEMENTED on the devices on the > > market so far. > > > > Robert > > > > --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote: > > > > > > There is a technique called JTAG boundary scanning. From memory, (I > > > did this some years ago) boundary scanning does not require the > > target > > > to come out of reset. In such a system, the "ememy" is all over the > > > code long before the processor even wakes up, and thus how quickly it > > > takes to secure flash becomes irrelevant. > > >

Robert, Boundary scan *is* implemented according to section 22.3 of the user manual for LPC214x parts. "The scan chains that are around the core for production test are reused in the debug state to capture information from the data bus and to insert new information into the core or the memory." Disabling debug by actively executing instruction simply disables the reuse of these scan chains for debugging purposes through ETM. The chains are however accessible long before the processor comes out of reset, and software security on LPC series is only as safe as how safely boundary scan specifications can be kept secret. Leaving boundary scaning methods aside, there are other methods of stalling the processor using ETM before it reaches third instruction, for example by manually clocking as it the processor out of reset. Reducing the window of opportunity by disabling debug port quickly serves only increases the effort it takes to sneak in. It does not prevent it. I would urge anyone who depends on code in the CEP enabled device being secure from preying eyes to seriosly look at issues as a whole, especially informatino that is not disclosed in the LPC scheme where CEP is dependent on execution of instructions in the boot loader after the procesor comes out of reset. Jaya --- In lpc2000@lpc2..., "philips_apps" <philips_apps@y...> wrote: > > Boundary Scan is not just a technique, it needs to be implemented in > hardware as such AND IT IS NOT IMPLEMENTED on the devices on the > market so far. > > Robert > > --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote: > > > > There is a technique called JTAG boundary scanning. From memory, (I > > did this some years ago) boundary scanning does not require the > target > > to come out of reset. In such a system, the "ememy" is all over the > > code long before the processor even wakes up, and thus how quickly it > > takes to secure flash becomes irrelevant. >

Hello, I've put a small program that blinks the LED of my Olimx H2294 board into the on-chip flash, with 0x1fc set to 0x87654321. Bootloader is version 1.63. JTAG doesn't work anymore. Here are the results you wanted: 190 A (entered G 0 A) 19tEsT A (entered G tEsT A) 191073741824 4 8 0 (entered T 1073741824 4 8 0) The reply was '19' (CODE_READ_PROTECTION_ENABLED) each time, indicating that the CRP works as promised. Regards, Dominic On Sunday 01 January 2006 15:45, jayasooriah wrote: > I do not wish to comment on what the T command is there for, except to > say it most will be surprised to know what it does, let alone that it > exists. I would like to give Philips an opportunity to respond to my > original question first. > > Meanwhile, could those interested in checking out CRP feature to do > the following and post the results: > > 1/ Enable CRP on a device (blank one will do). > > 2/ Verify CRP is enabled by Entering "G 0 A" and noting the result. > > 3/ Enter "G tEsT A" and observe what happens. > > 4/ Enter "T 1073741824 4 8 0" and observe the result code. > > I like to use these results to confirm that I have understood the boot > loader code correctly. I am not able to do these tests myself because > my board will not arrive for another couple of weeks. > > I will follow up with a reference to my documentation of boot loader > internals when this is ready, hopefully very soon. > > Many thanks. > > Jaya

I do not wish to comment on what the T command is there for, except to say it most will be surprised to know what it does, let alone that it exists. I would like to give Philips an opportunity to respond to my original question first. Meanwhile, could those interested in checking out CRP feature to do the following and post the results: 1/ Enable CRP on a device (blank one will do). 2/ Verify CRP is enabled by Entering "G 0 A" and noting the result. 3/ Enter "G tEsT A" and observe what happens. 4/ Enter "T 1073741824 4 8 0" and observe the result code. I like to use these results to confirm that I have understood the boot loader code correctly. I am not able to do these tests myself because my board will not arrive for another couple of weeks. I will follow up with a reference to my documentation of boot loader internals when this is ready, hopefully very soon. Many thanks. Jaya --- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...> wrote: > > On Monday 26 December 2005 04:32, rtstofer wrote: > > For the 2294, the current boot code is at least ver 1.63 and CRP > > wasn't implemented until ver 1.60. Is there a T command in the > > latest version of the boot code for the 2294? If not, the question > > above is irrelevant. And that is the issue - there is not one shred > > of evidence that the boot code, as implemented, doesn't work as > > described in the datasheet and errata. > I have a LPC2294 with boot code version 1.63, and it implements the 'T' > command. I've quickly checked through the corresponding code, and it does > access a GPIO register (E0028000), as Jaya said. Haven't had time to look > further into it. > > Regards, > > Dominic >

I meant LPC 2148 (damn fingers!) --- In lpc2000@lpc2..., "jayasooriah" <jayasooriah@y...> wrote: > > Thanks Dominic, > > This command also exists boot code version 2.1 for LPC 2194. If > someone with a CRP enabled can drop me an email, I can give you more > information about what arguments are needed so you can tell us all > what you find. > > Jaya

Thanks Dominic, This command also exists boot code version 2.1 for LPC 2194. If someone with a CRP enabled can drop me an email, I can give you more information about what arguments are needed so you can tell us all what you find. Jaya --- In lpc2000@lpc2..., Dominic Rath <Dominic.Rath@g...> wrote: > I have a LPC2294 with boot code version 1.63, and it implements the 'T' > command. I've quickly checked through the corresponding code, and it does > access a GPIO register (E0028000), as Jaya said. Haven't had time to look > further into it. > > Regards, > > Dominic >