A way to validate the hex file burned into device against the result (hex) of original source code

[Sansei]

Engineerings, We are looking around to find a way to prove that the hex file burned into the device is really the result of the original source code. Is there any idea/way to validate?

How Nrfgo verify the program code burned into the device? I'm asking on program code hex structure.

[Sansei]

I hope you know that the size and content of the read-back hex file is changing during the time as the variable data are changing/adding. It seems the Program code is stored apart from data, and I think this is the way Nrfgo can verify the program code during the time.

[endnode]

No, HEX file is just some list of data and addresses, these can be anything for any architecture. nRFgo definitely has no clue about the structure except basic memory limits (where SD starts and ends, where application area starts, where entire flash space ends).

You are right, HEX file as result of compilation and linking contains static initialization data for internal variables and objects (Google BSS) so if you change these hardcoded values or change size of buffers it's reflected in certain areas of HEX binary produced. BUT read-back HEX should be always the same size, because it's just some blob of bits read from certain logical address of the target. Nothing more, nothing less. Then comparison tools like nrfjprog or nRFgo Studio need to throw away all addresses which are not in the original HEX file (because their content doesn't matter - in fact they should be empty).

[endnode]

nRFgo Studio (or other tools like nrfjprog or SEGGER J-Link/J-FLash) don't validate content of the HEX file, they simply have some input HEX file from you, flash it to the memory, immediately read back the memory addresses they used during flashing and compare read data against original HEX. These should be equal. It's as stupid as comparing two files in your PC.

[Sansei]

Great tips, thanks. As another question, do you mean read-back hex file is exactly as same as the memory layout? If so, read-back program code contains which parts based on this layout?

[Sansei]

If it really shows application area including [Application, Free, AppData,..] so it seems both compiled hex and program read-back hex should have same Application band (i.e. started from SD size and ended by the App size), and we can compare them against each other after parsing the hex.