RE: Gottlieb / Q*bert scripts for the 9010A/9100
Ah ha! You've just spotted the reason for my previous question - What's the polynomial? I worked out the Cat Box polynomial directly from the PCB, you can actually _see_ the address counter and the XOR feedback points. Apparently the Cat Box polynomial is the same as the HP one. Now it gets a bit confusing... (Especially as I've not actually had time to get stuck into my Fluke and confirm all of this!) /As far as I can see/ The Fluke creates a signature with a similar procedure to a boring old checksum, by reading each byte of a region of memory space and performing a calculation on it to produce a single 16 bit signature. To create the signature, it right shifts each bit of each byte into the polynomimial XOR 'circuitry'. On the Cat Box the 'circuitry' is physical, but is probably software on the 9010a for reasons shown below. On a Fluke, there seems to be a bit of general confusion as to where the calculation is done, in the pod or in the main unit. I would be very surprised if it were done in the pod but I could be wrong. (I hope to have a look myself in the summer, when I've finished college...) Anyway, the Cat Box performs Signature /Analysis/, which also produces a signature, but not by reading in a chunk of bytes and creating a signature from them via software. Using a probe, it reads the chain of bits that occur at a particular point on a PCB when the address bus is ramped from 0 to FFFFH. To test one part of a circuit e.g. a single ROM, you would tie a sig analysis start and stop line to the chip enable of the ROM which in effect maps to that ROMs address space only. If you point the probe at the one data line of the ROM, you will get a stream of bits which you can XOR in a similar way to the standard Fluke signature. BUT the calculation will only be performed on one bit of each byte as there are 8 data lines and you only have one probe! Thus, you get 8 signatures per ROM as shown in the Atari Cat Box signature reference for each PCB. A Fluke signature is an improved way of testing a ROMs integrity over a checksum, but it can't be used to analyse anything other than a fixed areas of memory space i.e. ROM. Signature /Analysis/ can test /any/ digital part of a circuit as long at it derives from the processor's address and data decoding (i.e you can't do the video circuitry). My program uses a software way of calculating the signature, but it emulates the Atari probe hardware i.e. by testing only 1 bit of a byte and thus it is an emulator, as opposed to just a signature generator. I originally wrote it to do the 8 bits of a ROM, but this added an extra loop, and all I was really trying to do was show how it worked, so I went back to just one bit for clarity. Note BASIC has no bitwise operators so the code is a bit cumbersome, if you rewrote it in C, or even better Forth, it would be a fraction of the size. You could quite easily modify my emulation to either create all 8 checksums together like the Cat Box or pass all of the information from each byte serially into the calculation like the Fluke (if you knew it's polynomial). Cheers, Phillip Eaton http://www.phillipeaton.com ---- Original message ----
Date: Mon, 06 May 2002 21:45:41 -0700 From: John Robertson <jrr@flippers.com> Subject: RE: Gottlieb / Q*bert scripts for the 9010A/9100 To: "Phillip Eaton" <inbox@phillipeaton.com>, <TechToolsList@flippers.com>
Hi Phillip,
I just tried your emulator on a bunch of Asteroid files and compared them with the signatures on the 9010 and I do not get the same results... Does it not setup the same Signature that HP designed and thus should it not give the same results for any file as the Fluke would do on a ROM signature test? The signatures generated by your emulator are consistent - identical files give identical signatures...
Might I ask what the "Bit number <0 - 7>" refers to in the emulator?
John :-#)#
At 11:08 PM 06/05/2002 +0100, Phillip Eaton wrote:
I wrote one of these a few years back. It's part of my Atari Cat Box signature analysis write-up which is held at http://www.gamearchive.com/video/manufacturer/atari/vector/s ignatures/
It includes a very simple program source code (to aid understanding) to do what you mentioned in MS DOS QBasic for the Cat Box.
You could quite easily use it as a base to write your own, or simply change the polynomial in mine and it'd do what you need.
How did you work out the ploynomial?
Cheers, Phillip Eaton
-----Original Message----- From: owner-techtoolslist@www.flippers.com [mailto:owner-techtoolslist@www.flippers.com]On Behalf Of John Robertson Sent: 06 May 2002 22:03 To: TechToolsList@flippers.com Subject: Re: Gottlieb / Q*bert scripts for the 9010A/9100
What we need is for some bright person to write a simple utility that converts data files to signatures. The signature formula is fairly simple and if combined with Bill Ung's ROMSUM would be a nice tool for our package. If you don't know ROMSUM it is a dos utility that will give a checksum listing plus the ROM size for a single or group of files...
The Signature process is a CRC process that uses the following feedback equation: X(to the 16th) + X(to the 12th) + X(to the 9th) +X(to the 7th) + 1 or P(X) = X(15th) + X(9th) + X(7th) +X(4th) + 1
So who wants to make a simple (not for me!) binary program that allows one to input a file and outputs it's signature?
John :-#)#
At 09:11 AM 06/05/2002 -0400, Kev wrote:
Anyone written any test scripts for these or at the very least have some checksum signatures?
Thanks, Kev
Home today fighting a small chest infection... I don't think these ROM Signatures generated by the base numbers are true "Signatures" after all. Note that the coding for them does not follow the convention of using HP's ACFHPU, rather the "signature" generated uses standard HEX nomenclature.. Now I wonder what this number actually is...I'm going to try to use my new Arium ML1400 Logic Analyzer to see if I can find the section of code in the base that actually is used to create the ROM signature and report back. I think it is more likely a signature similar to the one ROMIDENT uses... anyone know it's root formula? John :-#)# At 10:06 AM 07/05/2002 +0100, Phillip Eaton wrote:
Ah ha! You've just spotted the reason for my previous question - What's the polynomial?
I worked out the Cat Box polynomial directly from the PCB, you can actually _see_ the address counter and the XOR feedback points. Apparently the Cat Box polynomial is the same as the HP one.
Now it gets a bit confusing... (Especially as I've not actually had time to get stuck into my Fluke and confirm all of this!)
/As far as I can see/ The Fluke creates a signature with a similar procedure to a boring old checksum, by reading each byte of a region of memory space and performing a calculation on it to produce a single 16 bit signature. To create the signature, it right shifts each bit of each byte into the polynomimial XOR 'circuitry'. On the Cat Box the 'circuitry' is physical, but is probably software on the 9010a for reasons shown below.
On a Fluke, there seems to be a bit of general confusion as to where the calculation is done, in the pod or in the main unit. I would be very surprised if it were done in the pod but I could be wrong. (I hope to have a look myself in the summer, when I've finished college...)
Anyway, the Cat Box performs Signature /Analysis/, which also produces a signature, but not by reading in a chunk of bytes and creating a signature from them via software.
Using a probe, it reads the chain of bits that occur at a particular point on a PCB when the address bus is ramped from 0 to FFFFH. To test one part of a circuit e.g. a single ROM, you would tie a sig analysis start and stop line to the chip enable of the ROM which in effect maps to that ROMs address space only.
If you point the probe at the one data line of the ROM, you will get a stream of bits which you can XOR in a similar way to the standard Fluke signature. BUT the calculation will only be performed on one bit of each byte as there are 8 data lines and you only have one probe! Thus, you get 8 signatures per ROM as shown in the Atari Cat Box signature reference for each PCB.
A Fluke signature is an improved way of testing a ROMs integrity over a checksum, but it can't be used to analyse anything other than a fixed areas of memory space i.e. ROM. Signature /Analysis/ can test /any/ digital part of a circuit as long at it derives from the processor's address and data decoding (i.e you can't do the video circuitry).
My program uses a software way of calculating the signature, but it emulates the Atari probe hardware i.e. by testing only 1 bit of a byte and thus it is an emulator, as opposed to just a signature generator.
I originally wrote it to do the 8 bits of a ROM, but this added an extra loop, and all I was really trying to do was show how it worked, so I went back to just one bit for clarity.
Note BASIC has no bitwise operators so the code is a bit cumbersome, if you rewrote it in C, or even better Forth, it would be a fraction of the size.
You could quite easily modify my emulation to either create all 8 checksums together like the Cat Box or pass all of the information from each byte serially into the calculation like the Fluke (if you knew it's polynomial).
Cheers, Phillip Eaton http://www.phillipeaton.com
---- Original message ----
Date: Mon, 06 May 2002 21:45:41 -0700 From: John Robertson <jrr@flippers.com> Subject: RE: Gottlieb / Q*bert scripts for the 9010A/9100 To: "Phillip Eaton" <inbox@phillipeaton.com>, <TechToolsList@flippers.com>
Hi Phillip,
I just tried your emulator on a bunch of Asteroid files and compared them with the signatures on the 9010 and I do not get the same results... Does it not setup the same Signature that HP designed and thus should it not give the same results for any file as the Fluke would do on a ROM signature test? The signatures generated by your emulator are consistent - identical files give identical signatures...
Might I ask what the "Bit number <0 - 7>" refers to in the emulator?
John :-#)#
At 11:08 PM 06/05/2002 +0100, Phillip Eaton wrote:
I wrote one of these a few years back. It's part of my Atari Cat Box signature analysis write-up which is held at http://www.gamearchive.com/video/manufacturer/atari/vector/s ignatures/
It includes a very simple program source code (to aid understanding) to do what you mentioned in MS DOS QBasic for the Cat Box.
You could quite easily use it as a base to write your own, or simply change the polynomial in mine and it'd do what you need.
How did you work out the ploynomial?
Cheers, Phillip Eaton
-----Original Message----- From: owner-techtoolslist@www.flippers.com [mailto:owner-techtoolslist@www.flippers.com]On Behalf Of John Robertson Sent: 06 May 2002 22:03 To: TechToolsList@flippers.com Subject: Re: Gottlieb / Q*bert scripts for the 9010A/9100
What we need is for some bright person to write a simple utility that converts data files to signatures. The signature formula is fairly simple and if combined with Bill Ung's ROMSUM would be a nice tool for our package. If you don't know ROMSUM it is a dos utility that will give a checksum listing plus the ROM size for a single or group of files...
The Signature process is a CRC process that uses the following feedback equation: X(to the 16th) + X(to the 12th) + X(to the 9th) +X(to the 7th) + 1 or P(X) = X(15th) + X(9th) + X(7th) +X(4th) + 1
So who wants to make a simple (not for me!) binary program that allows one to input a file and outputs it's signature?
John :-#)#
At 09:11 AM 06/05/2002 -0400, Kev wrote:
Anyone written any test scripts for these or at the very least have some checksum signatures?
Thanks, Kev
AFAIK, the signature that Rom Ident uses is a standard CRC-32 calculation, which is calculated in an identical way to CRC-16 and CCITT CRCs, using all bits of each byte in the file. The polynomial may be different (i.e. more bits for CRC-32), but the technique is the same for any CRC/Signature calculation. Have a search for CRC-16 and CRC-32 on Google, you get back loads of results. WinZip uses CRC-32, as does MAME, to see the CRC-32 for a file, zip it up in WinZip (8.0?) and set the configuraiton options to show the CRC. You'll see it's 8 hex characters i.e. 32 bits. Cheers, Phillip Eaton
-----Original Message----- From: John Robertson [mailto:jrr@flippers.com] Sent: 08 May 2002 22:44 To: Phillip Eaton; TechToolsList@flippers.com Subject: RE: Gottlieb / Q*bert scripts for the 9010A/9100
Home today fighting a small chest infection...
I don't think these ROM Signatures generated by the base numbers are true "Signatures" after all. Note that the coding for them does not follow the convention of using HP's ACFHPU, rather the "signature" generated uses standard HEX nomenclature.. Now I wonder what this number actually is...I'm going to try to use my new Arium ML1400 Logic Analyzer to see if I can find the section of code in the base that actually is used to create the ROM signature and report back.
I think it is more likely a signature similar to the one ROMIDENT uses... anyone know it's root formula?
John :-#)#
At 10:06 AM 07/05/2002 +0100, Phillip Eaton wrote:
Ah ha! You've just spotted the reason for my previous question - What's the polynomial?
I worked out the Cat Box polynomial directly from the PCB, you can actually _see_ the address counter and the XOR feedback points. Apparently the Cat Box polynomial is the same as the HP one.
Now it gets a bit confusing... (Especially as I've not actually had time to get stuck into my Fluke and confirm all of this!)
/As far as I can see/ The Fluke creates a signature with a similar procedure to a boring old checksum, by reading each byte of a region of memory space and performing a calculation on it to produce a single 16 bit signature. To create the signature, it right shifts each bit of each byte into the polynomimial XOR 'circuitry'. On the Cat Box the 'circuitry' is physical, but is probably software on the 9010a for reasons shown below.
On a Fluke, there seems to be a bit of general confusion as to where the calculation is done, in the pod or in the main unit. I would be very surprised if it were done in the pod but I could be wrong. (I hope to have a look myself in the summer, when I've finished college...)
Anyway, the Cat Box performs Signature /Analysis/, which also produces a signature, but not by reading in a chunk of bytes and creating a signature from them via software.
Using a probe, it reads the chain of bits that occur at a particular point on a PCB when the address bus is ramped from 0 to FFFFH. To test one part of a circuit e.g. a single ROM, you would tie a sig analysis start and stop line to the chip enable of the ROM which in effect maps to that ROMs address space only.
If you point the probe at the one data line of the ROM, you will get a stream of bits which you can XOR in a similar way to the standard Fluke signature. BUT the calculation will only be performed on one bit of each byte as there are 8 data lines and you only have one probe! Thus, you get 8 signatures per ROM as shown in the Atari Cat Box signature reference for each PCB.
A Fluke signature is an improved way of testing a ROMs integrity over a checksum, but it can't be used to analyse anything other than a fixed areas of memory space i.e. ROM. Signature /Analysis/ can test /any/ digital part of a circuit as long at it derives from the processor's address and data decoding (i.e you can't do the video circuitry).
My program uses a software way of calculating the signature, but it emulates the Atari probe hardware i.e. by testing only 1 bit of a byte and thus it is an emulator, as opposed to just a signature generator.
I originally wrote it to do the 8 bits of a ROM, but this added an extra loop, and all I was really trying to do was show how it worked, so I went back to just one bit for clarity.
Note BASIC has no bitwise operators so the code is a bit cumbersome, if you rewrote it in C, or even better Forth, it would be a fraction of the size.
You could quite easily modify my emulation to either create all 8 checksums together like the Cat Box or pass all of the information from each byte serially into the calculation like the Fluke (if you knew it's polynomial).
Cheers, Phillip Eaton http://www.phillipeaton.com
---- Original message ----
Date: Mon, 06 May 2002 21:45:41 -0700 From: John Robertson <jrr@flippers.com> Subject: RE: Gottlieb / Q*bert scripts for the 9010A/9100 To: "Phillip Eaton" <inbox@phillipeaton.com>, <TechToolsList@flippers.com>
Hi Phillip,
I just tried your emulator on a bunch of Asteroid files and compared them with the signatures on the 9010 and I do not get the same results... Does it not setup the same Signature that HP designed and thus should it not give the same results for any file as the Fluke would do on a ROM signature test? The signatures generated by your emulator are consistent - identical files give identical signatures...
Might I ask what the "Bit number <0 - 7>" refers to in the emulator?
John :-#)#
At 11:08 PM 06/05/2002 +0100, Phillip Eaton wrote:
I wrote one of these a few years back. It's part of my Atari Cat Box signature analysis write-up which is held at http://www.gamearchive.com/video/manufacturer/atari/vector/s ignatures/
It includes a very simple program source code (to aid understanding) to do what you mentioned in MS DOS QBasic for the Cat Box.
You could quite easily use it as a base to write your own, or simply change the polynomial in mine and it'd do what you need.
How did you work out the ploynomial?
Cheers, Phillip Eaton
-----Original Message----- From: owner-techtoolslist@www.flippers.com [mailto:owner-techtoolslist@www.flippers.com]On Behalf Of John Robertson Sent: 06 May 2002 22:03 To: TechToolsList@flippers.com Subject: Re: Gottlieb / Q*bert scripts for the 9010A/9100
What we need is for some bright person to write a simple utility that converts data files to signatures. The signature formula is fairly simple and if combined with Bill Ung's ROMSUM would be a nice tool for our package. If you don't know ROMSUM it is a dos utility that will give a checksum listing plus the ROM size for a single or group of files...
The Signature process is a CRC process that uses the following feedback equation: X(to the 16th) + X(to the 12th) + X(to the 9th) +X(to the 7th) + 1 or P(X) = X(15th) + X(9th) + X(7th) +X(4th) + 1
So who wants to make a simple (not for me!) binary program that allows one to input a file and outputs it's signature?
John :-#)#
At 09:11 AM 06/05/2002 -0400, Kev wrote:
Anyone written any test scripts for these or at the very least have some checksum signatures?
Thanks, Kev
On Wed, 8 May 2002 22:50:54 +0100, "Phillip Eaton" <inbox@phillipeaton.com> wrote:
AFAIK, the signature that Rom Ident uses is a standard CRC-32 calculation, which is calculated in an identical way to CRC-16 and CCITT CRCs, using all bits of each byte in the file.
The polynomial may be different (i.e. more bits for CRC-32), but the technique is the same for any CRC/Signature calculation. Have a search for CRC-16 and CRC-32 on Google, you get back loads of results.
WinZip uses CRC-32, as does MAME, to see the CRC-32 for a file, zip it up in WinZip (8.0?) and set the configuraiton options to show the CRC. You'll see it's 8 hex characters i.e. 32 bits.
Just for the fun of it I wrote a quick program that tried all possible feedback combinations for 16 bit CRCs (65536 combinations), none of them generated the proper signatures, so it's more than just a variation of the standard CRC calculations. (FWIW: I also tried reversing the bit read order. I ran this shifting in both the LSB and the MSB first, neither worked.) The signature may be easily cracked though, assuming no hidden states are saved in the Fluke processor. If this is similar to a standard signature, then given a starting CRC of 16 bits, and a new bit to shift in, the new CRC value will always be one of two new values, depending upon whether the bit value is a zero or a one. For instance if the current CRC is AB12, and the new bit to be shifted in is a one, and that creates a new CRC of 34F7, and if shifting a one into a CRC of AB12 *always* creates a new CRC of 34F7, then the signature can be calculated using two 128k lookup tables. If the above is true then a program could be written that would: if (next bit == 0) crc = CrcTbl0[crc]; else crc = CrcTbl1[crc]; That would pretty much be the whole signature calculation, and you can ignore any internal functions being done by the Fluke code. This would work assuming the signature does work similar to a CRC. If Fluke, for some reason, wants to make things really tough, they could do something similar to what a MD5 calculation does. It keeps track of previous bytes and changes the results based on what it previously read. For instance a CRC of AB12 with a one shifted in would only become 34F7 if the previous bit was a 0, otherwise it would be something else. That would be bad :^( There is hardware for running an HP signature in the 9010a. I found this in the service manual (page 4 of 4 of the main board schematic, or something like that, there was no page number). Included in the calculation was a counter that counts the number of high to low transitions made by the incoming data bitstream. If this circuit is being used to calculate the sigs, it could be that this count value is being added back into the calculation to convolute things. If this is the case, the above solution won't work. This could be tested by, finding two identical signatures, using different bytes, that created the same CRC, and then adding a third byte to see if they are both still equal. For instance if the bytes: 00 45 = CRC-1234, and, 12 BC = CRC-1234, then the CRC for the three bytes "00 45 01" should equal the CRC for "12 BC 01". This would be an immediate indicator as to whether or not we are dealing with a "standard" CRC calculation of some type. It would also be an indicator as to how hard it will be to crack the code. Anybody know of two different ROMs, or byte streams that result in the same signature? -Zonn
Cheers, Phillip Eaton
-----Original Message----- From: John Robertson [mailto:jrr@flippers.com] Sent: 08 May 2002 22:44 To: Phillip Eaton; TechToolsList@flippers.com Subject: RE: Gottlieb / Q*bert scripts for the 9010A/9100
Home today fighting a small chest infection...
I don't think these ROM Signatures generated by the base numbers are true "Signatures" after all. Note that the coding for them does not follow the convention of using HP's ACFHPU, rather the "signature" generated uses standard HEX nomenclature.. Now I wonder what this number actually is...I'm going to try to use my new Arium ML1400 Logic Analyzer to see if I can find the section of code in the base that actually is used to create the ROM signature and report back.
I think it is more likely a signature similar to the one ROMIDENT uses... anyone know it's root formula?
John :-#)#
At 10:06 AM 07/05/2002 +0100, Phillip Eaton wrote:
Ah ha! You've just spotted the reason for my previous question - What's the polynomial?
I worked out the Cat Box polynomial directly from the PCB, you can actually _see_ the address counter and the XOR feedback points. Apparently the Cat Box polynomial is the same as the HP one.
Now it gets a bit confusing... (Especially as I've not actually had time to get stuck into my Fluke and confirm all of this!)
/As far as I can see/ The Fluke creates a signature with a similar procedure to a boring old checksum, by reading each byte of a region of memory space and performing a calculation on it to produce a single 16 bit signature. To create the signature, it right shifts each bit of each byte into the polynomimial XOR 'circuitry'. On the Cat Box the 'circuitry' is physical, but is probably software on the 9010a for reasons shown below.
On a Fluke, there seems to be a bit of general confusion as to where the calculation is done, in the pod or in the main unit. I would be very surprised if it were done in the pod but I could be wrong. (I hope to have a look myself in the summer, when I've finished college...)
Anyway, the Cat Box performs Signature /Analysis/, which also produces a signature, but not by reading in a chunk of bytes and creating a signature from them via software.
Using a probe, it reads the chain of bits that occur at a particular point on a PCB when the address bus is ramped from 0 to FFFFH. To test one part of a circuit e.g. a single ROM, you would tie a sig analysis start and stop line to the chip enable of the ROM which in effect maps to that ROMs address space only.
If you point the probe at the one data line of the ROM, you will get a stream of bits which you can XOR in a similar way to the standard Fluke signature. BUT the calculation will only be performed on one bit of each byte as there are 8 data lines and you only have one probe! Thus, you get 8 signatures per ROM as shown in the Atari Cat Box signature reference for each PCB.
A Fluke signature is an improved way of testing a ROMs integrity over a checksum, but it can't be used to analyse anything other than a fixed areas of memory space i.e. ROM. Signature /Analysis/ can test /any/ digital part of a circuit as long at it derives from the processor's address and data decoding (i.e you can't do the video circuitry).
My program uses a software way of calculating the signature, but it emulates the Atari probe hardware i.e. by testing only 1 bit of a byte and thus it is an emulator, as opposed to just a signature generator.
I originally wrote it to do the 8 bits of a ROM, but this added an extra loop, and all I was really trying to do was show how it worked, so I went back to just one bit for clarity.
Note BASIC has no bitwise operators so the code is a bit cumbersome, if you rewrote it in C, or even better Forth, it would be a fraction of the size.
You could quite easily modify my emulation to either create all 8 checksums together like the Cat Box or pass all of the information from each byte serially into the calculation like the Fluke (if you knew it's polynomial).
Cheers, Phillip Eaton http://www.phillipeaton.com
---- Original message ----
Date: Mon, 06 May 2002 21:45:41 -0700 From: John Robertson <jrr@flippers.com> Subject: RE: Gottlieb / Q*bert scripts for the 9010A/9100 To: "Phillip Eaton" <inbox@phillipeaton.com>, <TechToolsList@flippers.com>
Hi Phillip,
I just tried your emulator on a bunch of Asteroid files and compared them with the signatures on the 9010 and I do not get the same results... Does it not setup the same Signature that HP designed and thus should it not give the same results for any file as the Fluke would do on a ROM signature test? The signatures generated by your emulator are consistent - identical files give identical signatures...
Might I ask what the "Bit number <0 - 7>" refers to in the emulator?
John :-#)#
At 11:08 PM 06/05/2002 +0100, Phillip Eaton wrote:
I wrote one of these a few years back. It's part of my Atari Cat Box signature analysis write-up which is held at http://www.gamearchive.com/video/manufacturer/atari/vector/s ignatures/
It includes a very simple program source code (to aid understanding) to do what you mentioned in MS DOS QBasic for the Cat Box.
You could quite easily use it as a base to write your own, or simply change the polynomial in mine and it'd do what you need.
How did you work out the ploynomial?
Cheers, Phillip Eaton
-----Original Message----- From: owner-techtoolslist@www.flippers.com [mailto:owner-techtoolslist@www.flippers.com]On Behalf Of John Robertson Sent: 06 May 2002 22:03 To: TechToolsList@flippers.com Subject: Re: Gottlieb / Q*bert scripts for the 9010A/9100
What we need is for some bright person to write a simple utility that converts data files to signatures. The signature formula is fairly simple and if combined with Bill Ung's ROMSUM would be a nice tool for our package. If you don't know ROMSUM it is a dos utility that will give a checksum listing plus the ROM size for a single or group of files...
The Signature process is a CRC process that uses the following feedback equation: X(to the 16th) + X(to the 12th) + X(to the 9th) +X(to the 7th) + 1 or P(X) = X(15th) + X(9th) + X(7th) +X(4th) + 1
So who wants to make a simple (not for me!) binary program that allows one to input a file and outputs it's signature?
John :-#)#
At 09:11 AM 06/05/2002 -0400, Kev wrote:
>Anyone written any test scripts for these or at the very least have some >checksum signatures? > >Thanks, >Kev
Just for the fun of it I wrote a quick program that tried all possible feedback combinations for 16 bit CRCs (65536 combinations), none of them generated the proper signatures, so it's more than just a variation of the standard CRC calculations.
Ah-ha! BUT!! Did you try for all possible combinations of /starting/ CRC? Try that 'just for fun' - it should only take 65536 times as long :-) In my old serial comms days, we always started our CRC's at some bizarre number (3403 IIRC), for two reasons 1) it offered better data security of our protocols and 2) because it was safer to start there as some random numbers are better generators than others. If you run a mathematical random number generators over a long period then you get less random bits that others (i.e. the numbers stay about the same for a while). This is the same for CRC's and thus the safety of the calculation in spotting single or double bit errors is dimished in certain areas.
Anybody know of two different ROMs, or byte streams that result in the same signature?
There's loads in ROMIdent - just run with a bunch of EPROMS from your MAME directory, and you're bound to find a couple. Cheers, Phillip Eaton
On Thu, 9 May 2002 00:14:15 +0100, "Phillip Eaton" <inbox@phillipeaton.com> wrote:
Just for the fun of it I wrote a quick program that tried all possible feedback combinations for 16 bit CRCs (65536 combinations), none of them generated the proper signatures, so it's more than just a variation of the standard CRC calculations.
Ah-ha! BUT!! Did you try for all possible combinations of /starting/ CRC? Try that 'just for fun' - it should only take 65536 times as long :-)
I didn't, but that seemed unlikely since a single byte is always(?), it's own signature -- that's really only going to happen if you start with 0, and your feedback points are high enough to keep from effecting the first byte. (I'd like for someone to try a get a signature of an FF, there's a chance it might come back as an FE, which would tell me a bit about the CRC they're using. IE - are they starting with the HP-sig?) If all values are possible, then starting with 65k values, and then using 65k different feedback loops, I should get 65k hits, which won't do me much good. Hold on.... Yep, a zillion hits, I didn't let it finish...
In my old serial comms days, we always started our CRC's at some bizarre number (3403 IIRC), for two reasons 1) it offered better data security of our protocols and 2) because it was safer to start there as some random numbers are better generators than others.
The ANSI standard CRC-32 (used by winzip) requires you to preload with FFFFFFFF. This is because if you start your CRC with 0's, then all leading zeros of the bitstream you want to CRC will be ignored.
If you run a mathematical random number generators over a long period then you get less random bits that others (i.e. the numbers stay about the same for a while).
And who's to say that is not random? ;^)
This is the same for CRC's and thus the safety of the calculation in spotting single or double bit errors is dimished in certain areas.
With a proper feedback selection single errors are always found, it's based on parity by selecting the proper feedback points. If the resulting parity is off, then at least a single error has occurred. This was explained in the HP5004 article on spies that John R pointed me to.
Anybody know of two different ROMs, or byte streams that result in the same signature?
There's loads in ROMIdent - just run with a bunch of EPROMS from your MAME directory, and you're bound to find a couple.
I didn't mean standard CRC-32, I meant, 9010a signatures. I'm assuming it's hard to run the 9010a signatures on files or this topic would have never come up! ;^) One way to find a two signatures that match would be to run the signature on any rom larger than 64k, and save a snapshot of the sig after each byte. After collection 64k signatures, the next one will have to match one of the previous ones. -Zonn
Cheers, Phillip Eaton
A number of months ago I tossed the following into the mix, looks like it is time to repost it: The Operators Manual states: "Rom Signature is a four-digit HEXADECIMAL number that is a shorthand representation of the data obtained in an area of ROM memory. The ROM signature is obtained by successively dividing the data in ROM by a binary number (they DON't say what the @!$%#$@% number is! - JR). The resulting signature identifies the data from which it is obtained, and provides a convenient way of" (....blah blah, no other description of the process)." John :-#)# At 12:14 AM 09/05/2002 +0100, Phillip Eaton wrote:
Just for the fun of it I wrote a quick program that tried all possible feedback combinations for 16 bit CRCs (65536 combinations), none of them generated the proper signatures, so it's more than just a variation of the standard CRC calculations.
Ah-ha! BUT!! Did you try for all possible combinations of /starting/ CRC? Try that 'just for fun' - it should only take 65536 times as long :-)
In my old serial comms days, we always started our CRC's at some bizarre number (3403 IIRC), for two reasons 1) it offered better data security of our protocols and 2) because it was safer to start there as some random numbers are better generators than others.
If you run a mathematical random number generators over a long period then you get less random bits that others (i.e. the numbers stay about the same for a while). This is the same for CRC's and thus the safety of the calculation in spotting single or double bit errors is dimished in certain areas.
Anybody know of two different ROMs, or byte streams that result in the same signature?
There's loads in ROMIdent - just run with a bunch of EPROMS from your MAME directory, and you're bound to find a couple.
Cheers, Phillip Eaton
For those interested, here's another checksum algorithm designed by BT in the UK, called a Frame Check Sequence number (FCS). It's not quite as secure as a CRC, but it is very close and it is much, much easier to calculate. (You can make out the algorithm from the code). I implemented it in Z80 assembly using a Forth cross-compiler (i.e. it's all backwards) for some embedded stuff I was working on. A CRC on the other hand, is much harder to calculate. See the comparable listing at the end. It also shows my start value as 8408. I'm a bit confused myself now, actually, as the CRC code seems to process the whole 16 bit old CRC in one go (or at least it would if the Z80 was a true 16 bit processor), which is a bit different from running 1 bit at a time. I'll hae to do some testing...when I get some time! Phil. \ -------------------------------------------------------------------------- - \ FCS \ \ Descripton: Piece of Z80/H64180 code to implement the FCS algorithm as \ defined by British Telecom New Networks Technical Forum - \ Document CP(83)/12 04/02/83. Call with the old FCS and data \ byte to be FCS'd and a new FCS is returned. Note the 'exx' \ at the start and end of the code - MPE Z80 forth crashes if \ you use the standard BC registers. You should be able to \ remove these if you are using any other compiler. \ To parse a complete buffer of information, you need an \ external loop which calls this function for each data byte. \ FCS = File Check Sequence \ \ Parameters: fcs_c0c1 - Old FCS to modify. \ char - Value to add to FCS. \ \ Returns: new_fcs_c0c1 - New FCS. \ \ -------------------------------------------------------------------------- - Code FCS \ fcs_c0c1 char --- new_fcs_c0c1 ; EXX BC POP \ Contains new data byte in C DE POP \ Contains old FCS, D=c0, E=c1 A, D LD \ Calc new c0, c0=c0+char A, C ADD NC, fcs1 JP \ If result > $ff then A INC \ add 1 to result L: fcs1 D, A LD \ Store back to c0 A, E LD \ Calc new c1, c1=c1+c0 A, D ADD NC, fcs2 JP \ If result > $ff then A INC \ add 1 to result L: fcs2 E, A LD \ Store back to c1 DE PUSH EXX NEXT, End-Code ************ CRC CODE STARTS HERE *********** HEX $8408 equ CRC-Seed \ Good initial value for CRC calculation. Code CRC-16 \ crc char --- new_crc ; EXX BC POP \ Contains new data byte in C DE POP \ Contains old CRC HL, # 0 LD \ Define Work Area A, E LD \ XOR bottom 8 bits of old CRC with data byte A, C XOR E, A LD A, H LD \ Swap bottom 8 bits of CRC with top 8 bits of H, E LD \ Work Area E, A LD A, D LD \ Swap top 8 bits of CRC with bottom 8 bits D, E LD E, A LD PE, L1 JP \ If parity of XOR even, miss out the CRC XOR A, D LD \ XOR the CRC with C001H A, # C0 XOR D, A LD A, E LD A, # 01 XOR E, A LD L: L1 SCF \ Right shift the CRC and then XOR it with work area CCF H RR L RR A, D LD A, H XOR D, A LD A, E LD A, L XOR E, A LD SCF \ Right shift the CRC and then XOR it with work area CCF \ again H RR L RR A, D LD A, H XOR D, A LD A, E LD A, L XOR E, A LD DE PUSH \ Shove the new CRC back on the stack EXX NEXT, End-code
This was originally called a Fletcher's Checksum after the creator. I agree it is a nice checksum, I've been using this to checksum things since the mid 80's! It's well documented in a back issue of Dr Dobb's journal, you could probably find it on their site, or at least in their back issue CD. FWIW: It's only "very close" to a CRC in security on blocks below 255 bytes, it's comparison to CRC falls off quickly after that. But for small packets it's very good! And for anything larger it's a heck of a lot better than a standard checksum. -Zonn On Thu, 9 May 2002 00:34:24 +0100, "Phillip Eaton" <inbox@phillipeaton.com> wrote:
For those interested, here's another checksum algorithm designed by BT in the UK, called a Frame Check Sequence number (FCS).
It's not quite as secure as a CRC, but it is very close and it is much, much easier to calculate. (You can make out the algorithm from the code).
I implemented it in Z80 assembly using a Forth cross-compiler (i.e. it's all backwards) for some embedded stuff I was working on.
A CRC on the other hand, is much harder to calculate. See the comparable listing at the end. It also shows my start value as 8408.
I'm a bit confused myself now, actually, as the CRC code seems to process the whole 16 bit old CRC in one go (or at least it would if the Z80 was a true 16 bit processor), which is a bit different from running 1 bit at a time. I'll hae to do some testing...when I get some time!
Phil.
\ -------------------------------------------------------------------------- - \ FCS \ \ Descripton: Piece of Z80/H64180 code to implement the FCS algorithm as \ defined by British Telecom New Networks Technical Forum - \ Document CP(83)/12 04/02/83. Call with the old FCS and data \ byte to be FCS'd and a new FCS is returned. Note the 'exx' \ at the start and end of the code - MPE Z80 forth crashes if \ you use the standard BC registers. You should be able to \ remove these if you are using any other compiler. \ To parse a complete buffer of information, you need an \ external loop which calls this function for each data byte. \ FCS = File Check Sequence \ \ Parameters: fcs_c0c1 - Old FCS to modify. \ char - Value to add to FCS. \ \ Returns: new_fcs_c0c1 - New FCS. \ \ -------------------------------------------------------------------------- -
Code FCS \ fcs_c0c1 char --- new_fcs_c0c1 ;
EXX
BC POP \ Contains new data byte in C DE POP \ Contains old FCS, D=c0, E=c1
A, D LD \ Calc new c0, c0=c0+char A, C ADD NC, fcs1 JP \ If result > $ff then A INC \ add 1 to result L: fcs1 D, A LD \ Store back to c0
A, E LD \ Calc new c1, c1=c1+c0 A, D ADD NC, fcs2 JP \ If result > $ff then A INC \ add 1 to result L: fcs2 E, A LD \ Store back to c1
DE PUSH
EXX NEXT,
End-Code
************ CRC CODE STARTS HERE *********** HEX
$8408 equ CRC-Seed \ Good initial value for CRC calculation.
Code CRC-16 \ crc char --- new_crc ;
EXX
BC POP \ Contains new data byte in C DE POP \ Contains old CRC HL, # 0 LD \ Define Work Area
A, E LD \ XOR bottom 8 bits of old CRC with data byte A, C XOR E, A LD
A, H LD \ Swap bottom 8 bits of CRC with top 8 bits of H, E LD \ Work Area E, A LD
A, D LD \ Swap top 8 bits of CRC with bottom 8 bits D, E LD E, A LD
PE, L1 JP \ If parity of XOR even, miss out the CRC XOR
A, D LD \ XOR the CRC with C001H A, # C0 XOR D, A LD
A, E LD A, # 01 XOR E, A LD
L: L1
SCF \ Right shift the CRC and then XOR it with work area CCF
H RR L RR
A, D LD A, H XOR D, A LD
A, E LD A, L XOR E, A LD
SCF \ Right shift the CRC and then XOR it with work area CCF \ again
H RR L RR
A, D LD A, H XOR D, A LD
A, E LD A, L XOR E, A LD
DE PUSH \ Shove the new CRC back on the stack
EXX NEXT,
End-code
participants (3)
-
John Robertson -
Phillip Eaton -
Zonn