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
MC9S12DP256B security
Started by ●August 4, 2006
Reply by ●August 4, 20062006-08-04
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 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 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 once 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/min.
Cosmic Language Compatabilty, which took me some time to figure out but once 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/min.
Reply by ●August 4, 20062006-08-04
Tim,
thanks for your input.
I don't have any issue with my Bootloader. This section works fine.
Like you just mentionned, it checks for a valid firmware present, and if
there is, it jumps to a fix location in memory.
The link below to the Mask set ERRATA states that you cannot reprogram Flash
and EEPROM when running Normal Single Chip mode with security enabled.
http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_1K7
9X.htm?srch=1
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.
cheers
Jean-Sebastien
_____
From: 6... [mailto:6...] On Behalf Of
Tim Milliken
Sent: August 4, 2006 10:41 AM
To: 6...
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 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 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 once
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/min.
thanks for your input.
I don't have any issue with my Bootloader. This section works fine.
Like you just mentionned, it checks for a valid firmware present, and if
there is, it jumps to a fix location in memory.
The link below to the Mask set ERRATA states that you cannot reprogram Flash
and EEPROM when running Normal Single Chip mode with security enabled.
http://www.freescale.com/files/microcontrollers/doc/errata/MSE9S12DP256B_1K7
9X.htm?srch=1
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.
cheers
Jean-Sebastien
_____
From: 6... [mailto:6...] On Behalf Of
Tim Milliken
Sent: August 4, 2006 10:41 AM
To: 6...
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 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 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 once
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/min.
Reply by ●August 4, 20062006-08-04
That link was not good. I now have an idea what you are up against. Have you
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/min.
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1/min.
Reply by ●August 7, 20062006-08-07
Tim,
My bootloader does the security handling. The chip is secured as soon as the
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.
thanks
js
_____
From: 6... [mailto:6...] On Behalf Of
Tim Milliken
Sent: August 4, 2006 8:10 PM
To: 6...
Subject: RE: [68HC12] MC9S12DP256B security
That link was not good. I now have an idea what you are up against. Have you
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/min.
My bootloader does the security handling. The chip is secured as soon as the
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.
thanks
js
_____
From: 6... [mailto:6...] On Behalf Of
Tim Milliken
Sent: August 4, 2006 8:10 PM
To: 6...
Subject: RE: [68HC12] MC9S12DP256B security
That link was not good. I now have an idea what you are up against. Have you
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/min.
Reply by ●August 7, 20062006-08-07
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/min or less.
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2/min or less.
Reply by ●August 7, 20062006-08-07
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.
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
Reply by ●August 7, 20062006-08-07
Tim,
what is the Mask set of the DJ256 with which your flash erase and reprogram
works withouth unsecuring the device?
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.
Errata MUCts00603 and MUCts00604 state my problem with the flash security
while reprogramming.
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.
thanks
_____
From: 6... [mailto:6...] On Behalf Of
Tim Milliken
Sent: August 7, 2006 11:15 AM
To: 6...
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/min or less.
what is the Mask set of the DJ256 with which your flash erase and reprogram
works withouth unsecuring the device?
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.
Errata MUCts00603 and MUCts00604 state my problem with the flash security
while reprogramming.
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.
thanks
_____
From: 6... [mailto:6...] On Behalf Of
Tim Milliken
Sent: August 7, 2006 11:15 AM
To: 6...
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/min or less.
Reply by ●August 8, 20062006-08-08
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..., "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
>
>
some of the new ones that have the errata with Flash&EEPROM
programming under Secure state fixed.
jasa
--- In 6..., "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
>
>
Reply by ●August 8, 20062006-08-08
--- In 6..., "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.
> 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.
