Lpc2000

For reference the posting we did on Dec 22
----
1) Am I right in assuming LPC2000 CRP is a software fence implemented
in the supplied boot loader code?

Partially. It is a combination of Hardware and Software supplied in
the bootloader code. Application running in micro has full access to
the entire memory space.

2) I am going to replace the Philips bootloader. I have figured out
how to do it.

Replacing the Philips bootloader is not recommended. It hides the
underlying hardware and allows Philips to use new flash technologies
without impacting the end user. Philips Bootloader may reside in ROM
or write/erase protected flash making replacement impossible. In
LPC2101/2/3 the bootloader resides in on-chip ROM.

3) How is Bootloader programmed for the first time?

Via JTAG on a tester. JTAG is accessible in virgin devices. Once
bootloader is programmed and CRP is enabled the tester can't access
the JTAG.

4) CRP in devices with internal flash and external bus.

The bootloader prevents external boot if CRP is enabled. User
Application residing in on-chip flash which needs to be protected
should not execute code from external memory.

5) Can bootloader write/erase itself?

No.

6) Can bootloader get corrupted?

Very unlikely if IAP/ISP calls are used for flash programming.
Very likely if Flash programming interface registers are directly
accessed for flash programming.

7) Can Philips comment if Quick-Pulse parallel programming can void 
CRP?

First of all there is no Quick-Pulse parallel programming option for
ARM based micros. We are sorry for not making clear what is meant by
"Parallel Programming" for ARM based micros. Parallel programming for
ARM based micros just means that the device can be mass programmed in
a commercial programmer. Parallel programmers still use JTAG and/or
ISP and go through the bootloader IAP routines to program the on-chip
flash. It does not matter how a part is programmed. If CRP is enabled
it will remain enabled once the part is programmed. If CRP is enabled
a parallel programmer can't access the flash unless it erases the
whole flash. Same applies to the ISP utility and JTAG based 
debuggers.

8) Is CRP option available for 2104/05/06?

Not yet.

9) Devices with external memory bus can be forced to boot from
external memory?

ONLY if CRP is NOT enabled or NO internal flash present. Also see 
(4).

10) Can I tell client Philips has confirmed CRP is not voided by PP?

Yes. Also see (7).

11) How do I reprogram a CRP enabled part?

Erase all user sectors in one go via ISP. You can reprogram it after 
a
power cycle.
Please note that the protected code vanished and was not visible to a
"spy" or "praying eyes".

--------
12) Can JTAG be or remain enabled through clocking the CPU slowly 
and JTAG fast during the initial time window after reset where JTAG 
is enabled?

No, the clock for JTAG and the CPU are syncronized on these devices. 
There are not enough JTAG clocks to control the CPU before the JTAG 
gets disabled by the bootloader software. 

13) Can the bootloader update be performed when CRP is enabled?

No, the bootloader update uses commands like copy RAM to Flash which 
is disabled when CRP is enabled. The message will be that there is 
no communication possible. 


Comment to Robert Adsets posting:
It is correct that support efforts would be significantly higher 
with published source code of the bootloader and let me add without 
adding any benefits to you, our customers.

Thank you!

Richard

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
wrote:
>
> For reference the posting we did on Dec 22
> ----
> 1) Am I right in assuming LPC2000 CRP is a software fence 
implemented
> in the supplied boot loader code?
> 
> Partially. It is a combination of Hardware and Software supplied in
> the bootloader code. Application running in micro has full access 
to
> the entire memory space.
> 
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
> 
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash 
technologies
> without impacting the end user. Philips Bootloader may reside in 
ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
> 
> 3) How is Bootloader programmed for the first time?
> 
> Via JTAG on a tester. JTAG is accessible in virgin devices. Once
> bootloader is programmed and CRP is enabled the tester can't access
> the JTAG.
> 
> 4) CRP in devices with internal flash and external bus.
> 
> The bootloader prevents external boot if CRP is enabled. User
> Application residing in on-chip flash which needs to be protected
> should not execute code from external memory.
> 
> 5) Can bootloader write/erase itself?
> 
> No.
> 
> 6) Can bootloader get corrupted?
> 
> Very unlikely if IAP/ISP calls are used for flash programming.
> Very likely if Flash programming interface registers are directly
> accessed for flash programming.
> 
> 7) Can Philips comment if Quick-Pulse parallel programming can 
void 
> CRP?
> 
> First of all there is no Quick-Pulse parallel programming option 
for
> ARM based micros. We are sorry for not making clear what is meant 
by
> "Parallel Programming" for ARM based micros. Parallel programming 
for
> ARM based micros just means that the device can be mass programmed 
in
> a commercial programmer. Parallel programmers still use JTAG and/or
> ISP and go through the bootloader IAP routines to program the on-
chip
> flash. It does not matter how a part is programmed. If CRP is 
enabled
> it will remain enabled once the part is programmed. If CRP is 
enabled
> a parallel programmer can't access the flash unless it erases the
> whole flash. Same applies to the ISP utility and JTAG based 
> debuggers.
> 
> 8) Is CRP option available for 2104/05/06?
> 
> Not yet.
> 
> 9) Devices with external memory bus can be forced to boot from
> external memory?
> 
> ONLY if CRP is NOT enabled or NO internal flash present. Also see 
> (4).
> 
> 10) Can I tell client Philips has confirmed CRP is not voided by 
PP?
> 
> Yes. Also see (7).
> 
> 11) How do I reprogram a CRP enabled part?
> 
> Erase all user sectors in one go via ISP. You can reprogram it 
after 
> a
> power cycle.
> Please note that the protected code vanished and was not visible 
to a
> "spy" or "praying eyes".
> 
> --------
> 12) Can JTAG be or remain enabled through clocking the CPU slowly 
> and JTAG fast during the initial time window after reset where 
JTAG 
> is enabled?
> 
> No, the clock for JTAG and the CPU are syncronized on these 
devices. 
> There are not enough JTAG clocks to control the CPU before the 
JTAG 
> gets disabled by the bootloader software. 
> 
> 13) Can the bootloader update be performed when CRP is enabled?
> 
> No, the bootloader update uses commands like copy RAM to Flash 
which 
> is disabled when CRP is enabled. The message will be that there is 
> no communication possible. 
> 
> 
> Comment to Robert Adsets posting:
> It is correct that support efforts would be significantly higher 
> with published source code of the bootloader and let me add 
without 
> adding any benefits to you, our customers.
>

It is so very easy to make you happy Richard :)

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:

> Thank you!
> 
> Richard

Many thanks to the summary and conclusion, and clarifications
 showing "no simple way of cracking the read protection."

I would suggest may be portion of bootloader should be locked 
up permanently, such that no user could reverse/disassembly 
the bootloader completely.  =>

- Break down bootloader flash into 2 segments/sectors,
- After power up, ARM7 runs on segment #0, immediately
   disables JTAG
- After doing all the secret chip initialization, disabling of 
   some chip features, switch to segment #1
- Bootloader Disables segment #0, this is sticky disabling and 
   could only be clear by reset or WDT
- Sticky bit also disables bootloader update, fulfilling some
  high expectation engineers bootloader will NEVER be corrupted
- Enable JTAG now if needed to, proceed to normal boot 
   loader functions...
- All user functions like flash programming are in segment #1

Nobody could predict what hackers will do after disassembly the 
boot loader, why not lock portion of it up permanently.  Only
drawback of user like us can no longer upgrade bootloader easily.

===================================
Secondly, may be good to build in a very very simple MMU on LPFQ144
in future...
- All flash+ram+bootloader inside chip are supervisor mode
- whatever outside chip are user mode
- I/O are not protected.
(better if it can be a pointer dividing internal flash memory into 2)

It will be good for:
- Someone to come out with a very nice LPC2xxx educational kit
- Some "Open Platform" oem board builder.

Regards


--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> 
wrote:
>
> For reference the posting we did on Dec 22
> ----
> 1) Am I right in assuming LPC2000 CRP is a software fence 
implemented
> in the supplied boot loader code?
> 
> Partially. It is a combination of Hardware and Software supplied in
> the bootloader code. Application running in micro has full access 
to
> the entire memory space.
> 
> 2) I am going to replace the Philips bootloader. I have figured out
> how to do it.
> 
> Replacing the Philips bootloader is not recommended. It hides the
> underlying hardware and allows Philips to use new flash 
technologies
> without impacting the end user. Philips Bootloader may reside in 
ROM
> or write/erase protected flash making replacement impossible. In
> LPC2101/2/3 the bootloader resides in on-chip ROM.
> 
> 3) How is Bootloader programmed for the first time?
> 
> Via JTAG on a tester. JTAG is accessible in virgin devices. Once
> bootloader is programmed and CRP is enabled the tester can't access
> the JTAG.
> 
> 4) CRP in devices with internal flash and external bus.
> 
> The bootloader prevents external boot if CRP is enabled. User
> Application residing in on-chip flash which needs to be protected
> should not execute code from external memory.
> 
> 5) Can bootloader write/erase itself?
> 
> No.
> 
> 6) Can bootloader get corrupted?
> 
> Very unlikely if IAP/ISP calls are used for flash programming.
> Very likely if Flash programming interface registers are directly
> accessed for flash programming.
> 
> 7) Can Philips comment if Quick-Pulse parallel programming can 
void 
> CRP?
> 
> First of all there is no Quick-Pulse parallel programming option 
for
> ARM based micros. We are sorry for not making clear what is meant 
by
> "Parallel Programming" for ARM based micros. Parallel programming 
for
> ARM based micros just means that the device can be mass programmed 
in
> a commercial programmer. Parallel programmers still use JTAG and/or
> ISP and go through the bootloader IAP routines to program the on-
chip
> flash. It does not matter how a part is programmed. If CRP is 
enabled
> it will remain enabled once the part is programmed. If CRP is 
enabled
> a parallel programmer can't access the flash unless it erases the
> whole flash. Same applies to the ISP utility and JTAG based 
> debuggers.
> 
> 8) Is CRP option available for 2104/05/06?
> 
> Not yet.
> 
> 9) Devices with external memory bus can be forced to boot from
> external memory?
> 
> ONLY if CRP is NOT enabled or NO internal flash present. Also see 
> (4).
> 
> 10) Can I tell client Philips has confirmed CRP is not voided by 
PP?
> 
> Yes. Also see (7).
> 
> 11) How do I reprogram a CRP enabled part?
> 
> Erase all user sectors in one go via ISP. You can reprogram it 
after 
> a
> power cycle.
> Please note that the protected code vanished and was not visible 
to a
> "spy" or "praying eyes".
> 
> --------
> 12) Can JTAG be or remain enabled through clocking the CPU slowly 
> and JTAG fast during the initial time window after reset where 
JTAG 
> is enabled?
> 
> No, the clock for JTAG and the CPU are syncronized on these 
devices. 
> There are not enough JTAG clocks to control the CPU before the 
JTAG 
> gets disabled by the bootloader software. 
> 
> 13) Can the bootloader update be performed when CRP is enabled?
> 
> No, the bootloader update uses commands like copy RAM to Flash 
which 
> is disabled when CRP is enabled. The message will be that there is 
> no communication possible. 
> 
> 
> Comment to Robert Adsets posting:
> It is correct that support efforts would be significantly higher 
> with published source code of the bootloader and let me add 
without 
> adding any benefits to you, our customers.
>

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:
>
> It is so very easy to make you happy Richard :)

Yes.  My applications are trivial, my knowledge nearly non-existent 
and security is no concern.  I'm just building toys, really.

I am more than willing to accept what is stated in the datasheet and, 
as I read it, CRP works.  Philips says it does, they stand behind 
their products; therefore, it is settled.  In my mind...

I would still be 'curious', but not concerned, about the 'T' command.

Richard

OK, Me too also accept and trust what Philips says.   I'm happy 
with the read protection mechanism what Philips had implemented 
so far.

There will always be some very unexpected way of hacking the chip.
May be by:
- clock the first few instructions at >100Mhz (after reset) such
  that the first few instruction for disabling the JTAG are 
  "screw up" and breaking the CRP.

But who cares...
Somebody please provide some proven way of cracking the chip 
else this thread should be concluded.

Regards

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
> >
> > It is so very easy to make you happy Richard :)
> 
> Yes.  My applications are trivial, my knowledge nearly non-
existent 
> and security is no concern.  I'm just building toys, really.
> 
> I am more than willing to accept what is stated in the datasheet 
and, 
> as I read it, CRP works.  Philips says it does, they stand behind 
> their products; therefore, it is settled.  In my mind...
> 
> I would still be 'curious', but not concerned, about the 'T' 
command.

> 
> Richard
>

I dont know why are so eager to quench this discussion just because
you have no (or very simplistic) requirements in relation to code
security. It is perfectly alright for you to be not interested.

There are many people here, including myself, who are concerned (to
say the least) as to how safe IP that is loaded onto on-chip flash is
when the part is in thehands of the those who know what they are doing.

The ball is now in Philips' court.  Give them time to respond
credibly, or not at all as they see fit.  We all know how to make
inferences.

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:

> Many thanks to the summary and conclusion, and clarifications
> showing "no simple way of cracking the read protection."
> ...
> Somebody please provide some proven way of cracking the chip 
> else this thread should be concluded.

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
>
> I dont know why are so eager to quench this discussion just because
> you have no (or very simplistic) requirements in relation to code
> security. It is perfectly alright for you to be not interested.
> 
> There are many people here, including myself, who are concerned (to
> say the least) as to how safe IP that is loaded onto on-chip flash 
is
> when the part is in thehands of the those who know what they are 
doing.
> 
> The ball is now in Philips' court.  Give them time to respond
> credibly, or not at all as they see fit.  We all know how to make
> inferences.
> 
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
> > Many thanks to the summary and conclusion, and clarifications
> > showing "no simple way of cracking the read protection."
> > ...
> > Somebody please provide some proven way of cracking the chip 
> > else this thread should be concluded.

But, they have answered.  Again, today.  They posted replies to each 
and every issue.  The only outstanding item, and it wasn't on the 
list, is the T command.

Each and every item, answered.  And, no, they're not going to post 
the source.  And they don't recommend replacing the boot code for a 
couple of pretty good reasons.

To continiue badgering over "it isn't good enough because it isn't 
hardware only" seems to me to be questioning the skills of the 
engineers and the integrity of the company.  I am not willing to do 
either.

The questions were answered.  Except for the T command.  And I am 
willing to believe that a) the engineers know it is there and b) it 
doesn't provide a way to get around what they have designed.

If I needed security and I wasn't convinced after the answers 
provided that the system was satisfactory, I would just buy another 
product.  No big deal, there are dozens of competing devices.

Richard

>

Badgering?  With all due respect, let Philips do their job as they see
fit.  The forum could do less with your brown nosing.

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:

> To continiue badgering over "it isn't good enough because it isn't 
> hardware only" seems to me to be questioning the skills of the 
> engineers and the integrity of the company.  I am not willing to do 
> either.

>The forum could do less with your brown nosing.
>

Well, that would imply that I wanted something from Philips.  I 
don't.  My total demand for silicon won't exceed 3 or 4 devices over 
the forseeable future.  I don't work, I don't consult and I never 
will again.  There is nothing I want that I can't buy.

So, brown nosing isn't it.   

I truly believe the questions have been asked and that the answers 
are satisfactory.  I believe the datasheets and I believe the 
engineers know how to design a chip.  I also believe that there are 
two choices re: the devices:  accept the answers and buy them or 
reject the answers and buy something else.  I don't see a 3d 
solution because I doubt that Philips is going to change the 
technology based on this forum.

Richard

What you believe is irrelevant.  I posed the questions.  I will let
you know when Philips answers them if the answers are satisfactory.

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
> I truly believe the questions have been asked and that the answers 
> are satisfactory.

Jayasooriah,

Maybe you should post a concise list of questions you consider to be 
unanswered and an idea of what you would consider to be a satisfactory 
answer before this thread degenerates any further.

John

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> wrote:

>
> What you believe is irrelevant.  I posed the questions.  I will let
> you know when Philips answers them if the answers are satisfactory.
> 
> --- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
> > I truly believe the questions have been asked and that the answers 
> > are satisfactory.
>

--- In lpc2000@yahoogroups.com, "junderwo12" <john@u...> wrote:
Good suggestion John.  Thanks.  Once Philips has had time to come back
to us on the "T" command and "tEsT" argument, plus what is supposed to
happen when you enter "J 0 0 0 0" (I am not sure which versions of
boot loader still have this problem), I will.

> Jayasooriah,
> 
> Maybe you should post a concise list of questions
> you consider to be unanswered and an idea of what
> you would consider to be a satisfactory answer
> before this thread degenerates any further.
> 
> John

Ummm...  hello, not that I'm not interested of. <<<Is question of
 whether can somebody please show me some proven way of hacking the
 chip and document the process properly (I would be very interested
 in that)!! >>>  if want to crack chip, just crack it.  Philips is
 not going to tell us chip is "CRACK-able"
The thread had been going on for 2 weeks without any solid
 findings.  All are just "PURE SPECULATIONS".

I've already listed a possible way of cracking the chip. Can
 somebody please try out:
=> I think the ARM7 Core is much robust than the Flash memory,
 cracking along that path might be successful..
- Enable the CRP on a  CRP capable device (LPC2124 or LPC2214)
- Clock the chip at >100mhz for first few instructions, try to screw
 up the bootloader attempting to disable the JTAG (first few
 instruction only)
- The ARM7 CPU core seems capable of running up to around 200MHz
  but I do not think the flash+ECC circuit can take it.  Especially
  the ECC.
- Chip is cracked if ARM7 skips the first few instructions (whatever
  the few instructions will be mis-interpreted as:  logical and, or,
  mov, shift command).  The chip can be cracked as long as the
  instruction pointer/program counter move by just 3-5 instructions
  counts and PINSEL2 not written properly.
- After that you might have enough clock cycles to force in your
  JTAG control (before any bootloader tries to disables it again
  after reading the 0x87654321 from 0x1fc)
- If you cannot get it work the first few time, try with
  higher/lower frequencies,
- Or on that first few instruction cycles, drive the Core Voltage 
  at 0.9V to 1.2V where the flash might not even work. Power back
  to normal 1.8V after that few instructions.   You have full
  control of the clock pulses and voltage.
- Again, this is just purely speculation.   50% of LPC2124 are 
  even having about 3-5% chances of reset failures when I drive it
  at 50MHz.  (Hee, actually the chip does not even meet the 50Mhz
  datasheet clock input spec.   I do  not know  if the XTALI pin
  could take >100MHz, May be need to power core at 2.1V to run ARM7
  at >100Mhz)
- Power the Core voltage at very low voltage might have much better 
  successful rate.   I believe the ARM core might still work if you
  power it at 1V and few MHZ.   But can that flash work at 1V?? 
  (Come to think of that, may be I better switch my LPC2124 to
  LPC2136 with LDO and brown-out detect)  Guys with JTAG tools...
  pls try power the chip at much lower voltage and crack it...

If you cannot get that working (means the chip cracked).   I can  
 always think of more ideas for you....  We can try another 10-20
 methods....
But having one Big questions of:  What do we get if the LPC2xxx chip 
 proven can be cracked?? Crack it and read back our own code?? (we
 are supposed to be victims), or Making $$$ from some class action 
 suit??   :) :)

If anybody not comfortable with philips CRP then better switch to
 atmel. But I can ensure you there would be much more Atmel hackers
 (than philips) in China and Taiwan as that's Atmel's big market.  
Those chip hackers are REAL hackers and I'm NOT a chip hacker.

Happy new year to everybody...I still do not want my new year mood 
vaporized due to "CRP too fragile"...
Regards




--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@y...> 
wrote:
>
> I dont know why are so eager to quench this discussion just because
> you have no (or very simplistic) requirements in relation to code
> security. It is perfectly alright for you to be not interested.
> 
> There are many people here, including myself, who are concerned (to
> say the least) as to how safe IP that is loaded onto on-chip flash 
is
> when the part is in thehands of the those who know what they are 
doing.

> 
> The ball is now in Philips' court.  Give them time to respond
> credibly, or not at all as they see fit.  We all know how to make
> inferences.
> 
> --- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
> > Many thanks to the summary and conclusion, and clarifications
> > showing "no simple way of cracking the read protection."
> > ...
> > Somebody please provide some proven way of cracking the chip 
> > else this thread should be concluded.
>

hi unity0724

mention a sinlge semi conductor company that does'nt
want to do a
business in china and thaiwan.

it is totally absurd  to say A company has a marketing
edge in X conutry because you can hack that company
chip 

shridhar
--- unity0724 <unity0724@...> wrote:

> Ummm...  hello, not that I'm not interested of.
> <<<Is question of
>  whether can somebody please show me some proven way
> of hacking the
>  chip and document the process properly (I would be
> very interested
>  in that)!! >>>  if want to crack chip, just crack
> it.  Philips is
>  not going to tell us chip is "CRACK-able"
> The thread had been going on for 2 weeks without any
> solid
>  findings.  All are just "PURE SPECULATIONS".
> 
> I've already listed a possible way of cracking the
> chip. Can
>  somebody please try out:
> => I think the ARM7 Core is much robust than the
> Flash memory,
>  cracking along that path might be successful..
> - Enable the CRP on a  CRP capable device (LPC2124
> or LPC2214)
> - Clock the chip at >100mhz for first few
> instructions, try to screw
>  up the bootloader attempting to disable the JTAG
> (first few
>  instruction only)
> - The ARM7 CPU core seems capable of running up to
> around 200MHz
>   but I do not think the flash+ECC circuit can take
> it.  Especially
>   the ECC.
> - Chip is cracked if ARM7 skips the first few
> instructions (whatever
>   the few instructions will be mis-interpreted as: 
> logical and, or,
>   mov, shift command).  The chip can be cracked as
> long as the
>   instruction pointer/program counter move by just
> 3-5 instructions
>   counts and PINSEL2 not written properly.
> - After that you might have enough clock cycles to
> force in your
>   JTAG control (before any bootloader tries to
> disables it again
>   after reading the 0x87654321 from 0x1fc)
> - If you cannot get it work the first few time, try
> with
>   higher/lower frequencies,
> - Or on that first few instruction cycles, drive the
> Core Voltage 
>   at 0.9V to 1.2V where the flash might not even
> work. Power back
>   to normal 1.8V after that few instructions.   You
> have full
>   control of the clock pulses and voltage.
> - Again, this is just purely speculation.   50% of
> LPC2124 are 
>   even having about 3-5% chances of reset failures
> when I drive it
>   at 50MHz.  (Hee, actually the chip does not even
> meet the 50Mhz
>   datasheet clock input spec.   I do  not know  if
> the XTALI pin
>   could take >100MHz, May be need to power core at
> 2.1V to run ARM7
>   at >100Mhz)
> - Power the Core voltage at very low voltage might
> have much better 
>   successful rate.   I believe the ARM core might
> still work if you
>   power it at 1V and few MHZ.   But can that flash
> work at 1V?? 
>   (Come to think of that, may be I better switch my
> LPC2124 to
>   LPC2136 with LDO and brown-out detect)  Guys with
> JTAG tools...
>   pls try power the chip at much lower voltage and
> crack it...
> 
> If you cannot get that working (means the chip
> cracked).   I can  
>  always think of more ideas for you....  We can try
> another 10-20
>  methods....
> But having one Big questions of:  What do we get if
> the LPC2xxx chip 
>  proven can be cracked?? Crack it and read back our
> own code?? (we
>  are supposed to be victims), or Making $$$ from
> some class action 
>  suit??   :) :)
> 
> If anybody not comfortable with philips CRP then
> better switch to
>  atmel. But I can ensure you there would be much
> more Atmel hackers
>  (than philips) in China and Taiwan as that's
> Atmel's big market.  
> Those chip hackers are REAL hackers and I'm NOT a
> chip hacker.
> 
> Happy new year to everybody...I still do not want my
> new year mood 
> vaporized due to "CRP too fragile"...
> Regards
> 
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "jayasooriah"
> <jayasooriah@y...> 
> wrote:
> >
> > I dont know why are so eager to quench this
> discussion just because
> > you have no (or very simplistic) requirements in
> relation to code
> > security. It is perfectly alright for you to be
> not interested.
> > 
> > There are many people here, including myself, who
> are concerned (to
> > say the least) as to how safe IP that is loaded
> onto on-chip flash 
> is
> > when the part is in thehands of the those who know
> what they are 
> doing.
> > 
> > The ball is now in Philips' court.  Give them time
> to respond
> > credibly, or not at all as they see fit.  We all
> know how to make
> > inferences.
> > 
> > --- In lpc2000@yahoogroups.com, "unity0724"
> <unity0724@y...> wrote:
> > > Many thanks to the summary and conclusion, and
> clarifications
> > > showing "no simple way of cracking the read
> protection."
> > > ...
> > > Somebody please provide some proven way of
> cracking the chip 
> > > else this thread should be concluded.
> >
> 
> 
> 
> 
> 



		
__________________________________________ 
Yahoo! DSL \ufffd Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com

Hi, I think you got my points all wrong...

=> It should be if a company's microcontrollers is more popular
in X country. It will attract more hackers hacking their chips.
(Hee, Atmel microcontroller traditionally is very popular in
China/Taiwan. I do not know how long can the new AT91 CRP last...)

It is definitely NOT "if chip is HACK-able, it will be more
popular/marketing edge..." :)

(Hee...  I hope you are NOT Atmel re-seller...)
==========================================

Anyway, those are beside the main topic.
=> Can somebody here please prove the Philips CRP are "HACK-able".
Before we start some discussion whether to switch to..atmel maybe...

Regards


--- In lpc2000@yahoogroups.com, shridhar joshi 
<shridharjoshi2000@y...> wrote:

>
> hi unity0724
> 
> mention a sinlge semi conductor company that does'nt
> want to do a
> business in china and thaiwan.
> 
> it is totally absurd  to say A company has a marketing
> edge in X conutry because you can hack that company
> chip 
> 
> shridhar
> --- unity0724 <unity0724@y...> wrote:
> 
> > Ummm...  hello, not that I'm not interested of.
> > <<<Is question of
> >  whether can somebody please show me some proven way
> > of hacking the
> >  chip and document the process properly (I would be
> > very interested
> >  in that)!! >>>  if want to crack chip, just crack
> > it.  Philips is
> >  not going to tell us chip is "CRACK-able"
> > The thread had been going on for 2 weeks without any
> > solid
> >  findings.  All are just "PURE SPECULATIONS".
> > 
> > I've already listed a possible way of cracking the
> > chip. Can
> >  somebody please try out:
> > => I think the ARM7 Core is much robust than the
> > Flash memory,
> >  cracking along that path might be successful..
> > - Enable the CRP on a  CRP capable device (LPC2124
> > or LPC2214)
> > - Clock the chip at >100mhz for first few
> > instructions, try to screw
> >  up the bootloader attempting to disable the JTAG
> > (first few
> >  instruction only)
> > - The ARM7 CPU core seems capable of running up to
> > around 200MHz
> >   but I do not think the flash+ECC circuit can take
> > it.  Especially
> >   the ECC.
> > - Chip is cracked if ARM7 skips the first few
> > instructions (whatever
> >   the few instructions will be mis-interpreted as: 
> > logical and, or,
> >   mov, shift command).  The chip can be cracked as
> > long as the
> >   instruction pointer/program counter move by just
> > 3-5 instructions
> >   counts and PINSEL2 not written properly.
> > - After that you might have enough clock cycles to
> > force in your
> >   JTAG control (before any bootloader tries to
> > disables it again
> >   after reading the 0x87654321 from 0x1fc)
> > - If you cannot get it work the first few time, try
> > with
> >   higher/lower frequencies,
> > - Or on that first few instruction cycles, drive the
> > Core Voltage 
> >   at 0.9V to 1.2V where the flash might not even
> > work. Power back
> >   to normal 1.8V after that few instructions.   You
> > have full
> >   control of the clock pulses and voltage.
> > - Again, this is just purely speculation.   50% of
> > LPC2124 are 
> >   even having about 3-5% chances of reset failures
> > when I drive it
> >   at 50MHz.  (Hee, actually the chip does not even
> > meet the 50Mhz
> >   datasheet clock input spec.   I do  not know  if
> > the XTALI pin
> >   could take >100MHz, May be need to power core at
> > 2.1V to run ARM7
> >   at >100Mhz)
> > - Power the Core voltage at very low voltage might
> > have much better 
> >   successful rate.   I believe the ARM core might
> > still work if you
> >   power it at 1V and few MHZ.   But can that flash
> > work at 1V?? 
> >   (Come to think of that, may be I better switch my
> > LPC2124 to
> >   LPC2136 with LDO and brown-out detect)  Guys with
> > JTAG tools...
> >   pls try power the chip at much lower voltage and
> > crack it...
> > 
> > If you cannot get that working (means the chip
> > cracked).   I can  
> >  always think of more ideas for you....  We can try
> > another 10-20
> >  methods....
> > But having one Big questions of:  What do we get if
> > the LPC2xxx chip 
> >  proven can be cracked?? Crack it and read back our
> > own code?? (we
> >  are supposed to be victims), or Making $$$ from
> > some class action 
> >  suit??   :) :)
> > 
> > If anybody not comfortable with philips CRP then
> > better switch to
> >  atmel. But I can ensure you there would be much
> > more Atmel hackers
> >  (than philips) in China and Taiwan as that's
> > Atmel's big market.  
> > Those chip hackers are REAL hackers and I'm NOT a
> > chip hacker.
> > 
> > Happy new year to everybody...I still do not want my
> > new year mood 
> > vaporized due to "CRP too fragile"...
> > Regards
> > 
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "jayasooriah"
> > <jayasooriah@y...> 
> > wrote:
> > >
> > > I dont know why are so eager to quench this
> > discussion just because
> > > you have no (or very simplistic) requirements in
> > relation to code
> > > security. It is perfectly alright for you to be
> > not interested.
> > > 
> > > There are many people here, including myself, who
> > are concerned (to
> > > say the least) as to how safe IP that is loaded
> > onto on-chip flash 
> > is
> > > when the part is in thehands of the those who know
> > what they are 
> > doing.
> > > 
> > > The ball is now in Philips' court.  Give them time
> > to respond
> > > credibly, or not at all as they see fit.  We all
> > know how to make
> > > inferences.
> > > 
> > > --- In lpc2000@yahoogroups.com, "unity0724"
> > <unity0724@y...> wrote:
> > > > Many thanks to the summary and conclusion, and
> > clarifications
> > > > showing "no simple way of cracking the read
> > protection."
> > > > ...
> > > > Somebody please provide some proven way of
> > cracking the chip 
> > > > else this thread should be concluded.
> > >
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 		
> __________________________________________ 
> Yahoo! DSL – Something to write home about. 
> Just $16.99/mo. or less. 
> dsl.yahoo.com
>

--- In lpc2000@yahoogroups.com, "unity0724" <unity0724@y...> wrote:
> Anyway, those are beside the main topic.
> => Can somebody here please prove the Philips CRP are "HACK-able".

It is naive to expect somebody will do this.

What basis do you have to think that Atmel chips would be immune to the 
hacking process as you describe?

At 01:52 PM 1/6/2006, you wrote:

>Hi, I think you got my points all wrong...
>
>=> It should be if a company's microcontrollers is more popular
>in X country. It will attract more hackers hacking their chips.
>(Hee, Atmel microcontroller traditionally is very popular in
>China/Taiwan. I do not know how long can the new AT91 CRP last...)
>
>It is definitely NOT "if chip is HACK-able, it will be more
>popular/marketing edge..." :)
>
>(Hee...  I hope you are NOT Atmel re-seller...)
>==========================================
>
>Anyway, those are beside the main topic.
>=> Can somebody here please prove the Philips CRP are "HACK-able".
>Before we start some discussion whether to switch to..atmel maybe...
>
>Regards

--- In lpc2000@yahoogroups.com, Sean <embeddedrelated@w...> wrote:
> What basis do you have to think that Atmel chips would be immune 
> to the hacking process as you describe?

Umm...  sorry... Don't know much of AT91...
- Do not know if AT91 will be immune to hacking
- Do not know much about Atmel, ST chips.  Have not study their
  datasheet yet.  I'm still loyalist to philips parts. (And I hope
  Philips do not screw up on the CRP)
- Do not know if AT91 chips have better CRP mechanism.
- Very seldom visiting the AT91 forum.
- I'm NOT a chip hacker.  Limited knowledge on hacking.
- This is not the forum for AT91.  
- I use the ARM7 chips for simple control replacing 8-bit uC
- I do not disassemble LPC2xxx bootloader, never attempt to hack
  the LPC2xxx CRP in the past.  Do not even know how hack-able 
  is the LPC2xxx part I'm using.  AT91?? completely no idea.
- I take/accept Philips description of "no simple way to hack the
  LPC2xxx"
- We cannot even get the LPC2xxx CRP proven hack-able here. 
  So far everything are just "speculations"....=> I'm not too
   concerned about AT91's CRP at the moment
- If somebody here shows LPC2xxx CRP hack-able, may be I will
  consider switching to AT91
- Only thing=> I believe there will be more AT91 chip hackers in 
  the far east as Atmel microcontroller traditionally is stronger
  there.  =>More people/resources trying to hack the chip   :)

Sorry, could not answer your question...hope someone familiar
with AT91/AVR and who did some in depth study of LPC2xxx BootLoader, 
LPC2xxx CRP mechanisms/loopholes could answer your question... :)

(Please help to stick to main topic/issue else thread is getting
more and more diverted... )



> 
> At 01:52 PM 1/6/2006, you wrote:
> >Hi, I think you got my points all wrong...
> >
> >=> It should be if a company's microcontrollers is more popular
> >in X country. It will attract more hackers hacking their chips.
> >(Hee, Atmel microcontroller traditionally is very popular in
> >China/Taiwan. I do not know how long can the new AT91 CRP last...)
> >
> >It is definitely NOT "if chip is HACK-able, it will be more
> >popular/marketing edge..." :)
> >
> >(Hee...  I hope you are NOT Atmel re-seller...)
> >==========================================
> >
> >Anyway, those are beside the main topic.
> >=> Can somebody here please prove the Philips CRP are "HACK-able".
> >Before we start some discussion whether to switch to..atmel 
maybe...

> >
> >Regards
>

Sorry for the delay, my email stopped sending and receiving for a while and 
by the time it was repaired yours is one of the messages that got lost.

  jayasooriah wrote:
>--- In lpc2000@yahoogroups.com, "robertadsett" <subscriptions@a...>
> > Not all of them do, in fact ST pops immediately to mind
> > as one who has done a very similar thing.
>
>If you can tell me which device in particular, I would like to look
>into it when get bored. My previous experience was with ST10 and its
>errata sheet was nothing like that for 2105 in terms of the types of
>bugs in silicon.

It's actually the 10F series I was thinking of.  Particularly the 168 and 
the STEAK algorithm which was introduced after the 167 um.. 
experience.  The ISP download for that family invokes a hidden ROM monitor 
and with the introduction of steak that same monitor was used for the flash 
support with the algorithm's invoked by a peculiar instruction sequence.

ST appear to have attempted the same thing with there own ARM 
implementation but botched it and according the rep I was speaking to 'are 
not going to fix it'.  Basically serial ISP disappeared between manual 
rev's which means you have no choice but to hook up JTAG.  Certainly having 
the bootloader in flash rather than it what appears to have been masked ROM 
would have been a boon for ST.

> >I can understand your security concerns even if I don't share
> >them but your angst over them not exposing the flash programming
> >algorithm seems to be overdone.
>
>Off top of my head:
>
>1/ The entire on-chip flash can be destroyed by scribbling over the
>just one location in memory with some random value. [PLLs and WDs
>incorporate feed sequences, but this self destruct sequence has none.]

That would be a good thing to have I agree but I have certainly run into 
chips with much more destructive software failure modes.  Some power chips 
that allow both high side and low sides to come on simultaneously as a for 
instance.

>2/ The sector bit maps are all over the place. In the case of 2105
>its 16 sectors are mapped to the top and bottom 8 bits, leaving out 16
>bits in the middle. [The product appears to be in its infant stages
>of development in relation to maturity of design.]

I don't see how that's of much concern to the end user.  That presumably is 
also a good reason to hide the details behind an abstracted interface.

<snip>

>About 10% of LPC2105 parts with bootloader versions prior to 1.52 did
>fail in the field according to Philips. One wonders what happened in
>the field resulting in Philips stating this in the errata sheet.

 From my observations the problem was parts that failed to program (not 
ones that self destructed).  And unlike ST they were able to fix the 
problem  Both approaches have issues and more protection may well be 
advised for the Philips flash registers but it does strike me that the 
issue as far as the bootloader and IAP goes the issue it not the SW but the 
vulnerability of the flash registers

Robert



" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/