This is a bit of the chicken and egg thing. If you want a embed the code c= hecksum in a code module to report the checksum, is there a way of doing th= is? It's a bit like being your own grandfather, I think.=20

I'm not thinking anything too fancy, like a CRC, but rather a simple modulo=
N addition, maybe N being 2^16. =20

I keep thinking of using a placeholder, but that doesn't seem to work out i=
n any useful way. Even if you try to anticipate the impact of adding the c= hecksum, that only gives you a different checksum, that you then need to an= ticipate further... ad infinitum. =20

I'm not thinking of coding any special checksum generator that excludes the=
checksum data. That would be too messy. Just use the existing tools to c= hecksum the file.=20

I keep thinking there is a different way of looking at this to achieve the = result I want...=20

Maybe I can prove it is impossible. Assume the file checksums to X when th=
e checksum data is zero. The goal would then be to include the checksum da=
ta value Y in the file, that would change X to Y. Given the properties of = the module N checksum, this would appear to be impossible for the general c= ase, unless... Add another data value, called, checksum normalizer. This = data value checksums with the original checksum to give the result zero. T= hen, when these two values are added to the file, the resulting checksum do=
es not change. =20

This might be inordinately hard for a CRC, but a simple checksum would not =
be an issue, I think. At least, this could work in software, where data ca=
n be included in an image file as itself. In a device like an FPGA, it mig=
ht not be included in the bit stream file so directly... but that might dep= end on where in the device it is inserted. Memory might have data that is = stored as itself. I'll need to look into that.=20

--=20

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)

On 20/04/2023 04:10, gnuarm.del...@gmail.com wrote:

This is a bit of the chicken and egg thing. If you want a embed the
code checksum in a code module to report the checksum, is there a way
of doing this? It's a bit like being your own grandfather, I think.

I'm not thinking anything too fancy, like a CRC, but rather a simple
modulo N addition, maybe N being 2^16.

I keep thinking of using a placeholder, but that doesn't seem to work
out in any useful way. Even if you try to anticipate the impact of
adding the checksum, that only gives you a different checksum, that
you then need to anticipate further... ad infinitum.

I'm not thinking of coding any special checksum generator that
excludes the checksum data. That would be too messy. Just use the
existing tools to checksum the file.

I keep thinking there is a different way of looking at this to
achieve the result I want...

Maybe I can prove it is impossible. Assume the file checksums to X
when the checksum data is zero. The goal would then be to include
the checksum data value Y in the file, that would change X to Y.
Given the properties of the module N checksum, this would appear to
be impossible for the general case, unless... Add another data
value, called, checksum normalizer. This data value checksums with
the original checksum to give the result zero. Then, when these two
values are added to the file, the resulting checksum does not
change.

This might be inordinately hard for a CRC, but a simple checksum
would not be an issue, I think. At least, this could work in
software, where data can be included in an image file as itself. In
a device like an FPGA, it might not be included in the bit stream
file so directly... but that might depend on where in the device it
is inserted. Memory might have data that is stored as itself. I'll
need to look into that.

I am not sure what your intended use-case is here. But it is very
common to add a checksum of some sort to binary image files after
generating them. This is done post-link. You have a struct in your
read-only data that you link at a known fixed point in the binary. Your post-link patcher can read this struct (for example, to get the program version number that is then used to rename the final image file). It
can modify the struct (such as inserting the length of the image). Then
it calculates a CRC and appends it to the end of the image.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 2023-04-20, gnuarm.del...@gmail.com <gnuarm.deletethisbit@gmail.com> wrote:

Maybe I can prove it is impossible. Assume the file checksums to X when
the checksum data is zero. The goal would then be to include the checksum data value Y in the file, that would change X to Y. Given the properties
of the module N checksum, this would appear to be impossible for the
general case, unless... Add another data value, called, checksum
normalizer. This data value checksums with the original checksum to give
the result zero. Then, when these two values are added to the file, the resulting checksum does not change.

- write the patch area with zero
- checksum the file
- write the negative of the checksum to the patch area
- make the software check that the sum is zero

However, that is only easy with a sum, not with a CRC or hash. It is common
to have the CRC/hash at the beginning or end of the image and exclude that
area from being summed/hashed to avoid the problem you describe.

LPC8xx is one CPU which needs a checksum in the vector table to even start
the flashed program:

https://github.com/nPipen/lpcpatchelf

https://stackoverflow.com/questions/24150030/storing-crc-into-an-axf-elf-file

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- MBSE BBS v1.0.8 (Linux-x86_64)
* Origin: ---:- FTN<->UseNet Gate -:--- (3:633/280.2@fidonet)