Wrong header offset in signed image generated with SPT v6?

[lorv]

Hi,

I have noticed an inconsistency between the generated signed image and the documentation of the rt600 user manual.

In chapter 42.4 of the user manual UM11147 is stated, that at offset 0x28 the header offset is located, which holds the offset from beginning of the image i.e index 0x0 to where the certificate block header begins.

I have tested two different images and the offset at 0x28 is off by 32 bytes. I have compared the binaries of the unsigned and signed image and there are 32 bytes inserted at the beginning of the signed image. I have attached two screenshot where one can see what I mean. I wanted to put them inline here but apparently  they are too big.

One can see in the screenshot, that the image length field in the unsigned image is the same as the header offset field in the signed image, but there are those additional bytes so the header offset can't be right, can it?

What are those additional 32 bytes? I was not able to find anything about them in the documentation.

The ROM bootloader boots the generated image so I assume it accounts for those 32 additional bytes?

I want to write a second stage bootloader, which checks the signature of the image. Can I assume, that the header offset is always off by 32 bytes? Does the "totalImageLenthInBytes" field in the certificate block header account for those 32 bytes? Otherwise my check of the signature not work.

Thanks for your help.

Regards,
lorv

[Gargy]

Hi,
 in addition of previous information there could be also optionally KeyStore block, which also doesn't affect header offset.

Keep this in mind.

For inspiration check the Fig 235. Encrypted image 

Thanks Petr 

[Gargy · Accepted solution]

Hello,

 as I checked picture of your image, you're using "Plain Signed Load-to-RAM Image" on rt600. And I have to say that you found BUG in documentation.  

So the "unknown" 32 bytes on offset 64  is injected HMAC value that is required for this type of image, but this injection doesn't change the certification block offset, because this HMAC value is handled by ROM code as a first and after that check the image is restored to original binary without this HMAC value.

So the original offset became again valid.


So my recommendation for you if you want to validate signature in your second stage bootloader is following:
- to find certification block, extend the offset from 0x28 by 32 bytes
- to validate signature, just omit the 32 bytes on offset 64. Just skip this HMAC value


Hope that helps
Petr  

[lorv]

Hello Petr,

Thank you very much for your answer. This helps me a lot.

Regards,
lorv

[Gargy]

You are welcome,
 thanks for reporting DOC bug, I resend it internally to documentation team. Hope in early update.