| Author |
Message |
ronkrem
Guest
|
 Posted:
Fri Dec 02, 2005 1:15 am Post subject:
M16C Security |
|
|
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:
One:
.section vectors,ROMDATA
.org 0fffdch
UDI: .addr dummy_int
.byte 01h ;
security byte ID1
OVER_FLOW: .addr etc...
Two:
.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?
Ron |
|
| Back to top |
|
 |
Markus Zingg
Guest
|
| Posted:
Fri Dec 02, 2005 1:15 am Post subject:
Re: M16C Security |
|
|
| Quote: | 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:
One:
.section vectors,ROMDATA
.org 0fffdch
UDI: .addr dummy_int
.byte 01h ;
security byte ID1
OVER_FLOW: .addr etc...
Two:
.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?
Ron
|
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....
HTH
Markus |
|
| Back to top |
|
|
ronkrem
Guest
|
| Posted:
Fri Dec 02, 2005 1:15 am Post subject:
Re: M16C Security |
|
|
Markus Zingg wrote:
| Quote: | 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:
One:
.section vectors,ROMDATA
.org 0fffdch
UDI: .addr dummy_int
.byte 01h ;
security byte ID1
OVER_FLOW: .addr etc...
Two:
.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?
Ron
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....
HTH
Markus
|
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?
Ron |
|
| Back to top |
|
|
Markus Zingg
Guest
|
| Posted:
Fri Dec 02, 2005 5:15 pm Post subject:
Re: M16C Security |
|
|
| Quote: | 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.
|
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.
| Quote: | What were you using instead?
|
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.
Markus |
|
| Back to top |
|
|
Grzegorz Mazur
Guest
|
| Posted:
Tue Dec 06, 2005 1:15 am Post subject:
Re: M16C Security |
|
|
ronkrem wrote:
| Quote: | 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:
Does anyone have experience with the correct method?
Ron
|
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. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in