--- In 6..., "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.

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..., "Jefferson Smith"
wrote:
>
> --- In 6..., "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.
>

--- In 6..., "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.

>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.

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.

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... [mailto:6...] On Behalf Of
> Oliver Betz
> Sent: August 9, 2006 10:06 AM
> To: 6...
> 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
>
>

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... [mailto:6...] On Behalf Of
Oliver Betz
Sent: August 9, 2006 10:06 AM
To: 6...
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

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

THANK YOU!!!!!!!!

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

>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