1.9.3 Bootloader Application Verification Method - CRC32

Overview

In the CRC32 verification method, a 32-bit CRC-32Q signature is calculated over a user specified range of memory addresses and is compared to a signature value stored in an application image header at the start of the application image. If the calculated signature matches the signature stored in the application image header, the application is allowed to launch.

This form of verification is good at detecting errors or if the memory has been accidentally erased/overwritten and good at detecting gross errors and even down to single bit errors. A CRC is not able to protect very well against intentional manipulation of the memory by an attacker. A CRC verification is not nearly as quick as a checksum, but provides better protection. It is faster than a hash algorithm, but less secure in terms of memory protection.

Implementation Details

Memory Formating and Addressing

16-bit devices have 3 bytes of instruction address per every 2 PC addresses. A 4th "phantom" byte is added with a 0x00 value. Below is an example of what the memory might look like:


PC Address	Opcode	Operation
0x1000	0x0007FFDF	rcall 0x14AE
0x1002	0x00060000	return

Note the 0x00 that pre each of the opcodes. This is the phantom byte. This doesn't actually exist in memory but is returned when a read of the memory is done of the instruction from firmware. Also note that between the two example instructions, the PC address only incremented by 2 addresses. With only 2 PC addresses for every 4 bytes, not every byte is addressable.

Since not every byte is addressable directly either a new addressing scheme has to be used (as is done in the .hex files) or limitations have to be put on the addressability of the memory. This implementation has chosen to keep the addresses so they match the hardware PC addresses. This implementation is thus limited to only allowing CRC calculations on complete instructions (all 4 bytes, including the phantom byte). Thus odd addresses are not allowed.

Application Image Header

The bootloader needs a known good value against which to compare the calculated CRC value. An application image header is created towards the start of the application image that stores all of the information required to verify the application image. Notice that these address may include the computed CRC32 itself. To avoid the obvious issue here of including the computed CRC32 in the signature space, when computing or verifying the CRC32 the values of these located will be zero during the computation or of the CRC32. For this implementation, the format of the application image header is as follows:


Offset	Length	Item	Description
0	4	CRC value	The expected 32-bit CRC value of the application image
4	4	Start Address	The first PC instruction included in the CRC calcuation. It is highly recommended that this is the start address point to itself so that it is included in the calculation. This address is configured in the application image so that an application can selectively decide to exclude some memory for checking for data that might not be common across all devices (e.g. - calibration data, serial numbers, emulated EEPROM, etc.)
8	4	End Address	The last PC instruction included in the CRC calculation. Every byte of the instruction addressed in this field will be included in the CRC calculation, including the phantom byte. This address is configured in the application image so that an application can selectively decide to exclude some memory for checking for data that might not be common across all devices (e.g. - calibration data, serial numbers, emulated EEPROM, etc.)

So if a device has a valid application memory partition from 0x3000-0x7FFF inclusive, then this is what the application image header might look like on that device:


Address	Length	Item	Value
0x3000	4	CRC-32Q signature value	(Calculated - e.g. 0x41FB310D)
0x3004	4	Start Address - first address to be checked. Recommended to include itself (but not the signature) so 0x3004 in this example.	0x00003004
0x3008	4	End Address	0x7FFE (last PC instruction address in memory range to be checked).

The application firmware image then immediately follows the application image header.

A few key items to note from this example:

The CRC start address can not include the CRC.
The CRC start address is recommended to include itself (thus set to 0x3004 in this example).
The CRC end address is the last valid PC instruction address in the memory (0x7FFE is the last valid instruction address in the application memory range).