M16C Security

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I want to add security to an M16C project. The manual in Figure 1.30.2
shows the 7 security bytes ID1 thru ID7 on the left-hand side, or what
I would call the lower address side of the four bytes, whereas the text
defines the addresses as the high side. The two options in the
sect30.inc file would be either:

                        .section         vectors,ROMDATA
                        .org               0fffdch
UDI:                  .addr             dummy_int
                        .byte             01h                        ;
security byte ID1
OVER_FLOW:  .addr  etc...

                        .section         vectors,ROMDATA
                        .org               0fffdch
UDI:                  .byte             01h                        ;
security byte ID1
                        .addr             dummy_int
OVER_FLOW:  .byte  etc...

Does anyone have experience with the correct method?

Re: M16C Security
Quoted text here. Click to load it

The Datasheet clearly states:

<------- beginn quote -------->
The ID code consists of 8-bit data,the areas of which,beginning with
the first byte,are:

0FFFDF16,0FFFE316,0FFFEB16,0FFFEF16,0FFFF316,0FFFF716,and 0FFFFB16.
<------- end quote -------->

An excerpt of my ".mot" file follows to hopefully further clear the
situation for you. Note, I replaced my ID bytes with "xx". I seperated
four bytes for readability and seperated the S record start also. The
checksum is represented here as YY.

S214 0FFFDC 5AF00Fxx 5AF00Fxx 5AF00F00 5AF00Fxx YY
S214 0FFFEC 5AF00Fxx B0EF0Fxx 5AF00Fxx 5AF00Fxx YY
S208 0FFFFC 00F00Fxx YY

You can see that there is one spot where you would expect an ID byte
but that this one is not used.

I'm not that sure, but I would say both of your versions are wrong in
that an address consumes FOUR bytes, hence the .byte instruction that
follows your .addr statement or is in front of it respectively also
generates one ADITIONAL byte of code. I could be wrong here though.
Apart from this your "One" version IMHO comes closer.

Do you intend to access the ID bytes from within your firmware code?
IMHO there is no need for this since from what I know the ID code
protects the uC from being read out or reprogrammed unless the propper
ID code is passed in to the uC from the firmware programming process
over the serial interface (or paralell programmer). The lmc30
statement also places the bytes to the propper locations when it
generates the .mot file so....



Re: M16C Security

Quoted text here. Click to load it

The "One" version was what I thought would be correct, it was the
figure that appeared confusing. The .addr seems to insert only 3-bytes.
What were you using instead?


Re: M16C Security
Quoted text here. Click to load it

Provided it really inserts only 3 bytes you are right, but I somehow
doubt it. Well, you could eaisly verify this with a compile and then
look at the debugger or so.

Quoted text here. Click to load it

Nothing. :)

Seriousely, we have a networded product and when it comes to
distinguishing devices we use the MAC address which we individually
"patch" into the MOT file before the uC is programmed.

When it comes to the ID code, we are happy to know that it requires
someone else to have OUR ID code in order to read out the flash.
That's sufficient for our needs since a brute force attack seems
unfeasable considering the latency of the RS232 port and the asociated
commands to set the ID.

The ID code is stored into the MOT file at the point in time you
invoce lmc30 which takes our ID's on the command line.


Re: M16C Security
Quoted text here. Click to load it

Not sure if you consider my method "correct", but it surely works:

    .lword    int_vect1 + 012000000h
    .lword    int_vect2 + 034000000h
    .lword    int_vect3 + 056000000h
    .lword    int_vect4 + 078000000h

Where 12, 34, 56, 78 are the ID values.

The ID bytes are the most significant (unused) bytes of addresses.

Site Timeline