Reversing The Encoding Of Serial Numbers In PALs or GALs

[OzOnE]

Awesome work, Phil.

I had Easy68K in my "Quantel Harriet" folder as well, but I've been stepping through the code in the MAME debugging instead.

(I added a basic skeleton driver for the Harriet, but I'm not handling the serial stuff yet.)

Due to my lack of 68K experience, I was finding it tough to work out which arguments were actually put on the stack for that SecurityPAL routine, so I didn't have an example string to go on.
I also couldn't find a place in the code where it actually checks the serial number of the PAL?

I need to get my head around the code you've produced. lol

The comments about the 777777 thing were added by another guy in Oz btw (no, not that one. :p )
I was still working through that routine last night, but didn't make a huge amount of progress once I realised it was a fair bit more complex than I first thought.

I did find the identical security routine in the main OS file btw (from the previous working Harriet that I had, which was sent to a friend some time ago).

I'll send you the files from that, so you can have a look with IDA Pro etc.

I'm still a tad baffled that the binary you posted doesn't match the one I generated from the EQN though?
However, you file does indeed match 100% to the one that Mr Dexter read using the programmer, so that confirms that.

Did you also spot that the /A2 input in the EQN was inverted? I guess you must have? :p

Have you tried randomly changing a few bits in the binary / equations, to see how the output changes, or would that just completely scramble everything, or cause the routine to return with an error?

I did a search through the main OS file for any addresses starting with 0xFD0xxx btw, and 0xFD0000 only appears in that same routine as in the ROM monitor.
There are four or five other places in the raw hex that starts with 0xFD0xxx, but that's probably just random data.

So, I think we can be fairly confident that all their crypto works through that same routine.
Once we work out how to produce the correct response for the different serials, we should just be able to patch the code instead of generating a PAL each time (and therefore essentially "cracking" the Quantel OS).

Now, I'll have to try to understand Phil's code now. lol

OzOnE.

[philpem]

Latest update: I now have a tool which can create PAL images, in "PROM-like image" form. I've just created a completely fake PAL with a description of "Hummingbird", which I'm quite sure never existed:

Code: [Select]

$ make && ./quan_enc
cc -g -ggdb   -c -o quan_enc.o quan_enc.c
cc -g -ggdb  -o quan_enc quan_enc.o
Quantel Paintbox Protection PAL builder.
Serial numbers: 12345, 76543
Description:    HUMMINGBIRD
Raw buffer:
  00 00 30 39 00 01 2A FF 48 55 4D 4D 49 4E 47 42
  49 52 44 20 20 20 20 20 20 20 20 20 20 20 20 20
  00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Raw checksum: 1649
Enc checksum: 5212
Encrypted buffer:
  43 6F 40 40 72 68 4D 97 3C 75 65 0E 60 6E 16 37
  28 3C 30 45 4C 00 6C 54 44 00 11 19 18 15 0E 00
  55 73 65 28 77 69 74 68 6F 75 74 20 70 65 72 6D
  69 73 73 69 6F 6E 20 66 6F 72 62 69 64 64 65 6E

$ make && ./quan_alg ../quan_enc/enc.bin
make: 'quan_alg' is up to date.
Processing PAL image file ../quan_enc/enc.bin
addr=0CEA, d2=0x02, testing bit d3=1, mask=0x02    SET
addr=1164, d2=0x02, testing bit d3=1, mask=0x02    SET
addr=1166, d2=0x02, testing bit d3=1, mask=0x02    SET
addr=144E, d2=0x02, testing bit d3=1, mask=0x02    SET
addr=193A, d2=0x02, testing bit d3=1, mask=0x02    SET
addr=1A22, d2=0x02, testing bit d3=1, mask=0x02    SET
addr=1B08, d2=0x02, testing bit d3=1, mask=0x02    SET

Crypted string:   Co@@rhM-<ue-`n-7(<0EL-lTD-------Use(without permission forbidden

Hex crypted string:
  43 6F 40 40 72 68 4D 97 3C 75 65 0E 60 6E 16 37
  28 3C 30 45 4C 00 6C 54 44 00 11 19 18 15 0E 00
  55 73 65 28 77 69 74 68 6F 75 74 20 70 65 72 6D
  69 73 73 69 6F 6E 20 66 6F 72 62 69 64 64 65 6E


DONE -->

DeCrypted string:   --09--*-HUMMINGBIRD             --------------------------------

Hex decrypted string:
  00 00 30 39 00 01 2A FF 48 55 4D 4D 49 4E 47 42
  49 52 44 20 20 20 20 20 20 20 20 20 20 20 20 20
  00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Crypted string checksum (D7 loword): 5212

Clear string checksum   (D7 hiword): 1649

AddrBitLastSeen aka Addr0                    (internal): 3402 3460 3418 2188 2948 2345 4609 1594

BitActiveCounter aka Addr1 - should all be 7 (internal): 7 7 7 7 7 7 7 7


There's only one thing that concerns me -- the eight bytes after the Description string seem to be used for "something":

Code: [Select]

Harriet #12360:            00 00 00 08 00 00 00 00
PFrame Paintbox #15462-E:  00 00 10 00 04 00 00 00
Editbox #17624-1:          10 00 01 00 00 00 00 00
Editbox #17624-2:          00 42 01 00 00 00 00 00
Network #17642-N:          00 60 00 00 00 00 00 00

If the description string is meaningless to the machine (it could well be), this may well be a bitmask which says "unlock these features by default"... in which case, you'd need to know what the bits mean.

I wonder how complex the "licence string" scheme is. Whether it just locks to serial number (in which case that's all you need to get right) or whether these bits matter too...

Awesome work, Phil.

Thanks

Due to my lack of 68K experience, I was finding it tough to work out which arguments were actually put on the stack for that SecurityPAL routine, so I didn't have an example string to go on.
I also couldn't find a place in the code where it actually checks the serial number of the PAL?

I'm not sure the monitor ROM would - at least I wouldn't expect it to. All I'd expect it to do is see if the PAL is there and maybe print the serial number. The main software would be what checked the serial number, read license strings, decrypted those, and decided whether you were worthy of advanced features and such.

I'm guessing the thing boots from disk, and that there's more advanced licence checking in there.


As regards the stack -- what it's putting on the stack are two pointers. "retcode_success_1" is a pointer to a variable which receives a return code from the function (ehh, the usual 68k calling convention is to use D0, but whatever). "inputCryptoString" isn't actually an input -- it's an output. It's a 64-byte buffer (not 0x3F -- the guy in Oz missed that a DBF loop loops n+1 times) which receives the decrypted version of the "cryptstring", which is actually the contents of the security PAL.

That string encodes the serial number, description string (up to 24 characters, space padded) and 32 bytes of additional data which is usually 0x00 but some bits can be set to '1'.

I need to get my head around the code you've produced. lol

It is... a bit heavy going. Or at least the decoder is. When you see the encoder it might click.

I did find the identical security routine in the main OS file btw (from the previous working Harriet that I had, which was sent to a friend some time ago).

I'll send you the files from that, so you can have a look with IDA Pro etc.

Excellent! Thank you
I did suspect the OS would be poking and prodding the security PAL. The question is, what does it do with the data from the PAL -- especially the data after the description?

I'm still a tad baffled that the binary you posted doesn't match the one I generated from the EQN though?
However, you file does indeed match 100% to the one that Mr Dexter read using the programmer, so that confirms that.

Could just be a typo maybe? 

I used a Python script to undo JED2EQN's word wrapping, then fed the output of that into a Sed script to rename the pins and convert the EQN code into C.

Did you also spot that the /A2 input in the EQN was inverted? I guess you must have? :p

Yep! I read through the thread before I started hacking on this. Standing on the shoulders of giants, as it were! 

Have you tried randomly changing a few bits in the binary / equations, to see how the output changes, or would that just completely scramble everything, or cause the routine to return with an error?

That'd break the checksums on the PAL data (it checksums the encrypted and decrypted data).

So, I think we can be fairly confident that all their crypto works through that same routine.
Once we work out how to produce the correct response for the different serials, we should just be able to patch the code instead of generating a PAL each time (and therefore essentially "cracking" the Quantel OS).

Ehh. I prefer "no patches" fixes, myself.

It's always nicer if you can run the original hardware and ROMs without having to patch the software

[philpem]

And here's the PAL generator.

Modify the constants at the top (serial numbers and product description string), compile it, run it, and it'll spit out two files.

ENC.BIN is a "PROM-like" binary you can load into Quan_Alg to check the PAL.
ENC.PLD is an Atmel-WinCUPL equation file which can be used to produce a GAL20V8.

If you want to compile the PLD file, go into the WinCUPL options and set Logic Minimisation to "None" or "Quick". I found that at least with this file, Quine-McCluskey minimisation caused WinCUPL to crash during the CUPLM phase.

There's also an example showing how to "fudge" the data bits which are nonzero in the Harriet PLD, so you can generate a functional duplicate of that.

Enjoy!

[dexters_lab]

O M G

it's too late to play tonight, i'll have a proper look tomorrow

[dexters_lab]

thanks Philpem for all your work

i nice little exercise for me would be to learn how to make a basic windows GUI or command line util to make it a bit more user friendly

can anyone recommend any tools to help?

[OzOnE]

@phil - I just sent you a big message via PM, but it didn't seem to appear in the Sent Items, so let me know if you received it OK.

Luckily, I remembered to do a Ctrl-A, Ctrl-C, then paste the message into a text file.
(The way this forum shows the previously sent replies on the Messages screen is a bit strange too.)

Here's my Verilog of the 12360 PAL, but with the "binary" terms converted to Hex...
http://pastebin.com/wx5nUgha

It's very possible I made a few typos in that one, but originally I was using the file I'd converted from the EQN.
That was using NotePad++ to change the OR / AND / NOT operators though, and change the pin numbers to proper names etc.

I got the same exact result when running the binary or hex term version on the dev board, but it still didn't match what you produced, or what Mr Dexter got from reading on the TL866, so I've obviously screwed something else up. lol

I did invert the A2 bit input in the code, and also realise that the 68K doesn't hook up /LDS or /UDS, nor has A0 etc., but it should have produced the same result as reading the PAL as a "ROM". Oh well. It's not important now, just one of those things that's bugging me. hehe


I'll have a look now to see how to disassemble the whole OS file with IDA Pro. Unless anyone else knows?
I managed it some time ago, but now can't recall how to just blindly dump the whole 68K binary back to an ASM file?

Once we have enough of it disassembled, we should see exactly which routines are accessing that same PAL Security routine, and hopefully how it processes the passwords too.

The passwords themselves seem to simply be written in cleartext at the start of the main OS file.

The OS itself looks to be only 2 or 3 MBytes. The whole rest of the HDD image is just for storing the uncompressed video frames.

(4:2:2 component, which the guy in Oz kindly converted back to RGB for us.)
Here are a few example images from the Harriet unit I sent to Mr Dexter.

http://imgur.com/a/uguw6

Clearly, some of those images were from the BBC's "Airport" program. I remember it well. hehe

That Harriet unit, and the previous one seemed to have been used right up until about 2002-2004. Amazing really.

You can see how it stores the fonts and brushes as uncompressed, and even captures the palette box if it was enabled at the time.
Kind of unsurprising, as the whole thing operates directly on the framebuffer(s), with only a certain amount of "hardware acceleration" for things like 3D rotations and scaling.

The Harriet system uses the 68010, but also has the MC68450 DMA Controller.

The classic Paintbox DPB-7001 used only the 68000, and virtually all of it's drawing functions were done using jellybean TTL logic, and some multipler chips etc. It stored the chosen brush shape on a separate RAM board, and would then do a Read-Modify-Write on the framebuffer contents, depending on the pressure of the stylus on the tablet / selected colour etc.

It could also do "Copy 'n' paste" and masking effects between the two separate frame stores.
Extremely impressive for 1981, especially since the 68000 CPU only got released in 1979 (IIRC).

For anyone not familiar with the PB, here's the unit I'd been helping to get running for about three years (but sadly failed, as I'm 200 miles away from it. lol) This is the PB which is now in Mr Dexter's possession...




And here's a demo of it's painting functions.
Again, crude by today's standards of course, but absolutely groundbreaking for it's time...




There were a number of copyright challenges by Quantel against Adobe over the years.
It's clear that many of the techniques used in programs like Photoshop share a lot of similarities, but I guess we'll never know quite how much of it was "inspired" by the Quantel units.


Right - back to trying to figure out Phil's (and amyk's) code. lol

OzOnE.

[OzOnE]

I've started to find more routines in the main OS file now...

It's interesting that it also has ASCII strings for different add-on options, like "HD Painting", "AV Painting" etc.

http://imgur.com/a/wkY1h

As Mr Dexter said the other day, the Harriet isn't technically a "Harriet" unless it's linked to other units to make a more complete system.
It should really be referred to as a "V-Series" unit, AFAIK?

There are more routines for crypt / decrypt of files using the passwords (and serial number by the looks of it).

I still haven't figured out how to force IDA to just disassemble the entire 2.11MB file, but I'm getting closer to finding which routines talk to the PAL, or use the serial number etc.

OzOnE.

[dexters_lab]

incidentally this is what the software keys look like:

the first part is the key, then the option code it unlocks and then an expiry date, none means it's never expires

Code: [Select]

AVE KMX BW3 LGG 2HM ZXM     33      None
AZE 69T BW7 CGC WH9 VTR     69      None
AVE KMT BW3 CGC 2HM ZTR    113      None

[philpem]

@phil - I just sent you a big message via PM, but it didn't seem to appear in the Sent Items, so let me know if you received it OK.

Got it, I think. Links to a video about the DPB-7001?

Here's my Verilog of the 12360 PAL, but with the "binary" terms converted to Hex...
http://pastebin.com/wx5nUgha

It's very possible I made a few typos in that one, but originally I was using the file I'd converted from the EQN.
That was using NotePad++ to change the OR / AND / NOT operators though, and change the pin numbers to proper names etc.

I got the same exact result when running the binary or hex term version on the dev board, but it still didn't match what you produced, or what Mr Dexter got from reading on the TL866, so I've obviously screwed something else up. lol

You've got the logic a bit wrong.

ALEC enables the I/Os.
The data lines are normally high, but pull low if one of the Pterms detects a "hit".

So if you scan through the address range, you should see a ton of 0xFF bytes, and 56 '0' bits scattered within that space.

For anyone not familiar with the PB, here's the unit I'd been helping to get running for about three years (but sadly failed, as I'm 200 miles away from it. lol) This is the PB which is now in Mr Dexter's possession...

Nice! I remember watching the videos of that on Youtube while Retrogamer was trying to get it up and running. I wondered what had happened to it.



With regard to the OS... it looks like it's been loaded at address 0x0. I bet that isn't the load address.

You need to know what address (in RAM) the boot ROM loads the OS into, and what address it starts executing from. If you give IDA that, it should get a long way into the disassembly.
I think it might be stopping because the load/exec addresses are wrong.

[dexters_lab]

OS is loaded at $400000

[OzOnE]

Hi,

You should have a message with links to MEGA with the IDA stuff etc.?

You've got the logic a bit wrong.

ALEC enables the I/Os.
The data lines are normally high, but pull low if one of the Pterms detects a "hit".

So if you scan through the address range, you should see a ton of 0xFF bytes, and 56 '0' bits scattered within that space.

Ahh, that probably explains it. lol

I thought something might be inverted somewhere.

I'm too used to Verilog, where you generally don't have inverted output pins unless you specifically code that.
I forgot that PALs / GALs often have Active-Low outputs.

I've just inverted the data bus on the Verilog, and it's now matching 100% with your 12360 binary.

With regard to the OS... it looks like it's been loaded at address 0x0. I bet that isn't the load address.

You need to know what address (in RAM) the boot ROM loads the OS into, and what address it starts executing from. If you give IDA that, it should get a long way into the disassembly.
I think it might be stopping because the load/exec addresses are wrong.

Yep, I'm just trying to disassemble what I can atm, then work out where it normally loads the executables in RAM.
I would imagine it loads the entire 2-4MB OS file(s) directly into RAM, as it does seem to point to routines in that range a lot.

I did have the OS file for my older Harriet mostly disassembled in IDA, but the older IDA did have some bugs and glitches.

So, I've started again with IDA 6.6 instead.
I have nearly 50% of the code done so far, but I'm having to do a Ctrl-U to go to the next Undefined code, then hit C to convert to ASM.

Most of the strings / data come before the routine of course, so I'm having to skip those manually too.

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

HW devices :
  CPU 68010
  DMA Controller MC68450 MC68450
  MFP MC68901 MC68901
  SCSI Controller WD33C93A WD33C93A  x2          (found one only)
  2 Serial Ports + 8 I/O : MC68681  x2 MC68681      (found one only)
  SRAM + clock M48T02 x2 M48T02
  3 rotary encoders move.w 0xFA0000, d0
 
Optional Ethernet module is implemented on SCSI ID 6, with simple command


Mapping addrs :
0x000000 - 0x008000 ROM (32 KBytes)
0x000100 - 0x0003FF RAM
0x040000 - 0x0407FF NVRAM, default boot device
0x040800 - 0x040FFF NVRAM2
0x400000   RAM do be verified
0x7FD000 - … (seems used as RAM too : Input Console buffer)
0x7FE000 - 0x7FFFFF RAM  (4 KBytes)   Initialized/tested during init
0xF10000 - 0xF1001F : Serial Port MC68681  need To be verified (A0 = 1 for decoding)
0xF100F1 : write on Serial GPIO : LED 7 segments front display (‘0’ to ‘9’)
0xF20000 - 0xF2002F : MFP MC68901 (Serial Console)
0xF30000 - 0xF300FF : DMA Controller MC68450
0xF40000 - 0xF4003F : SCSI Controller WD93C33A

0xF60000 : Device with DMA transfer on 0xF60000 (DMA channel 2), 0xF60002 (DMA channel 3)
0xF60007 : linked with burst write at 0xFE0004,8,A @sub3C0A
F6 Memory Storage Board ?

0xF96000 : one word write
0xFA0000 : 3x Rotary Hex Switch : Word value
      0F00 => SW14
      00F0 => SW15
      000F => SW7

sw14 SCSI Controller ID (normally 7 by default)
sw7   BootID (0 DebugMonitor, F Boot from NVRam (Autoboot) else Printf “Autoboot From %d”, BootID)
 
0xFB0000 : Leds ?  Write 1 byte : 0x00 (init only) 0x1F or 0xFF (word)  ; start and end of scsi cmds
0xFB0001 : Read 12Bits (dip switch ?)   used only in one place to index  BootDeviceList
0xFD0000 - 0xFD1FFF : Security PAL @sub52DC
                                        Security PAL store 2 flags, seems related to HW configuration/installation (like is a floppy drive present, serial number ….)


0xFE0000 : ? @sub2726
0xFE0004,8,A : Writing word burst cmd 1,3,5,7,0 to these addr @sub3E8C
0xFE device is a Floppy Controller ?


I have found a few routines in the OS file which process the serial numbers, but they also appear to JSR to routines in RAM.
Here's one example...

ROM:00070D50 loc_70D50:                              ; CODE XREF: ROM:00070D48j
ROM:00070D50                 adda.w  #$44,sp ; 'D'
ROM:00070D54                 movem.l d0-a4,-(sp)
ROM:00070D58                 lea     -$A(a6),a1
ROM:00070D5C                 lea     ($404100).l,a2
ROM:00070D62                 lea     ($403CF2).l,a3
ROM:00070D68                 lea     ($6362DE).l,a4
ROM:00070D6E                 moveq   #$C,d2
ROM:00070D70                 moveq   #1,d5
ROM:00070D72                 subq.w  #2,sp
ROM:00070D74                 pea     -$4A(a6)
ROM:00070D78                 jsr     $4710E8       ; <- Hard-coded to a routine in RAM.
ROM:00070D7E                 addq.w  #4,sp
ROM:00070D80                 tst.b   (sp)+
ROM:00070D82                 bne.s   loc_70DA0
ROM:00070D84                 pea     aSerialNumberIn ; "Serial number invalid"
ROM:00070D88                 pea     ($15).w
ROM:00070D8C                 move.l  (sp),-(sp)
ROM:00070D8E                 jsr     $403FA4
ROM:00070D94                 adda.w  d2,sp
ROM:00070D96                 jsr     (a2)
ROM:00070D98                 jsr     (a2)
ROM:00070D9A                 clr.b   -(sp)
ROM:00070D9C                 jsr     (a3)
ROM:00070D9E                 addq.w  #2,sp


OzOnE.

[dexters_lab]

i should point out that the Harriet is actually working right now, when i get a moment i will go into a bit more detail here about what was done after philpem's code and of course i will be making a video in due course!

just want to thank everyone for all of their help, it's certainly been an adventure getting this running!!

[mikeselectricstuff]

There has to be a Hackaday/EMFcamp/<insert favorite event> talk to be gotten out of all this....

[SeanB]

There has to be a Hackaday/EMFcamp/<insert favorite event> talk to be gotten out of all this....

I think more an Amp hour episode instead at first. Then a collaborative video with Mark and Dave about reverse engineering. We need the other collaborators in there as well at a minimum.

[dexters_lab]

interesting thoughts there

i will at least make a start to finish video about all the twists and turns and how it all came together

[philpem]

interesting thoughts there

i will at least make a start to finish video about all the twists and turns and how it all came together

I'm looking forward to watching it

(I may or may not be a bit of a sucker for Paintboxes...)

[mikeselectricstuff]

Now what to use to do graphics for the video....

[philpem]

OS is loaded at $400000

I don't suppose you know where the monitor jumps to after it's loaded the OS, do you?

[dexters_lab]

AFAIK it jumps directly to $400000

[philpem]

You should have a message with links to MEGA with the IDA stuff etc.?

Yep!

I'm too used to Verilog, where you generally don't have inverted output pins unless you specifically code that.
I forgot that PALs / GALs often have Active-Low outputs.

It was in the EQN file - "/D1 = ..." 

I've just inverted the data bus on the Verilog, and it's now matching 100% with your 12360 binary.

I have found a few routines in the OS file which process the serial numbers, but they also appear to JSR to routines in RAM.
Here's one example...

ROM:00070D50 loc_70D50:                              ; CODE XREF: ROM:00070D48j
ROM:00070D50                 adda.w  #$44,sp ; 'D'
ROM:00070D54                 movem.l d0-a4,-(sp)
ROM:00070D58                 lea     -$A(a6),a1
ROM:00070D5C                 lea     ($404100).l,a2
ROM:00070D62                 lea     ($403CF2).l,a3
ROM:00070D68                 lea     ($6362DE).l,a4
ROM:00070D6E                 moveq   #$C,d2
ROM:00070D70                 moveq   #1,d5
ROM:00070D72                 subq.w  #2,sp
ROM:00070D74                 pea     -$4A(a6)
ROM:00070D78                 jsr     $4710E8       ; <- Hard-coded to a routine in RAM.
ROM:00070D7E                 addq.w  #4,sp
ROM:00070D80                 tst.b   (sp)+
ROM:00070D82                 bne.s   loc_70DA0
ROM:00070D84                 pea     aSerialNumberIn ; "Serial number invalid"
ROM:00070D88                 pea     ($15).w
ROM:00070D8C                 move.l  (sp),-(sp)
ROM:00070D8E                 jsr     $403FA4
ROM:00070D94                 adda.w  d2,sp
ROM:00070D96                 jsr     (a2)
ROM:00070D98                 jsr     (a2)
ROM:00070D9A                 clr.b   -(sp)
ROM:00070D9C                 jsr     (a3)
ROM:00070D9E                 addq.w  #2,sp

You've loaded the OS in at address zero, but the monitor loads it into RAM -- so IDA can't make head nor tail of the addresses.

What you need to do is either reload it with the offset set to 0x400000 (not the "in paragraphs" one -- the one below it), or you might be able to get away with opening View -> Segments, then right clicking "ROM", selecting "Move Segment", then entering 0x400000 in the box.

Needless to say, save your IDB file and take a backup before you try this.

[philpem]

AFAIK it jumps directly to $400000

Sadly I don't think it is... that address is full of MOVEs, ORs with zero and BTSTs, which doesn't look like valid code

[dexters_lab]

Now what to use to do graphics for the video....

lol, yea i am sure i can use it somehow

will be nice to get the ramcorder working, it connects to the paintbox using CCIR601 so it can do animation, all 12 seconds of it!

[dexters_lab]

AFAIK it jumps directly to $400000

Sadly I don't think it is... that address is full of MOVEs, ORs with zero and BTSTs, which doesn't look like valid code

oh, erm... dunno then

it could be different when it autoboots, i will check and let you know

[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.

[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