×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Semi-Automatic Hacking of Masked ROM Code From Microscopic Images

Soulskill posted about a year ago | from the making-a-computer-read-a-computer dept.

Security 42

An anonymous reader writes "Decapping chips and recovering code or data is nothing new, but the old problem of recovering Masked ROM through visual inspection (binary '0' and '1' can be distinguished within the images) is normally done by crowd sourcing a manual typing effort. Now a tool that semi-automates this process and then recovers the data automatically has been released."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

42 comments

india-nigger (-1, Troll)

SparrowOS (2792265) | about a year ago | (#42806323)

The C64 ROM was not hidden. Reverse engineering is for niggers.

Re:india-nigger (-1)

Anonymous Coward | about a year ago | (#42806435)

So you copied ROM to RAM and poked around at the ROM BASIC's variables, after reading a book. Jealous? Bet you cant reverse engineer shit!

THIS is what we need more of on /. (0)

Anonymous Coward | about a year ago | (#42806601)

This is proper hacking. Not the 'I figured out how to wire an LED and a battery together' shit that usually infests Slashdot.

Re:THIS is what we need more of on /. (0)

Anonymous Coward | about a year ago | (#42807209)

You can do that? How?

Re:THIS is what we need more of on /. (4, Insightful)

Jorl17 (1716772) | about a year ago | (#42807621)

And yet, only 18 comments. Why? This was the most awesome article in MONTHS.

Re:THIS is what we need more of on /. (0)

Anonymous Coward | about a year ago | (#42812637)

For 5 nerds, maybe. Quite frankly most of us couldn't give half a rat's ass about this.

This is awesome... (4, Interesting)

jonwil (467024) | about a year ago | (#42806751)

Could be useful for future MAME work if someone is able to decap (and photograph) various otherwise un-dumpable mask-ROM-based MCUs and other chips.

Re:This is awesome... (4, Interesting)

Rik Sweeney (471717) | about a year ago | (#42806927)

Interestingly, this was done for Bubble Bobble to ensure that the emulation was perfect:

http://mamelife.blogspot.co.uk/2006/08/completed-at-last.html [blogspot.co.uk]

Re:This is awesome... (4, Informative)

Anonymous Coward | about a year ago | (#42807059)

This is done for the SNES, and all known coprocessors have been perfectly emulated. Write-up here [byuu.org], with pictures and explanations.

Re:This is awesome... (3, Insightful)

Applekid (993327) | about a year ago | (#42809339)

I'd like to take a moment and thank all these people for working tirelessly in uncovering these secret bits of gaming history. I'm both envious of how smart these people are and grateful that they've spent their energy on something I just so happen to love.

Re:This is awesome... (1)

Khyber (864651) | about a year ago | (#42809577)

Sadly that perfect emulation also means perfect errors popping up on poorly-coded ROMs.

This is why I use ZSNES for Super Nintendo. Those errors in ROM, ZSNES can work around them without any in-game problems. Byuu does exactly as it's supposed to, and fails upon the error.

Sometimes, perfect emulation isn't warranted.

Re:This is awesome... (1)

chrylis (262281) | about a year ago | (#42807045)

*crosses fingers* Please, Raiden II, please, Raiden II...

Re:This is awesome... (3, Informative)

jonwil (467024) | about a year ago | (#42807131)

The devs have said many times that decapping will NOT help emulate Raiden II

Re:This is awesome... (1)

chrylis (262281) | about a year ago | (#42809083)

My understanding was that the issue wasn't that they didn't have a dump but that there was a one-off coprocessor that nobody had specs for. Would this not be of any assistance reverse-engineering such a chip?

Re:This is awesome... (2)

Khyber (864651) | about a year ago | (#42809655)

In fact, it's this very chip you mention that prevents Raiden II from being emulated at all. It's a specialized coprocessor harking back from the 386/486 era, though this chip isn't Intel-made.

The purpose of this chip was to handle the flight paths of all the bullets flying around, thus relieving the main CPU from having to raster/render all these sprites and the direction they'd go.

Also, this same chip controls the homing plasma cannon beam.

And even then, (depending upon the arcade manager) at higher difficulties the arcade machine would still lag, going from 30FPS to roughly 17-20FPS during a nasty bullet storm.

Re:This is awesome... (1)

harrkev (623093) | about a year ago | (#42810493)

No. The technique described here works perfectly well for ROM images. This is because the data is actually encoded in the metal layers. I would presume that the underlying silicon is just a regular grid on transistors, so you can effectively ignore it.

Now, an actual processor, on the other hand, is a completely different can of worms. In order to reverse-engineer it, you would need not only the information from the metal layers (and not just the top metal layer), but also reverse-engineer the actual cells used in the layout.

I would guess that a chip from that area would probably have around 4-5 metal signal layers (just a wild guess). You would first need to map out each metal layer separately. If a trace goes UNDER another trace, you still need to be able to follow it. Is this possible with fancy image processing? I don't know -- If you took a bunch of pictures under a microscope with varying focus adjustments, you might be able to tease together a 3d image. Another way to approach this might be to physically grind off each metal layer at a time and take pictures. Difficult, but possible in theory.

Ok, once you have the metal layers decoded, you still need to know what the actual cells are (is that an inverter or a register). If you have access to the original libraries used to make the chip (good luck since they are typically under NDA), then you could probably use the metal-1 layout to figure out what the cell is. If you do not have the libraries, then you have to do some educated guesses to figure out what each cell is. Possible, but it would certainly take a person with some very good knowledge of CMOS circuit design to recognize the circuit. Big clues would be the size of the cell and the number of ports.

I certainly have not done this, but, given my knowledge of ASIC design (I have done a couple of chips), this is how I would probably go about it. Yes, with enough resources it is possible, but would likely be either very time-consuming or very expensive, or both.

Re:This is awesome... (1)

chrylis (262281) | about a year ago | (#42819509)

So the gist is that the basic principles ought to work but that the advances in ASIC manufacturing between the 8085 and Raiden II mean that it's not feasible now to reverse-engineer the coprocessor?

Re:This is awesome... (1)

harrkev (623093) | about a year ago | (#42820493)

Not at all. I am pretty sure that there is somebody out there who could reverse-engineet it. This is rather old tech at this point. However, who is going to pay them? I would susupect that this would be too much of an effort for a hobbyist.

Re:This is awesome... (0)

Anonymous Coward | about a year ago | (#42813685)

It's not even a coprocessor, per se - a coprocessor would indicate that there's a stored program somewhere that could conceivably decapped and read out.

The Seibu COP, on the other hand, is simply a custom gate array from (I believe) Toshiba. VLIW-like "instructions", if you can call them that, are sent directly to it by the main CPU, and after a given number of cycles the result is presented. There's no real independent functionality, which makes any sort of decapping effort a dead stop.

Re:This is awesome... (1)

Khyber (864651) | about a year ago | (#42809595)

The devs don't have a working Raiden II board. I do (arcade cabinet got leaked upon from the top, ruined the CRT and controls, board left intact and undamaged.) Decapping will DEFINITELY help as Raiden II had a coprocessor to help handle the incessant bulletstorm.

As said this is not really new... (5, Informative)

rimcrazy (146022) | about a year ago | (#42807047)

I use to work for a large semiconductor company that manufactures microcontrollers. (I won't say who but they really make very small micro chips) I got into hot water once as I was the geek they called into a meeting to explain to a customer just how secure their technology was and because the rom code was stored in EEPROM that all was safe and secure. Well, first, no one told me the issue that was bothering the customer and second, they just called me in cold and I was asked "Can someone reverse engineer the code that is stored in the device." Being Dilbert to a T I looked at the crowd and said, "Sure if you have enough money. Just decap the device, put it into a voltage contrast SEM and fire it up. You'll have nice pictures of bright and dark spots on the memory array and in no time you'll have the code". Customer went batshit. My boss gave me the look of death and I'm standing there saying "What?" "You asked me if it can be done" "I just told you how to do it. It's not cheap but it's possible".

These days this is probably a lot more difficult as many, not all, but many IC's are mounted in a package face down as they use bump technology to do both die attach and signal connections.

Re:As said this is not really new... (1)

omglolbah (731566) | about a year ago | (#42807061)

And really.. if your code is THAT important, you should use a security-based chip to begin with.
There are tamper-resistant packages and a variety of defenses against this, but they all cost money.

Re:As said this is not really new... (1)

Anonymous Coward | about a year ago | (#42807275)

And even those measures (metal grid layers, e-fuses etc) can be defeated [flylogic.net] although as with any security it's about making it uneconomically difficult for most attackers to do so. Also the security shouldn't depend on any secrets like a hardcoded universal key or the fact that you fake the encryption - several "secure" flash drives have been found to do this, the unencrypted data can be read right off the flash when you bypass the controller.

Re:As said this is not really new... (2)

CODiNE (27417) | about a year ago | (#42811645)

Those fake encrypted flash drives remind me of the old Zip disks. If you put in a disk with a known password and unlocked it you could force it out and put in an encrypted disk you didn't know the password to. They didn't even bother to XOR the data with your password so any disk could be read that way.

Re:As said this is not really new... (3, Interesting)

Anonymous Coward | about a year ago | (#42808125)

I also work at a large semiconductor company. There is some interesting research in both mitigating and defeating chip security. One attack technique for breaking into chips is to hold the debug line high and scan a laser over the surface of the chip to randomly flip bits, hoping to flip the one that is locking the debug line low. If the hardware designers were not thinking about redundantly, physically separating things on the chip, you might enable debug mode which bypasses all the lockdowns and encryptions.

Hardware designers are wise to this of course, and now there are often entirely separate ARM cores with no purpose other than as a data integrity watchdog on the 'main' system(s) that can shut everything down. There are some very popular chips which use 2 identical ARM cores, one of which is delayed by 2 cycles. There is a dedicated circuit that performs a CMP on the output of the two chips and shuts everything down if there are any differences.

I have seen designs that hardware encrypt everything including the bus and the EEPROM, so all program code is stored in the EEPROM encrypted, so who cares if you can image it? The decryption key is stored, also encrypted, in the EEPROM as well. There is a separate master boot key which decrypts the memory decryption key stored in a special battery-backed RAM register, which does not leave an 'after-image'. If the hardware watchdog system detects any shenanigans, or if you try to remove the chip from the system without preserving the battery backing, the master key is simply flushed and the chip rebooted. At that point it looks like a blank chip that hasn't been through UV erase (random data everywhere).

I'm not a uC or hardware guy so some of this might be old news, but I found it interesting at least.

Re:As said this is not really new... (1)

slew (2918) | about a year ago | (#42811279)

FWIW, in some modern ICs (that I've worked on) the most critical parts of a rom (e.g., a boot loader that validates a pre-boot image), are generally not implemented as a masked rom, but basically compiled gates. The logic compiler (more often than not the program called Design Compiler from Synopsys) is given the contents of the rom described as a big case statement: given an address, assign data output. The compiler produces a semi-optimal set of logic gates to implement the 'ROM' function.

During the layout process, a big batch of spare gates is heaped into the mess in case a metal-mask patch is required. To create the patch, a complex tool is used to recompile the gates, using the constraints that only existing gates are used to create the patch. Although it sounds like a magical tool, most large semiconductor companies have such tools (often called ECO or engineering-change-order tools) to allow them to make small logical changes in a chip to fix small bugs in a few metal masks to avoid going through a whole chip refabrication that changes which gates are used (basically the same idea as a masked rom). For those software folks among us, think about the ECO tool as the hardware analogy of a tool that automates return-oriented programming (ROP).

Since the result is just a pile of gates and not a regular grid, it has the effect of retrieving the contents really difficult to automate from a visual inspection point of view (almost as difficult as the Logic-vs-schematic design verification process except now you have to create the schematic from pictures from different layers on the chip).

On the other hand, that is usually not the weakest link in the system. As mentioned, if the embedded processor can read the rom, it can be often tricked into doing so by being run in a debug mode, so this is only one piece of the security puzzle.

Re:As said this is not really new... (1)

flonker (526111) | about a year ago | (#42813885)

As I've learned, the correct answer is, "Sure, but it'll cost them $n megabucks, and it will take x amount of time." (I'm sure rimcrazy also figured this out since then.)

In confused America (1)

Dunbal (464142) | about a year ago | (#42807053)

Hacking your XBox 360 is clearly a crime worthy of being charged for, but taking the cover off a microchip and reading code that wasn't meant to be read is not a DMCA violation at all.

Re:In confused America (2)

RaceProUK (1137575) | about a year ago | (#42807103)

taking the cover off a microchip and reading code that wasn't meant to be read is not a DMCA violation at all.

You're not bypassing DRM, as there is no DRM. So no violation, beyond standard copyright infringement, and even that's a grey area.

Re:In confused America (0)

Anonymous Coward | about a year ago | (#42809255)

Except that you won't be charged with a crime for hacking your xbox.

Re:In confused America (1)

Applekid (993327) | about a year ago | (#42809395)

Hacking your XBox 360 is clearly a crime worthy of being charged for, but taking the cover off a microchip and reading code that wasn't meant to be read is not a DMCA violation at all.

That's only because the right folks haven't been getting their campaign contributions to make that illegal, too.

Wow (1)

zacherynuk (2782105) | about a year ago | (#42807069)

That is seriously interesting and very very impressive.
I can't help but wonder, though, if he hadn't popped the chip into a vat of boiling acid, he could have taken a note of the manufacturers code and dropped them a polite email... :)

Pshhhh...trivial challenge. (0)

Anonymous Coward | about a year ago | (#42807255)

I just feed it into my anti-mass spectrometer, and... VOILA.

Silly monkeys.

A better method: captcha (5, Funny)

ctrl-alt-canc (977108) | about a year ago | (#42807271)

Just split the ROM mask image into subimages, and ask engineers to decode a piece of the embedded code to access pr0n sites, and you will get the job done in a few minutes.

Semi-Automatic Hacking (2)

xdor (1218206) | about a year ago | (#42808179)

Isn't this banned? Or is it only the ones that have military features?

Re:Semi-Automatic Hacking (1)

Applekid (993327) | about a year ago | (#42809211)

Isn't this banned? Or is it only the ones that have military features?

I really don't see the need for the average citizen to use a semi automatic hacking tool. We should ban them and force hackers to reboot after every hack.

Re:Semi-Automatic Hacking (0)

Anonymous Coward | about a year ago | (#42813879)

Nothing is banned when you make your own rules.
Please leave your allegiance at the door.

trivial (0)

Anonymous Coward | about a year ago | (#42812041)

Haven't CD players been doing the same thing for a couple of decades now?

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...