Raiders of the Lost ROM

Once upon a time, arcades were all the rage. You could head down to your local arcade with a pocket full of quarters and try many different games. These days, video arcades are less popular. As a result, many old arcade games are becoming increasingly difficult to find. They are almost like the artifacts of an ancient age. They are slowly left to rot and are often lost or forgotten with time. Enter, MAME.

MAME (Multiple Arcade Machine Emulator) is a software project, the goal of which is to protect gaming history by preventing these arcade machines from being lost or forgotten. The MAME emulator currently supports over 7000 titles, but there are still more out there that require preservation. The hackers who work on preserving these games are like the digital Indiana Jones of the world. They learn about lost games and seek them out for preservation. In some cases, they must circumvent security measures in order to accurately preserve content. Nothing as scary as giant rolling boulders or poison darts, but security nonetheless.

Many of the arcade cabinets produced by a publisher called NMK used a particular sound processor labeled, “NMK004″. This chip contains both a protected internal code ROM and an unprotected external ROM that controls the sound hardware. The actual music data is stored on a separate unprotected EEPROM and is different for each game. The system reads the music data from the EEPROM and then processes it using the secret data inside the NMK004.

The security in place around the internal ROM has prevented hackers from dumping its contents for all this time. The result is that NMK games using this chip have poorly emulated sound when played using MAME, since no one knows exactly how the original chip processed audio. [trap15] found it ridiculous that after 20 years, no one had attempted to circumvent the security and dump the ROM. He took matters into his own hands.

The full story is a bit long and contains several twists and turns, but its well worth the read. The condensed version is that after a lot of trial and error and after writing many custom tools, [trap15] was able to finally dump the ROM. He was able to accomplish this using a very clever trick, speculated by others but never before attempted on this hardware. [trap15] exploited a vulnerability found in the unprotected external ROM in order to trick the system into playing back the protected internal ROM as though it were the sound data stored on the EEPROM. The system would read through the internal ROM as though it were a song and play it out through the speakers. [trap15] recorded the resulting audio back into his PC as a WAV file. He then had to write a custom tool to decode the WAV file back into usable data.

[trap15] has released all of his tools with documentation so other hackers can use them for their own adventures into hardware hacking. The project was a long time in the making and it’s a great example of reverse engineering and perseverance.

[Thanks Ryan]

A Detailed Look at the 7805 Voltage Regulator

We’re quite sure that all hobbyists have used the 7805 voltage regulator at least once in their lives. They are a simple way to regulate 7V+ voltages to the 5V that some of our low power projects need. [Ken Shirriff] wrote an amazingly detailed article about its theory of operation and implementation in the silicon world.

As you may see in the picture above such a regulator is composed of very different elements: transistors, resistors, capacitors and diodes, all of them integrated in the die. [Ken] provides the necessary clues for us to recognize them and then explains how the 7805 can have a stable output even when its temperature changes. This is done by using a bandgap reference in which the difference between transistor base-emitter voltages for high and low current is used to counter the effects of temperature. As some elements looked a bit odd during [Ken]’s reverse engineering process, he finally concluded that what he purchased on Ebay may be a counterfeit (read this Reddit comment for another opinion).

Joe Grand Talks Deconstructing Circuit Boards

With the exception of [Eric Evenchick], the Hackaday crew are safely back from Defcon and not missing in the desert. This means we can really start rolling out all the stuff we saw this weekend, beginning with an interview with [Joe Grand], creator of the JTAGulator, early member of l0pht, and generally awesome dude.

The focus of [Joe]’s many talks this year was reverse engineering circuit boards. Most of these techniques involved fairly low-tech methods to peel apart circuit boards one layer at a time: sandpaper and milling machines are the simplest techniques, but [Joe] is also using some significantly more uncommon methods. Lapping machines get a mention, as do acoustic microscopy, CAT scans, and x-rays. [Joe]’s Defcon talk isn’t up on the intertubes yet, but his BSides talk about techniques that didn’t work is available.

In case you forgot, [Joe] is also a judge for a little contest we’re running, and we asked what he’s looking for in a truly spaceworthy entry. [Joe]’s looking for projects with a lot of effort put into them. Don’t get us wrong, project that require no effort can be extremely popular, but documentation is king. [Joe] thinks well documented projects are evidence project creators are building something because they want to build it, and not because they want to win a prize. That’s intrinsic motivation, kiddies. Learn it.

Reverse Engineering a GPS Watch to Upload Custom Firmware


Sometimes GPS watches are too good to be left with their stock firmware. [Renaud] opened his Kalenji 300 GPS watch, reverse engineered it in order to upload his own custom firmware.

The first step was to sniff the serial traffic between the PC and the microcontroller when upgrading firmware to understand the protocol and commands used. [Renaud] then opened the watch, figured out what the different test points and components were. He used his buspirate with OpenOCD to extract the existing STM32F103 firmware. The firmware helped him find the proper value to store in a dedicated register for the boot loader to start.

By looking at the disassembly code he also found the SPI LCD initialization sequence and discovered that it uses a controller similar to the ST7571. He finally compiled his own program which uses the u8glib graphics library. Follow us after the break for the demonstration video.

Continue reading “Reverse Engineering a GPS Watch to Upload Custom Firmware”

Reverse Engineering a NAND Flash Device Management Algorithm

unsoldered flash chip

Put your hand under you chin as here comes a 6 months long jaw-dropping reverse engineering work: getting the data back from a (not so) broken SD card. As you can guess from the picture above, [Joshua]’s first step was to desolder the card’s Flash chip as the tear-down revealed that only the integrated SD-to-NAND Flash controller was damaged. The flash was then soldered on a breadboard so it could be connected to a Digilent Nexys-2 FPGA board. [Joshua] managed to find a similar Flash datasheet, checked that his wire-made bus was reliable and generated two 12GiB dump files on his computer.

In order to extract meaningful data from the dumps he first had to understand how SD-to-NAND controllers work. In his great write-up he provides us with a background of the Flash technology, so our readers can better understand the challenges we face with today’s chips. As flash memories integrate more storage space while keeping the same size, they become less reliable and have nifty problems that should be taken care of. Controllers therefore have to perform data whitening (so neighboring blocks of data don’t have similar content), spread data writes uniformly around the flash (so physical blocks have the same life expectancy) and finally support error correcting codes (so damaged bits can still be recovered). We’ll let our users imagine how complex reverse engineering the implementation of such techniques is when you don’t know anything about the controller. [Joshua] therefore had to do a lot of research, perform a lot of statistical analysis on the data he extracted and when nothing else was possible, use bruteforce…

Reverse Engineering LCD Displays

Dorkbot logo on a large LCD display

Over at DorkbotPDX in Portland, a member showed up with a stack of large LCD displays from point of sale terminals. [Paul] took it upon himself to reverse engineer the displays so that they can be recycled in future projects.

The control circuit for this LCD resides on a rather large PCB with quite a variety of components. The board was reduced to three main components: an MSM6255 display controller, a 32k RAM chip which is used as the framebuffer, and a tri-state driver.

With all the unneeded components out of the way, a custom board based around an ATmega88 MCU was added. This board was soldered in to interface with the LCD controller’s bus. This allows data to be written from the 128k flash ROM on the custom board into the frame buffer. Once this is done, the display controller will display the data on the LCD.

Now that data could be written, [Paul] figured out the correct configuration for the display controller. That was the final piece in getting images to show up correctly on the display. If you happen to find some old Micros 2700 POS terminals, [Paul]’s detailed write-up will help you scavenge the displays.

MSP430-Based CTF Hardware Hacking Challenge

Hardware 'Flag'

Hacking conferences often feature a Capture the Flag, or CTF event. Typically, this is a software hacking challenge that involves breaking into targets which have been set up for the event, and capturing them. It’s good, legal, hacking fun.

However, some people are starting to build CTFs that involve hardware hacking as well. [Balda]’s most recent hardware hacking challenge was built for the Insomni’hack 2014 CTF. It uses an MSP430 as the target device, and users are allowed to enter commands to the device over UART via a Bus Pirate. Pull off the exploit, and the wheel rotates to display a flag.

For the first challenge, contestants had to decompile the firmware and find an obfuscated password. The second challenge was a bit more complicated. The password check function used memcpy, which made it vulnerable to a buffer overflow attack. By overwriting the program counter, it was possible to take over control of the program and make the flag turn.

The risk of memcpy reminds us of this set of posters. Only abstaining from memcpy can 100% protect you from overflows and memory disclosures!