Dumping Vulcan GALs...HELP!

... as they have a security bit. There were some experiments back in the day (mid to end 1980s) to dump them using differential current analysis but AFAIK this never worked well enough to get perfect dumps and also varied with GAL generation and manufacturer. So GALs were popular protection devices against copycats. And it worked. I had a product in the mid 1980s which was based on TTL (and was quickly copied by these parasites) but the next generation used the brand new GALs and never was copied, and made me my first million.

Oh, and about dumping PLDs/GALs back in the day, I was involved in this, too, as some companies had shot themselves in the foot by securing their production PLDs/GALs and all was fine and fancy until the masters were damaged (or lost in the mail) and the JEDEC files could not be found anymore, and the archived source listings (if existing) turned out to be earlier versions of the design. The designer had gotten a new PC and so all the makeshift "revisions" were gone with the old hardisk that was destroyed. That was before companies had company wide networks and routine backup capabilities.

What a mess. And a goldmine for our consulting company.

I don't say it's impossible to dump GALs but it's not easy and it's more a reverse engineering process involving special CAD programs and test vectors. Lots and lots of test vectors.

I would be interested if you find somebody who has a GAL dumper using differential current analysis which can extract the fuse map of a GAL with a set security fuse. Please send me a PM if you find this mythical device, or traces of it.

- Uncle Bernie

Thanks to nama_chari having piqued my interest in the topic, I searched around in the web and found this:

https://gitlab.com/MHeinrichs/galdurino

Looks like an interesting project and it's claimed it can read secured GAL devices. Since I have not built one and never had one of those, I can't vouch that it can accomplish this feat. But back in the 1980s we had  experts who somehow could extract the fuse map both from PALs and GALs. The PALs were easy: decap them and take a microphotograph of the die, and then look which fuses were burned and which were intact. GAL uses EEPROM cells so the optical method did not work. All I remember is that one of these "wizards" uttered the words "differential current analysis" but he of course never explained how he did it or the trick(s) involved. Some GALs he could read out perfectly, some with a few errors in the fuse matrix (which we fixed with further investigative work using sophisticated proprietary software and hardware) and others he could not read out. He took a heinous amount of money for this service. We did the same for our finishing work ;-)   .  .  . actually it's not too difficult to reverse engineer a GAL even no fuse map is known. It has at most 256 states (8 state bits in 8 macrocells) none of which are buried (so all are observable) and depending on how the device is used quite a limited number of free inputs. Say, 10 free inputs give you 1024 possible input combinations for each of the states. Even back in the 1980s, typical PCs were fast enough to systematically construct a state transition diagram using our proprietary software. Where it got tricky is asynchronous state machines where the state transitions are not triggered by the CLK input (pin #1 on all GALs). The GAL22V10 was much tougher, of course. All these algorithms and methods I had developed came from my ATVG work and never were published.  They worked fine for these relatively simple early PLDs but once the number of state variables exceeded 12, all bets were off. This is why the industry nowadays uses scan chains / scan test methods in their ICs. For PLDs, "preload" was similar but happened in parallel. Most security fuses suppressed preload for a reason. Aaah, the fond memories of the most interesting decade in programmable logic (1980 to 1990). After that, the more complex CPLDs came up and then the FPGAs. Beginning with the CPLDs most prior test (and reverse engineering) methods ran out of steam. Too many state variables, and many of them buried, not observable at a pin. It's called "technical progress".

- Uncle Bernie

There are more advanced techniques for reverse-engineering ICs, formerly very confidential and maybe even classified.

"Differential current analysis" is more commonly called Differential Power Analysis or DPA. The idea is to capture very detailed power consumption traces while feeding the IC samples of random data. Using a model of the internal register structure, you derive a function that predicts the value of a single bit based on the values of data entering that subunit (for a GAL it would be the value of a bitline between the NAND and NOR macroblocks), then correlating the power traces with the values of the modeling function to discover the unknown internal states.

There are many papers on the subject if you use the DPA search term. For example: https://paulkocher.com/doc/DifferentialPowerAnalysis.pdf

Another (destructive) method of inspecting an IC in operation is called a Focused Ion Beam workstation (or FIB). A kind of hotrodded scanning electron microscope, it can implant different ions selectively in small regions of a functioning IC. By thus "editing" the IC, it can be prepared for receiving microprobes on specific metal layers or even changing the characteristics of transistors. This is used to recover "transient keys" which normally would be erased by the device to prevent tampering.

To recover a GAL's program, it may be as simple as using a SEM, since the charge stored on the floating gates would repel the electron beam.

In post #5, robespierre wrote:

Another (destructive) method of inspecting an IC in operation is called a Focused Ion Beam workstation (or FIB).

Uncle Bernie begs to differ:

a FIB in competent hands is not necessarily destructive. We used FIB to "fix" botched IC designs by cutting metal traces and depositing new connection traces. And they worked afterwards ! The problem is that the operator of the FIB machine must be an engineer, a scientist and an artist and have a high IQ. Very hard to find nowadays. And he must have had *plenty* of experience with his particular FIB machine. The dreaded event is the "lightning flash" when something goes wrong and this often is destructive to the IC.

A truly skilled FIB operator could disable the "security bit" of any PAL or GAL in a few hours of work.

But I did not mention this in my above posts because I think this level of technology is far above what nama_chari would want to pay for the true, reverse engineered fusemap of his GALs. Give me enough money, and I will give you the keys to the powers of the Universe ... harharhar. Those who work for those big corporations are so spoilt that they don't see the costs / the economics of these marvelous technological gadgets.

- Uncle Bernie

Late reply, but I just stumbled across this thread by coincidence.

I've got one of those Galdurinos and have had great success with it dumping countless GALs.

What it does is actually pretty easy, it simply applies the programming voltage before turning VCC to the chip on and that is enough to get most GALs to ignore the security fuse completely and a normal read operation can take place.

It can even be done by hand with an interposer board in  a normal chip programmer. Cut VPP from the programmer to the chip and inject voltage through an external adjustable power supply.

The "attack" if one wants to call it that is timing and voltage critical so you have to play around somewhat for it to work.

Timing between turning on VPP and VCC and the value of VPP differ from chip to chip. Results are just as you described earlier how it was for your guys back then... sometimes it works perfectly, sometimes there are a few errors that need to be verified by trying over and over again comparing the changing fusemap outputs, sometimes it just fails altogether. So this is probably the same trick they used back then.

This method works for all GALs that follow the "original" Lattice programming algorithm.

AMD PALCE chips are not secure either. There are chinese programmers from back in the day that can disable the security fuse on PALCE16V8 and 20V8s leaving the chip unprotected so it can read with any other programmer afterwards.

Check out "Runfei" - their programmers had some other fancy features. I've got one of them and it can read some protected GALs as well using the same method as the Galdurino/manual reverse poweron sequence but the Galdurino actually works better.

ReactiveMicro sells them.