Re: Fluke Signatures....

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

</x-flowed>
Received on Tue Oct 22 00:16:00 2002