Reversing The Encoding Of Serial Numbers In PALs or GALs

[dexters_lab]

I have a number of JEDEC files here for the PAL/GAL 20V8 that encode a serial number into the logic array and i would like to figure out how the serial number is encoded so i can create new ones with new serial numbers.

These GAL20V8's are used in a 30 year old quantel paintbox to give each machine a unique serial number and i think it's also used to perform some kind of de-encryption of the software license keys. I found in a stash of these devices i acquired, that what Quantel call a 'SecurityPAL', it seems that someone at quantel was not doing their job properly and forgot to set the no readback fuse on them so i have several images of valid ICs.

I should point out that Quantel (who don't even exist anymore as Quantel) stopped servicing these old machines decades ago & the industry does not use them anymore so i doubt this exercise will create any legal issues.

The serial number is never any longer than 5 digits and there can be two serial numbers encoded.

If anyone fancies a friday challenge, i have attached the read out data, the challenge now is for someone to tell me how they are encoding the serial number into the array! 

The filename is the serial number encoded into the IC and also printed on the label stuck to each IC.

I have  also attached a segment of the schematic showing how it's inputs are wired to the CPU address lines A1-A13, outputs are 8 bit onto the data bus. The system is a motorola 68k architecture.

We're also tackling this from the software side too, disassembling the code that reads the PAL but that is work in progress.

any thoughts would be appreciated!!

[mikeselectricstuff]

ISTR you saying some units used a 20L8 - if so it has to be pretty simple as this device has no internal registers

If you look at the architecture of the device, the number has to be encoded as inputs, not outputs.
e.g. for the simplest case, and assumomng a 16 bit number space it could be there are 4 'bit select' inputs, and it outputs one bit of the number, selected by the select inputs  via one output.
Obviosuly there could be some obfuscation by XORing etc., but it could NOT be something lie a LSFR shift-register.

With a 20V8 it could be a little more complex, worst-case you may have outouts enabled by an obscure sequence, but from memory I don't think the  20V8 can have buried internal state that can feed back to the matrix.

Of course it could be that there is no actual relationship between the number and the PAL contents and they had a database.

If you can find something like a PAL disassembler it should be possible to figure it out.
But as you have a working unit, it would be good to poke about the pins with a scope or logic analyzer to see if you can figure anything out, if only which pins are used.

[mikeselectricstuff]

Just noticed the schematic - it looks like it's just being used as a PROM.
My guess is most of the address lines are a decode, and a subset will be a word select.
As it isn't possible for it to be feeding back any state to internal registers (e.g. to read different things on multiple reads)  I think simply cycling through all the addresses would reveal the PROM contents.

In the absence of a JEDEC disassembler, You _could_ do it by manually decoding the JEDEC file, but would probably be quicker to read the devices like a PROM. If you have access to an EPROM programmer, make up a header to map the pins to an EPROM of suitable size. Or lash up some simple hardware to step through the addresses & spit out the data.

[stj]

there is an old dos program called "JED2BEQ",
infact there are several versions of it - it was included with logic compilers like "PLAN"

[dexters_lab]

thanks Mike

your probably right about the PROM thoughts, i have just burned one of those serials onto a new GAL and the machine picks the new serial number up just fine so i doubt there is a database of patterns

time to have another play

[CJay]

Grab a copy of OPALJR21 from various places, it's got a nice command line utility which takes the .jed files you uploaded and spits out a .eqn file which should be simpler to simulate.

Also worth a look, open two files in notepad, cut out the duplicated lines and you're left with what might reasonably be the serial number, it at least removes the deadwood.

Attached the .eqn for 12360

[mikeselectricstuff]

Grab a copy of OPALJR21 from various places, it's got a nice command line utility which takes the .jed files you uploaded and spits out a .eqn file which should be simpler to simulate.

Also worth a look, open two files in notepad, cut out the duplicated lines and you're left with what might reasonably be the serial number, it at least removes the deadwood.

Attached the .eqn for 12360

Unless the number is blindingly obvious You'd probably want to compare all of them as you may gave 2 files with the same values in some bit positions

[dexters_lab]

having never touched PALs or GALs before this is out of my league now.

A friend of mine is helping with this side of it, Ash... he's going to post in a moment

meanwhile i will look at trying to read one of them as a rom in the TL-866 and see what it spits out

[OzOnE]

Hi, mike / all,

(I still have that Photo-multiplier tube I bought from you on eBay btw. Still not sure what to build with it though. lol)

I've been helping Mr Dexter to reverse the GALs / PALs, and already used OPALJR to convert the JED files to EQN logic equation files.

(I may have been partly responsible for the current "snowball effect" of Quantel stuff, after I sent Mr Dexter my Quantel V-Series "Harriet" system in a swap for the NAC High-speed camera. lol)


I translated the EQN file for one of the GALs (with the 12360 serial number) to Verilog, by just changing the logical operators to the Verilog ones.
I then ran that on the DE1 dev board, since it's easier to just run the thing and debug via SignalTap rather than using that evil ModelSim simulator.

It does indeed look like it's just using the GAL as a simple PROM, as the address bus from the 68000 very likely comes from an always-enabled buffer, so it's not doing anything fancy there.
The /ALEC input is just an /Output-Enable by the looks of it, and the EQN files seem to confirm that theory.

We're fairly confident that the schematic from the newer Paintbox uses the same GAL pinout for the GAL as the older "Harriet" style systems do.
Mr Dexter has also read the GAL from the other similar Harriet system too, so that's a good confirmation that all the chips work the same way.

When I ran through all the addresses on the dev board, the outputs hardly ever changed at all, so I'm thinking there may be an issue with just doing a direct translation to Verilog.
I can't see why though tbh, as the logic terms only consist of rows of AND gates, and a few ORs in-between each row? It's also working on single-bit wide input signals too, of course.

I've just tidied up the Verilog a tad, and it looks like a pretty simple ROM type layout...

http://imgur.com/a/aJn3y


I've attached the original EQN file for the "12360" serial GAL too, and that was converted using the OPALJR tool.
The logic at least seems to tally with that newer schematic, and it doesn't look like it's using the registers nor registered-outputs at all.

OzOnE. (ElectronAsh on YouTube.)

[CJay]

Grab a copy of OPALJR21 from various places, it's got a nice command line utility which takes the .jed files you uploaded and spits out a .eqn file which should be simpler to simulate.

Also worth a look, open two files in notepad, cut out the duplicated lines and you're left with what might reasonably be the serial number, it at least removes the deadwood.

Attached the .eqn for 12360

Unless the number is blindingly obvious You'd probably want to compare all of them as you may gave 2 files with the same values in some bit positions

My bad, what I should have said was 'what might reasonably be the serial number or a portion of it', we only need to worry at the moment about the differences, if we can work on those and figure out how to alter the serial in a predictable way by changing the differing lines then we can expand that to the rest of the data and see if it 'fits' with the other files.

Won't take more than a few iterations to see if it's a reasonable approach.

[OzOnE]

Just mentioned the PROM / TL866 thing to Mr Dexter before reading your post, Mike. Great minds. :p


The data output hardly seems to change at all when I run the Verilog on the dev board?

If we can see the ROM reader output, it will confirm that I'm converting it correctly.
I'm doubtful that I have tbh, as I would have expected the data output to change on almost every address?


It's possible that was intentional though, or just the way their algo for the serial number works?

While looking at the routines in the 68000 disassm (IDA Pro), it does look like it's doing some basic XOR stuff from a given input string and a "Copyright (c) Quantel...." string.
I'll have a look to see where it reads the serial number too, as I don't think we've checked that code yet.

Hopefully it just sends a fixed string to the "VerifySecurityPAL" routine, and then that spits out the serial number in the same way as it would scramble / de-scramble any other fixed string.
That routine seems to be the only place where it ever reads from the PAL though, so there's hope.

I did start to get the V-Series / Harriet 32K ROM monitor to boot by adding some skeleton code to MAME too.
That allows me to step through the code and see what each routine does, so should come in handy.

I did a similar thing for the older classic Paintbox about 3 years ago now...


That DPB-7001 (from the BBC) is now in the possession of Mr Dexter too, as some of you have no doubt noticed. lol
We still have yet to get that damned thing to boot either.

The only machine I had that was booting fully was the previous V-Series "Harriet" unit from over a year ago.

The unit I sent to Mr Dexter was actually attempting to boot for the first two or three times I powered it up.
I was then simply trying to get into the ROM monitor via the serial port to quickly note down the passwords in there.

To do that, I had to lift the lid on the unit just a tad, flip the hex switch to the "0" position, then boot it up again.
The damned thing then refused to boot into the "desktop" after that, and would only give a Bus Error.

(#spoilers - Mr Dexter since found out that it was the video board causing that, so it must have just died due to old age / bad tant caps, or a bad buffer IC?)

So then the "incident" with the original GAL chip occurred, and that's where we are now.


OzOnE. (ElectronAsh on YouTube.)

[mikeselectricstuff]

Pretty straghtforward. Each line is a bunch of terms ANDED, with the lines ORed to produce the result
Looks like there are seven high-order addresses. Each line represents the output of that bit for each address
It may be that they are effectively encoding an input function on some of the lower-order addresses, so there may be quite a few "valid" addresses within the address space, but for each data bit, there will only be seven addresses within the whole address space (ignoring duplicates from unused address bits) that return a '1'

Each line will return a "1" for the address where Ax is '1' and /Ax is '0'

e.g.

Code: [Select]

D0 =  /A12 * /A13 * /A11 * A10 * /A9 * /A8 * /A7 * A6 * A5 * A4 * /A1 * A3  * A2    outputs '1' when Address = 0001000111110X
    + /A12 * /A13 * A11 * /A10 * /A9 * /A8 * A7 * A6 * A5 * A4 * /A1 * A3  * /A2      outputs 1 when    address= 0010001111100X
    + /A12 * /A13 * A11 * /A10 * A9 * A8 * A7 * /A6 * /A5 * /A4 * A1 * /A3 * /A2                                                   0010111000001X               
    + A12 * /A13 * /A11 * /A10 * A9 * /A8 * /A7 * /A6 * A5 * A4 * A1 * /A3 * A2                                                    0100100011011X
    + A12 * /A13 * /A11 * /A10 * A9 * A8 * /A7 * /A6 * /A5 * A4 * A1 * /A3 * A2                                                    0100110001011X
    + A12 * /A13 * /A11 * A10 * A9 * A8 * A7 * A6 * A5 * /A4 * A1 * /A3    * /A2                                                   0101111110001X
    + A12 * /A13 * A11 *  A10 * /A9 * /A8 * A7 * A6 * /A5 * /A4 * A1 * /A3  * /A2                                                  0111001100001X


[OzOnE]

Hi, CJay.

Do you think my "translation" of the EQN to Verilog was a tad optimistic? lol

It literally only seems to change about ten bytes in the whole address range?
All the other bytes stay at 0x00, so that's either the way the PALs worked in the first place, or I'm way off with my conversion?

Do you know of any software which could just simulate the GAL chip outputs directly?

It's strange though, as Mr Dexter has now written the JED file back to a blank GAL, and that is indeed reading the serial number just fine (whether directly, or via the usual VerifySecurityPAL routine, which I still need to double-check).

The issue of course is that the serial on these working PALs no long match the passwords on the system (which IIRC, are stored on the HDD in the main OS file.)

This is fun at least.
I love investigating / reversing things like this.

OzOnE. (ElectronAsh on YouTube.)

[OzOnE]

Mike - do you mean you would expect only several bytes to change at all in the address space (which is what I'm seeing so far)?

All the rest on the Verilog run seem to output 0x00?

The output data looks very sparse indeed, but that could be my simple conversion to Verilog was flawed...

http://imgur.com/a/gxese

[OzOnE]

Actually, good point.

I'll go through now, and just change the logic terms into something more readable.

ie. change the input address bits into the Hex equivalents.

[mikeselectricstuff]

See amended post above. Due to the architecture, each bit will only be '1' at seven addresses within the space.
I suspect they are encoding data on the address bus. Just needs the common adddresses ( same for each bit & line) to be eliminated, then some turning inside-out ( reorder list by content) to make it look more meaningful 

[mikeselectricstuff]

To clarify above turning inside out  - once you have stripped the upper addresses, say you get a list like this ( abbreviated0
'1' at the following adddresses :
000 = 0
010 = 2
100 = 4
111  = 7

This would convert to the following for that bit
Adddress / data
0  1 ( '1' at address 0 position)
1  0
2  1 ('1' at addr 2 position)
3  0
4  1
5  0
6  0
7  1

Once you do that I suspect you may get something that correlates to the number.

You may be able to deduce something from how the system behaves - e.g. is it a case that it 'tests' a number coded into teh software and gets a yes/no answer, or can it actually read and ddisplay the number of the installe chip ? If the latter it would have to scan through the whole address space

[OzOnE]

Ahh - I see what you mean.

I didn't spot that at all. lol

Only seven terms for each bit, so only seven possible addresses where that bit would go High.
That does seem to confirm the Verilog then, and it only outputs a byte other than zero at a handful of addresses.

From what I've seen of the Verify routine, it looks like it may be cycling through 0-9 while it's incrementing the address to the PAL (and doing a few other things which we're not quite sure about yet).

My knowledge of 68K Asm is a tad lacking, so it's not intuitive yet, and takes me a while to figure it out.
The last time I really got stuck into it was while trying to bypass a password on a certain airport X-Ray scanner.


OK, I'm just converting all the rows of logic terms to binary (or hex)...

OzOnE.

[OzOnE]

@Mike - yep, it's looking like the whole thing could be done with a fairly short list of terms, and that may mean the serial number really is just encoded onto a few bits.

I was expecting it to do far more scrambling / checksum type stuff than that, but I guess they weren't trying to be super-secure?

It has at least managed to cause us a few headaches already, so it did it's job. lol

EDIT: Worth noting that the address bits on the "PAL" starts at A1, as in a lot of 68K-based systems (with no /UDS nor /LDS hooked up to the "ROM").
So, if you read each address in turn with Byte instructions, the same output data would probably appear twice?

When read in 16-bit Word mode, the output from the PAL should just be mapped to the lower 8-bits, of course.

Although I believe the Byte and Word routines on the serial monitor do spit out the values correctly.
We did try reading the PAL back via the serial commands yesterday, but it looked like it may have been locked out by another register? Or, Mr Dexter just had to hit the Enter key a few hundred more times. :p

OzOnE.

[amyk]

I've taken the 12360 equations and turned them into table in the following code which should reproduce what it looks like in the addres space of the CPU (except with every byte duplicated since A0 isn't connected). Each row represents a bit, each column represents an address at which that bit becomes 0.

Code: [Select]

#include <stdio.h>

unsigned short btab[][7] = {
 { 0x023E, 0x047C, 0x05C1, 0x091B, 0x098B, 0x0BF1, 0x0E61 },
 { 0x0263, 0x04B2, 0x05B3, 0x0627, 0x0899, 0x090B, 0x0B80 },
 { 0x0078, 0x03CD, 0x04E3, 0x0645, 0x06BE, 0x0732, 0x0991 },
 { 0x0113, 0x0355, 0x0373, 0x0398, 0x03B9, 0x0627, 0x068D },
 { 0x0162, 0x02AF, 0x02C4, 0x053C, 0x07AD, 0x081D, 0x0A86 },
 { 0x0567, 0x0764, 0x087E, 0x0AE4, 0x0D4E, 0x0FB9, 0x1022 },
 { 0x0207, 0x0470, 0x0683, 0x06F4, 0x096B, 0x0B88, 0x0DF2 },
 { 0x0057, 0x00A8, 0x00A9, 0x0116, 0x0180, 0x01EB, 0x025A },
};

int main() {
 int i;
 for(i=0;i<8192;i++) {
  int j;
  unsigned char c = 255;
  for(j=0;j<8;j++) {
   int k;
   for(k=0;k<7;k++)
    c &= ~((i == btab[j][k]) << j);
  }
  putchar(c);
 }
 return 0;
}Attached is the output of the above code, it is indeed very sparse.

[OzOnE]

@amyk

That was FAST.

Superb work.

I've only just started manually converting the logic rows to Hex, and only got the 0x023E one done. lol

[OzOnE]

@amyk

Did you see that address bit input A2 was inverted btw?

I had to create an internal "wire" on the Verilog version to do that, but the EQN can do it directly on the input pin declaration.

OzOnE.

[amyk]

@amyk

Did you see that address bit input A2 was inverted btw?

I had to create an internal "wire" on the Verilog version to do that, but the EQN can do it directly on the input pin declaration.

OzOnE.

Oops. Don't have any more time to play with this now but XOR'ing all the addresses in the table with 4 should fix it...

[mikeselectricstuff]

Only seven terms for each bit, so only seven possible addresses where that bit would go High.

But these addresses are almost certainly different for each number and maybe also for each bit. Needs some bit-twiddling to covert from address space to bit patterns on the address lines

[OzOnE]

No problem, amyk, it's still awesome. :p

I should try using C more often, but I've been using FPGAs so much now that I do a lot of stuff in Verilog faster.
(not that I'm an expert on either.)

I'm just about to compile and run the Verilog again, but using your Hex values to compare with what I was getting before.
It should match 100%, in theory.

@mike - yep, there will be a fair few addresses where the output changes, and that's what I'm seeing so far.
Still fairly sparse though, so their serial algo can't have been too complex after all.