<x-flowed>
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 Sun Oct 20 14:08:54 2002
This archive was generated by hypermail 2.1.8 : Tue Dec 02 2003 - 18:40:49 EST