So here's another question concerning security while running a bootloader. If you have the processor in secure mode and you want to update the firmware, then you would send it a command (SCI/CAN etc) to use the back door key to unsecure the processor in order to write new firmware to flash. At this point, is the device not open to BDM activity? Or do you have to reset in order for the BDM to work in which case the security would kick in at reset? Am I missing something here? Thanks, Steve |
|
disabling security in bootloader
Started by ●July 6, 2004
Reply by ●July 6, 20042004-07-06
Steve, I believe that the MC9S12DT256 documentation on the Freescale / Motorola web site is the best source for how securing and un-securing should work. Note that many of the older mask sets of MC9S12DP256 parts do not operate as described for the newest parts. Things to note in the quote from the documentation below: It clearly states that the correct backdoor key sequence "unsecures" the MCU. I take this to mean that the program in flash could then enable BDM, even if the MCU is in Normal Single Chip mode. For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 MCUs have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all 1, a change from early MC9S12DP256 documnetation. Check the most recent specific documentation for your MCU.) From a recent copy of the flash documentation for the MC9S12DT256: 4.5.1 Unsecuring via the Backdoor Key Access The MCU may only be unsecured by using the Backdoor Key Access feature which requires knowledge of the contents of the Backdoor Keys (four 16-bit words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the KEYACC bit is set, a write to a Backdoor Key address in the Flash array triggers a comparison between the written data and the Backdoor Key data stored in the Flash array. If all four words of data are written to the correct addresses in the correct order and the data matches the Backdoor Keys stored in the Flash array, the MCU will be unsecured. The data must be written to the Backdoor Keys sequentially staring with $FF00-1 and ending with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit is set, reads of the Flash array will return invalid data. The user code stored in the Flash array must have a method of receiving the Backdoor Key from an external stimulus. This external stimulus would typically be through one of the on-chip serial ports. If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the ackdoor Access Sequence described below: 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 sequentially starting with $FF00. 3. Clear the KEYACC bit. 4. If all four 16-bit words match the Backdoor Keys stored in Flash addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the FSEC register are forced to the unsecure state of "10". The Backdoor Access Sequence is monitored by the internal Security State Machine. An illegal operation during the Backdoor Access Sequence will cause the Security State Machine to lock, leaving the MCU in the secured state. A reset of the MCU will cause the Security State Machine to exit the lock state and allow a new Backdoor Access Sequence to be attempted. The following illegal operations will lock the Security State Machine: 1. If any of the four 16-bit words does not match the backdoor keys programmed in the Flash array. 2. If the four 16-bit words are written in the wrong sequence. 3. If more than four 16-bit words are written. 4. If any of the four 16-bit words written are $0000 or $FFFF. 5. If the KEYACC bit does not remain set while the four 16-bit words are written. After the Backdoor Access Sequence has been correctly matched, the MCU will be unsecured. The Flash security byte can be programmed to the unsecure state, if desired. In the unsecure state, the user has full control of the contents of the four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the Flash Protection/Options Field. The security as defined in the Flash Security/Options byte ($FF0F) is not changed by using the Backdoor Access Sequence to unsecure. The Backdoor Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor Access Sequence. After the next reset sequence, the security state of the Flash module is determined by the Flash Security/Options byte ($FF0F). The Backdoor Access Sequence has no effect on the program and erase protections defined in the Flash Protection Register (FPROT). It is not possible to unsecure the MCU in Special Single Chip mode by the Backdoor Access Sequence via the Background Debug Mode. A further comment below. Hope this helps. Steve Russell Nohau Emulators At 07:04 PM 7/6/2004, Steve Letkeman wrote: >So here's another question concerning security while running a >bootloader. If you have the processor in secure mode and you >want to update the firmware, then you would send it a command >(SCI/CAN etc) to use the back door key to unsecure the processor >in order to write new firmware to flash. At this point, is the >device not open to BDM activity? Or do you have to reset in order >for the BDM to work in which case the security would kick in at reset? >Am I missing something here? Yes, but we all do. There are 1500+ pages of documentation for each HCS-12 part, and new updates come out periodically. The best of the documentation is like that quoted above: Correct but terse. The worst, such as the early documentation for flash security, is what you might expect from a confused writer >Thanks, >Steve >Yahoo! Groups Links > > ************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 ext. 1873 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* |
|
Reply by ●July 7, 20042004-07-07
Thanks for the response, I did read through the documentation that
you've quoted below and what I don't find to be clear is this: If I unsecure the MCU with the backdoor method in order to write to the flash memory, does the BDM automatically become active without my program specifically enabling it? The documentation does say that the BDM is active while in unsecure mode, right? Any comments welcome, Steve ----- Original Message ----- From: Steve Russell To: Sent: Tuesday, July 06, 2004 9:49 PM Subject: Re: [68HC12] disabling security in bootloader Steve, I believe that the MC9S12DT256 documentation on the Freescale / Motorola web site is the best source for how securing and un-securing should work. Note that many of the older mask sets of MC9S12DP256 parts do not operate as described for the newest parts. Things to note in the quote from the documentation below: It clearly states that the correct backdoor key sequence "unsecures" the MCU. I take this to mean that the program in flash could then enable BDM, even if the MCU is in Normal Single Chip mode. For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 MCUs have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all 1, a change from early MC9S12DP256 documnetation. Check the most recent specific documentation for your MCU.) From a recent copy of the flash documentation for the MC9S12DT256: 4.5.1 Unsecuring via the Backdoor Key Access The MCU may only be unsecured by using the Backdoor Key Access feature which requires knowledge of the contents of the Backdoor Keys (four 16-bit words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the KEYACC bit is set, a write to a Backdoor Key address in the Flash array triggers a comparison between the written data and the Backdoor Key data stored in the Flash array. If all four words of data are written to the correct addresses in the correct order and the data matches the Backdoor Keys stored in the Flash array, the MCU will be unsecured. The data must be written to the Backdoor Keys sequentially staring with $FF00-1 and ending with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit is set, reads of the Flash array will return invalid data. The user code stored in the Flash array must have a method of receiving the Backdoor Key from an external stimulus. This external stimulus would typically be through one of the on-chip serial ports. If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the ackdoor Access Sequence described below: 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 sequentially starting with $FF00. 3. Clear the KEYACC bit. 4. If all four 16-bit words match the Backdoor Keys stored in Flash addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the FSEC register are forced to the unsecure state of "10". The Backdoor Access Sequence is monitored by the internal Security State Machine. An illegal operation during the Backdoor Access Sequence will cause the Security State Machine to lock, leaving the MCU in the secured state. A reset of the MCU will cause the Security State Machine to exit the lock state and allow a new Backdoor Access Sequence to be attempted. The following illegal operations will lock the Security State Machine: 1. If any of the four 16-bit words does not match the backdoor keys programmed in the Flash array. 2. If the four 16-bit words are written in the wrong sequence. 3. If more than four 16-bit words are written. 4. If any of the four 16-bit words written are $0000 or $FFFF. 5. If the KEYACC bit does not remain set while the four 16-bit words are written. After the Backdoor Access Sequence has been correctly matched, the MCU will be unsecured. The Flash security byte can be programmed to the unsecure state, if desired. In the unsecure state, the user has full control of the contents of the four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the Flash Protection/Options Field. The security as defined in the Flash Security/Options byte ($FF0F) is not changed by using the Backdoor Access Sequence to unsecure. The Backdoor Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor Access Sequence. After the next reset sequence, the security state of the Flash module is determined by the Flash Security/Options byte ($FF0F). The Backdoor Access Sequence has no effect on the program and erase protections defined in the Flash Protection Register (FPROT). It is not possible to unsecure the MCU in Special Single Chip mode by the Backdoor Access Sequence via the Background Debug Mode. A further comment below. Hope this helps. Steve Russell Nohau Emulators At 07:04 PM 7/6/2004, Steve Letkeman wrote: >So here's another question concerning security while running a >bootloader. If you have the processor in secure mode and you >want to update the firmware, then you would send it a command >(SCI/CAN etc) to use the back door key to unsecure the processor >in order to write new firmware to flash. At this point, is the >device not open to BDM activity? Or do you have to reset in order >for the BDM to work in which case the security would kick in at reset? >Am I missing something here? Yes, but we all do. There are 1500+ pages of documentation for each HCS-12 part, and new updates come out periodically. The best of the documentation is like that quoted above: Correct but terse. The worst, such as the early documentation for flash security, is what you might expect from a confused writer >Thanks, >Steve >Yahoo! Groups Links > > ************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 ext. 1873 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* ------ Yahoo! Groups Links a.. To |
|
Reply by ●July 7, 20042004-07-07
Maybe I missed something at the beginning of this thread, but in my bootloader I don't have to unsecure the uP in order to update the flash. Only the startup and bootloader code is write-protected. Mike ----- Original Message ----- From: "Steve Letkeman" <> To: <> Sent: Wednesday, July 07, 2004 8:39 AM Subject: Re: [68HC12] disabling security in bootloader > Thanks for the response, I did read through the documentation that you've > quoted below and what I don't find to be clear is this: If I unsecure the > MCU with the backdoor method in order to write to the flash memory, > does the BDM automatically become active without my program > specifically enabling it? The documentation does say that the BDM > is active while in unsecure mode, right? > > Any comments welcome, > Steve > ----- Original Message ----- > From: Steve Russell > To: > Sent: Tuesday, July 06, 2004 9:49 PM > Subject: Re: [68HC12] disabling security in bootloader > Steve, > > I believe that the MC9S12DT256 documentation on the Freescale / Motorola > web site is the best source for how securing and un-securing should work. > >snip > |
|
Reply by ●July 7, 20042004-07-07
Steve, After re-reading the BDM documentation, I believe that the BDM is not active or enabled after you unsecure with the backdoor key. Reading between the lines, I think that you can set ENBDM in the BDMSTS register with a "hardware" BDM command after the part is unsecured. However, this is not explicitly stated, so experiment is indicated. Again note that the securing logic has evolved from none on the very first MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask sets. Just because things work one way on you trusty old development system, doesn't mean that they will work the same way on the latest production parts. "The manufacturer reserves the right to improve the specifications without notice." Steve Russell Nohau Emulators At 06:39 AM 7/7/2004, Steve Letkeman wrote: >Thanks for the response, I did read through the documentation that you've > quoted below and what I don't find to be clear is this: If I unsecure the > MCU with the backdoor method in order to write to the flash memory, > does the BDM automatically become active without my program >specifically enabling it? The documentation does say that the BDM > is active while in unsecure mode, right? > >Any comments welcome, >Steve > ----- Original Message ----- > From: Steve Russell > To: > Sent: Tuesday, July 06, 2004 9:49 PM > Subject: Re: [68HC12] disabling security in bootloader > Steve, > > I believe that the MC9S12DT256 documentation on the Freescale / Motorola > web site is the best source for how securing and un-securing should work. > > Note that many of the older mask sets of MC9S12DP256 parts do not operate > as described for the newest parts. > > Things to note in the quote from the documentation below: > > It clearly states that the correct backdoor key sequence "unsecures" > the MCU. > > I take this to mean that the program in flash could then enable BDM, even > if the MCU is in Normal Single Chip mode. > > For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 > MCUs > have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all > 1, a change from early MC9S12DP256 documnetation. Check the most recent > specific documentation for your MCU.) > > From a recent copy of the flash documentation for the MC9S12DT256: > > 4.5.1 Unsecuring via the Backdoor Key Access > > The MCU may only be unsecured by using the Backdoor Key Access feature > which requires knowledge of the contents of the Backdoor Keys (four 16-bit > words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the > KEYACC bit is set, a write to a Backdoor Key address in the Flash array > triggers a comparison between the written data and the Backdoor Key data > stored in the Flash array. If all four words of data are written to the > correct addresses in the correct order and the data matches the Backdoor > Keys stored in the Flash array, the MCU will be unsecured. The data > must be > written to the Backdoor Keys sequentially staring with $FF00-1 and ending > with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit > is set, reads of the Flash array will return invalid data. > > The user code stored in the Flash array must have a method of receiving > the > Backdoor Key from an external stimulus. This external stimulus would > typically be through one of the on-chip serial ports. > > If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the > ackdoor Access Sequence described below: > > 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). > > 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 > sequentially starting with > $FF00. > > 3. Clear the KEYACC bit. > > 4. If all four 16-bit words match the Backdoor Keys stored in Flash > addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the > FSEC > register are forced to the unsecure state of "10". > > The Backdoor Access Sequence is monitored by the internal Security State > Machine. An illegal operation during the Backdoor Access Sequence will > cause the Security State Machine to lock, leaving the MCU in the secured > state. A reset of the MCU will cause the Security State Machine to exit > the > lock state and allow a new Backdoor Access Sequence to be attempted. The > following illegal operations will lock the Security State Machine: > > 1. If any of the four 16-bit words does not match the backdoor keys > programmed in the Flash array. > > 2. If the four 16-bit words are written in the wrong sequence. > > 3. If more than four 16-bit words are written. > > 4. If any of the four 16-bit words written are $0000 or $FFFF. > > 5. If the KEYACC bit does not remain set while the four 16-bit words are > written. > > After the Backdoor Access Sequence has been correctly matched, the MCU > will > be unsecured. The Flash security byte can be programmed to the unsecure > state, if desired. > > In the unsecure state, the user has full control of the contents of the > four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the > Flash Protection/Options Field. > > The security as defined in the Flash Security/Options byte ($FF0F) is not > changed by using the Backdoor Access Sequence to unsecure. The Backdoor > Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor > Access Sequence. After the next reset sequence, the security state of the > Flash module is determined by the Flash Security/Options byte ($FF0F). The > Backdoor Access Sequence has no effect on the program and erase > protections > defined in the Flash Protection Register (FPROT). > > It is not possible to unsecure the MCU in Special Single Chip mode by the > Backdoor Access Sequence via the Background Debug Mode. > > A further comment below. > > Hope this helps. > > Steve Russell > Nohau Emulators > At 07:04 PM 7/6/2004, Steve Letkeman wrote: > >So here's another question concerning security while running a > >bootloader. If you have the processor in secure mode and you > >want to update the firmware, then you would send it a command > >(SCI/CAN etc) to use the back door key to unsecure the processor > >in order to write new firmware to flash. At this point, is the > >device not open to BDM activity? Or do you have to reset in order > >for the BDM to work in which case the security would kick in at reset? > >Am I missing something here? > > Yes, but we all do. > > There are 1500+ pages of documentation for each HCS-12 part, and new > updates come out periodically. The best of the documentation is like that > quoted above: Correct but terse. > > The worst, such as the early documentation for flash security, is what you > might expect from a confused writer > >Thanks, > >Steve > ************************************************************************* > Steve Russell mailto: > Senior Software Design Engineer http://www.nohau.com > Nohau Corporation phone: (408)866-1820 ext. 1873 > 51 East Campbell Avenue fax: (408)378-7869 > Campbell, CA 95008 > ************************************************************************* > |
Reply by ●July 7, 20042004-07-07
Mike, If the security bits in flash are un-secured, you won't have to worry about security. Most flash programmers set these bits to un-secured after a mass erase, so you would likely be un-secured unless you have taken some explicit steps to secure the part. If the part is secured, and of a recent mask set, BDM just plain won't work, except for "hardware" BDM commands accessing the registers. Even this access is specified to work only in special single-chip mode, but it might work in other modes. If you have one of the original MC9S12DP256 Mask Set 0K36N parts you will find no sign of functioning security. (You will also find a bunch of other remarkable features you probably don't want, see the errata.) What part and mask sets have you been using? Steve Russell Nohau Emulators At 11:16 AM 7/7/2004, Michael Huslig wrote: >Maybe I missed something at the beginning of this thread, but in my >bootloader I don't have to unsecure the uP in order to update the flash. >Only the startup and bootloader code is write-protected. > >Mike > >----- Original Message ----- >From: "Steve Letkeman" <> >To: <> >Sent: Wednesday, July 07, 2004 8:39 AM >Subject: Re: [68HC12] disabling security in bootloader > > Thanks for the response, I did read through the documentation that you've > > quoted below and what I don't find to be clear is this: If I unsecure >the > > MCU with the backdoor method in order to write to the flash memory, > > does the BDM automatically become active without my program > > specifically enabling it? The documentation does say that the BDM > > is active while in unsecure mode, right? > > > > Any comments welcome, > > Steve > > ----- Original Message ----- > > From: Steve Russell > > To: > > Sent: Tuesday, July 06, 2004 9:49 PM > > Subject: Re: [68HC12] disabling security in bootloader > > > > > > Steve, > > > > I believe that the MC9S12DT256 documentation on the Freescale / Motorola > > web site is the best source for how securing and un-securing should >work. > > > >snip > > ************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 ext. 1873 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* |
Reply by ●July 7, 20042004-07-07
I appreciate the help from this group, especially when a person is going in circles. I figured the best way to get this sorted out was to run some tests and then I ran into the problem of not being able to secure the C32. Kinda makes it hard to test the security features...If zeta_alph2002 says they can be secured I'll keep trying...I reduced my S19 file to S105FF0EFFFCF2 Also, I think Michael is correct in saying that the MCU doesn't have to be unsecured in order for the bootloader to write to flash, this was a mistake in my understanding of the security feature. Steve ----- Original Message ----- From: Steve Russell To: Sent: Wednesday, July 07, 2004 1:03 PM Subject: Re: [68HC12] disabling security in bootloader Steve, After re-reading the BDM documentation, I believe that the BDM is not active or enabled after you unsecure with the backdoor key. Reading between the lines, I think that you can set ENBDM in the BDMSTS register with a "hardware" BDM command after the part is unsecured. However, this is not explicitly stated, so experiment is indicated. Again note that the securing logic has evolved from none on the very first MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask sets. Just because things work one way on you trusty old development system, doesn't mean that they will work the same way on the latest production parts. "The manufacturer reserves the right to improve the specifications without notice." Steve Russell Nohau Emulators At 06:39 AM 7/7/2004, Steve Letkeman wrote: >Thanks for the response, I did read through the documentation that you've > quoted below and what I don't find to be clear is this: If I unsecure the > MCU with the backdoor method in order to write to the flash memory, > does the BDM automatically become active without my program >specifically enabling it? The documentation does say that the BDM > is active while in unsecure mode, right? > >Any comments welcome, >Steve > ----- Original Message ----- > From: Steve Russell > To: > Sent: Tuesday, July 06, 2004 9:49 PM > Subject: Re: [68HC12] disabling security in bootloader > Steve, > > I believe that the MC9S12DT256 documentation on the Freescale / Motorola > web site is the best source for how securing and un-securing should work. > > Note that many of the older mask sets of MC9S12DP256 parts do not operate > as described for the newest parts. > > Things to note in the quote from the documentation below: > > It clearly states that the correct backdoor key sequence "unsecures" > the MCU. > > I take this to mean that the program in flash could then enable BDM, even > if the MCU is in Normal Single Chip mode. > > For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 > MCUs > have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all > 1, a change from early MC9S12DP256 documnetation. Check the most recent > specific documentation for your MCU.) > > From a recent copy of the flash documentation for the MC9S12DT256: > > 4.5.1 Unsecuring via the Backdoor Key Access > > The MCU may only be unsecured by using the Backdoor Key Access feature > which requires knowledge of the contents of the Backdoor Keys (four 16-bit > words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the > KEYACC bit is set, a write to a Backdoor Key address in the Flash array > triggers a comparison between the written data and the Backdoor Key data > stored in the Flash array. If all four words of data are written to the > correct addresses in the correct order and the data matches the Backdoor > Keys stored in the Flash array, the MCU will be unsecured. The data > must be > written to the Backdoor Keys sequentially staring with $FF00-1 and ending > with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit > is set, reads of the Flash array will return invalid data. > > The user code stored in the Flash array must have a method of receiving > the > Backdoor Key from an external stimulus. This external stimulus would > typically be through one of the on-chip serial ports. > > If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the > ackdoor Access Sequence described below: > > 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). > > 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 > sequentially starting with > $FF00. > > 3. Clear the KEYACC bit. > > 4. If all four 16-bit words match the Backdoor Keys stored in Flash > addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the > FSEC > register are forced to the unsecure state of "10". > > The Backdoor Access Sequence is monitored by the internal Security State > Machine. An illegal operation during the Backdoor Access Sequence will > cause the Security State Machine to lock, leaving the MCU in the secured > state. A reset of the MCU will cause the Security State Machine to exit > the > lock state and allow a new Backdoor Access Sequence to be attempted. The > following illegal operations will lock the Security State Machine: > > 1. If any of the four 16-bit words does not match the backdoor keys > programmed in the Flash array. > > 2. If the four 16-bit words are written in the wrong sequence. > > 3. If more than four 16-bit words are written. > > 4. If any of the four 16-bit words written are $0000 or $FFFF. > > 5. If the KEYACC bit does not remain set while the four 16-bit words are > written. > > After the Backdoor Access Sequence has been correctly matched, the MCU > will > be unsecured. The Flash security byte can be programmed to the unsecure > state, if desired. > > In the unsecure state, the user has full control of the contents of the > four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the > Flash Protection/Options Field. > > The security as defined in the Flash Security/Options byte ($FF0F) is not > changed by using the Backdoor Access Sequence to unsecure. The Backdoor > Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor > Access Sequence. After the next reset sequence, the security state of the > Flash module is determined by the Flash Security/Options byte ($FF0F). The > Backdoor Access Sequence has no effect on the program and erase > protections > defined in the Flash Protection Register (FPROT). > > It is not possible to unsecure the MCU in Special Single Chip mode by the > Backdoor Access Sequence via the Background Debug Mode. > > A further comment below. > > Hope this helps. > > Steve Russell > Nohau Emulators > At 07:04 PM 7/6/2004, Steve Letkeman wrote: > >So here's another question concerning security while running a > >bootloader. If you have the processor in secure mode and you > >want to update the firmware, then you would send it a command > >(SCI/CAN etc) to use the back door key to unsecure the processor > >in order to write new firmware to flash. At this point, is the > >device not open to BDM activity? Or do you have to reset in order > >for the BDM to work in which case the security would kick in at reset? > >Am I missing something here? > > Yes, but we all do. > > There are 1500+ pages of documentation for each HCS-12 part, and new > updates come out periodically. The best of the documentation is like that > quoted above: Correct but terse. > > The worst, such as the early documentation for flash security, is what you > might expect from a confused writer > >Thanks, > >Steve > ************************************************************************* > Steve Russell mailto: > Senior Software Design Engineer http://www.nohau.com > Nohau Corporation phone: (408)866-1820 ext. 1873 > 51 East Campbell Avenue fax: (408)378-7869 > Campbell, CA 95008 > ************************************************************************* > ------ Yahoo! Groups Links a.. To |
|
Reply by ●July 7, 20042004-07-07
Well if you really want to secure the MCU include this sample to your code.. Be warn, you may have to remove and replace the MCU, but it will be secured ;-). org $FF00 dc.b $AA,$AA,$AA,$AA,$AA,$AA,$AA,$FF dc.b $FF,$FF,$FF,$FF,$FF,$7F,$FF,$00 The key to securing is Address $FF00 - $FF07, $FF0D, $FF0F --- In , "Steve Letkeman" <hc12list1@z...> wrote: > I appreciate the help from this group, especially when a person > is going in circles. I figured the best way to get this sorted out > was to run some tests and then I ran into the problem of not > being able to secure the C32. Kinda makes it hard to test > the security features...If zeta_alph2002 says they can be > secured I'll keep trying...I reduced my S19 file to > S105FF0EFFFCF2 > Also, I think Michael is correct in saying that the MCU > doesn't have to be unsecured in order for the bootloader > to write to flash, this was a mistake in my understanding > of the security feature. > > Steve > ----- Original Message ----- > From: Steve Russell > To: > Sent: Wednesday, July 07, 2004 1:03 PM > Subject: Re: [68HC12] disabling security in bootloader > Steve, > > After re-reading the BDM documentation, I believe that the BDM is not > active or enabled after you unsecure with the backdoor key. > > Reading between the lines, I think that you can set ENBDM in the BDMSTS > register with a "hardware" BDM command after the part is > unsecured. However, this is not explicitly stated, so experiment is indicated. > > Again note that the securing logic has evolved from none on the very first > MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask > sets. Just because things work one way on you trusty old development > system, doesn't mean that they will work the same way on the latest > production parts. > > "The manufacturer reserves the right to improve the specifications without > notice." > > Steve Russell > Nohau Emulators > > At 06:39 AM 7/7/2004, Steve Letkeman wrote: > >Thanks for the response, I did read through the documentation that you've > > quoted below and what I don't find to be clear is this: If I unsecure the > > MCU with the backdoor method in order to write to the flash memory, > > does the BDM automatically become active without my program > >specifically enabling it? The documentation does say that the BDM > > is active while in unsecure mode, right? > > > >Any comments welcome, > >Steve > > ----- Original Message ----- > > From: Steve Russell > > To: > > Sent: Tuesday, July 06, 2004 9:49 PM > > Subject: Re: [68HC12] disabling security in bootloader > > > > > > Steve, > > > > I believe that the MC9S12DT256 documentation on the Freescale / Motorola > > web site is the best source for how securing and un-securing should work. > > > > Note that many of the older mask sets of MC9S12DP256 parts do not operate > > as described for the newest parts. > > > > Things to note in the quote from the documentation below: > > > > It clearly states that the correct backdoor key sequence "unsecures" > > the MCU. > > > > I take this to mean that the program in flash could then enable BDM, even > > if the MCU is in Normal Single Chip mode. > > > > For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 > > MCUs > > have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all > > 1, a change from early MC9S12DP256 documnetation. Check the most recent > > specific documentation for your MCU.) > > > > From a recent copy of the flash documentation for the MC9S12DT256: > > > > 4.5.1 Unsecuring via the Backdoor Key Access > > > > The MCU may only be unsecured by using the Backdoor Key Access feature > > which requires knowledge of the contents of the Backdoor Keys (four 16-bit > > words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the > > KEYACC bit is set, a write to a Backdoor Key address in the Flash array > > triggers a comparison between the written data and the Backdoor Key data > > stored in the Flash array. If all four words of data are written to the > > correct addresses in the correct order and the data matches the Backdoor > > Keys stored in the Flash array, the MCU will be unsecured. The data > > must be > > written to the Backdoor Keys sequentially staring with $FF00- 1 and ending > > with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit > > is set, reads of the Flash array will return invalid data. > > > > The user code stored in the Flash array must have a method of receiving > > the > > Backdoor Key from an external stimulus. This external stimulus would > > typically be through one of the on-chip serial ports. > > > > If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the > > ackdoor Access Sequence described below: > > > > 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). > > > > 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 > > sequentially starting with > > $FF00. > > > > 3. Clear the KEYACC bit. > > > > 4. If all four 16-bit words match the Backdoor Keys stored in Flash > > addresses $FF00 - $FF07, the MCU is unsecured and bits SEC [1:0] in the > > FSEC > > register are forced to the unsecure state of "10". > > > > The Backdoor Access Sequence is monitored by the internal Security State > > Machine. An illegal operation during the Backdoor Access Sequence will > > cause the Security State Machine to lock, leaving the MCU in the secured > > state. A reset of the MCU will cause the Security State Machine to exit > > the > > lock state and allow a new Backdoor Access Sequence to be attempted. The > > following illegal operations will lock the Security State Machine: > > > > 1. If any of the four 16-bit words does not match the backdoor keys > > programmed in the Flash array. > > > > 2. If the four 16-bit words are written in the wrong sequence. > > > > 3. If more than four 16-bit words are written. > > > > 4. If any of the four 16-bit words written are $0000 or $FFFF. > > > > 5. If the KEYACC bit does not remain set while the four 16- bit words are > > written. > > > > After the Backdoor Access Sequence has been correctly matched, the MCU > > will > > be unsecured. The Flash security byte can be programmed to the unsecure > > state, if desired. > > > > In the unsecure state, the user has full control of the contents of the > > four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the > > Flash Protection/Options Field. > > > > The security as defined in the Flash Security/Options byte ($FF0F) is not > > changed by using the Backdoor Access Sequence to unsecure. The Backdoor > > Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor > > Access Sequence. After the next reset sequence, the security state of the > > Flash module is determined by the Flash Security/Options byte ($FF0F). The > > Backdoor Access Sequence has no effect on the program and erase > > protections > > defined in the Flash Protection Register (FPROT). > > > > It is not possible to unsecure the MCU in Special Single Chip mode by the > > Backdoor Access Sequence via the Background Debug Mode. > > > > A further comment below. > > > > Hope this helps. > > > > Steve Russell > > Nohau Emulators > > > > > > At 07:04 PM 7/6/2004, Steve Letkeman wrote: > > >So here's another question concerning security while running a > > >bootloader. If you have the processor in secure mode and you > > >want to update the firmware, then you would send it a command > > >(SCI/CAN etc) to use the back door key to unsecure the processor > > >in order to write new firmware to flash. At this point, is the > > >device not open to BDM activity? Or do you have to reset in order > > >for the BDM to work in which case the security would kick in at reset? > > >Am I missing something here? > > > > Yes, but we all do. > > > > There are 1500+ pages of documentation for each HCS-12 part, and new > > updates come out periodically. The best of the documentation is like that > > quoted above: Correct but terse. > > > > The worst, such as the early documentation for flash security, is what you > > might expect from a confused writer > > > > > > >Thanks, > > >Steve > > > > > > ********************************************************************** *** > > Steve Russell mailto:stever@n... > > Senior Software Design Engineer http://www.nohau.com > > Nohau Corporation phone: (408)866- 1820 ext. 1873 > > 51 East Campbell Avenue fax: (408)378-7869 > > Campbell, CA 95008 > > ********************************************************************** *** > > -------------------------------- ---------- > Yahoo! Groups Links > > a.. To > > |
Reply by ●July 7, 20042004-07-07
Steve, I've been spending a lot of time securing and unsecuring the 9S12E64 derivative and I've come across a few things. Your S-record example: S105FF0EFFFCF2 implies 0xFF0E = 0xFF, and 0xFF0F = 0xFC I've had better luck using 0xFF0F = 0x80. This allows backdoor key access and still secures the flash. Also, section 4.5.1 of the C32 flash document specifically states that "$0000 and $FFFF keys are not permitted.". I don't know if this means all 4 words cannot be 0x0000 or 0xFFFF or if this implies that NONE of the 4 backdoor key words can be either 0x0000 or 0xFFFF. To be on the safe side, I would set all 4 words (8 bytes) from 0xFF00 thru 0xFF07 to a value other than 0x0000 or 0xFFFF. We've also been working on a method to permit our factory programmer to unsecure the flash and perform code verification. Unfortunately, it is only possible to unsecure the flash from code running in user mode, i.e. BDM is not active. This puts a slight damper on things. In addition, the code which writes the backdoor keys CANNOT run from the flash itself and must run from RAM. The solution we've come up with is to implement a small routine which gets executed via the Startup_ function prior to RAM initialization and calling main(). This routine tests 8 bytes stored at a fixed RAM location against a checksum in the next two bytes. If the 2-byte checksum matches, the routine copies a small routine into RAM which will load the 8 bytes from the RAM location into the backdoor key registers thus unsecuring the flash. The unsecure procedure we use is as follows: 1. The BDM programmer enters special single chip mode and uses the hardware BDM command, WRITE_BD_WORD, to write the backdoor key bytes into the fixed RAM locations. This is permitted even if the flash is secured. 2. Trigger a reset using the RESET pin. This forces the user code to execute in normal single chip mode and unsecure the flash using the special routine. 3. The BDM programmer then enables the BDM by setting the ENBDM flag in the BDM Status Register using the hardware WRITE_BD_WORD command. 4. The BDM programmer activates the BDM using the hardware BACKGROUND command. At this point, the BDM in enabled and the flash is now unsecured. 5. The BDM programmer reads out the flash code to verify the programming. This is a pain, but it's the only method we've come up with for now. If anybody has a better idea, I'd love to hear it. Chris ------- Original Message ------- On Wed, 7 Jul 2004 14:08:18 -0600 Steve Letkeman wrote:I appreciate the help from this group, especially when a person is going in circles. I figured the best way to get this sorted out was to run some tests and then I ran into the problem of not being able to secure the C32. Kinda makes it hard to test the security features...If zeta_alph2002 says they can be secured I'll keep trying...I reduced my S19 file to S105FF0EFFFCF2 Also, I think Michael is correct in saying that the MCU doesn't have to be unsecured in order for the bootloader to write to flash, this was a mistake in my understanding of the security feature. Steve ----- Original Message ----- From: Steve Russell To: Sent: Wednesday, July 07, 2004 1:03 PM Subject: Re: [68HC12] disabling security in bootloader Steve, After re-reading the BDM documentation, I believe that the BDM is not active or enabled after you unsecure with the backdoor key. Reading between the lines, I think that you can set ENBDM in the BDMSTS register with a "hardware" BDM command after the part is unsecured. However, this is not explicitly stated, so experiment is indicated. Again note that the securing logic has evolved from none on the very first MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask sets. Just because things work one way on you trusty old development system, doesn't mean that they will work the same way on the latest production parts. "The manufacturer reserves the right to improve the specifications without notice." Steve Russell Nohau Emulators At 06:39 AM 7/7/2004, Steve Letkeman wrote: >Thanks for the response, I did read through the documentation that you've Thanks for the response, I did read through the documentation that you've > quoted below and what I don't find to be clear is this: If I unsecure the quoted below and what I don't find to be clear is this: If I unsecure the > MCU with the backdoor method in order to write to the flash memory, MCU with the backdoor method in order to write to the flash memory, > does the BDM automatically become active without my program does the BDM automatically become active without my program >specifically enabling it? The documentation does say that the BDM specifically enabling it? The documentation does say that the BDM > is active while in unsecure mode, right? is active while in unsecure mode, right? > >Any comments welcome, Any comments welcome, >Steve Steve > ----- Original Message ----- ----- Original Message ----- > From: Steve Russell From: Steve Russell > To: To: > Sent: Tuesday, July 06, 2004 9:49 PM Sent: Tuesday, July 06, 2004 9:49 PM > Subject: Re: [68HC12] disabling security in bootloader Subject: Re: [68HC12] disabling security in bootloader > > > Steve, Steve, > > I believe that the MC9S12DT256 documentation on the Freescale / Motorola I believe that the MC9S12DT256 documentation on the Freescale / Motorola > web site is the best source for how securing and un-securing should work. web site is the best source for how securing and un-securing should work. > > Note that many of the older mask sets of MC9S12DP256 parts do not operate Note that many of the older mask sets of MC9S12DP256 parts do not operate > as described for the newest parts. as described for the newest parts. > > Things to note in the quote from the documentation below: Things to note in the quote from the documentation below: > > It clearly states that the correct backdoor key sequence "unsecures" It clearly states that the correct backdoor key sequence "unsecures" > the MCU. the MCU. > > I take this to mean that the program in flash could then enable BDM, even I take this to mean that the program in flash could then enable BDM, even > if the MCU is in Normal Single Chip mode. if the MCU is in Normal Single Chip mode. > > For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 > MCUs MCUs > have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all > 1, a change from early MC9S12DP256 documnetation. Check the most recent 1, a change from early MC9S12DP256 documnetation. Check the most recent > specific documentation for your MCU.) specific documentation for your MCU.) > > From a recent copy of the flash documentation for the MC9S12DT256: From a recent copy of the flash documentation for the MC9S12DT256: > > 4.5.1 Unsecuring via the Backdoor Key Access 4.5.1 Unsecuring via the Backdoor Key Access > > The MCU may only be unsecured by using the Backdoor Key Access feature The MCU may only be unsecured by using the Backdoor Key Access feature > which requires knowledge of the contents of the Backdoor Keys (four 16-bit which requires knowledge of the contents of the Backdoor Keys (four 16-bit > words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the > KEYACC bit is set, a write to a Backdoor Key address in the Flash array KEYACC bit is set, a write to a Backdoor Key address in the Flash array > triggers a comparison between the written data and the Backdoor Key data triggers a comparison between the written data and the Backdoor Key data > stored in the Flash array. If all four words of data are written to the stored in the Flash array. If all four words of data are written to the > correct addresses in the correct order and the data matches the Backdoor correct addresses in the correct order and the data matches the Backdoor > Keys stored in the Flash array, the MCU will be unsecured. The data Keys stored in the Flash array, the MCU will be unsecured. The data > must be must be > written to the Backdoor Keys sequentially staring with $FF00-1 and ending written to the Backdoor Keys sequentially staring with $FF00-1 and ending > with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit > is set, reads of the Flash array will return invalid data. is set, reads of the Flash array will return invalid data. > > The user code stored in the Flash array must have a method of receiving The user code stored in the Flash array must have a method of receiving > the the > Backdoor Key from an external stimulus. This external stimulus would Backdoor Key from an external stimulus. This external stimulus would > typically be through one of the on-chip serial ports. typically be through one of the on-chip serial ports. > > If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the > ackdoor Access Sequence described below: ackdoor Access Sequence described below: > > 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). > > 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 > sequentially starting with sequentially starting with > $FF00. $FF00. > > 3. Clear the KEYACC bit. 3. Clear the KEYACC bit. > > 4. If all four 16-bit words match the Backdoor Keys stored in Flash 4. If all four 16-bit words match the Backdoor Keys stored in Flash > addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the > FSEC FSEC > register are forced to the unsecure state of "10". register are forced to the unsecure state of "10". > > The Backdoor Access Sequence is monitored by the internal Security State The Backdoor Access Sequence is monitored by the internal Security State > Machine. An illegal operation during the Backdoor Access Sequence will Machine. An illegal operation during the Backdoor Access Sequence will > cause the Security State Machine to lock, leaving the MCU in the secured cause the Security State Machine to lock, leaving the MCU in the secured > state. A reset of the MCU will cause the Security State Machine to exit state. A reset of the MCU will cause the Security State Machine to exit > the the > lock state and allow a new Backdoor Access Sequence to be attempted. The lock state and allow a new Backdoor Access Sequence to be attempted. The > following illegal operations will lock the Security State Machine: following illegal operations will lock the Security State Machine: > > 1. If any of the four 16-bit words does not match the backdoor keys 1. If any of the four 16-bit words does not match the backdoor keys > programmed in the Flash array. programmed in the Flash array. > > 2. If the four 16-bit words are written in the wrong sequence. 2. If the four 16-bit words are written in the wrong sequence. > > 3. If more than four 16-bit words are written. 3. If more than four 16-bit words are written. > > 4. If any of the four 16-bit words written are $0000 or $FFFF. 4. If any of the four 16-bit words written are $0000 or $FFFF. > > 5. If the KEYACC bit does not remain set while the four 16-bit words are 5. If the KEYACC bit does not remain set while the four 16-bit words are > written. written. > > After the Backdoor Access Sequence has been correctly matched, the MCU After the Backdoor Access Sequence has been correctly matched, the MCU > will will > be unsecured. The Flash security byte can be programmed to the unsecure be unsecured. The Flash security byte can be programmed to the unsecure > state, if desired. state, if desired. > > In the unsecure state, the user has full control of the contents of the In the unsecure state, the user has full control of the contents of the > four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the > Flash Protection/Options Field. Flash Protection/Options Field. > > The security as defined in the Flash Security/Options byte ($FF0F) is not The security as defined in the Flash Security/Options byte ($FF0F) is not > changed by using the Backdoor Access Sequence to unsecure. The Backdoor changed by using the Backdoor Access Sequence to unsecure. The Backdoor > Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor > Access Sequence. After the next reset sequence, the security state of the Access Sequence. After the next reset sequence, the security state of the > Flash module is determined by the Flash Security/Options byte ($FF0F). The Flash module is determined by the Flash Security/Options byte ($FF0F). The > Backdoor Access Sequence has no effect on the program and erase Backdoor Access Sequence has no effect on the program and erase > protections protections > defined in the Flash Protection Register (FPROT). defined in the Flash Protection Register (FPROT). > > It is not possible to unsecure the MCU in Special Single Chip mode by the It is not possible to unsecure the MCU in Special Single Chip mode by the > Backdoor Access Sequence via the Background Debug Mode. Backdoor Access Sequence via the Background Debug Mode. > > A further comment below. A further comment below. > > Hope this helps. Hope this helps. > > Steve Russell Steve Russell > Nohau Emulators Nohau Emulators > > > At 07:04 PM 7/6/2004, Steve Letkeman wrote: At 07:04 PM 7/6/2004, Steve Letkeman wrote: > >So here's another question concerning security while running a >So here's another question concerning security while running a So here's another question concerning security while running a > >bootloader. If you have the processor in secure mode and you >bootloader. If you have the processor in secure mode and you bootloader. If you have the processor in secure mode and you > >want to update the firmware, then you would send it a command >want to update the firmware, then you would send it a command want to update the firmware, then you would send it a command > >(SCI/CAN etc) to use the back door key to unsecure the processor >(SCI/CAN etc) to use the back door key to unsecure the processor (SCI/CAN etc) to use the back door key to unsecure the processor > >in order to write new firmware to flash. At this point, is the >in order to write new firmware to flash. At this point, is the in order to write new firmware to flash. At this point, is the > >device not open to BDM activity? Or do you have to reset in order >device not open to BDM activity? Or do you have to reset in order device not open to BDM activity? Or do you have to reset in order > >for the BDM to work in which case the security would kick in at reset? >for the BDM to work in which case the security would kick in at reset? for the BDM to work in which case the security would kick in at reset? > >Am I missing something here? >Am I missing something here? Am I missing something here? > > Yes, but we all do. Yes, but we all do. > > There are 1500+ pages of documentation for each HCS-12 part, and new There are 1500+ pages of documentation for each HCS-12 part, and new > updates come out periodically. The best of the documentation is like that updates come out periodically. The best of the documentation is like that > quoted above: Correct but terse. quoted above: Correct but terse. > > The worst, such as the early documentation for flash security, is what you The worst, such as the early documentation for flash security, is what you > might expect from a confused writer might expect from a confused writer > > > >Thanks, >Thanks, Thanks, > >Steve >Steve Steve > > > ************************************************************************* ************************************************************************* > Steve Russell mailto: Steve Russell mailto: > Senior Software Design Engineer Senior Software Design Engineer http://www.nohau.com > Nohau Corporation phone: (408)866-1820 ext. 1873 Nohau Corporation phone: (408)866-1820 ext. 1873 > 51 East Campbell Avenue fax: (408)378-7869 51 East Campbell Avenue fax: (408)378-7869 > Campbell, CA 95008 Campbell, CA 95008 > ************************************************************************* ************************************************************************* > ------ |
Reply by ●July 7, 20042004-07-07
Thanks for the comments and suggestion, Chris. I was using the same values as you suggested despite my simplified S-record. Here is what I know based on an afternoon of experimenting. The NoIce12 program with the ComPod12 interface refuses to program location 0xFF0F when downloading the proper S-record. The StarProg does the same. This same procedure does work on a DG128. How I eventually got this to work is by using the bootloader program itself. When it powers up it uses it's flash routines to write to 0xFF0F to enable security and then writes to 0xFF0D to enable write protection of the upper 4k to protect the monitor program from changes. (The backdoor key was set during download) When reset, everything is protected and secured. I can then use the bootloader program itself to download a user program without unsecuring the processor but my monitor program won't allow any reads from memory until the part is unsecured. If I want full access to read and write all memory, I send the backdoor key which loads a routine to ram to compare to the flash key and then opens everything up, whew... As far as the procedure you are using, why not allow your bootloader to unsecure memory (as you are doing) and then use the bootloader itself to verify the flash contents without even using the BDM? Thanks again for all the help, Steve ----- Original Message ----- From: Chris Knight To: Sent: Wednesday, July 07, 2004 4:16 PM Subject: RE: Re: [68HC12] disabling security in bootloader Steve, I've been spending a lot of time securing and unsecuring the 9S12E64 derivative and I've come across a few things. Your S-record example: S105FF0EFFFCF2 implies 0xFF0E = 0xFF, and 0xFF0F = 0xFC I've had better luck using 0xFF0F = 0x80. This allows backdoor key access and still secures the flash. Also, section 4.5.1 of the C32 flash document specifically states that "$0000 and $FFFF keys are not permitted.". I don't know if this means all 4 words cannot be 0x0000 or 0xFFFF or if this implies that NONE of the 4 backdoor key words can be either 0x0000 or 0xFFFF. To be on the safe side, I would set all 4 words (8 bytes) from 0xFF00 thru 0xFF07 to a value other than 0x0000 or 0xFFFF. We've also been working on a method to permit our factory programmer to unsecure the flash and perform code verification. Unfortunately, it is only possible to unsecure the flash from code running in user mode, i.e. BDM is not active. This puts a slight damper on things. In addition, the code which writes the backdoor keys CANNOT run from the flash itself and must run from RAM. The solution we've come up with is to implement a small routine which gets executed via the Startup_ function prior to RAM initialization and calling main(). This routine tests 8 bytes stored at a fixed RAM location against a checksum in the next two bytes. If the 2-byte checksum matches, the routine copies a small routine into RAM which will load the 8 bytes from the RAM location into the backdoor key registers thus unsecuring the flash. The unsecure procedure we use is as follows: 1. The BDM programmer enters special single chip mode and uses the hardware BDM command, WRITE_BD_WORD, to write the backdoor key bytes into the fixed RAM locations. This is permitted even if the flash is secured. 2. Trigger a reset using the RESET pin. This forces the user code to execute in normal single chip mode and unsecure the flash using the special routine. 3. The BDM programmer then enables the BDM by setting the ENBDM flag in the BDM Status Register using the hardware WRITE_BD_WORD command. 4. The BDM programmer activates the BDM using the hardware BACKGROUND command. At this point, the BDM in enabled and the flash is now unsecured. 5. The BDM programmer reads out the flash code to verify the programming. This is a pain, but it's the only method we've come up with for now. If anybody has a better idea, I'd love to hear it. Chris ------- Original Message ------- On Wed, 7 Jul 2004 14:08:18 -0600 Steve Letkeman wrote:I appreciate the help from this group, especially when a person is going in circles. I figured the best way to get this sorted out was to run some tests and then I ran into the problem of not being able to secure the C32. Kinda makes it hard to test the security features...If zeta_alph2002 says they can be secured I'll keep trying...I reduced my S19 file to S105FF0EFFFCF2 Also, I think Michael is correct in saying that the MCU doesn't have to be unsecured in order for the bootloader to write to flash, this was a mistake in my understanding of the security feature. Steve ----- Original Message ----- From: Steve Russell To: Sent: Wednesday, July 07, 2004 1:03 PM Subject: Re: [68HC12] disabling security in bootloader Steve, After re-reading the BDM documentation, I believe that the BDM is not active or enabled after you unsecure with the backdoor key. Reading between the lines, I think that you can set ENBDM in the BDMSTS register with a "hardware" BDM command after the part is unsecured. However, this is not explicitly stated, so experiment is indicated. Again note that the securing logic has evolved from none on the very first MC9S12DP256 mask set to pretty bullet-proof on the latest HCS-12 mask sets. Just because things work one way on you trusty old development system, doesn't mean that they will work the same way on the latest production parts. "The manufacturer reserves the right to improve the specifications without notice." Steve Russell Nohau Emulators At 06:39 AM 7/7/2004, Steve Letkeman wrote: >Thanks for the response, I did read through the documentation that you've Thanks for the response, I did read through the documentation that you've > quoted below and what I don't find to be clear is this: If I unsecure the quoted below and what I don't find to be clear is this: If I unsecure the > MCU with the backdoor method in order to write to the flash memory, MCU with the backdoor method in order to write to the flash memory, > does the BDM automatically become active without my program does the BDM automatically become active without my program >specifically enabling it? The documentation does say that the BDM specifically enabling it? The documentation does say that the BDM > is active while in unsecure mode, right? is active while in unsecure mode, right? > >Any comments welcome, Any comments welcome, >Steve Steve > ----- Original Message ----- ----- Original Message ----- > From: Steve Russell From: Steve Russell > To: To: > Sent: Tuesday, July 06, 2004 9:49 PM Sent: Tuesday, July 06, 2004 9:49 PM > Subject: Re: [68HC12] disabling security in bootloader Subject: Re: [68HC12] disabling security in bootloader > > > Steve, Steve, > > I believe that the MC9S12DT256 documentation on the Freescale / Motorola I believe that the MC9S12DT256 documentation on the Freescale / Motorola > web site is the best source for how securing and un-securing should work. web site is the best source for how securing and un-securing should work. > > Note that many of the older mask sets of MC9S12DP256 parts do not operate Note that many of the older mask sets of MC9S12DP256 parts do not operate > as described for the newest parts. as described for the newest parts. > > Things to note in the quote from the documentation below: Things to note in the quote from the documentation below: > > It clearly states that the correct backdoor key sequence "unsecures" It clearly states that the correct backdoor key sequence "unsecures" > the MCU. the MCU. > > I take this to mean that the program in flash could then enable BDM, even I take this to mean that the program in flash could then enable BDM, even > if the MCU is in Normal Single Chip mode. if the MCU is in Normal Single Chip mode. > > For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 For the MC9S12DT256 there are 2 bits in the KEYEN field. (Some HCS-12 > MCUs MCUs > have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all have only 1 bit for KEYEN. Also backdoor key words cannot be all 0 or all > 1, a change from early MC9S12DP256 documnetation. Check the most recent 1, a change from early MC9S12DP256 documnetation. Check the most recent > specific documentation for your MCU.) specific documentation for your MCU.) > > From a recent copy of the flash documentation for the MC9S12DT256: From a recent copy of the flash documentation for the MC9S12DT256: > > 4.5.1 Unsecuring via the Backdoor Key Access 4.5.1 Unsecuring via the Backdoor Key Access > > The MCU may only be unsecured by using the Backdoor Key Access feature The MCU may only be unsecured by using the Backdoor Key Access feature > which requires knowledge of the contents of the Backdoor Keys (four 16-bit which requires knowledge of the contents of the Backdoor Keys (four 16-bit > words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the words programmed at addresses $FF00 - $FF07). If KEYEN[1:0] and the > KEYACC bit is set, a write to a Backdoor Key address in the Flash array KEYACC bit is set, a write to a Backdoor Key address in the Flash array > triggers a comparison between the written data and the Backdoor Key data triggers a comparison between the written data and the Backdoor Key data > stored in the Flash array. If all four words of data are written to the stored in the Flash array. If all four words of data are written to the > correct addresses in the correct order and the data matches the Backdoor correct addresses in the correct order and the data matches the Backdoor > Keys stored in the Flash array, the MCU will be unsecured. The data Keys stored in the Flash array, the MCU will be unsecured. The data > must be must be > written to the Backdoor Keys sequentially staring with $FF00-1 and ending written to the Backdoor Keys sequentially staring with $FF00-1 and ending > with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit with $FF06-7. $0000 and $FFFF keys are not permitted. When the KEYACC bit > is set, reads of the Flash array will return invalid data. is set, reads of the Flash array will return invalid data. > > The user code stored in the Flash array must have a method of receiving The user code stored in the Flash array must have a method of receiving > the the > Backdoor Key from an external stimulus. This external stimulus would Backdoor Key from an external stimulus. This external stimulus would > typically be through one of the on-chip serial ports. typically be through one of the on-chip serial ports. > > If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the If KEYEN[1:0] in the FSEC register, the MCU can be unsecured by the > ackdoor Access Sequence described below: ackdoor Access Sequence described below: > > 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). 1. Set the KEYACC bit in the Flash Configuration Register (FCNFG). > > 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 2. Write the correct four 16-bit words to Flash addresses $FF00 - $FF07 > sequentially starting with sequentially starting with > $FF00. $FF00. > > 3. Clear the KEYACC bit. 3. Clear the KEYACC bit. > > 4. If all four 16-bit words match the Backdoor Keys stored in Flash 4. If all four 16-bit words match the Backdoor Keys stored in Flash > addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the addresses $FF00 - $FF07, the MCU is unsecured and bits SEC[1:0] in the > FSEC FSEC > register are forced to the unsecure state of "10". register are forced to the unsecure state of "10". > > The Backdoor Access Sequence is monitored by the internal Security State The Backdoor Access Sequence is monitored by the internal Security State > Machine. An illegal operation during the Backdoor Access Sequence will Machine. An illegal operation during the Backdoor Access Sequence will > cause the Security State Machine to lock, leaving the MCU in the secured cause the Security State Machine to lock, leaving the MCU in the secured > state. A reset of the MCU will cause the Security State Machine to exit state. A reset of the MCU will cause the Security State Machine to exit > the the > lock state and allow a new Backdoor Access Sequence to be attempted. The lock state and allow a new Backdoor Access Sequence to be attempted. The > following illegal operations will lock the Security State Machine: following illegal operations will lock the Security State Machine: > > 1. If any of the four 16-bit words does not match the backdoor keys 1. If any of the four 16-bit words does not match the backdoor keys > programmed in the Flash array. programmed in the Flash array. > > 2. If the four 16-bit words are written in the wrong sequence. 2. If the four 16-bit words are written in the wrong sequence. > > 3. If more than four 16-bit words are written. 3. If more than four 16-bit words are written. > > 4. If any of the four 16-bit words written are $0000 or $FFFF. 4. If any of the four 16-bit words written are $0000 or $FFFF. > > 5. If the KEYACC bit does not remain set while the four 16-bit words are 5. If the KEYACC bit does not remain set while the four 16-bit words are > written. written. > > After the Backdoor Access Sequence has been correctly matched, the MCU After the Backdoor Access Sequence has been correctly matched, the MCU > will will > be unsecured. The Flash security byte can be programmed to the unsecure be unsecured. The Flash security byte can be programmed to the unsecure > state, if desired. state, if desired. > > In the unsecure state, the user has full control of the contents of the In the unsecure state, the user has full control of the contents of the > four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the four word Backdoor Key by programming it in bytes $FF00 - $FF07 of the > Flash Protection/Options Field. Flash Protection/Options Field. > > The security as defined in the Flash Security/Options byte ($FF0F) is not The security as defined in the Flash Security/Options byte ($FF0F) is not > changed by using the Backdoor Access Sequence to unsecure. The Backdoor changed by using the Backdoor Access Sequence to unsecure. The Backdoor > Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor Keys stored in addresses $FF00 - $FF07 are unaffected by the Backdoor > Access Sequence. After the next reset sequence, the security state of the Access Sequence. After the next reset sequence, the security state of the > Flash module is determined by the Flash Security/Options byte ($FF0F). The Flash module is determined by the Flash Security/Options byte ($FF0F). The > Backdoor Access Sequence has no effect on the program and erase Backdoor Access Sequence has no effect on the program and erase > protections protections > defined in the Flash Protection Register (FPROT). defined in the Flash Protection Register (FPROT). > > It is not possible to unsecure the MCU in Special Single Chip mode by the It is not possible to unsecure the MCU in Special Single Chip mode by the > Backdoor Access Sequence via the Background Debug Mode. Backdoor Access Sequence via the Background Debug Mode. > > A further comment below. A further comment below. > > Hope this helps. Hope this helps. > > Steve Russell Steve Russell > Nohau Emulators Nohau Emulators > > > At 07:04 PM 7/6/2004, Steve Letkeman wrote: At 07:04 PM 7/6/2004, Steve Letkeman wrote: > >So here's another question concerning security while running a >So here's another question concerning security while running a So here's another question concerning security while running a > >bootloader. If you have the processor in secure mode and you >bootloader. If you have the processor in secure mode and you bootloader. If you have the processor in secure mode and you > >want to update the firmware, then you would send it a command >want to update the firmware, then you would send it a command want to update the firmware, then you would send it a command > >(SCI/CAN etc) to use the back door key to unsecure the processor >(SCI/CAN etc) to use the back door key to unsecure the processor (SCI/CAN etc) to use the back door key to unsecure the processor > >in order to write new firmware to flash. At this point, is the >in order to write new firmware to flash. At this point, is the in order to write new firmware to flash. At this point, is the > >device not open to BDM activity? Or do you have to reset in order >device not open to BDM activity? Or do you have to reset in order device not open to BDM activity? Or do you have to reset in order > >for the BDM to work in which case the security would kick in at reset? >for the BDM to work in which case the security would kick in at reset? for the BDM to work in which case the security would kick in at reset? > >Am I missing something here? >Am I missing something here? Am I missing something here? > > Yes, but we all do. Yes, but we all do. > > There are 1500+ pages of documentation for each HCS-12 part, and new There are 1500+ pages of documentation for each HCS-12 part, and new > updates come out periodically. The best of the documentation is like that updates come out periodically. The best of the documentation is like that > quoted above: Correct but terse. quoted above: Correct but terse. > > The worst, such as the early documentation for flash security, is what you The worst, such as the early documentation for flash security, is what you > might expect from a confused writer might expect from a confused writer > > > >Thanks, >Thanks, Thanks, > >Steve >Steve Steve > > > ************************************************************************* ************************************************************************* > Steve Russell mailto: Steve Russell mailto: > Senior Software Design Engineer Senior Software Design Engineer http://www.nohau.com > Nohau Corporation phone: (408)866-1820 ext. 1873 Nohau Corporation phone: (408)866-1820 ext. 1873 > 51 East Campbell Avenue fax: (408)378-7869 51 East Campbell Avenue fax: (408)378-7869 > Campbell, CA 95008 Campbell, CA 95008 > ************************************************************************* ************************************************************************* > ------ ------ Yahoo! Groups Links a.. To |
|