8-bit MicrocontrollersのトピックRe: FXTH87xx security backdoor key issue

FXTH87xx security backdoor key issue

seanwu — Thu, 08 Dec 2016 03:10:44 GMT

Dear Sir,

I want to use backdoor key to unsecure 87xx.

But I got an issue to run the code.

I added the code to unsecure device. But it will crash to write the compared backdoorkey.

FCNFG= FCNFG_KEYACC_MASK;
vfnFlashWrite(0xFFB0, (const UINT8*)au8BackDoorKey, N_ELEMENTS(au8BackDoorKey)); --> crash here
FCNFG= 0;

Please help me to check where the issue is. Attached is my code.

Thanks.

BR,

Sean

Original Attachment has been moved to: main.c.zip

Re: FXTH87xx security backdoor key issue

kef2 — Thu, 08 Dec 2016 10:52:01 GMT

Looks like you totally misunderstood how backdoor unsecure is supposed to work. Backdoor key in backdoor NV locations should be programmed simultaneously with flash programming. To backdoor unsecure you set KEYACC bit in FCNFG and then write to backdoor key locations as if it was RAM. Not vfnFlashWrite(), but

((const UINT8*)au8BackDoorKey)[0] = key0;

((const UINT8*)au8BackDoorKey)[1] = key1;

etc ...

Another problem is that flash code is not readable while KEYACC is set. So you need to jump to function in RAM, which will set KEYACC, write backdoor key locations, clear KEYACC and return to code in flash. Since flash is not readable while KEYACC is set, you also need to keep in mind that backdoor key values to compare can't stay as constants in flash, you need to copy them to RAM prior to setting KEYACC. As well, since flash is not readable while KEYACC is set, you need to make interrupts disabled while KEYACC is set.

Re: FXTH87xx security backdoor key issue

seanwu — Fri, 09 Dec 2016 00:58:56 GMT

Dear Sir,

Could you suggest how to modify my code(attached file) please?

vfnFlashWrite() will copy Pre-compiled flashing algo into RAM first: vfnFlashLoadAlgoInRam();

So this is not work in RAM?

Thanks.

BR,

Sean

Re: FXTH87xx security backdoor key issue

kef2 — Sat, 10 Dec 2016 15:02:33 GMT

It is boring and time consuming to create non portable, hard to modify arrays of precompiled codes while compiler is able to do it for you. It’s very easy to move any routine to RAM in CW. See attached example CW6.3 project. I don’t have CW10, but I think it shouldn’t be hard to port this to CW10.x.

Look at CODE_SEG pragmas in main.c around RAM routine
Define RAMCODESEG placement to RAM in PRM file
Add –NoSectCompat to linker command line

That’s it. With these 3 changes your routine in RAM should work, unless you disabled default ANSI startup routine, which is supposed to copy your RAM code from flash to RAM at startup.

Re: FXTH87xx security backdoor key issue

seanwu — Wed, 21 Dec 2016 09:10:43 GMT

Dear sir,

This is my code flow, please see the comment.

Set backdoor key and secure the device if the device is unsecured. And if device is secured, set KEYACC and write backdoor key to unsecure the device.

//If the device is not secured, I set backdoor key and KEYEN to 1, and then secure device.

if((FOPT&0x03)==0x02){
   FlashSectorBackup(0xFE00);

   vfnFlashErase(0xFFB0);

   au8BackDoorKey[0] = 0x70;
   au8BackDoorKey[1] = 0x61;
   au8BackDoorKey[2] = 0x52;
   au8BackDoorKey[3] = 0x43;
   au8BackDoorKey[4] = 0x34;
   au8BackDoorKey[5] = 0x25;
   au8BackDoorKey[6] = 0x16;
   au8BackDoorKey[7] = 0x07;

   vfnFlashWrite(0xFFB0, (const UINT8*)au8BackDoorKey, N_ELEMENTS(au8BackDoorKey));

   u8NewNVOPT = 0xC0;

   vfnFlashWrite(0xFFBF, (const UINT8*)&u8NewNVOPT, 1u);

   FlashSectorRestore(0xFE00);
}

else{

   //After reset, the device is secured, then unsecure the device by set KEYACC to 1 and write backbook key, then set KEYACC to 0.
   vfnCopyInRAM();
   vfnUnsecure();

FlashSectorBackup(0xFE00);

vfnFlashErase(0xFFBF);

//If unsecured is successful, then set NVOPT to 0x82 to make device be always unsecured.
   u8NewNVOPT=0x82;
   vfnFlashWrite(0xFFBF, (const UINT8*)&u8NewNVOPT, 1u);
   vfnFlashWrite(0xFFB0, (const UINT8*)au8BackDoorKey, N_ELEMENTS(au8BackDoorKey));

   FlashSectorRestore(0xFE00);
}

The code can secure the device successfully, but how I could implement the unsecured code in secured situation during debug mode ?

I followed your suggestion from the link like below, and make vfnUnsecure() routine to unsecure device.

https://community.nxp.com/message/653031?commentID=653031#comment-653031

This code is right? And it runs in RAM(vfnCopyInRAM)

#pragma CODE_SEG FLASH_ROUTINES
void vfnUnsecure(void)
{
   DisableInterrupts;
   FCNFG_KEYACC=1;
   *(byte*)0xFFB0 = 0x70;
   *(byte*)0xFFB1 = 0x61;
   *(byte*)0xFFB2 = 0x52;
   *(byte*)0xFFB3 = 0x43;
   *(byte*)0xFFB4 = 0x34;
   *(byte*)0xFFB5 = 0x25;
   *(byte*)0xFFB6 = 0x16;
   *(byte*)0xFFB7 = 0x07;
   FCNFG_KEYACC=0;
   EnableInterrupts;
   return;
}

#pragma CODE_SEG DEFAULT

void vfnCopyInRAM(void)
{
   unsigned int Size = (unsigned int)Size_Copy_In_RAM;
   unsigned char *SourcePtr;
   unsigned char *DestinationPtr;

   SourcePtr= (unsigned char*)Start_Copy_In_RAM;
   DestinationPtr = (unsigned char*)&vfnUnsecure;
   while (Size--)
   {
      *DestinationPtr = *SourcePtr;
      DestinationPtr++;
      SourcePtr++;
   }
}

Could you please spend some time to check the code, and teach me how to implement the code in debug mode?

Thanks.

BR,

Sean Wu

Re: FXTH87xx security backdoor key issue

kef2 — Wed, 21 Dec 2016 10:58:55 GMT

First of all, manipulating flash sector in which reset vectors reside, also manipulating bootloader code is the same like shooting into your own foot. Just think about loss of power or something which could suddenly reset your MCU! A big (perhaps tiny) cold brick.

If you are manipulating flash sector with NVSEC, then why do you bother to unsecure via backdoor unsecure mechanism??? Just change NVSEC to unsecured state and voila.

Backdoor unsecure mechanism allows you to keep flash untouched if you just need to do some BDM debugging. MCU is kept unsecured until reset or power cycle. Don’t know how in CW10, but in CW6.3 debugger you need to click Hotsync button instead of Connect button to connect to backdoor unsecured target. Clicking default Connect would reset your MCU back to secured mode.

I hope you knew already that you can’t initiate backdoor unsecure from debugger. It is not possible. Only code, which runs in your target can trigger backdoor unsecure routine. So you need to send some command via RS232 or something, or manipulate some pins to make your unsecure recognized by code running in your MCU.

I hope you understand backdoor unsecure a little better now.

vfnUnsecure() looks right. But I don’t understand purpose of your vfnCopyInRAM(). As I said previously, startup routine in startup.c should initialize vfnUnsecure() RAM locations with right codes, vfnCopyInRAM() has nothing to do.

Regards

Edward

Re: FXTH87xx security backdoor key issue

seanwu — Fri, 23 Dec 2016 01:16:00 GMT

Dear Sir,

Thanks for your feedback.

What we really want to do is to field upgrade a previously backdoor key protected S08 code to a new revision. Do re-flashing, and protect it again.

At beginning, in the first flashing, the backdoor key and security were set. Then the F/W is protected by backdoor key, and ship to users.
After we have new F/W revision, and hope to field upgrade the user device. (This procedure is under a secured environment).
We first do backdoor key un-protection through serial port as you mentioned. Then re-flash the Security state code to unsecured.
Flash is unsecured again, and we do F/W upgrading again just as step 1.
Now the user device F/W is newly upgraded and also secured again.

Just for easy debugging, we generate the testing code as presented to you before. It will do automatic protection in the first “if” part of code, and it worked. What we really want to try and got trouble is at the second “else” part – to do un-protection and re-flashing the SEC bits. They are not for the real case.

Just now, we have successfully made the test work. Thanks for your great help.

Thank you!

Re: FXTH87xx security backdoor key issue

kef2 — Fri, 23 Dec 2016 10:08:29 GMT

Backdoor unsecure has nothing to do and is not useful in any way for field upgrades! The only purpose of backdoor unsecure is to allow debugging without modifying any bit of flash.

To switch NVSEC to unsecured state you don’t need backdoor unsecure, just reflash NVSEC byte (whole sector).

Are thinking about backdoor unsecure to help you remove flash write protection? But backdoor unsecure doesn’t remove flash write protection! Once NVPROT is set to protect sector with NVPROT, to enable NVPROT write/erase protection you need BDM eraser/debugger, you can’t unprotect NVPROT from core in MCU.

Are you having problems reflashing over BDM while MCU is secured? Then again, it’s just a problem of your PC software. Perhaps you just need to change some PC SW settings or run appropriate unsecure tool on PC.

Regards,

Edward