[Techtoolslist] Cracking the 9010/9100 ROM signature

[John Robertson]

I've fielded some inquiries about how the Fluke Signature was generated 
and realizing that not everyone has ALL the TTL emails (75mb in 
Thunderbird format) on their computer (the archives are a bit cumbersome 
to search) so I'm reseeding this message from 2003 - the subject line is 
the search you want to do if you are interested in how the 9010A 
signature was cracked - "Cracking the 9010A ROM signature generator" in 
2002 and 2003.

In 2010 Martin White got interested in cracking the 9100 signature 
(subject "9100 ROM Signature Algorithm") but nothing seemed to come of 
that I'm afraid...

John :-#)#

John Robertson wrote:

> It's been a while since I last looked at this, and some others have 

> been attempting it as well. Just curious if anyone got any further and 

> forgot to post results?

>

> I have a nice Arium ML4400 logic analyzer so if anyone has some 

> suggestions I'd be happy to take this up again.

>

> John :-#)#

>

> At 06:31 PM 10/06/2002 -0700, John Robertson wrote:

>> It is on Spies:

>>

>> http://www.spies.com/arcade/.TE/9010CourseNotes.pdf

>>

>> Note that AL does NOT want anyone posting links to his site on any 

>> newsgroup....

>>

>> John :-#)#

>>

>>

>>>> More on this - reading the 9010A Troubleshooting Seminar - Student 

>>>> Workbook # 805663 (1985), I find a reference to Rom Signatures. "To 

>>>> develop a ROM signature, the data is 'compressed' into a 4 digit 

>>>> hexadecimal number by passing all the ROM data through a /two-stage 

>>>> CRC type/ (this is new info for us!) of signature algorithm"

>>>>

>>>> I recommend that any student of the 9010A print this booklet out 

>>>> and read it thoroughly. I am constantly finding neat tid-bits that 

>>>> are not nearly as well covered in the Operators Manual. For example 

>>>> - how the probe interfaces with the UUT. If you use the synchronize 

>>>> function then the probe ONLY shows activity during valid Read/Write 

>>>> periods. Also the Probe pulse can be synchronized with the R/W.

>>>>

>>>> A lot of other useful training is there.

>>>>

>>>> ftp://www.flippers.com/Fluke

>>>>

>>>> I can send copies of the Workbook to anyone that needs one. I 

>>>> believe it is about 12 megs....My space is limited on my server

>>>>

>>>> John :-#)#

>>>>

>>>>> Further digging, and watching the Fluke 9010 Training video (Fluke 

>>>>> 9010Training1.RM minutes 40 - 46) leads me to believe that this is 

>>>>> a mathematical function called a Pseudorandom Binary Sequence. It 

>>>>> looks to me as if Fluke adopted HP's Signature standard of a 

>>>>> sixteen-bit register with the feedback form of X(16) + X(12) + 

>>>>> X(7) + 1.  (One of 2048 possible feedback taps, the computer 

>>>>> industry uses CRC-16 X(16) + X(15) + X(2) + 16 or CCITT-16 X(16) + 

>>>>> X(12) + X(5) + 1 commonly... ) A bit hairy to dig out of the code 

>>>>> I am sure!

>>>>>

>>>>> I think this work is done in the base unit, the pod just streams 

>>>>> the data into it.

>>>>>

>>>>> I believe that they use a software PBSC generator that takes each 

>>>>> BIT and pushes it through the sixteen-bit register (above)... I 

>>>>> wonder if this is similar to how ROMIDENT works?

>>>>>

>>>>> So now I am looking at making a simple Fluke Checksum program to 

>>>>> run like this:

>>>>> ----------------------------------------------------------------------

>>>>> Display - Checksum Test - Select Range

>>>>> Display - Beginning of ROM

>>>>> Dis...    -  End of ROM

>>>>>

>>>>> Begin  (Label 1)

>>>>> Go to 1st ROM location

>>>>> Add ROM byte to data memory location

>>>>> Increment ROM address by 1

>>>>> Is this > End of ROM?

>>>>> If not then goto Begin

>>>>>

>>>>> Display Checksum (read Data memory location)

>>>>> END

>>>>> -----------------------------------------------------------------

>>>>>

>>>>> At the moment I don't know how to take a Byte of data and add it 

>>>>> to the previous one (Within the Fluke script). Have a simple 

>>>>> script that asks for the beginning and ending address, then chugs 

>>>>> through the ROM...just haven't figured out the additive (in the 

>>>>> Checksum meaning) process with Fluke Script.

>>>>>

>>>>> Any suggestions?

>>>>>

>>>>> John :-#)#

>>>>>

>>>>>

>>>>>

>>>>> At 05:50 PM 11/08/01, you wrote:

>>>>>> The signature (I can't call it a checksum..;-) is the same no 

>>>>>> matter where the memory location is (tried 0000 & 0001, then 0154 

>>>>>> & 0155 for example-same results) with a 6800 pod on a different 

>>>>>> test bed (Heathkit 6800 trainer) and 9010A (shop) base unit.

>>>>>>

>>>>>> The first results were with a 6802 pod on an old Heathkit 6802 

>>>>>> trainer and my 9010A that is at home.

>>>>>>

>>>>>> Looks to me like the process is something like this, take the 8 

>>>>>> bit byte, reverse the last four bits order and exchange it with 

>>>>>> the first four bits. Add a 1 to the least significant bit if 

>>>>>> odd... Shall dig around some more and try other combinations.

>>>>>>

>>>>>> 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 02:55 PM 11/08/01, you wrote:

>>>>>>> I've done some dissassembly on the code for both the pod and the 

>>>>>>> base, and

>>>>>>> have to agree with David, whatever it was written in had an awful

>>>>>>> compiler! - It's not easy tracking down anything, since the code 

>>>>>>> is so

>>>>>>> illogical!

>>>>>>>

>>>>>>> the code in the pod is a little more understandable, but only 

>>>>>>> just, and not

>>>>>>> understanding (yet) how the pod communicates to the UUT makes ot 

>>>>>>> difficult

>>>>>>> to follow as well.

>>>>>>>

>>>>>>> My next step in the attack on understanding the code is to try 

>>>>>>> and create an

>>>>>>> emulator for the pod software, at least then I may be able to 

>>>>>>> trap all of

>>>>>>> the reads/writes that communicate with the pod (I need to know 

>>>>>>> this for a

>>>>>>> later project anyway!) - hopefully, seeing the data transfers 

>>>>>>> may help gain

>>>>>>> understanding in how the entire thing works

>>>>>>>

>>>>>>> from your examples, it certainly follows no checksum algorithm I 

>>>>>>> know of,

>>>>>>> reversing the bit pattern either needs a lookup table (which I 

>>>>>>> will check

>>>>>>> for in a minute) or some nasty calculations (which again, should be

>>>>>>> obvious!). I'm going to have another troll though the 48k of 

>>>>>>> code looking

>>>>>>> for anything that may implement such things.

>>>>>>>

>>>>>>> just out of interest, does the 6502 pod (or another 8 bit pod) 

>>>>>>> generate the

>>>>>>> same checksum, and secondly, does it generate the same checksum 

>>>>>>> for the same

>>>>>>> data at a different address ?

>>>>>>>

>>>>>>>

>>>>>>>  To UNSUBSCRIBE from techtoolslist, send a message with 

>>>>>>> "UNSUBSCRIBE" in the

>>>>>>>  message body to: techtoolslist-request at flippers.com. Please 

>>>>>>> direct other

>>>>>>>  questions, comments, or problems to jrr at flippers.com.



-- 
John's Jukes Ltd. 2343 Main St., Vancouver, BC, Canada V5T 3C9 
Call (604)872-5757 or Fax 872-2010 (Pinballs, Jukes, VideoGames)
                 www.flippers.com 
"Old pinballers never die, they just flip out"