How To Reverse Engineer, Featuring the Rigol DS1054Z

For a few years now, the Rigol DS1052E has been the unofficial My First Oscilloscope™. It’s cheap, it’s good enough for most projects, and there have been a number hacks and mods for this very popular scope to give it twice as much bandwidth and other interesting tools. The 1052E is a bit long in the tooth and Rigol has just released the long-awaited update, the DS1054Z. It’s a four-channel scope, has a bigger screen, more bells and whistles, and only costs $50 more than the six-year-old 1052E. Basically, if you’re in the market for a cheap, usable oscilloscope, scratch the ~52E off your list and replace it with the ~54Z.

With four channels of input, [Dave Jones] was wondering how the engineers at Rigol managed to stuff two additional front ends into the scope while still meeting the magic price point of $400. This means it’s time for [Dave] to reverse engineer the 1054Z, and give everyone on the Internet a glimpse at how a real engineer tears apart the worth of other engineers.

The first thing [Dave] does once the board is out of the enclosure is taking a nice, clear, and in-focus picture of both sides of the board. These pictures are edited, turned into a line drawing, and printed out on a transparency sheet. This way, both sides of the board can be viewed at once, allowing for a few dry erase marker to highlight the traces and signals.

Unless your voyage on the sea of reverse engineering takes you to the island of despair and desoldering individual components, you’ll be measuring the values of individual components in circuit. For this, you’ll want a low-voltage ohms function on your meter; if you’re putting too much voltage through a component, you’ll probably turn on some silicon in the circuit, and your measurements will be crap. Luckily, [Dave] shows a way to test if your meter will work for this kind of work; you’ll need another meter.

From there, it’s basically looking at datasheets and drawing a schematic of the circuit; inputs go at the left, outputs at the right, ground is at the bottom, and positive rails are at the top. It’s harder than it sounds – most of [Dave]’s expertise in this area is just pattern recognition. It’s one thing to reverse engineer a circuit through brute force, but knowing the why and how of how the circuit works makes things much easier.

Continue reading “How To Reverse Engineer, Featuring the Rigol DS1054Z”

Reverse Engineering a Bathroom Scale for Automated Weight Tracking

[Darell] recently purchased a fancy new bathroom scale. Unlike an average bathroom scale, this one came with a wireless digital display. The user stands on the scale and the base unit transmits the weight measurement to the display using infrared signals. The idea is that you can place the display in front of your face instead of having to look down at your feet. [Darell] realized that his experience with infrared communication would likely enable him to hack this bathroom scale to automatically track his weight to a spreadsheet stored online.

[Darell] started by hooking up a 38khz infrared receiver unit to a logic analyzer. Then he recorded the one-way communication from the scale to the display. His experience told him that the scale was likely using pulse distance coding to encode the data. The scale would start each bit with a 500ms pulse. Then it would follow-up with either another 500ms pulse, or a 1000ms pulse. Each combination represented either a 1 or a 0. The problem was, [Darell] didn’t know which was which. He also wasn’t sure in which order the bits were being transmitted. He modified a software plugin for his logic analyzer to display 1’s and 0’s on top of the waveform. He then made several configurable options so he could try the various representations of the data.

Next it was time to generate some known data. He put increasing amounts of weight on the scale and recorded the resulting data along with the actual reading on the display. Then he tried various combinations of display settings until he got what appeared to be hexadecimal numbers increasing in size. Then by comparing values, he was able to determine what each of the five bytes represented. He was even able to reconstruct the checksum function used to generate the checksum byte.

Finally, [Darell] used a Raspberry Pi to hook the scale up to the cloud. He wrote a Python script to monitor an infrared receiver for the appropriate data. The script also verifies the checksum to ensure the data is not corrupted. [Darell] added a small LED light to indicate when the reading has been saved to the Google Docs spreadsheet, so he can be sure his weight is being recorded properly.

Reverse Engineering Altium Files

Several times in the last few weeks, I’ve heard people say, ‘this will be the last PCB I design in Eagle.’ That’s bad news for CadSoft, but if there’s one thing Eagle has done right, its their switch to an XML file format. Now anyone can write their own design tools for Eagle without mucking about with binary files.

Not all EDA softwares are created equally, and a lot of vendors use binary file formats as a way to keep their market share. Altium is one of the worst offenders, but by diving into the binary files it’s possible to reverse engineer these proprietary file formats into something nearly human-readable.

[dstanko.au]’s first step towards using an Altium file with his own tools was opening it up with a hex editor. Yeah, this is as raw as it can possibly get, but simply by scrolling through the file, he was able to find some interesting bits hanging around the file. It turns out, Altium uses something called a Compound Document File, similar to what Office uses for Word and PowerPoint files, to store all the information. Looking through the lens of this file format, [dstanko.au] found all the content was held in a stream called ‘FileHeader’, everything was an array of strings (yeah, everything is in text), and lines of text are separated by ‘|’ in name=value pairs.

With a little bit of code, [dstanko] managed to dump all these text records into a pseudo plain text format, then convert everything into JSON. You can check out all the code here.

Reverse Engineering Star Wars: Yoda Stories

Star Wars: Yoda Stories was released by LucasArts in 1997 to minimal critical acclaim. As IGN said, “like Phantom Menace proved, just because it’s Star Wars doesn’t mean it’s good.” This didn’t stop [Zach] from playing it, and years later, taking an interest in reverse engineering the game.

[Zach]’s reverse engineering of Star Wars: Yoda Stories (google cache) takes a look at the game’s data file. This binary file is parsed by the game at run time to extract sound effects, sprites, and map tiles. Perhaps the best known game data file type was Doom’s WAD file, which had purpose built editing programs from third parties.

After a quick look at the data file in HxD, [Zach] began writing scripts in C# to extract different sections of the data file. Once the sections were found, more code was used to apply a color palette and generate bitmaps.

In the end, [Zach] managed to get a couple thousand tiles of the game’s data. He found some interesting ones, such as the sports car that he replaced the X-Wing with in his mod. The engine for an earlier Lucasarts game, Indiana Jones and His Desktop Adventures, should be very similar, and once we find the Mac install disk and a copy of ResEdit, we’ll post something on Hackaday.io.

Thermal Printer Brain Transplant is Two Hacks in One

You know how sometimes you just can’t resist collecting old hardware, so you promise yourself that you will get around to working on it some day? [Danny] actually followed through on one of those promises after discovering an old Radio Shack TRS-80 TP-10 thermal printer in one of his boxes of old gear. It looks similar to a receipt printer you might see printing receipts at any brick and mortar store today. The original printer worked well enough, but [Danny] wasn’t satisfied with its 32 character per line limitation. He also wanted to be able to print more complex graphics. To accomplish this goal, he realized he was going to have to give this printer a brain transplant.

First, [Danny] wanted to find new paper for the printer. He only had one half of a roll left and it was 30 years old. He quickly realized that he could buy thermal paper for fax machines, but it would be too wide at 8.5 inches. Luckily, he was able to use a neighbor’s saw to cut the paper down to the right size. After a test run, he knew he was in business. The new fax paper actually looked better than the old stuff.

The next step was to figure out exactly how this printer works. If he was going to replace the CPU, he was going to need to know exactly how it functioned. He started by looking at the PCB to determine the various primary functions of the printer. He needed to know which functions were controlled by which CPU pins. After some Google-Fu, [Danny] was able to find the original manual for the printer. He was lucky in that the manual contained the schematic for the circuit.

Once he knew how everything was hooked up, [Danny] realized that he would need to learn how the CPU controlled all of the various functions. A logic analyzer would make his work much easier, but he didn’t happen to have one lying around. [Danny] he did what any skilled hacker would do. He built his own!

He built the analyzer around an ATMega664. It can sample eight signals every three microseconds. He claims it will fill its 64k of memory in about one fifth of a second. He got his new analyzer hooked up to the printer and then got to work coding his own logic visualization software. This visualization would provide him with a window to the inner workings of the circuit.

Now that he was able to see exactly how the printer functioned, [Danny] knew he would be able to code new software into a bigger and badder CPU. He chose to use another ATMega microcontroller. After a fair bit of trial and error, [Danny] ended up with working firmware. The new firmware can print up to 80 characters per line, which is more than double the original amount. It is also capable of printing simple black and white graphics.

[Danny] has published the source code and schematics for all of his circuits and utilities. You can find them at the bottom of his project page. Also, be sure to catch the demonstration video below. Continue reading “Thermal Printer Brain Transplant is Two Hacks in One”

Stepping Through Code on a Pace 4000 Set Top Box

[Lee] wrote in to tell us about a Set Top Box he hacked. Before the cable industry lawyers get out their flaming swords… he’s not stealing cable, or really doing much of anything. This is a hack just for the adventure and thrill of making someone else’s hardware design do your bidding without any kind of instructions.

He posted about the adventure in two parts. The first is finding the JTAG header and identifying the pins. Arduino to the rescue! No really, and this is the type of Arduino use we love. Using a package called JTAGenum the board becomes a quick tool for probing and identifying JTAG connections.

The image above shows a different piece of hardware. From looking at it we’re pretty sure this is a Bus Blaster which is specifically designed for JTAG debugging with ARM processors. This is the beginning of the second part of his documentation which involves code dumping and stepping through lines code (or instructions) using OpenOCD and GDB. It’s a chore to follow all that [Lee] discovered just to write his name to the display of the box. But we certainly found it interesting. The display has a convoluted addressing scheme. We assume that there are cascading shift registers driving the segments and that’s why it behaves the way it does. Take a look for yourself and let us know what you think in the comments.

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]