Why simply “dumping” a PAL isn’t always possible?

Rom Dumping

Dumping ROMs is a pretty common practice in the space of reverse engineering, and many eeprom readers are cheap, easily available, and there’s really not much to them. Plunk your ROM chip in the reader, press, go, and you have a binary file with the contents. Provided that your reader supports the ROM chip, or you need an adapter like I built in this post to read Commodore Amiga ROMs in a TL866A:

It’s really not too bad. You can’t easily prevent a ROM chip from being read because the way in which the chip is used in the circuit is also the same way you dump it. You assert the address, wait, and get a value on the data port.

PALs are different from ROMs, of course, and unfortunately reading them isn’t so trivial. Let’s look at when you can, and when you can’t.

Reading purely combinatorial PALs

If every output from a PAL is a pure function of the input, then that’s said to be combinatorial, or uses combinational logic. You put certain values in, you get certain values out, despite what’s happened before. It’s deterministic and retains no state whatsoever. Wikipedia does a better job than I could:

…combinational logic (also referred to as time-independent logic ^[1] or combinatorial logic ^[2]) is a type of digital logic which is implemented by Boolean circuits, where the output is a pure function of the present input only. This is in contrast to sequential logic, in which the output depends not only on the present input but also on the history of the input. In other words, sequential logic has memory while combinational logic does not.

https://en.wikipedia.org/wiki/Combinational_logic

You can see, then, how you can simply iterate the input possibilities, wait the propagation delay of the pal, read the outputs and build a lookup table. That lookup table can be reduced into logic equations.

Of course, from the outside, you really have no way of determining whether your particular pal is programmed with pure combinational logic, or not. Even a PAL device capable of supporting state doesn’t need to be programmed to do so. So in general, dumping PALs with part numbers like PAL16R8 is not possible, but with PAL16L8, it might be.

You can see then if you create an adapter between the normal ROM address pins and the input pins on the pal, and then wire the outputs of the PAL to the data pins, that it’s fairly trivial for ROM reader to iterate all possible values. If you’ve got 12-bits of input, 2^12=4096, possible — and if each output is 6-bits, then you end up with a neat and tidy 4096 byte file. Of course you need to process and convert that file into something usable.

That’s what the project I’ve linked at below does. It gives you a schematic for building an adapter, and more importantly a (albeit 16-bit) windows executable that converts the ROM dump into PAL equations.

Clicking the image above takes you to the site.

You can see my attempts here to build and use the adapter during my reverse engineering attempts with my Dataflyer Plus SCSI card. Spoiler: It didn’t work.

It is probably worth the effort initially to simply try and dump it — you might get lucky with a simple design.

The dreaded security fuse(and other mechanisms)

A pal fuse map, typically stored in a .jed file, is the result of the .PLD compilation process, which converts logic equations into device-specific information that gets programmed into the PAL. By default, a one-time programmable PAL has all of the AND gates connected together by blowable fuses. The fuse map describes which fuses to blow, and which ones to keep intact.

The programming interface for a PAL allows for both burning the fuse map, but also for reading it out to verify that the programming worked. This blowing of fuses is a physical thing that happens in these OTP chips, and so it has to be verified that, in fact, it worked. So a normal part of programming is also reading back the configuration.

As part of the programming process, you can choose to blow the security fuse on the PAL, which does not allow for the reading of the fuse map back out of the device. I’ve read that there’s ways to bypass this fuse, and if you have more information, please share!

Expensive PAL Readers

Programmers like the Xeltek Superpro 1600N support reading PALs and GALs, assuming their security features have not been enabled, but at a cost in the neighborhood of $1100. There may be some other less expensive ones, and if so, make sure and let me know. The problem is that there’s no silver bullet here, and just plunking down the cash does not guarantee success.

Latches and registers(more state, oh my!)

The net effect of having any type of state, whether it’s a latch on an output pin or a register to store a few bits is that it makes it harder to reverse. Why? Because now the output is NOT simply a function of the input, it’s input+existing state=output. How many bits of state are there? Which output pins are affected by this state? This is hard to know without more detailed analysis, which we’ll get to!

Resets

For many circuits, whether they are in physical silicon form, soft IP, Verilog modules, etc have a reset pin. Whenever the sequential(remember, contrast this with combinatorial!) logic circuit in question has a state, then there has to be some mechanism to reset it back to the initial starting state. Machines crash, get restarted, have errors, and so on. Many systems assert a system-wide reset on startup, sometimes by use of a simple 555-timer circuit, to get all of the separate pieces default back to the initial state.

What happens is that during a ROM dump of a PAL is that if one of the input bits is a RESET then you have modification of the internal state of the device any time those particular “addresses” are accessed.

Wrapping up…

Now it should be obvious to see why that sometimes you can ‘dump’ a PAL but many times you can’t.

The next installment in this series will talk about understanding the system. This will include trying to determine how much state your particular target PAL has.