Thursday, October 24, 2019

C055: changyu2/CYE 87C51

TeamEurope recently asked us to dump an 87C51. We thought we had done this before, but turns out we had only looked at related chips like 8751H and 87C51FA. This adds a few complications:
  • Not known if vulnerable to laser glitching like 87C51FA
  • Don't have a known fuse location like 8751H
  • Not familiar with the XOR encryption scheme


So we procured some sample chips, this time literally marked SAMPLE.


Sample decapped


After a few masking tests, we discover the security fuses are in the location marked above. This makes the project interesting because its rather close to the EPROM. However, we are able to apply masks reasonably precisely, so didn't worry about this too much.



Here is the final mask on C055. Note that the mask was applied pretty heavily to try to minimize edge leakage.

00000000  ec e1 45 b3 09 23 a2 dc  fd bf 76 65 8d 61 20 a3  |..E..#....ve.a .|
00000010  21 54 fc 76 da ef 54 32  44 da bc 30 54 33 35 61  |!T.v..T2D..0T35a|
00000020  12 32 45 83 f4 5d a2 dc  fd bf 76 55 fa c8 12 9e  |.2E..]....vU....|
00000030  51 de b3 b3 66 a0 a3 b8  2b e5 10 92 5b 8f 5a a9  |Q...f...+...[.Z.|
00000040  98 44 ab c4 87 7f 28 a9  13 35 01 16 fa d8 02 28  |.D....(..5.....(|
...
This yields the ROM above!

However, this is encrypted, so we now need to address cracking the XOR table. The basic idea is that there are 0x20 XOR encryption key bytes that are linearly applied, modulo the address. However, since the default key of 0xFF should not change the contents, the result is also inverted. This yields something like this:

for address, pt_byte in enumerate(plaintext):
    encrypted[i] = pt_byte ^ key[address % len(key)] ^ 0xFF

Now with this in mind, note that the key cannot be read out, even if the chip is unprotected. Some options to deal with this:
  • Reprogram the table and XOR out the key from the new ROM readout
  • Guess the key
Guessing the key is probably not too hard as, for example, usually firmware starts with LJMP (0x02). More on this later.

We started by looking at reprogramming the XOR table as a direct extraction technique. Unfortunately, our primary programmer (BP Microsystems) doesn't allow directly programming the table. However, the commercial minipro software did:


We set the key to 0 which yielded this:

00000000  fe d3 00 fd fd 7e 00 00  00 00 00 fd fd fe cd 00  |.....~..........|
00000010  00 00 00 cd 00 00 00 00  00 00 00 cd 00 00 00 00  |................|
00000020  00 00 00 cd 00 00 00 00  00 00 00 cd 8a 57 ff 3d  |.............W.=|
00000030  70 8a 4f 08 bc 4f f7 8a  6f 3f ac 6f 0f bc 6f c8  |p.O..O..o?.o..o.|
00000040  8a 76 ee 8a 73 22 8a 75  ee 8a 77 8e 8a 47 ef 8b  |.v..s".u..w..G..|

Now XOR'ing the two dumps:

00000000  12 32 45 4e f4 5d a2 dc  fd bf 76 98 70 9f ed a3  |.2EN.]....v.p...|
00000010  21 54 fc bb da ef 54 32  44 da bc fd 54 33 35 61  |!T....T2D...T35a|
00000020  12 32 45 4e f4 5d a2 dc  fd bf 76 98 70 9f ed a3  |.2EN.]....v.p...|
00000030  21 54 fc bb da ef 54 32  44 da bc fd 54 33 35 61  |!T....T2D...T35a|
00000040  12 32 45 4e f4 5d a2 dc  fd bf 76 98 70 9f ed a3  |.2EN.]....v.p...|

Which means the encryption key is:

00000000  12 32 45 4e f4 5d a2 dc  fd bf 76 98 70 9f ed a3  |.2EN.]....v.p...|
00000010  21 54 fc bb da ef 54 32  44 da bc fd 54 33 35 61  |!T....T2D...T35a|

Applying the key now to the original dump:

00000000  01 2c ff 02 02 81 ff ff  ff ff ff 02 02 01 32 ff  |.,............2.|
00000010  ff ff ff 32 ff ff ff ff  ff ff ff 32 ff ff ff ff  |...2.......2....|
00000020  ff ff ff 32 ff ff ff ff  ff ff ff 32 75 a8 00 c2  |...2.......2u...|
00000030  8f 75 b0 f7 43 b0 08 75  90 c0 53 90 f0 43 90 37  |.u..C..u..S..C.7|
00000040  75 89 11 75 8c dd 75 8a  11 75 88 71 75 b8 10 74  |u..u..u..u.qu..t|

However, this is suspicious. Usually the first mcs51 instruction is 0x02 (LJMP). However, popping into Ghidra:


Aha! They've just used AJMP instead of LJMP. Additionally we see clean disassembly and familiar register initialization. We have a dump!

Finally, what if we tried guessing the key? Well, we probably undersold just how bad this scheme is. One major flaw is that often people don't use the entire chip and its partly left unprogrammed (ie 0xFF filled). Here's the end of the encrypted dump:

00000fa0  ae cd bc bd f5 82 66 23  04 4c 77 47 ba 60 14 50  |......f#.LwG.`.P|
00000fb0  20 8b 2c 44 23 1c 55 cd  bb 25 43 02 ab cc ca 9e  | .,D#.U..%C.....|
00000fc0  ed cd ba b1 0b a2 5d 23  02 40 89 67 8f 60 12 5c  |......]#.@.g.`.\|
00000fd0  de ab 03 44 25 10 ab cd  bb 25 43 02 ab cc ca 9e  |...D%....%C.....|
00000fe0  ed cd ba b1 0b a2 5d 23  02 40 89 67 8f 60 12 5c  |......]#.@.g.`.\|
00000ff0  de ab 03 44 25 10 ab cd  bb 25 43 02 ab cc ca 9e  |...D%....%C.....|

Where near the end we clearly see a pattern repeated every 0x20 bytes, the telltale sign of filling with 0xFF. So yeah...pretty weak encryption as this is simply inverted to extract the key.


We also recently received a bunch more chips, including a number of 87C5X. So hopefully there will be a follow up soon.

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