Wednesday, October 2, 2019

AT89C51 glitching


Above: MJ-DFMJ. AT89C51 lower left

We have a number of inherited dumped AT89C51 chips in our inventory as well as a few new undumped ones:

AT89C51 is known to be vulnerable to voltage glitching. Basically there is a race condition when erasing where the security fuse is erased before the main data. If you pull power at just the right time, you clear protection without erasing the data.

However, we had a few concerns approaching this:
  1. If glitching fails, it may erase the part
  2. Concerns over EA damaged to prevent readout
  3. Known microprobing alternate attack

We started by analyzing the chip health to see if they had damaged EA or other issues. While we didn't detect any issues with EA, we did see some odd behavior on C056. When an AT89C51 is protected, the debug interface shuts down and results in the following observations:
  1. Memory is read as 0xFF
  2. Chip ID as 0xFFF00
C056 reported its memory as 0xFF, but the chip ID was reported correctly (0x1E51FF). This implies that the chip is not only unlocked, but its also erased! To confirm this, we did the following:
  1. Create a test pattern of all FF's, except FE on the first byte
  2. Program test pattern, making sure erase is not selected. Programming will likely fail due to first byte not matching
  3. Read back chip. If unprotected, bit 0x01 is cleared on the first byte
When tested on C056 programming did not fail and the first bit was cleared. Unfortunately this is pretty concrete evidence the chip is not protected, and is indeed blank.

Moving on, we still have two chips that we'd like to dump. After some discussion, we decided the best approach was to attempt glitching once. If it fails, fallback to microprobing. Originally we tried implementing the glitch ourselves, but got access to a RunFei commercial voltage glitcher and went with that instead. Unfortunately, C054 did not dump via glitching and will have to be microprobed. 


However, C017 succeeded! It's unfortunate we only got 1/3 dumped so far, but its still good progress that 2/3 of our AT89C51 inventory is processed. We are also investigating using the RunFei for related chips like AT89C2051.

Stay tuned for a post on 87C51!


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.

Lucky HD647180


We previously dumped some HD647180 and TeamEurope asked if we could do a few more.


The new chips are in obscure gambling machines of which little is known other than a little work on Lucky 74. The boards don't even work, but we hope that a successful ROM extraction could be used to learn more about them.



However, these were in the more obscure SDIP90 package. To truly appreciate their massive size, here'ss one with a DIP40.



We've numbered these C050 to C053. They are the same size as a Motorola 68K, but have a 0.07" pitch instead of 0.1". SDIP90 seems rather uncommon and I wonder if there are any other chips that use this package.


Unfortunately, while we both BP Microsystems and Xeltek make SDIP adapters, we've only seen them to 64 pins.


So TeamEurope helped design an SDIP90 to 27C256 EPROM adapter so that we could use a commodity device programmer. Originally we thought we'd have to solder each chip in, but somehow managed to find an SDIP90 socket.


We proceeded to decap a sample SDIP90 part to try to reduce the following risks:

  1. Organic film over chip can be difficult to remove
  2. Some QFN parts have a wire bonding defect (see previous post)
  3. The SDIP adapter was untested
Early testing also revealed the sample was received protected. Interestingly, it had a similar sticker residue (the sticker itself was gone) to the target chips.


Here's some of an organic layer that wasn't fully removed. It must at least be partially removed to expose the security fuse and allow applying a mask to protect the EPROM. We're not sure what its made out of, but its possibly silicone. Its very chemically resistant but is relatively soft and, if the bond pads are strong, can be removed mechanically by gently tugging on it. More chemical treatment seems to soften it more, so is a delicate balance between prolonged acid exposure (weakens material but can weaken pads) and mechanical force applied to the wires. On the sample we used a mix of white fuming nitric acid (WFNA) and H2SO4 at a relatively low temperature based on some previous notes. This seemed to work pretty well and the sample was processed successfully.


No bonding defects were found.


We applied a UV mask like done previously and cleared the security bit. Fortunately the adapter worked we we successfully dumped the sample! Unfortunately, there are no strings in it, so we really aren't sure what it is.

Anyway, the process was then repeated to successfully dump C051 to C053! Sample strings from Lucky 21-D / C051:

000011d0  13 e1 c1 23 23 10 dc cd  08 06 c9 18 43 52 45 44 |...##.......CRED|
000011e0  49 54 20 49 4e 00 18 43  52 45 44 49 54 20 4f 55 |IT IN..CREDIT OU|
000011f0  54 00 18 43 52 45 44 49  54 20 25 00 18 25 00 18 |T..CREDIT %..%..|
00001200  54 4f 54 41 4c 20 42 45  54 00 18 54 4f 54 41 4c |TOTAL BET..TOTAL|
00001210  20 57 49 4e 00 18 57 49  4e 20 25 00 18 25 00 18 | WIN..WIN %..%..|
00001220  50 4c 41 59 20 43 4f 55  4e 54 00 18 25 53 45 54 |PLAY COUNT..%SET|
00001230  20 43 4f 55 4e 54 00 18  50 4f 57 45 52 20 4f 4e | COUNT..POWER ON|
00001240  20 43 4f 55 4e 54 00 10  50 55 53 48 20 53 54 41 | COUNT..PUSH STA|
00001250  52 54 20 53 57 20 46 4f  52 20 51 55 49 54 00 20 |RT SW FOR QUIT. |

However, you may have noticed we omitted C050 (Lucky 25). We were having some issues removing the organic layer and so did a little more H2SO4 acid soak at a relatively low temperature. While this was fine in testing, it resulted in corrosion on C050 pads. We switched to pure WFNA for C051 to C053, which results in more package wear but, when done properly, is gentler on the actual die. We're looking into options to repair the pads. This would be pretty straightforward with a FIB, but unfortunately don't have access to one. There are also some alternatives under investigation.

Special thanks to TeamEurope for both supplying the chips and designing the adapter board! Finally, stay tuned for AT89C51 glitching post!

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.

Thursday, July 4, 2019

Rainbow Islands (Extra Version) C-Chip


Rainbow Islands (Extra Version) is a variant of the original Rainbow Islands game with tweaked enemies and music. While this game was well enough understood that it was playable in MAME, it had some hacks to get around differences between the classic and extra version. While we've been interested to dump it from the beginning, our c-chip dumping process is destructive and unfortunately this game is relatively rare. However, Kevin Eshbach donated a chip in the spirit of faithfully preserving this game for generations to come. Thank you!


Originally we hoped to experiment with a tungsten probe card and/or pogo pin PCB to make dumping quicker and/or maybe even keep the chip alive. However, it's been sitting in inventory for a few months now and we decided to do the existing method in the interest of progress. After all, there would be nothing worse than sacrificing a rare game to get nothing at all!



So the traditional procedure was done and successfully gave us a dump!

So what did we learn from the dump? First, some details about existing MAME workarounds. MAME devs observed enemy attribute and world structure differences that could be explained by simple table changes from the classic c-chip firmware. Additionally, some tables needed to be reordered due to level order changes. MAME developers then wrote a new extra edition ROM that behaved like the Taito extra edition ROM by tweaking the table data and adding code to swap table order.

However, it was expected that the real Rainbow Islands Extra c-chip ROM would reorder ROM tables according to the order expected by the game. To our surprise, Taito instead modified the pointer table.  Data structure aside, the table data itself matches the predicted values. Finally, the dump confirmed no fundamentally new features were added.

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.

x

Saturday, June 1, 2019

Mosaic (Space) PIC16C5X


The PCB for this game has this curious chip:





Chip markings have been shaved off leaving just "A" visible on top and "357" on the bottom.


However, it was suspected to be a PIC16C57. Looking at this table, based on package, it could also be  PIC16C55:


We stuck it in our programmer and successfully dumped it as a PIC16C57 protected/truncated binary.  Unfortunately the programmer didn't recognize a device ID for PIC16C55 vs PIC16C57, so still not sure.

It was then decapped:


Which looks more like a PIC16C55 like we saw before on High Seas Havoc:


Masked:


Which was successfully unlocked! When dumped as a PIC16C57 (2K words) we get two identical dumps, noting that half of it looked like reserved / internal PIC data. So really only one unique 512 word code section. With all of this we are pretty sure its PIC16C55.

Finally, we briefly compared it to the existing workaround in mosaic.cpp:


Now compare this to some Ghidra disassembly:


And we see the same table!

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.

Thursday, August 30, 2018

Operation Wolf c-chip c-omplete!

Background:
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.

Wednesday, May 23, 2018

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.

Monday, May 7, 2018

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.