HC908JB16 security problem

[Inliner]

Hello! I want to protect my ICP based project in flash from unauthorizing reading. As i read from datasheets, simply security bytes is not good protection... Can level of protection can be increased? I want to defend my firmware from common backdoor methods. Any solutions for this? Thanks!

[Ake]

Hi,

The security bytes in the HC908 is an 8 byte string that ïs from $fff6 - $fffd.

This is actually a piece of the interrupt vector table. In the HC908JB16 it is Timer 1 Ch0, IRQ, USB and SWI vectors, so it consists of the vectors to those 4 interrupts.

The Monitor ROM program, first accepts 8 bytes of code which it internally will check that these are the same as in the Security table. There is no feedback if the code was correct or not, but if you check that bit 6 in RAM 0x80 is set, then the correct Security bytes have been entered.

8 bytes, that is 2^8^8 = 256^8 = 1.8 * 10^19 which is a quite large number.

As it takes 2 * 8 * (1+8+2)/9600 = 16.6 mS just to enter the security , it would take 3 * 10^17 s = 5 * 10^15 m = 8.3 * 10^13 hours = 3.47 * 10^12 days = 9512 million years before all the combinations have been tested.

To make it extra tricky to try to get the code, read/write out of RAM can be taken away by writing 0x7b into 0xffd1.

But if someone has a lot of lab equipment, he could take your MCU, crack the IC and microprobe each cell. First he must find out in which order they are positioned, he must internally disconnect the CPU from driving the address bus and the control signals.

At last he can sit down an microprobe each cell. 8 cells for a byte.

So why do we say that "No security feature is absolutely secure....."?

That is just what it says. There is no way to produce an absolutely secure Flash EPROM protection.

But if you are not interested in security bytes?

The security bytes are always enabled. In a newly erased part all the cells are 0xff, so the security bytes are all 0xff.

Then you program your MCU, perhaps with a vector for the IRQ.

Then you run the part in the development tool. It seems to have cracked the security right away.

But it hasn't. It only remembers the security bytes for the 10 last MCUs that you have programmed and will try them.

There is one way to get past the security bytes. That is to erase the part. The erase command is the only command that can always be used.

I hope I cleared the security matter a bit.

Regards,

Ake

[bigmac]

Hello,

Ake wrote:

To make it extra tricky to try to get the code, read/write out of RAM can be taken away by writing 0x7b into 0xffd1.

Actually this "extended security" might be applicable only to a limited number of MCU types - I had not previously noticed it for any other 908 types.  But then this data is well "buried" within the data sheet.

According to the 908JB16 data sheet (section 9.5.1), a word value at 0xFFD0 needs to be written with the value 0x877B to enable extended security mode, permitting only a mass erase.  However, the associated table seems very ambiguous and unclear.

Within the memory map data, the location 0xFFD0 is implied as an unused vector location, and there seems to be no mention of an "extended security" register.

Regards,

Mac

[Inliner]

Thanks for the replies, i entereed in monitor mode and written to RAM my own procedure to read bytes from secure locations. In normal monitor mode (with correct enteres security key), my procedure can successfully read the bytes from any location, from 0xFFF6-0xFFFD too. In monitor mode with bypassing key, i can load and execute my proc in RAM too, but some bytes is not accessile. I tried to run LDx commands, but in result i have only bytes i passed with the parameters for LDx. Is there any docs datasheet with detailed information how works the security in low level? WBR, Inliner

[peg]

Hi,

Judging by the amount of enquiries about this here, there seems to be no "crack" for the security that is widely known (or even known at all).

The reason for the warning about just how secure it may be is obviously put there by the legal department rather than for any technical reason.

On your other query, the security has to be passed via a monitor connection from outside the device. Sure, you could erase the security locations from inside (along with everything else) and then you would know how to get in but your code would be gone too. Refer to app. note AN-HK-32 for more info on this subject.