Operation Wolf c-chip c-omplete!

Background:

• Looking inside Taito C-Chip
• Taito C-Chip: data by lobotomy

Our quest to acquire the Operation Wolf c-chip EPROM content was the most exciting. Since they are relatively common we used a few Operation Wolf c-chips for some early dump attempts. For example, we milled just above the EPROM, cut the wires, and tried to patch in. However, this was deemed too risky with the time and equipment we were willing to put into it.

Next, we explored a badly damaged Bonze Adventure c-chip:

We were able to patch onto the busted EPROM pads and verify the chip was still alive. This inspired us repackage an Operation Wolf die:

This gave us more room to work and resulted in a partial dump. For example, we got this string:

By_TAITO_Copration_On_OSAKA_BUNSHITU._01.Sep.1987_Toshiaki.Kato_Tsutomu.Yoshikawa_4

However, the setup was flaky and we decided it would be better to try something else than improve this method.

We analyzed the c-chip further and came up with a plan to replace the ASIC with external EPROM hookups:

This successfully dumped various c-chips. However, we used all of our Operation Wolf chips during initial testing, and needed another. So someone donated this c-chip:

We soldered it up:

...but it didn't resemble the original Operation Wolf dump! The ROM was much shorter and lacked the "By_TAITO_Copration" (sic) string. We checked our archives and discovered it matched the existing Superman dump! This board was in unknown condition and we suspect someone (unsuccessfully) swapped parts trying to fix one. With the sticker worn off we didn't have a way to verify contents without doing our extraction procedure.

Fortunately our donor had another chip, this time with an intact sticker:

Soldered up:

And got a good dump!

This makes a total of 7 c-chips wired up:

for a total of 6 EPROM dumps.

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

8751 close shave

In the previous post we discussed dumping a lot of mostly PIC16C57s. These also came with a pair of 8751 chips. The first being F-1 Dream (C014):

And the second being Breywood (C015):

The Breywood gold top packages are rather easy to decap as the package is simply heated up and the steel cap is lifted off:

This was then masked and dumped with a masked UV attack as done in previous posts:

The F-1 Dream is a glass frit CERDIP which is a little trickier to decap. Glossing over details, the best technique we've come up with is to strongly heat the top to release it. This melts the glass holding it on without melting the glass holding the pins in place. However, this is a delicate operation that can go wrong in many ways.

Here's the die after decap:

Which was masked like on Breywood:

However, the chip did not dump. Closer inspection revealed the leadframe had shifted a bit and had caused some minor bond wire damage, notably one had completely snapped. This is very hard to see in the pictures, but was easily found with a continuity test and some probing. So it was patched with some epoxy:

Even after this, dumps were very flaky. We got a few decent looking dumps but they started getting worse. We suspected bad pin connections and tried to clean up the chip a bit more. However, on closer inspection we noticed microfractures on the die:

So, it seems that we narrowly got this chip dumped before it stopped working. We could have potentially patched some of these up, but this would have gotten complicated quickly.

What happened? In the past we had pre-heated the chip / workholder for longer, but this time didn't wait quite as long. We suspect that the chip was cooled faster than expected, causing the microfractures. Suppose all is well that ends well, but a lesson for the future to be more conservative on these parts.

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

Mostly PIC16C57

We were recently sent 8 "PIC16C57s" from:

High Seas Havoc (403/C013)

Wargods (U69, C020)

MACE (U96, C021)

Carnevil (U96, C022)

BioFreaks (C023)

Gauntlet Dark Legacy (C024)

Gauntlet (U37, C025)

Blitz 99 (U96, C026)

Here are the packages:

First, note the upper left chip (BioFreaks):

Hmm, that's not a PIC16C57 but rather a PIC16F57. We decapped a sample and its much finer technology than we've dealt with so far. This one's been shelved for now in lieu of easier targets.

Next, note the lower left chip (High Seas Havoc (HSH)):

The marking has been removed, but this is allegedly a PIC16C57. We popped it into a reader and it spit back a scrambled (protected) dump, so this was plausible.

Here are most (Gauntlet Dark Legacy not shown) of the PIC16C57s after decapping and masking:

These were dumped as done in previous posts. Here's Wargods close up:

Next, you'll notice there are only 6 chips left of the original 8. In addition to BioFreaks, HSH was in fact not a PIC16C57. Additionally, its wires were a bit higher and got trimmed during decap:

While its not a PIC16C57, it does look close, basically just with a smaller EPROM. It looks to be about 1/4 the size of PIC16C57 (2K), so lets say its probably 512 words. There are two members of the PIC16C5X family with 512 words: PIC16C54 and PIC16C55. PIC16C54 doesn't come in DIP28, so its probably PIC16C55.

Fortunately we had a PIC16C55 on hand:

Here's the identifying info on HSH:

And here's a PIC16C55 sample:

Odd...the die ID matches but the masks don't completely match.  After some discussion, we decided this was close enough to proceed. The main concern is that PIC16C55A has some more sophisticated protection that might be problematic if we tried a simple UV attack. However, HSH has a 1988 copyright, and the sample has a 1988 copyright as well. Additionally, we know that PIC16C57C was a big redesign over PIC16C57. So all evidence points that this really is a PIC16C55 despite the different masks.

We secured a sample and applied a mask:

Which after 15 minute or so of UV erasing had lost protection but retained the original data.

Next we mended the broken wires. When we fixed similar chips in the past, we installed new wires. However, there are mostly wires intact, they just need some bridging. So instead of adding wires, we just carefully added conductive epoxy tracks to bridges them back together:

Here the nail polish is being used to strengthen the wires from breaking as they get pushed around and also from having the epoxy short out against the edge of the die (see the lower left connection for example). This passed continuity and gave out the scrambled output we saw before decap.

We then added additional masking to fully cover the EPROM;

After 15 minutes of UV erasing we were able to retrieve the ROM.

Finally, a few small updates on works in progress:

• Taito C-Chip: we've dumped all samples we have except Operation Wolf (partial dump only). We have a spare chip in hand but we'd like to try a bit more to extract one of the existing decaps first
• Contact mask ROMs (TGP + MCS48 such as Great Swordsman): general consensus is that the TGP captures are mostly acceptable, but the MCS48 captures are too noisy. We've briefly explored a few alternate capture techniques to improve accuracy, but haven't found something we are satisfied with yet
• Altera FPGAs: we've been unable to identify the specific chip used for 79/80 based on samples we've procured. Reach out if you have interest in this / think you might have something to contribute
• As the chips that can be trivially dumped dwindles, we are evaluating new analysis techniques. Some of these updates may be less frequent, but the write ups should be more involved

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

Taito C-Chip: data by lobotomy

In a previous post we described some early attempts to analyze the Taito C-Chip. See Haze's forum post for some background on the C-Chip itself.

In particular we're interested in the EPROM. Previous efforts focused on less invasive techniques with the goal of keeping the C-Chip alive after dumping. Unfortunately, we've been unable to successfully send an unlock command and efforts to rebond the EPROM die have been difficult with the equipment we have on hand.

With this in mind, we took a break to regroup. If we remove the ASIC we can solder to PCB traces shared with the EPROM. Traces are documented in our wiring diagram:

Which allows us to make an attack (soldering) plan:

The basic idea is to mill and etch away the purple masked area to expose the PCB. Then, solder wires as indicated by the green dots.

A few issues, but nothing too bad. First, this implies requires removing the ASIC to have enough room to work. As there is not a reliable way to safely remove it (or easily put it back for that matter), this means killing the module. Second, the PCB traces are roughly 6 mil (ie 0.006" => 0.15 mm) width and roughly 12 mil (0.3 mm) pitch. These are non-trivial to solder, although doesn't require as much precision as hand wire bonding (roughly 0.1 mm pads at 0.2 mm pitch). Sort of like soldering a bunch of "0201" size resistors in close proximity.

Lets get started. First, take a c-chip:

Mill it to near PCB:

We went about 2.5 mils down at a time until the ASIC paddle just starts to show. You can see bits of shattered die clinging to the paddle corners.

Then use acid to fully expose PCB:

Next tin areas where we'll make connections:

Now mount to protoboard:

And wire up:

Which successfully dumped the EPROM!

A little hard to measure, but it takes roughly 3 hours per module using this technique. Definitely better at soldering since starting this project.

To date we've dumped Volfied, Superman, and Bonze Adventure (not shown):

Volfied (top) was our first attempt and has the CPU removed due to some early issues getting a dump. We thought the CPU might have been driving some control lines, but it turned out to actually be some solder debris shorting out the power rails. Surprisingly our programmer didn't generate any error messages (over current, continuity, etc).

We have a few more chips in the pipeline that we expect to finish over the next couple of weeks. We're still figuring out which chips, if any, we still need to source to cover all known games.

We've also continued to think about the best ways to keep the module alive. There are still a few options like decapping the area between the dies and using a laser cutter to isolate the EPROM control lines from the ASIC. This is a littler riskier though as we might accidentally sever a bond wire or corrode EPROM pads. For example, if any solder crept to the bond wire it would dissolve the gold, severing the connection.

Finally, what about keeping the PCBs alive after the C-Chip lobotomy? At this point we're thinking the best option is to design a C-Chip compatible module. We know the CPU, have the firmware, and have a reasonable understanding about how the ASIC works. We suspect with a little fiddling one should be able to figure out the remaining details. That said, we'd like to focus on the extracting data rather than repairing PCBs. So this may be left as an exercise to the reader.

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.

EDIT: Rainbow Islands dumped!

Decap C016: GMS' MJ-DFMJ (PIC16F84)

We got this PCB:

Sounds like there's some debate as to what this game is called, and we couldn't find much info elsewhere about it either. The EPROM's have "MJ-DFMJ" stickers, so we're rolling with that for now.

It has a secured PIC16F84 here:

A sample PIC16F84 was decapped to yield:

With the main memory areas as:

We then live decapped a few:

And put them into a UV EPROM eraser but, while flash and EPROM were erased, the security fuse was not. No dice either using angled erasure even with varying angles and long erasure time.

Time to regroup. Where are the fuses on the die? These seem like a good candidate:

Such that the metal rectangles are shielding. Configuration words correspond to 4 14 bit (56 bit total) user configurable words and 1 general configuration word that's either 4 or 14 bits depending on how literally you interpret the datasheet. The left grouping has 6 * 8 rectangles above and 2 * 3 rectangles below = 54. Close, but not quite right. This area is still plausible if you count adjacent rectangles, but more likely these are capacitors for ADC or something of that sort.

But not to worry. Part of the reason we agreed to do this part is that there are several known attacks against it. First, there are voltage glitching attacks. Second, the same author also mentions that PIC16F84 is vulnerable to optical glitching (pg 104): "The light from the 20 W halogen bulb installed inside our probing station microscope’s illuminator".

Optical glitching is somewhat straightforward to try out, so we started with that. One risk with optical glitching though is that it can cause the chip to latchup (short out), destroying it. Fortunately we have a high end programmer that cuts power if it detects unusual power draw. Anyway, first a sample chip was decapped live. Then, we enabled protection and started repeatedly reading the chip. At the same time we shined a red 5 mW laser pointer randomly across the die and observed responses. Unfortunately, this didn't do much...maybe gave a few bad reads. However, we re-tried with a green 5 mW laser pointer and got it to dump its contents despite being protected!

Unfortunately, this was really hard to reproduce. Fortunately Tim the Toolman Taylor taught us the solution to every problem: MORE POWER! We switched to a 200 mW 650 nm red laser and got more reliable dumps.

We were able to roughly narrow it down to the lower right of the die (relative to above images) but for various reasons decided to get more specific information. Targeting a region also reduces the chances of latchup, although tests showed that the programmer was sufficiently protecting against everything we tried.

Towards that goal we put the sample on our microscope XY stage and tried to trigger glitches using its illuminator. Unfortunately, we were unable to get any responses at all, protection or otherwise. However, we know the high power red laser works reliably. So we mounted it to the microscope XY stage and recorded responses. This roughly gave:

Where:

• Red: power out of spec / overcurrent shutdown
• Green: protection disabled
• Gray (hard to see): no response
• The left and bottom (beyond the red/gray) are not entirely in the scan

Close up of this region:

There are 14 repeated units, so its plausible this is the configuration word. Presumably shining the laser here forces the entire configuration word to all 1's, unlocking the chip.

With this in mind we decapped the real PIC16F84 and repeated the attack, successfully dumping its flash and EEPROM. Victory!

We also did a few follow up experiments. First, we added neutral density filters to the high power red laser, attenuating the beam by 64x (ie <5 mW), and was still able to dump. Second, we re-tried microscope illumination glitching and were able to get this region to glitch:

Which is in this area:

Shrinking the region or moving away removes the glitch. Other regions may work; it wasn't investigated thoroughly. 100x magnification was required at max power (50W bulb, no polarizers, etc).

We also have an AT89C51 in the pipeline from the same board, but are hitting a snag related to getting samples successfully programmed. Hopefully this will be resolved soon and we'll shortly have a follow up post.

Special thanks to EdHunter for supporting this project!

Enjoy this post? Please support us on Patreon! Note: with the Indiegogo campaign over we unfortunately don't currently have a way to accept one time donations.