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 ...