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@lpc2..., "rtstofer" <rstofer@p...> wrote:
> I truly believe the questions have been asked and
that the answers
> are satisfactory.
Bootloader / CRP summary update
Started by ●January 5, 2006
Reply by ●January 6, 20062006-01-06
Reply by ●January 6, 20062006-01-06
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@lpc2..., "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@lpc2..., "rtstofer" <rstofer@p...> wrote:
> > I truly believe the questions have been asked and that the answers
> > are satisfactory.
>
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@lpc2..., "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@lpc2..., "rtstofer" <rstofer@p...> wrote:
> > I truly believe the questions have been asked and that the answers
> > are satisfactory.
>
Reply by ●January 6, 20062006-01-06
--- In lpc2000@lpc2..., "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
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
Reply by ●January 6, 20062006-01-06
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@lpc2..., "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@lpc2..., "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.
>
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@lpc2..., "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@lpc2..., "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.
>
Reply by ●January 6, 20062006-01-06
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@unit...> 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@lpc2..., "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@lpc2..., "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
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@unit...> 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@lpc2..., "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@lpc2..., "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
Reply by ●January 6, 20062006-01-06
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@lpc2..., 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@lpc2..., "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@lpc2..., "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
>
=> 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@lpc2..., 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@lpc2..., "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@lpc2..., "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
>
Reply by ●January 6, 20062006-01-06
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
Reply by ●January 6, 20062006-01-06
--- In lpc2000@lpc2..., "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.
> 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.
Reply by ●January 6, 20062006-01-06
--- In lpc2000@lpc2..., 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
>
> 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
>
Reply by ●January 10, 20062006-01-10
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@lpc2..., "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/
by the time it was repaired yours is one of the messages that got lost.
jayasooriah wrote:
>--- In lpc2000@lpc2..., "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/
