Ah yes but what are you using for a seed file for the CRC 16 /32 calculators? I belive the Fluke version is possibly based on some of the original articles that were in BYTE circa 1983. I'll need to research that a bit more. Kev
Still looking for this one - what is the algorithm used to generate the ROM Signature in the 9100/9010s? Have tried almost all the CRC programs I could download, none were correct. It's not CRC-16, CRC-32, CCITT, CHECKSUM....
Anyone get any further?
Attached is the file that I used to try and identify the signature and these are the results:
CRC-16 =58B8 CRC-32 =C1E6AB10 CCITT =E63C
(the "Correct" Fluke signature is = 8B1A)
The file is from a video game, it's a 4K size chunk of the main program...
John :-#)#
Seed file? I used the Pacman 6E as I recall. Just ran the calculator utility included with Hexedit (http://www.expertcomsoft.com/) a nice windows file editor - search and replace etc... There was mention that the signature was created using "The ROM signature is obtained by successively dividing the data in ROM by a binary number" in the manual as you may recall...what order would the data be divided? Would this matter? John :-#)# At 11:38 PM 12/10/2002 -0400, Kev wrote:
Ah yes but what are you using for a seed file for the CRC 16 /32 calculators?
I belive the Fluke version is possibly based on some of the original articles that were in BYTE circa 1983. I'll need to research that a bit more.
Kev
Still looking for this one - what is the algorithm used to generate the ROM Signature in the 9100/9010s? Have tried almost all the CRC programs I could download, none were correct. It's not CRC-16, CRC-32, CCITT, CHECKSUM....
Anyone get any further?
Attached is the file that I used to try and identify the signature and these are the results:
CRC-16 =58B8 CRC-32 =C1E6AB10 CCITT =E63C
(the "Correct" Fluke signature is = 8B1A)
The file is from a video game, it's a 4K size chunk of the main program...
John :-#)#
I have found a nice CRC web site that allows one to change many of the settings of the CRC to try out various polynomials. http://www.gpfn.sk.ca/~rhg/csc8550s02/crc.html I've been tossing in a few numbers at random to see if I can see what variation of the CRC-16 polynomial it is. I believe that Fluke used the standard CRC-16 formula with a preset CRC value as there is mention in the docs about dividing the data into a fixed number. Now to figure out the number... I'm just using an old posting of mine where I tried some two byte data chunks on the Fluke ROM Signature generator...but I'm not getting very far yet. I don't know how to solve hexadecimal polynomial problems...considering that we pretty much know the formula X16 + X15 + X2 + 1, and the data and the result, but the mystery "binary number" is the tricky bit ... I'm way too rusty (like 30 years since I last did this) to figure this one out without a bit of help... Sig. - DATA (two bytes) 93D0 - FF 00 9351 - FF 01 9390 - FF 02 9311 - FF 03 ..... 93AF - FF FE 932E - FF FF John :-#)# At 10:45 PM 12/10/2002 -0700, John Robertson wrote:
Seed file? I used the Pacman 6E as I recall. Just ran the calculator utility included with Hexedit (http://www.expertcomsoft.com/) a nice windows file editor - search and replace etc...
There was mention that the signature was created using "The ROM signature is obtained by successively dividing the data in ROM by a binary number" in the manual as you may recall...what order would the data be divided? Would this matter?
John :-#)#
At 11:38 PM 12/10/2002 -0400, Kev wrote:
Ah yes but what are you using for a seed file for the CRC 16 /32 calculators?
I belive the Fluke version is possibly based on some of the original articles that were in BYTE circa 1983. I'll need to research that a bit more.
Kev
Still looking for this one - what is the algorithm used to generate the ROM Signature in the 9100/9010s? Have tried almost all the CRC programs I could download, none were correct. It's not CRC-16, CRC-32, CCITT, CHECKSUM....
Anyone get any further?
Attached is the file that I used to try and identify the signature and these are the results:
CRC-16 =58B8 CRC-32 =C1E6AB10 CCITT =E63C
(the "Correct" Fluke signature is = 8B1A)
The file is from a video game, it's a 4K size chunk of the main program...
John :-#)#
<snip>
I don't know how to solve hexadecimal polynomial problems...considering that we pretty much know the formula X16 + X15 + X2 + 1, and the data and the result, but the mystery "binary number" is the tricky bit ...
John :-#)#
The 'mystery "binary number"' is... Pi
I brute forced every possible mask and every possible CRC seed value for 16 bit CRC, using the standard polynomial feedback, and nothing worked. I was able to find matches for 2 different values but never a third: For instance, using 0x4080 as the polynomial feedback, and an initial value of 0x3513, and then inverting the CRC results I could get: 93D0 - FF 00 9351 - FF 01 but, 92D2 - FF 03 I could find matches for every pair I tried (I didn't try them all), but could find anything that allowed a third match. FWIW: Any of these 16 bit CRCs can be cracked with a 32meg lookup table (not really that un-doable given today's computers, this is after all, only the size of a small Compact Flash Card.) Starting with any 16 bit CRC, and any 8 bit value: Given the same starting 16 bit value and the same 8 bit value, the results will always be the same 16 bit results. So given 65536 lookup tables, with 256 (word) entries per table, any 16 bit CRC can be cracked. The trick would be to write some type of Fluke program that can dump all possible, 16 million, values to a hard drive (and let it run for a while). You would need some type of program that would give you: Start|Byte| Results -------------------- 0000 00 = ???? 0000 01 = ???? . . . 0000 FF = ???? 0001 00 = ???? . . . etc. Note that the program would not have to dump them in sequential order. The software after that would be a breeze. FWIW: If it is possible to calculate these CRCs 1 bit at a time (like the way *real* CRCs work), the lookup table would only need to be 256k. (65536 lookup tables with only two word entries for each table, one entry for 0, the other for 1.) The Fluke program would have to dump: Start|Bit| Results -------------------- 0000 0 = ???? 0000 1 = ???? 0001 0 = ???? 0001 1 = ???? . . . etc Finding the right algorithm is obviously a better solution, but the above would crack *any* 16 bit CRC. Just something to think about... -Zonn On Sun, 13 Oct 2002 20:11:19 -0700, John Robertson <jrr@flippers.com> wrote:
I have found a nice CRC web site that allows one to change many of the settings of the CRC to try out various polynomials.
http://www.gpfn.sk.ca/~rhg/csc8550s02/crc.html
I've been tossing in a few numbers at random to see if I can see what variation of the CRC-16 polynomial it is. I believe that Fluke used the standard CRC-16 formula with a preset CRC value as there is mention in the docs about dividing the data into a fixed number. Now to figure out the number... I'm just using an old posting of mine where I tried some two byte data chunks on the Fluke ROM Signature generator...but I'm not getting very far yet.
I don't know how to solve hexadecimal polynomial problems...considering that we pretty much know the formula X16 + X15 + X2 + 1, and the data and the result, but the mystery "binary number" is the tricky bit ... I'm way too rusty (like 30 years since I last did this) to figure this one out without a bit of help...
Sig. - DATA (two bytes) 93D0 - FF 00 9351 - FF 01 9390 - FF 02 9311 - FF 03 ..... 93AF - FF FE 932E - FF FF
John :-#)#
At 10:45 PM 12/10/2002 -0700, John Robertson wrote:
Seed file? I used the Pacman 6E as I recall. Just ran the calculator utility included with Hexedit (http://www.expertcomsoft.com/) a nice windows file editor - search and replace etc...
There was mention that the signature was created using "The ROM signature is obtained by successively dividing the data in ROM by a binary number" in the manual as you may recall...what order would the data be divided? Would this matter?
John :-#)#
At 11:38 PM 12/10/2002 -0400, Kev wrote:
Ah yes but what are you using for a seed file for the CRC 16 /32 calculators?
I belive the Fluke version is possibly based on some of the original articles that were in BYTE circa 1983. I'll need to research that a bit more.
Kev
Still looking for this one - what is the algorithm used to generate the ROM Signature in the 9100/9010s? Have tried almost all the CRC programs I could download, none were correct. It's not CRC-16, CRC-32, CCITT, CHECKSUM....
Anyone get any further?
Attached is the file that I used to try and identify the signature and these are the results:
CRC-16 =58B8 CRC-32 =C1E6AB10 CCITT =E63C
(the "Correct" Fluke signature is = 8B1A)
The file is from a video game, it's a 4K size chunk of the main program...
John :-#)#
More numbers...I've tried using my Arium ML4100 to disassemble the 9010's ROM process but it (the 4100) just croaked. So I thought maybe a real simple code would give some clues. What I did was to write to RAM 00 = 01, then the RAM from 01 - 0F is all 00. Then I read the Signatures - here are the results: Start/Finish Signature 00/01 D9E1 00/02 D9E1 00/03,04,05 D9E1 00/06,07 2C97 00/08,09,0A D81D 00/0B 536A 00/0C,0D,0E 2403 00/0F A7DA So, it appears that there is a minimum size of ROM Signature that might be valid. I'm going to fire up my other 4100 when I bring it home tomorrow and see if I can trace it that way. There did seem to be a thread of disassembly that was interesting but I am no code jockey. Just a hacker, moi. John :-#)# Anyone with any bright ideas? I've tried a few algorithms with no success. At 10:41 PM 13/10/2002 -0700, zonn@zonn.com wrote:
I brute forced every possible mask and every possible CRC seed value for 16 bit CRC, using the standard polynomial feedback, and nothing worked.
I was able to find matches for 2 different values but never a third:
For instance, using 0x4080 as the polynomial feedback, and an initial value of 0x3513, and then inverting the CRC results I could get:
93D0 - FF 00 9351 - FF 01
but,
92D2 - FF 03
I could find matches for every pair I tried (I didn't try them all), but could find anything that allowed a third match.
FWIW: Any of these 16 bit CRCs can be cracked with a 32meg lookup table (not really that un-doable given today's computers, this is after all, only the size of a small Compact Flash Card.)
Starting with any 16 bit CRC, and any 8 bit value:
Given the same starting 16 bit value and the same 8 bit value, the results will always be the same 16 bit results.
So given 65536 lookup tables, with 256 (word) entries per table, any 16 bit CRC can be cracked.
The trick would be to write some type of Fluke program that can dump all possible, 16 million, values to a hard drive (and let it run for a while).
You would need some type of program that would give you:
Start|Byte| Results -------------------- 0000 00 = ???? 0000 01 = ???? . . . 0000 FF = ???? 0001 00 = ???? . . . etc.
Note that the program would not have to dump them in sequential order.
The software after that would be a breeze.
FWIW: If it is possible to calculate these CRCs 1 bit at a time (like the way *real* CRCs work), the lookup table would only need to be 256k. (65536 lookup tables with only two word entries for each table, one entry for 0, the other for 1.)
The Fluke program would have to dump:
Start|Bit| Results -------------------- 0000 0 = ???? 0000 1 = ???? 0001 0 = ???? 0001 1 = ???? . . . etc
Finding the right algorithm is obviously a better solution, but the above would crack *any* 16 bit CRC. Just something to think about...
-Zonn ...
Not sure how many of you guys have a Midway tester, but I've scanned the manual and archived the roms for it on my tips page. http://www.vidpin.com/tips.asp I have also included the Williams tech series Recap guides. I've got the Defender ones done. I will have the Stargate / Robotron and the Sound & Speech one done in the next couple of days. If any of you have the corresponding video tapes for these I'd be VERY intrested in getting a copy. Hope these help ya! Callan.
Okay... Robotron /Stargate, and Sound and Speech are up. http://www.vidpin.com/tech_videorecap.asp Enjoy. Callan. ----- Original Message ----- From: "Vidpin Amusements" <callan@vidpin.com> To: <techToolsList@flippers.com> Sent: Sunday, October 20, 2002 3:04 PM Subject: Video Recap Guides - Midway Tester
Not sure how many of you guys have a Midway tester, but I've scanned the manual and archived the roms for it on my tips page.
http://www.vidpin.com/tips.asp
I have also included the Williams tech series Recap guides. I've got the Defender ones done. I will have the Stargate / Robotron and the Sound & Speech one done in the next couple of days.
If any of you have the corresponding video tapes for these I'd be VERY intrested in getting a copy.
Hope these help ya!
Callan.
I posted a note on the newsgroup alt.crypto and a fellow responded with a great web address for understanding the structure of CRCs, http://www.repairfaq.org/filipg/LINK/F_crc_v32.html is the page I am studying now. Next I plan to re-assemble a working ML4100 so I can trace the handling of a simple few numbers as read from the pod and see what happens to them. The division by a number is part of the CRC calculation, but there might be a need to have "W" zeros added to the string before the division is done. So I shall be looking for that to see if this is how it is done. I wonder if there is a minimum length of data before the signature is actually valid. It might be that they used 8 or 16 bytes as the minimum size of the data filed to be divided by the polynomial. John :-#)# At 12:43 PM 20/10/2002 -0700, John Robertson wrote:
More numbers...I've tried using my Arium ML4100 to disassemble the 9010's ROM process but it (the 4100) just croaked. So I thought maybe a real simple code would give some clues. What I did was to write to RAM 00 = 01, then the RAM from 01 - 0F is all 00. Then I read the Signatures - here are the results:
Start/Finish Signature 00/01 D9E1 00/02 D9E1 00/03,04,05 D9E1 00/06,07 2C97 00/08,09,0A D81D 00/0B 536A 00/0C,0D,0E 2403 00/0F A7DA
So, it appears that there is a minimum size of ROM Signature that might be valid. I'm going to fire up my other 4100 when I bring it home tomorrow and see if I can trace it that way. There did seem to be a thread of disassembly that was interesting but I am no code jockey. Just a hacker, moi.
John :-#)#
Anyone with any bright ideas? I've tried a few algorithms with no success.
At 10:41 PM 13/10/2002 -0700, zonn@zonn.com wrote:
I brute forced every possible mask and every possible CRC seed value for 16 bit CRC, using the standard polynomial feedback, and nothing worked.
I was able to find matches for 2 different values but never a third:
For instance, using 0x4080 as the polynomial feedback, and an initial value of 0x3513, and then inverting the CRC results I could get:
93D0 - FF 00 9351 - FF 01
but,
92D2 - FF 03
I could find matches for every pair I tried (I didn't try them all), but could find anything that allowed a third match.
FWIW: Any of these 16 bit CRCs can be cracked with a 32meg lookup table (not really that un-doable given today's computers, this is after all, only the size of a small Compact Flash Card.)
Starting with any 16 bit CRC, and any 8 bit value:
Given the same starting 16 bit value and the same 8 bit value, the results will always be the same 16 bit results.
So given 65536 lookup tables, with 256 (word) entries per table, any 16 bit CRC can be cracked.
The trick would be to write some type of Fluke program that can dump all possible, 16 million, values to a hard drive (and let it run for a while).
You would need some type of program that would give you:
Start|Byte| Results -------------------- 0000 00 = ???? 0000 01 = ???? . . . 0000 FF = ???? 0001 00 = ???? . . . etc.
Note that the program would not have to dump them in sequential order.
The software after that would be a breeze.
FWIW: If it is possible to calculate these CRCs 1 bit at a time (like the way *real* CRCs work), the lookup table would only need to be 256k. (65536 lookup tables with only two word entries for each table, one entry for 0, the other for 1.)
The Fluke program would have to dump:
Start|Bit| Results -------------------- 0000 0 = ???? 0000 1 = ???? 0001 0 = ???? 0001 1 = ???? . . . etc
Finding the right algorithm is obviously a better solution, but the above would crack *any* 16 bit CRC. Just something to think about...
-Zonn ...
participants (5)
-
John Robertson -
Kev -
Mark Shostak -
Vidpin Amusements -
zonn＠zonn.com