Reversing The Encoding Of Serial Numbers In PALs or GALs

[technix]

Next up is "How the bleeding hell do I make a PROM to satisfy this thing?!"

Brute force ?
There are a lot of permutations but a lot of them can be eliminated.
Looks like the scheme was designed to make it hard, but computing power has come rather a long way since it was designed.
Obvious constraints :
One bit at a time, obviously
Only 7 of 8192 possible addresses can be active.
That's rather a big space, but I'm sure there must be ways to eliminate some based on other constraints.

8192 is not a big address space at all if you can code your brute force program to fully utilize the computing resources of your modern computer, especially GPU. It is a few seconds of run time at most on a R9 380 running OpenCL, less if you bump the GPU up to GTX 1080.

Actually it is, if you can't ia lot of it.
The number of permutations of seven '1' bits within that space is 8192x8191x8190x8189x8188x8187x8186, which is 2.46x10^27 , a rather large number to brute-force. 
If you did one test per microsecond, it would take 7.8^13 years

The key is on a modern GPU there are thousands of processing cores. For that kind of address space we can write a brute force searcher in OpenCL, break the entire address space up into chunks, and mount a distributed effort of brute forcing it. Although if someone can figure out a mathematical model to reduce the address space it would be nicer.

[np]

Our guy in Oz did a superb job of figuring out most of the "Harriet" memory map btw.
(hope this is OK to post?)...

Thank you 

I was quite busy these days/weeks but I see that you (all) did a good job.
If any further help is required send me a PM

Nicolas

[mikeselectricstuff]

Next up is "How the bleeding hell do I make a PROM to satisfy this thing?!"

Brute force ?
There are a lot of permutations but a lot of them can be eliminated.
Looks like the scheme was designed to make it hard, but computing power has come rather a long way since it was designed.
Obvious constraints :
One bit at a time, obviously
Only 7 of 8192 possible addresses can be active.
That's rather a big space, but I'm sure there must be ways to eliminate some based on other constraints.

8192 is not a big address space at all if you can code your brute force program to fully utilize the computing resources of your modern computer, especially GPU. It is a few seconds of run time at most on a R9 380 running OpenCL, less if you bump the GPU up to GTX 1080.

Actually it is, if you can't ia lot of it.
The number of permutations of seven '1' bits within that space is 8192x8191x8190x8189x8188x8187x8186, which is 2.46x10^27 , a rather large number to brute-force. 
If you did one test per microsecond, it would take 7.8^13 years

The key is on a modern GPU there are thousands of processing cores. For that kind of address space we can write a brute force searcher in OpenCL, break the entire address space up into chunks, and mount a distributed effort of brute forcing it. Although if someone can figure out a mathematical model to reduce the address space it would be nicer.

OK say 1000 cores on a million years. Now down to 78,000 years

[OzOnE]

@phil - I'll have a look at some of the other EQN files now, because the one I produced first using OpalJr doesn't have inverted "data" bus outputs?

The only inversions were on /A2, /ALEC, and the logic terms themselves?

Again, not important now, just one of those brain-teasers. lol

Thanks for the tip about IDA btw - it looks like moving the seg worked perfectly.
I did Google about that yesterday, but the IDA site itself said that it was impossible to move the segments without adding them from scratch again.

I guess they really need to update their docs, as it worked fine in IDA 6.6. hehe
I'll add the other segs / references for the hardware regs now, like Nicolas did for the ROM monitor disassem.

At some point, I'll start adding more stuff to the FPGA Harriet, and see if I can at least get the serial monitor going.

I had the ROM monitor for the classic DPB running on the dev board before, and translated a lot of the schematics into Verilog, but to actually get it running fully would require either adding lots of external RAM, or writing an SDRAM controller for the frame stores, disk store etc. The main RAM just uses the SRAM chip, so that should be fine.

Interestingly, I believe that all of the main code on the classic Paintbox is stored on PROMs.
One of the spare boards has the full 512KB of PROMs on it, IIRC. The floppy disks and giant HDD are only for storing uncompressed frames / fonts / brushes / cutouts etc.


@np - Thanks, Nicolas - Some great work you did on the ROM code.
What you did in only a few days would have taken me about 4 months. :p


As said in the last few posts, it doesn't look like the ROM monitor jumps directly to 0x400000 after loading the main OS, so it will be interesting to find out where it gets the vector from.

Ahh - @philm - this may be very important to mention - when I grabbed those OS.BIN and OS2.BIN files from the HDD image of the first Harriet unit, I simply copied them out of the HDD image.
It looked like that was the only 4MB chunk on the whole drive which actually contained any data, and the two "files" seemed to be almost the same apart from the "header"...

http://imgur.com/a/QvgtA


We know now that you can simply list the files on the HDD using the serial monitor, and it returns the proper offsets for the files on the HDD.
The old OS and OS2 files were from many years ago though, and from when I was just eager to start disassembling some code.

We'll sort all of this out soon. lol
Now that Mr Dexter has that new hoard of Quantel goodness, it's brought back a lot of the fun of working with them again.

I think a Hackaday article would be great, and even better if there was a collab vid between Mr Dexter and Mr Jones.


OzOnE.

[technix]

Next up is "How the bleeding hell do I make a PROM to satisfy this thing?!"

Brute force ?
There are a lot of permutations but a lot of them can be eliminated.
Looks like the scheme was designed to make it hard, but computing power has come rather a long way since it was designed.
Obvious constraints :
One bit at a time, obviously
Only 7 of 8192 possible addresses can be active.
That's rather a big space, but I'm sure there must be ways to eliminate some based on other constraints.

8192 is not a big address space at all if you can code your brute force program to fully utilize the computing resources of your modern computer, especially GPU. It is a few seconds of run time at most on a R9 380 running OpenCL, less if you bump the GPU up to GTX 1080.

Actually it is, if you can't ia lot of it.
The number of permutations of seven '1' bits within that space is 8192x8191x8190x8189x8188x8187x8186, which is 2.46x10^27 , a rather large number to brute-force. 
If you did one test per microsecond, it would take 7.8^13 years

The key is on a modern GPU there are thousands of processing cores. For that kind of address space we can write a brute force searcher in OpenCL, break the entire address space up into chunks, and mount a distributed effort of brute forcing it. Although if someone can figure out a mathematical model to reduce the address space it would be nicer.

OK say 1000 cores on a million years. Now down to 78,000 years

That is one GPU. Each machine can have more than one GPU, and in a distributed project there can be a lot more computers in general. Now if we can get 80k volunteers, it is already down to less than a yaer. And it is more likely than not some of them have dual GPU or more (Cards like AMD R9 295X2 count as two GPUs, and there are gaming rigs that have dual, tri or quad GPU setups), this just reduces the total search time further. Even better if some of us have Playstation 3 consoles that still had the older firmware revision (or hacked) that can run Linux.

Such a problem is embarrassingly parallel as each tested case is independent of each other, hence you can just pile hardware onto the problem, and the time reduction is linear.

[OzOnE]

I think I see what's going on with the OS disassem now...

It does look like the first 0x400 bytes (two sectors?) is just the AFS header for the file.

Then, at offset 0x400 (which would normally be loaded to the start of RAM at 0x400000), the first instruction is a JMP 0x40003C.

The instructions at offset 0x43C in the file (which will be at 0x3C when the header is removed) are then...

ori #$2700,sr
reset

Which is pretty much what we see in the ROM monitor at it's reset vector of 0x5D0.
Although, in the ROM monitor, the instructions at the reset vector are...

nop
reset
ori #$2700,sr
move.w #$FF,($FB0000).l
etc...

So, I'm just re-loading the OS file into IDA, but with the 1K "header" removed, and also loading it at the start of RAM (0x400000).
Hopefully the hard-coded addresses for the serial number routines will then point to the right places.

OzOnE.

[technix]

I think I see what's going on with the OS disassem now...

It does look like the first 0x400 bytes (two sectors?) is just the AFS header for the file.

Then, at offset 0x400 (which would normally be loaded to the start of RAM at 0x400000), the first instruction is a JMP 0x40003C.

The instructions at offset 0x43C in the file (which will be at 0x3C when the header is removed) are then...

ori #$2700,sr
reset

Which is pretty much what we see in the ROM monitor at it's reset vector of 0x5D0.
Although, in the ROM monitor, the instructions at the reset vector are...

nop
reset
ori #$2700,sr
move.w #$FF,($FB0000).l
etc...

So, I'm just re-loading the OS file into IDA, but with the 1K "header" removed, and also loading it at the start of RAM (0x400000).
Hopefully the hard-coded addresses for the serial number routines will then point to the right places.

OzOnE.

If we can get the key checking algorithm, we can rewrite it into OpenCL and start firing up GPUs.

[philpem]

If we can get the key checking algorithm, we can rewrite it into OpenCL and start firing up GPUs.

The problem is already solved. Look back in the thread.

EDIT: This post: https://www.eevblog.com/forum/projects/reversing-the-encoding-of-serial-numbers-into-pals-or-gals/msg1083933/#msg1083933

It was solved by running the algorithm in reverse, and the solution runs in under a second on a modern PC. Heck, it'd probably run in under a second or two on an 8MHz Z80 with enough RAM, it's all shifts, rotates, loops and moves.

[technix]

If we can get the key checking algorithm, we can rewrite it into OpenCL and start firing up GPUs.

The problem is already solved. Look back in the thread.

EDIT: This post: https://www.eevblog.com/forum/projects/reversing-the-encoding-of-serial-numbers-into-pals-or-gals/msg1083933/#msg1083933

It was solved by running the algorithm in reverse, and the solution runs in under a second on a modern PC. Heck, it'd probably run in under a second or two on an 8MHz Z80 with enough RAM, it's all shifts, rotates, loops and moves.

Now can we figure out the meanings of each valid key?

[dexters_lab]

@Philpem

Just trying to dot the Is and cross the Ts while this is still fresh...

I have read out all of the SecurityPALs as TMS2764 EPROMs and attached them, would you be able to run these through your decoder and reveal the contents?

It might give us a clue to the use of the other 'spare' bytes after the description you mentioned before

[philpem]

@Philpem

Just trying to dot the Is and cross the Ts while this is still fresh...

I have read out all of the SecurityPALs as TMS2764 EPROMs and attached them, would you be able to run these through your decoder and reveal the contents?

It might give us a clue to the use of the other 'spare' bytes after the description you mentioned before

Here you go!

Some new description strings in this one:
  * 10311 Picturebox identifies as "GV SERIES"; the entire "spare" area is set to zero

Harriet:
  * 12360 Harriet - "00 00 00 08" in both copies

HAL:
  * 12875 & 11907: ID string is "HAL". First serial number in the ROM is 11907, second is 12875 (I'm curious which is the group one). Mystery bytes "00 04 00 00"
  * 14201: "HAL", mystery bytes "00 04 00 00"

Editbox:
  * 13784_1, 13822_1, 15719_1, 16109_1, 16134_1, 16138_1, 16161_1, 17624_1dup1, 17624_1dup2: "EDITBOX". Mystery bytes "10 00 01 00"
  * 13784_2, 13822_1, 15719_2, 16109_2, 16134_2, 16138_1, 16161_1, 17624_2dup1, 17624_2dup2: "EDITBOX". Mystery bytes "00 42 01 00"

Editbox Platinum (only the description text has changed though, possibly just different software keys):
  * 16450_1, 16879_1, 16980_1: "EDITBOX (PLATINUM)". Mystery bytes "10 00 01 00"
  * 16450_2, 16584_2, 16879_2, 16880_2: "EDITBOX (PLATINUM)". Mystery bytes "00 42 01 00"

Edit Seat? -- possibly some special kind of Editbox:
  * 14340_1, 14491_1, 14691_1: "EDIT SEAT", Mystery bytes "10 00 00 00, 00 10 00 00"
  * 14340_2, 14491_2, 14691_2: "EDIT SEAT", Mystery bytes "00 42 00 00, 00 10 00 00"

Domino?:
  * 13923 Dup 1: "DOMINO", Mystery bytes "00 00 20 00"
  * 13923 Dup 2: "DOMINO", Mystery bytes "00 00 04 00"

Snetcom / Remote Mag Opt:
  * 14768, 17811: "REMOTE MAG OPT", Mystery bytes "00 00 00 00 10 00 00 00"

PFrame Paintbox:
  * 15462 E dup1, 15462 E dup2: "PFRAME PAINTBOX", Mystery bytes "00 00 10 00 04 00 00 00"

Paintbox:
  * 15546: "OPTIONS", Mystery bytes "00 00 00 08"

Picturebox:
  * 70579: "PICTUREBOX", Mystery bytes "80 00 00 00"

Henry:
  * 15671_1: "HENRY", Mystery bytes "10 00 00 10"
  * 15671_2: "HENRY", Mystery bytes "00 42 00 10"

Network cards:
  * 13464 (HAL): ID string is "NETCOM". Mystery bytes "00 60 00 00" which is a network card
  * 15671_N, 15719_N_EB, 16879_N_ED, 16880_N_ED: "NETWORK". Mystery bytes "00 60 00 00"

PMAN / GRID:
  * 15929 GRID: "PMAN". Mystery bytes "00 00 08 00"

Bridge Processor:
  * 70579 BP: "BRIDGEPROC". Mystery bytes "00 60 00 00" -- yep, same as a network card. Maybe 00:60 just means "expansion card".



At a guess, I'd say the mystery bytes encode the machine/card type. Dual-CPU machines at least have a PROM with encoding "10 00" for CPU1, and "00 42" for CPU2.

There doesn't seem to be any other pattern to it, other than "specific machine types have specific values". A bit like the Gestalt values on old Macs, maybe?

Cheers,
Phil.

[dexters_lab]

Some new description strings in this one:
  * 10311 Picturebox identifies as "GV SERIES"; the entire "spare" area is set to zero

GV?, hmm no idea on that one!

Harriet:
  * 12360 Harriet - "00 00 00 08" in both copies

good, this one could be important

HAL:
  * 12875 & 11907: ID string is "HAL". First serial number in the ROM is 11907, second is 12875 (I'm curious which is the group one). Mystery bytes "00 04 00 00"
  * 14201: "HAL", mystery bytes "00 04 00 00"

Editbox:
  * 13784_1, 13822_1, 15719_1, 16109_1, 16134_1, 16138_1, 16161_1, 17624_1dup1, 17624_1dup2: "EDITBOX". Mystery bytes "10 00 01 00"
  * 13784_2, 13822_1, 15719_2, 16109_2, 16134_2, 16138_1, 16161_1, 17624_2dup1, 17624_2dup2: "EDITBOX". Mystery bytes "00 42 01 00"

Editbox Platinum (only the description text has changed though, possibly just different software keys):
  * 16450_1, 16879_1, 16980_1: "EDITBOX (PLATINUM)". Mystery bytes "10 00 01 00"
  * 16450_2, 16584_2, 16879_2, 16880_2: "EDITBOX (PLATINUM)". Mystery bytes "00 42 01 00"

Edit Seat? -- possibly some special kind of Editbox:
  * 14340_1, 14491_1, 14691_1: "EDIT SEAT", Mystery bytes "10 00 00 00, 00 10 00 00"
  * 14340_2, 14491_2, 14691_2: "EDIT SEAT", Mystery bytes "00 42 00 00, 00 10 00 00"

yea i don't know that much about Editbox, it had a long life so probably went through many versions, there could also be custom products.

Domino?:
  * 13923 Dup 1: "DOMINO", Mystery bytes "00 00 20 00"
  * 13923 Dup 2: "DOMINO", Mystery bytes "00 00 04 00"

Domino was Quantels 'movie' editor, it was a film scanner and setter. For restoring or editing movie film. Scan a frame, edit, then write frame back to film.

Snetcom / Remote Mag Opt:
  * 14768, 17811: "REMOTE MAG OPT", Mystery bytes "00 00 00 00 10 00 00 00"

1U rack device with a MO drive connected to the network so other things could access the images on the disk it has a Snetcom board inside which seems to be the same as the Snetcom board installed in the v-series chassis.

PFrame Paintbox:
  * 15462 E dup1, 15462 E dup2: "PFRAME PAINTBOX", Mystery bytes "00 00 10 00 04 00 00 00"

PictureFrame, i have heard it mentioned before but no idea what it actually is.

Paintbox:
  * 15546: "OPTIONS", Mystery bytes "00 00 00 08"

Picturebox:
  * 70579: "PICTUREBOX", Mystery bytes "80 00 00 00"

  these could be significant

Henry:
  * 15671_1: "HENRY", Mystery bytes "10 00 00 10"
  * 15671_2: "HENRY", Mystery bytes "00 42 00 10"

earlier version of Editbox IIRC

Network cards:
  * 13464 (HAL): ID string is "NETCOM". Mystery bytes "00 60 00 00" which is a network card
  * 15671_N, 15719_N_EB, 16879_N_ED, 16880_N_ED: "NETWORK". Mystery bytes "00 60 00 00"

These install inside the V-Series chassis for network connection through the SCSI port, they have their own 68k on board

PMAN / GRID:
  * 15929 GRID: "PMAN". Mystery bytes "00 00 08 00"

no idea!

Bridge Processor:
  * 70579 BP: "BRIDGEPROC". Mystery bytes "00 60 00 00" -- yep, same as a network card. Maybe 00:60 just means "expansion card".

i am wondering if the BridgeProcessor is just an earlier version of the Netcom or Snetcom

At a guess, I'd say the mystery bytes encode the machine/card type. Dual-CPU machines at least have a PROM with encoding "10 00" for CPU1, and "00 42" for CPU2.

There doesn't seem to be any other pattern to it, other than "specific machine types have specific values". A bit like the Gestalt values on old Macs, maybe?

i've attached one last PAL image, it's from my other v-series chassis and i thinks it's a picturebox.. if you could decode that one as well?

[philpem]

i've attached one last PAL image, it's from my other v-series chassis and i thinks it's a picturebox.. if you could decode that one as well?

Well this one is a touch on the odd side...

ID string is "COMBO", magic bytes are 00 00 00 00 02 00 00 00

So who knows what that is... only way to tell is probably to boot it and see what it says on power-on.

Cheers.

[dexters_lab]

i've attached one last PAL image, it's from my other v-series chassis and i thinks it's a picturebox.. if you could decode that one as well?

Well this one is a touch on the odd side...

ID string is "COMBO", magic bytes are 00 00 00 00 02 00 00 00

So who knows what that is... only way to tell is probably to boot it and see what it says on power-on.

Cheers.

yes nobody is sure what it is!

it's a much newer system from 1998, with SDI (serial) digital video, the later 68040 CPU card and snetcom (network), the sticker on the back says it's a Picturebox Express. It does boot but i can't seem to get a working keyboard or tablet on it. But just boots to a blank screen with the crosshairs

I was told it's possibly a 'Combo' machine as in it's a Picturebox and a Paintbox in one which is quite possible as the licensing system from quantel certainly allowed that the hardware could run just about any configuration of software

wish i knew what all the option codes that unlock parts of the software meant as it would help unravel it

according to the list it has option 33, 69 & 113

my older working one has 10001, 7, 30, 10002, 1, 5, 18 & 44

here are some snippets from the bootlog

Code: [Select]


PAL standard 2103, 2300
Serial number: 71335

Description  : COMBO                   
Options      : 4000000000    39