Unsecuring FLASH using backdoor keys - M5223X

[mjbcswitzerland]

Hi All

We have been using the security function to block access to internal program in FLASH - this stops any BDM access and thus also subsequent debugging and is perfect for the protection requirement.

It is possible for us to upload new encrypted code via the Internet (HTTP post) to the device - the CPU can delete and program the new code after decryption so there is generally no need to be able to access the FLASH at a later time.

If it is necessary to be able to debug on a board we can delete the complete code via EzPort, which opens up BDM access again, and then work normally.

What we are missing is the ability to unlock a board by entering the backdoor keys (eg. when EzPort is not an option). This is implemented on a web side in the device, allowing the (secret) 16 bytes backdoor keys to be entered and the idea is to temporarily unlock the FLASH (security is deactivated until next reset) and then clear the configuration FLASH in this state (write block 0x400 to 0x418  to zero).

Presently the last step is proving to be a difficulty. We have tried various interpretations of the guidelines to doing this in the users' manual but haven't been successful yet. What is sure is that the FLASH is secured and that the backdoor access is indeed enabled. Has any one achieved this?

Here are more details:

The security setting:
.long 0x11223344    // backdoor key set to 0x1122334455667788
.long 0x55667788
.long 0x00000000
.long 0x00000000
.long 0x00000000
.long 0x80004AC8  // security enabled with backdoor access allowed

This is a variant of the code being used to try to unlock this (the backdoor keys are passed as two long words):

Code:

extern int fnEnableBackdoor(unsigned long key[2]){    unsigned long *ulKeyLocation = (unsigned long *)0x400;    if (CFMSEC & SECSTAT) {                                              // device secured—        if (CFMSEC & KEYEN) {                                            // is backdoor key access enabled–            CFMMCR |= KEYACC;                                            // enable backdoor key access            *(unsigned long*)(BACKDOOR_FLASH + ulKeyLocation++)) = key[0]; // write backdoor access keys            *(unsigned long*)(BACKDOOR_FLASH + ulKeyLocation)) = key[1];            CFMMCR &= ~KEYACC;                                           // normal flash access            if (!(CFMSEC & SECSTAT)) {                                   // check whether the device could be unsecured                return 1;            }            else {                return 0;            }        }        else {            return 0;        }    }    return 1;}

 It is not absolutely clear whether the writes to the backdoor keys need to be via the backdoor or direct - we have tried all combinations. Some cause exceptions when tried, some don't, but no attempt has yet been successful in actually unsecuring a device.

Any ideas?

Regards

Mark Butcher

www.uTasker.com

[DavidS]

Hi Mark,

Enclosed is a CodeWarrior for ColdFire 7.0 project that runs on the M5213EVB.

If you don’t have or don’t want to install the free version, there are s19 and elf files in the ~ FlashSecurityCode\mcf5213\obj\mwerks\m5213evb folder.  I’ve tested using CF Flasher with S19 that it works.

Set your terminal window to 19200, 8, 1, no parity.

Instructions get printed with reset…and by typing “help”.

The simplest test is to secure the flash, try accessing via BDM (and you will not be able to), then unsecure the flash and try accessing via BDM (and you will be able to).

The command line steps to secure the flash:

CFM>  fsw 4ac8          //writing to the CFM security register indicating you want to secure the flash

CFM>  flash                 //copies the CFM security register to flash (actually erases the 1^st page of flash, copies vector table and CFM registers to flash

CFM>  rst                    //resets the MCU to have flash mode of operation take affect.

Try accessing MCU via BDM and you should fail

The command line steps to un-secure flash:

CFM>  fsw 0               //clear the CFM security register

CFM>  flash                 // copies the updated CFM security register to flash

CFM>  rst                    // resets the MCU to have flash mode of operation take affect.

Try accessing MCU via BDM and you should succeed

I’ll also post this reply to the WildRice ColdFire Forum.

Regards,

David

[mjbcswitzerland]

Hi David

I am using a similar technique (controlled via Ethernet) to do the same, which doesn't have any problems, however it is not the method which I am discussing.

Reprogramming the first sector to gain access is not the same as gaining temporary access by using the backdoor keys.

To test this, "fsw 80004ac8" needs to be set.
Also 2 x 4 byte secret keys need to be programmed to 0x400 and 0x404 (0x00000000 and 0xffffffff are not valid keys)

After the reset, the goal is not to reprogram the sector again - which gains permanent access - but to enter the secret keys to gain 'temporary' access. After the next reset the FLASH is then still secured.
The question is however whether there is any real advantage of being able to do this since connecting the BDM resets the chip and thus blocks access again - or is there a way around this...?

Regards

Mark

www.uTasker.com

[mjbcswitzerland]

Hi All

A short follow up to avoid a possible obvious suggestion:

I have also tried using the same FLASH write routine as used for generally writing new value to FLASH (configured the FLASH controller, uses FLASH commands and runs from SRAM)

...
            CFMMCR |= KEYACC;                                            // enable backdoor key access
            fnWriteLongWordFlash(ulKeyLocation++, key[0]));
            fnWriteLongWordFlash(ulKeyLocation, key[1]);
            CFMMCR &= ~KEYACC;                                           // normal flash access
...

and these didn't seem to help.

One strange effect occurs when
            CFMMCR |= KEYACC;
is used but the normal FLASH access is not returned. The program runs correctly (presumably instruction accesses as normal) but reading data from FLASH (presumably data accesses) returns the sequence 0xff 0x04 0xc8 0xff 0xff 0x04, 0xc8, 0xff 0xff ... repeated.
I wonder whether someone can explain that?

Regards

Mark

[kef]

Mark,

I don't know Coldfires well, but on S12/S12X parts setting KEYACC bit makes flash memory not readable. So you are right, code between your C 

|= KEYACC and &= ~KEYACC lines should run not from flash. Also you should make sure that you are reading your backdoor keys also not from flash. Are key[0], key[1]... consts in flash? If so then I believe it wan't work that way.

Regards

[mjbcswitzerland]

Hi Kef

The keys used for comparison are entered by the user - they are passed as variables and so are not read form the FLASH.

What I have seen is that the code between |= KEYACC and &= ~KEYACC can run from FLASH but data reads from FLASH return 'strange' values. In fact if the &= ~HEYACC is never restored, the code continues to operate normally as long as it doesn't read const data from FLASH.

I'm still hunting for new ideas as to what could help.

Regards

Mark

PS. I will try running the code from SRAM to be sure...

[J2MEJediMaster]

This thread has some info on programming via the backdoor, and for a ColdFire CPU. The thread also has a link to another thread with some source code.

---Tom

[mjbcswitzerland]

Hi Tom

The thread deals with writing to memory using the backdoor accesses and not backdoor keys.

After some more experimentation (and extra debug support) we have found some interesting new details.

1. Originally the FLASH configuration is set up as
0x11223344
0x55667788
0x00000000
0x00000000
0x00000000
0x80004ac8

2. Using the original code together with the method of writing via back door
            fnWriteLongWordFlash(ulKeyLocation++, key[0]);
            fnWriteLongWordFlash(ulKeyLocation, key[1]);
does in fact work!

What we find is that issuing the backdoor key sequence unsecures the device temporarily (until next reset).

However, if an incorrect back door key is tried, it actually overwrites the original.
If, for example, 11223340 is attempted, the FLASH content afterwards is:
0x11223340
0x55667788
0x00000000
0x00000000
0x00000000
0x80004ac8

The backdoor keys have been overwritten (?) and then the access code works with the new one after a reset. If the values 0x00000000 are attempted, they are no longer valid so unsecuring is no longer possible. Since we hadn't seen this before, the unsecure looked as if it was always failing, although it obvioulsy does work in a way.

As well as this unexpected behavious it also throws up a new question as to the use of the unsecure capabilitly. Since connecting a BDM to the board generates a reset, it simply secures itself again so still doesn't solve any problems.

Therefore we have tried simply issuing a mass erase (after password protection). This deletes all code, including the FLASH configurations and so leaves the board in a state with no traces of original program and with BDM capabilities. This is in fact a better level of security... but it would still be interesting to understand the backdoor key method and its possible limitations.

Regards

Mark