There is no code verification of protected uC on standard way.
Code is only downloaded in encrypted state from PC to uC, after receiving encrypted code, code is decrypted in AVR inside using decryption keys for this job.
- - - Updated - - -
Some questions on page 13:
What will happen if power is removed during a firmware update?
What is the state of the microcontroller when power is restored back?
Are lock bits and reset vectors set properly at all times?
Are there any assumptions that can be made on what plaintext data will look like?
In order for AES to be broken, there must be a pattern to look for.
The attack software will have to be configured to search for a known pattern, such as interrupt vectors at the start of program memory, memory areas padded with zero or one, and so on.
Is there any feedback that can be derived from the decryption process? Any such feedback can help the attacker. For example, if the decryption algorithm inside the bootloader would give an OK / Not-OK type of signal for each block processed, then this signal could be used as feedback to the attacker.
Should encrypted frames be sent in another order? If the first frame sent to the bootloader always includes the first block of the encrypted file then the attacker can make some assumptions from this. For example, it can be assumed that the first frame maps program data starting from address zero and that it contains the interrupt vector table. This information helps the attacker to refine the key search.
To increase the security of the system, send the frames in random order (the decrypted frames will be mapped to their proper address, anyhow).