maybe this topic should be put in the heap section, since it is not very serious, but it is algorithm related: what about the following:

a routine that calculates the crc32 over itselves, while having the expected comparision crc32 in the same routine.

to be less cryptically, a example:

you have a routine that calculates the crc32 over itself, and compares it with the value it has to be. the first time you assume 12345678h as the value it has to be. then you run the program in your debugger, and then you see the real value (output of the routine). then you change the 12345678h to the value calculated. but the next time you run the routine, it will calc. another crc32, since the compare value is changed.

how would it be possible make this thing go right? imho it is impossible in a nice way.

one possibility is to assume a result CRC32 (0xdeadbeef) and then generate garbage after the routine until it matches 0xdeadbeef. but i see that as playing false.

anyone? :)
Posted on 2002-05-16 13:37:32 by lifewire
Calculate the CRC32 of your data, then choose the DWORD value that will make the CRC32 your desired result. It's like you say at the end - generate garbage, but only a little garbage is needed.
Posted on 2002-05-16 14:14:18 by bitRAKE
It is possible to code a function which "fixes a broken CRC" and all it really does is this:
1) calculate the existing CRC
2) compare to expected CRC
3) modify the initial CRC value by the Difference

(Optional 4) Confirm the new CRC = expected CRC

There's no trial and error involved, it is a one-step method for accurately measuring and correcting CRC error.

In the Olden Dayes, we would simply look for some unused data and alter it to correct the CRC of the entire binary chunk.

All this works on the supposition that your CRC algo is a standard 16 or 32 bit rolling Counter.
Posted on 2002-05-18 01:34:25 by Homer