68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC

When you implement the built-in security feature on the DP256B mask 1K79x
running Normal Single Chip mode, you cannot erase and write EEPROM and flash
on the device. (From Freescale ERRATA MUCts00603 and MUCts00604.)

We need to be able to reprogram the MCU while in the field.
In order to do this, our firmware update PC tool launches the Bootloader on
the MCU, unsecures the device using the Backdoor access and then program the
firmware.
However, during the reprogramming time, the MCU is unsecure and thus, one
could be able to copy the firmware and the EEPROM memory locations and dump
them on another MCU.

Has anyone encoutered this issue and how did you work-around it?

thanks for your help

Jean-Sebastien
[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

I has used the AN2720 to reprog my part in the feild. You have to put the b=
ootloader in the low part of mem (Non_Banked) and also make sure all func.s=
that it uses are also in the non banked section. Then you have to make sur=
e that when the part starts up that you check to make sure there is a valid=
app in the banked section. I did it by setting a eeprom location to 0 when=
I erase the flash then back to 1 when I reprog the part. I did that so tha=
t if there was not valid code in the banked section then I would lock it in=
the bootlaoder. Another thing to consider is to make sure that you prog ma=
in is always in the same location in the banked section, cause allt he boot=
lader will know is that it is going to jump to Loc_380000 (or where ever yo=
ur compiler linked it) and it is going to assume that valid code is there. =
I never had any issues with the security and I never unsecured my part duri=
ng the reprog either. On that app note it does not mention that you will ha=
ve to enable
Cosmic Language Compatabilty, which took me some time to figure out but on=
ce I did it worked fine. Let me know if you have any more questions. Tim
=20=09=09
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates=
starting at 1=A2/min.

[Non-text portions of this message have been removed]

=20

=20

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Tim,
=20
thanks for your input.
I don't have any issue with my Bootloader. This section works fine.=20
Like you just mentionned, it checks for a valid firmware present, and if
there is, it jumps to a fix location in memory.
=20
The link below to the Mask set ERRATA states that you cannot reprogram Flas=
h
and EEPROM when running Normal Single Chip mode with security enabled.
http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_1K=
7
9X.htm?srch=3D1
Before finding this ERRATA, I have tried to make it work and it didn't.
I have to say that I have the same Bootloader running on a MC9S12DP512 with
mask 4L00M and I am able to reprogram this MCU withouth unsecuring the
device first.
=20
cheers
=20
Jean-Sebastien

_____=20=20

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
Tim Milliken
Sent: August 4, 2006 10:41 AM
To: 6...@yahoogroups.com
Subject: Re: [68HC12] MC9S12DP256B security

I has used the AN2720 to reprog my part in the feild. You have to put the
bootloader in the low part of mem (Non_Banked) and also make sure all func.=
s
that it uses are also in the non banked section. Then you have to make sure
that when the part starts up that you check to make sure there is a valid
app in the banked section. I did it by setting a eeprom location to 0 when =
I
erase the flash then back to 1 when I reprog the part. I did that so that i=
f
there was not valid code in the banked section then I would lock it in the
bootlaoder. Another thing to consider is to make sure that you prog main is
always in the same location in the banked section, cause allt he bootlader
will know is that it is going to jump to Loc_380000 (or where ever your
compiler linked it) and it is going to assume that valid code is there. I
never had any issues with the security and I never unsecured my part during
the reprog either. On that app note it does not mention that you will have
to enable
Cosmic Language Compatabilty, which took me some time to figure out but onc=
e
I did it worked fine. Let me know if you have any more questions. Tim

---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
starting at 1=A2/min.

[Non-text portions of this message have been removed]

=20
[Non-text portions of this message have been removed]

=20

=20


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

That link was not good. I now have an idea what you are up against. Have yo=
u look at using the backdoor key to unlock (unsecure) the flash only while =
erasing or programing? If you are interested in keeping it secure I would o=
nly use it while in the bootloader and not unlock it unless there is some k=
ind of security algorythm in place to make sure that someone does not read =
out your code by letting it get almost all the way programed then pulling t=
he power to it before you have a chance to resecure it. If you have a direc=
t link or app note to the problem let me know what it is. I will help all I=
can. Tim
=20=09=09
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates=
starting at 1=A2/min.

[Non-text portions of this message have been removed]

=20

=20



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Tim,
=20
My bootloader does the security handling. The chip is secured as soon as th=
e
bootloader is programmed in.
The bootloader uses the backdoor security access to temporarily unlock the
MCU for Flash erasing and programming.
But when the bootloader unsecures the flash using the backdoor key, is it
possible to connect to the chip using a BDM tool?
If it is possible, then like you said, one could wait for the end of the
programming routine to then halt the programming and view the code and the
security bits.
=20
thanks
=20
js

_____=20=20

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
Tim Milliken
Sent: August 4, 2006 8:10 PM
To: 6...@yahoogroups.com
Subject: RE: [68HC12] MC9S12DP256B security

That link was not good. I now have an idea what you are up against. Have yo=
u
look at using the backdoor key to unlock (unsecure) the flash only while
erasing or programing? If you are interested in keeping it secure I would
only use it while in the bootloader and not unlock it unless there is some
kind of security algorythm in place to make sure that someone does not read
out your code by letting it get almost all the way programed then pulling
the power to it before you have a chance to resecure it. If you have a
direct link or app note to the problem let me know what it is. I will help
all I can. Tim

---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
starting at 1=A2/min.

[Non-text portions of this message have been removed]

=20
[Non-text portions of this message have been removed]

=20

=20
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Yes it would be possable to get into it through the BDM, try to reprog it w=
ithout using the backdoor key. It works for my hardware (9S12DJxxx). If it =
works for you then there should not be any securty issues as it will always=
be secured and there should not be anyway to read it out. That is with out=
maijor hardware mods and alot of detailed info on the micro (which is not =
public info). Let me know if that works. Tim
=20=09=09
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ coun=
tries) for 2=A2/min or less.

[Non-text portions of this message have been removed]

=20

=20


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Also do not allow any LARE(load ram and execute) to take place. That is a VERY BIG security risk. Cause one can write download code to basicly read the flash contents and spit it back out via the SCI or SPI port. Tim

---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.

[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Tim,
=20
what is the Mask set of the DJ256 with which your flash erase and reprogram
works withouth unsecuring the device?
=20
The link I pasted earlier that didnot work is the ERRATA for mask set 1k79x=
.
On the freescale website, type "ERRATA 1k79x" under the keyword search. The
first hit is the ERRATA for the MC9S12Dx256B mask set 1k79x device.=20
Errata MUCts00603 and MUCts00604 state my problem with the flash security
while reprogramming.
=20
BTW, thanks for the tip concerning LARE. This is a major issue. I have
revised my bootloader with a DoOnStack routine similar to what is suggested
in AN2270.
=20
thanks

_____=20=20

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
Tim Milliken
Sent: August 7, 2006 11:15 AM
To: 6...@yahoogroups.com
Subject: RE: [68HC12] MC9S12DP256B security

Yes it would be possable to get into it through the BDM, try to reprog it
without using the backdoor key. It works for my hardware (9S12DJxxx). If it
works for you then there should not be any securty issues as it will always
be secured and there should not be anyway to read it out. That is with out
maijor hardware mods and alot of detailed info on the micro (which is not
public info). Let me know if that works. Tim

---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
countries) for 2=A2/min or less.

[Non-text portions of this message have been removed]

=20
[Non-text portions of this message have been removed]

=20

=20


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

another suggestion would be to not use the old 1K79X mask set, but
some of the new ones that have the errata with Flash&EEPROM
programming under Secure state fixed.

jasa

--- In 6...@yahoogroups.com, "Jean-Sebastien Bouchard"
wrote:
>
> When you implement the built-in security feature on the DP256B mask
1K79x
> running Normal Single Chip mode, you cannot erase and write EEPROM
and flash
> on the device. (From Freescale ERRATA MUCts00603 and MUCts00604.)
>
> We need to be able to reprogram the MCU while in the field.
> In order to do this, our firmware update PC tool launches the
Bootloader on
> the MCU, unsecures the device using the Backdoor access and then
program the
> firmware.
> However, during the reprogramming time, the MCU is unsecure and
thus, one
> could be able to copy the firmware and the EEPROM memory locations
and dump
> them on another MCU.
>
> Has anyone encoutered this issue and how did you work-around it?
>
> thanks for your help
>
> Jean-Sebastien
> [Non-text portions of this message have been removed]
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "jasa.rm" wrote:
> another suggestion would be to not use the old 1K79X mask set, but
> some of the new ones that have the errata with Flash&EEPROM
> programming under Secure state fixed.
>
> jasa

But seriously, I would like to know how to actually *choose* the
maskset. When I ask distributors, they don't even tell me what I'm
getting without a choice.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

> --- In 6...@yahoogroups.com, "jasa.rm" wrote:
>> another suggestion would be to not use the old 1K79X mask set, but
>> some of the new ones that have the errata with Flash&EEPROM
>> programming under Secure state fixed.
>>
>> jasa
>
> But seriously, I would like to know how to actually *choose* the
> maskset. When I ask distributors, they don't even tell me what I'm
> getting without a choice.
>

Maybe stick to RoHS only parts? These can't be 1K79X, can they?



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Jean,
My susgestion is to 1) Use the backdoor key to place it in an unsecured state 2) have a "watchdog" type func that if (current tick count - last tick count) >= your preset value then jump to a flash secure func and resecure the flash and abort programing 3)use encryption/compression on the s rec that you download (there are many small/fast routines out there or write your own) 4)Incorprate and seed and key routine that will prevent unwanted unlocking of the part 5)Use a good Win32 encryption/compression (packer) program to protect your WIN32 app or make a special loader hardware that houses a intermeadite encryption. So the way it would work is that the Win32 app would have 1 encryption routine it would load it to the "special hardware" then that hardware would decrypt it and reencrypt it with either a new key or a whole new encyption and then load it over say the Can bus to the 9S12XDP256 and then it would have the makeshift watchdog the will provide the last bit of
securty. It might sound hard but it will be easy. If you need help with any of the above methods get me off list for some code, ect... later Tim

---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.

[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Tim Milliken wrote:

> My susgestion is to 1) Use the backdoor key to place it in an
> unsecured state 2)

where an intruder can read all the code with a simple BDM interface.

[...]

> securty. It might sound hard but it will be easy. If you need help

No, it's _not_ easy. It might sound easy but its very difficult to
make a _really_ secure loader. There are many pitfalls to avoid, and
one has to be extremly careful.

Jean-Sebastien: don't proceed with the wrong mask sets if you really
need security. Get the correct chips else it is not safe.

Let a person with good crypto knowledge check your bootloader and/or
tell/ask in sci.crypt about your implementation.

Maybe you find some hints for a safe bootloader in the discussions I
had in sci.crypt last year.

Oliver
--
Oliver Betz, Muenchen

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

So what you are telling me is that even without know the crypto that was used and with no way to get it that you can crack?? I don't think so. Part of my job is a crypto analyst, what is you job. So many people on the net are experts at everything till they have to go do it.... He ask my opinion on how to use that chip and get his job done. I gave it. If he does not want it then that is fine, as for you either add knowledge to the talk or please stay out. Tim

---------------------------------
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail Beta.

[Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Tim Milliken wrote:

> So what you are telling me is that even without know the crypto that
> was used and with no way to get it that you can crack??

that's the definition of "cracking" an encryption, isn't it? If one
"know the crypto", it's no more breaking ("crack") the encryption.

It's not enough to select the appropriate cipher. So many encryptions
have been compromised because the whole system was designed badly.

> I don't think so. Part of my job is a crypto analyst,

that's no proof that you have good knowledge about it.

> what is you job.

Although this doesn't matter (because it doesn't tell whether I do a
good job): industrial electronic design.

> So many people on the net are experts at everything till they have
> to go do it.... He ask my opinion on how to use that chip and get
> his job done. I gave it.

I pointed out that your advice was unsuitable and dangerous.

> If he does not want it then that is fine, as for you either
> add knowledge to the talk or please stay out. Tim

Hard to comment this politely => EOD for me.

Oliver
--
Oliver Betz, Muenchen

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

a) agree, you can not place order for certain specific mask-set

b) but you can still specifed the product number and the product
numbers are different across the mask-sets that are significantly
changed(bug fixes). It is not fully up-to-date but look at
file "MC9S12Dx256x_comparison.pdf" in Files section of this group.
Note that some of the old mask-sets has suffix B or C but the latest
ones do not have any suffix! So just find the appropriate comparing
to your needs.

c) do not use the wrong mask-sets if you need re-programming
capability and secure mode of operation...it is really not safe!

jasa

--- In 6...@yahoogroups.com, "Jefferson Smith"
wrote:
>
> --- In 6...@yahoogroups.com, "jasa.rm" wrote:
> > another suggestion would be to not use the old 1K79X mask set,
but
> > some of the new ones that have the errata with Flash&EEPROM
> > programming under Secure state fixed.
> >
> > jasa
>
> But seriously, I would like to know how to actually *choose* the
> maskset. When I ask distributors, they don't even tell me what I'm
> getting without a choice.
>



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

>From the datasheet:

BDM is available in all operating modes but must be enabled before
firmware commands are executed.

I think that if the firmware of the micro changes the status from secured to unsecured, at that point the BDM Interface is useless to dump the code.
I done the boot exaxtly like Tim Milliken wrote, and I was no able to connect to the target with the BDM Interface.
Tim Milliken wrote:
>
>> My susgestion is to 1) Use the backdoor key to place it in an
>> unsecured state 2)
>
>where an intruder can read all the code with a simple BDM interface.
>
>[...]
>
>> securty. It might sound hard but it will be easy. If you need help
>
>No, it's _not_ easy. It might sound easy but its very difficult to
>make a _really_ secure loader. There are many pitfalls to avoid, and
>one has to be extremly careful.
>
>Jean-Sebastien: don't proceed with the wrong mask sets if you really
>need security. Get the correct chips else it is not safe.
>
>Let a person with good crypto knowledge check your bootloader and/or
>tell/ask in sci.crypt about your implementation.
>
>Maybe you find some hints for a safe bootloader in the discussions I
>had in sci.crypt last year.
>
>Oliver
>--
>Oliver Betz, Muenchen



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

THANK YOU!!!!!!!!

---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.

[Non-text portions of this message have been removed]



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

m...@yahoo.it wrote:

> BDM is available in all operating modes but must be enabled before
> firmware commands are executed.

- You don't need firmware commands to read memory. Hardware commands
are sufficient.

- You can enable BDM firmware via hardware BDM commands.

> I think that if the firmware of the micro changes the status from
> secured to unsecured, at that point the BDM Interface is useless to
> dump the code.

The intention of the backdoor is temporarily unsecuring (think a
moment about the word) a device to allow authorized people debugging.

This wouldn't make much sense if one couldn't access S12 memory in
this state, would it?

> I done the boot exaxtly like Tim Milliken wrote, and I
> was no able to connect to the target with the BDM Interface.

Are you sure that you _really_ unsecured the device, from within
your application, executed from RAM, setting the KEYACC bit?

No word of the key was 0 or 0xffff?

The SEC bits were 1:0 after this procedure (checked by your app and
reported somehow?

Does your debugger actually support "hot attach"?

Could you "hot attach" at all to an unsecured device?

Maybe standard debugger software doesn't support this case very
conveniently, but you shouldn't think it's not possible at all.
That's rather dangerous designing "secure" applications.

Oliver
--
Oliver Betz, Muenchen



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

I have to admit that if a Backdoor exists, it is for debugging purposes,
thus BDM attachment on secure devices. But since the Flash security does not
work has it was initially specified, then maybe that the Backdoor unsecure
does not work as it is expected, i.e. it may allow flash access to the
resident program but the BDM is still unaccessible.
I am not able to connect to the MCU thorugh BDM when the chip is unsecured
thorugh the Backdoor. Maybe my settings are the problem. Does anyone have
suggestions that would proove Oliver's point?

I am using
BDM Tool - P&E BDM-multilink Parrallel port rev.B
Freescale Codewarrior 4.5

BTW, I can guarantee that my MCU is running unsecured because it is the
condition that I have to meet in order to write Flash or EEPROM.

Was anyone ever able to connect thourgh BDM to a secure HCS12Dx device with
MASK SET 1k79x which was unsecured with the Backdoor access key?

thanks

NOTE: Guys, please, this is an interresting discussion. Everyone's input is
what will help us build better and more secure products. This is exactly why
this forum exists! Please stop personnal attacks. All the inputs are
valuable and make the discussion most interresting.

js

_____

From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
Oliver Betz
Sent: August 9, 2006 10:06 AM
To: 6...@yahoogroups.com
Subject: Re: [68HC12] RE: MC9S12DP256B security

marcogalli80@ yahoo.it wrote:

> BDM is available in all operating modes but must be enabled before
> firmware commands are executed.

- You don't need firmware commands to read memory. Hardware commands
are sufficient.

- You can enable BDM firmware via hardware BDM commands.

> I think that if the firmware of the micro changes the status from
> secured to unsecured, at that point the BDM Interface is useless to
> dump the code.

The intention of the backdoor is temporarily unsecuring (think a
moment about the word) a device to allow authorized people debugging.

This wouldn't make much sense if one couldn't access S12 memory in
this state, would it?

> I done the boot exaxtly like Tim Milliken wrote, and I
> was no able to connect to the target with the BDM Interface.

Are you sure that you _really_ unsecured the device, from within
your application, executed from RAM, setting the KEYACC bit?

No word of the key was 0 or 0xffff?

The SEC bits were 1:0 after this procedure (checked by your app and
reported somehow?

Does your debugger actually support "hot attach"?

Could you "hot attach" at all to an unsecured device?

Maybe standard debugger software doesn't support this case very
conveniently, but you shouldn't think it's not possible at all.
That's rather dangerous designing "secure" applications.

Oliver
--
Oliver Betz, Muenchen

[Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Jean-Sebastien Bouchard wrote:

>I have to admit that if a Backdoor exists, it is for debugging purposes,
> thus BDM attachment on secure devices. But since the Flash security does
> not
> work has it was initially specified, then maybe that the Backdoor unsecure
> does not work as it is expected, i.e. it may allow flash access to the
> resident program but the BDM is still unaccessible.
> I am not able to connect to the MCU thorugh BDM when the chip is unsecured
> thorugh the Backdoor. Maybe my settings are the problem. Does anyone have
> suggestions that would proove Oliver's point?
>
> I am using
> BDM Tool - P&E BDM-multilink Parrallel port rev.B
> Freescale Codewarrior 4.5

I didn't met any 1k79x like parts. Maybe you are right that backdoor key
unsecured 1k79x doesn't allow BDM comms, but I think you just don't know how
to connect to parts without resetting them. Everyday debugging assumes
special singlechip mode. When you start your normal debug session your
multilink pulls BKGD pin low, pulls and releases /RESET (resets MCU and
security to flashed security level!), finally releases BKGD pin. So if you
unsecurred your part with backdoor and hit connect button (or start
hiwave) - part will be reset by multilink, security bits will be reset to
flash security bits, part's secured. And Olivers "hot attach" means Hivawe's
"At startup MCU is running (hot plug0" or something, check Hivawe ICD12
options. "Hot plug" is different setup, when you to target part isn't reset.
Instead of this debugger sends via multilink and BKGD line 2 or so commands,
first one maybe to enable BDM firmware and second to stop target.
Enable Hivawe Hotplug option and try to connect to backdoor key unsecured
target again. With Hotplug=off it is impossible to connect to backdoor
unsecured target having it's security bits flashed to security=on.
Edward

>
> BTW, I can guarantee that my MCU is running unsecured because it is the
> condition that I have to meet in order to write Flash or EEPROM.
>
> Was anyone ever able to connect thourgh BDM to a secure HCS12Dx device
> with
> MASK SET 1k79x which was unsecured with the Backdoor access key?
>
> thanks
>
> NOTE: Guys, please, this is an interresting discussion. Everyone's input
> is
> what will help us build better and more secure products. This is exactly
> why
> this forum exists! Please stop personnal attacks. All the inputs are
> valuable and make the discussion most interresting.
>
> js
> _____
>
> From: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] On Behalf Of
> Oliver Betz
> Sent: August 9, 2006 10:06 AM
> To: 6...@yahoogroups.com
> Subject: Re: [68HC12] RE: MC9S12DP256B security
>
> marcogalli80@ yahoo.it wrote:
>
>> BDM is available in all operating modes but must be enabled before
>> firmware commands are executed.
>
> - You don't need firmware commands to read memory. Hardware commands
> are sufficient.
>
> - You can enable BDM firmware via hardware BDM commands.
>
>> I think that if the firmware of the micro changes the status from
>> secured to unsecured, at that point the BDM Interface is useless to
>> dump the code.
>
> The intention of the backdoor is temporarily unsecuring (think a
> moment about the word) a device to allow authorized people debugging.
>
> This wouldn't make much sense if one couldn't access S12 memory in
> this state, would it?
>
>> I done the boot exaxtly like Tim Milliken wrote, and I
>> was no able to connect to the target with the BDM Interface.
>
> Are you sure that you _really_ unsecured the device, from within
> your application, executed from RAM, setting the KEYACC bit?
>
> No word of the key was 0 or 0xffff?
>
> The SEC bits were 1:0 after this procedure (checked by your app and
> reported somehow?
>
> Does your debugger actually support "hot attach"?
>
> Could you "hot attach" at all to an unsecured device?
>
> Maybe standard debugger software doesn't support this case very
> conveniently, but you shouldn't think it's not possible at all.
> That's rather dangerous designing "secure" applications.
>
> Oliver
> --
> Oliver Betz, Muenchen
> [Non-text portions of this message have been removed]
>



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Well guys, I am not claiming to be the best at any of this. I am self taught on everything I know, so I have not had any formal training on how someone thinks is the right way to do this stuff. What I do know is though I crack micro's on a regular basis and the one's that are secured are much harder to get into. No matter if it uses the backdoor key. How ever if it uses the load ram functions then I can/will get into it. As for using a different mask set that IMHO would be a better route to take, but if that is not and option then I think we are on the way to making it as secured as possable. Oliver if you have any ideas that I have not thought of please feel free to input the info. I think that the method that I gave to have 2nd cypher was a good idea. I do not think that there is anyone out there that can crack a crypto without knowing the cypher or by having access to the asm code from the unit that decrypts it. There are bruteforce apps out there that will make a poor
atempt to crack it but there are so many variations of each cypher that it would take even the sharpest cracker and the fastest pc a very long time to crack and then by the time you are finished you could have wrote the code yourself. My 2 cents.. Tim

---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.

[Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

>I have to admit that if a Backdoor exists, it is for debugging purposes,
>thus BDM attachment on secure devices....

After the device is unsecured with the backdoor you could unsecure the device permanently. So you can debug the same FW with the BDM, you have not to unsecure with the BDM the micro, you have not to lose your FW.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "jasa.rm" wrote:
>
> a) agree, you can not place order for certain specific mask-set
>
> b) but you can still specifed the product number and the product
> numbers are different across the mask-sets that are significantly
> changed(bug fixes).

FSL support tried to tell me at first that the DP256C was one maskset
and DP256B was another. The problem was I was holding a "C" with the
maskset they though was a "B". Later they informed me that I was
right, I really was holding in my hand a DP256C which did exist. So
there is at least one maskset with two different part numbers. They
explained that the letters changed when the Flash rewrite cycles
improved (nothing to do with the maskset). Hey, we can only go by what
the designer of the product tells us... right?

I guess they just decided some masksets were compatible enough, and
made no distinction in the part numbers.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

what exactly is written on your silicon package?

according to my knowledge the following should be valid:

DP256B = 1K79X mask-set
DP256C = 2K79X mask-set

jasa

--- In 6...@yahoogroups.com, "Jefferson Smith"
wrote:
>
> --- In 6...@yahoogroups.com, "jasa.rm" wrote:
> >
> > a) agree, you can not place order for certain specific mask-set
> >
> > b) but you can still specifed the product number and the product
> > numbers are different across the mask-sets that are significantly
> > changed(bug fixes).
>
> FSL support tried to tell me at first that the DP256C was one
maskset
> and DP256B was another. The problem was I was holding a "C" with the
> maskset they though was a "B". Later they informed me that I was
> right, I really was holding in my hand a DP256C which did exist. So
> there is at least one maskset with two different part numbers. They
> explained that the letters changed when the Flash rewrite cycles
> improved (nothing to do with the maskset). Hey, we can only go by
what
> the designer of the product tells us... right?
>
> I guess they just decided some masksets were compatible enough, and
> made no distinction in the part numbers.
>

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "jasa.rm" wrote:
>
> what exactly is written on your silicon package?
>
> according to my knowledge the following should be valid:
>
> DP256B = 1K79X mask-set
> DP256C = 2K79X mask-set

Are you saying that you don't believe FSL?

My chip is DP256C, 2K79X (of course you can believe that). Apparently
there is also DP256B, 2K79X.

I asked FSL support if this was the wrong errata sheet as given in web
pages:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC9S12DP256C

links to the erratta:

http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_2K79X.htm

Notice that says "MSE9S12DP256B_2K79X". When I finally got the guy to
see that it says "B" instead of "C" he thought something was wrong.
Later he verified that the B -> C was not related to the mask set
change, therefor the document is correct.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )