Figure out checksum/CRC in a configuration file

[Staffan321]

Hello,

I have a test instrument (Wiltron 37247 Vector Network Analyzer) running a VME board MVME-162. It stores configurations files on either floppy or internal harddisk. I would like to modify these configuration files, but run into trouble from what I believe is CRC in the files. In some locations, I have identified fairly straightforward checksums being sums of bytes that are easy enough to handle, but in some locations, even a very small change in the configuration file seems to change the values in an unpredictable way (i.e., not just a sum). So, I guess there is some kind of CRC number there. Possibly something the programmers  responsible for one part of the file added in their own way.
Question is: given that I know what has changed between two files, is there any way of figuring out what CRC has been used? The result is a 16 bit word, but apart from that, I know very little what set of data is checked. I only know what has changed between two different files for example.

It's not very easy to generate arbitrary config files for checking, unfortunately. Any hints would be much appreciated!

Regards,
  Staffan

[PlainName]

There are standard CRCs and it's likely that one of these will have been used. Easy enough to check if you know the range of checked data (that is, the start and end locations).  For 16 bits, try:

http://srecord.sourceforge.net/crc16-ccitt.html

Edit: for speed and simplicity a lookup table is often used, but the longhand way might be more appropriate when messing about.

[Staffan321]

Thanks, will check.
My problem at the moment is that I have very few clues as to where the count starts and ends. One brute force way could be to vary the start point and check if/when the calculated crc matches the target. If there is any other (bit more clever) way, I’d love to hear!

Regards,
 Staffan

[PlainName]

Tricky. If you're sure you have the checksum identified, start at the beginning of the file and change a byte until the checksum also changes, then you are fairly sure of where it starts. Likely ends the byte before the sum, but the same process backwards would confirm that. Having figured where the start and end is, try and figure the actual summing technique. The same checksumming method can give different answers depending on whether the calculated sum is stored, or whether some value that added to the sum gives a go/no-go value. On the plus side, anything doing that likely follows some well-known standard to the letter so there are only a couple of variations to check

[Staffan321]

Hello,
The procedure sounds straightforward and I’m considering to do just that. Only problem is that the instrument only reads from floppies and a 180k file -is- big then :-(
I would have to generate a set of files where I change the data ( not CRC) and see when the read fails. Possible problem is that the file is split in sections and there may be ’holes’ inbetween that is not considered.
Anyways, this way is perhaps the safest to go forward with. Just need to find a suitable week and heaps of coffee. The latter is no problem at least.
Regards,
 Staffan

[SethGI]

Honestly, if you're trying to figure out what data they sent through CRC and have no idea where to look, email the manufacturer and ask. You may be pleasantly surprised.