TechTools Archives: Re: Cracking the 9010A ROM signature generat

From: John Robertson <jrr_at_flippers.com>
Date: Mon Jun 10 2002 - 17:35:23 EDT

<x-html>
<html>
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. 
<a href="ftp://www.flippers.com/Fluke" eudora="autourl">ftp://www.flippers.com/Fluke</a>
 
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 :-#)# 
<blockquote type=cite class=cite cite>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: 
<blockquote type=cite class=cite cite>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: 
<blockquote type=cite class=cite cite>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@flippers.com. Please direct other 
 questions, comments, or problems to jrr@flippers.com.</blockquote></blockquote></blockquote></html>

</x-html>
Received on Mon Jun 10 20:00:39 2002

This archive was generated by hypermail 2.1.8 : Tue Dec 02 2003 - 18:40:45 EST

Re: Cracking the 9010A ROM signature generator