Editing Circuits With Focused Ion Beams

April 1, 2014 by Brian Benchoff 38 Comments

CPLD

[Andrew] has been busy running a class on hardware reverse engineering this semester, and figured a great end for the class would be something extraordinarily challenging and amazingly powerful. To that end, he’s editing CPLDs in circuit, drilling down to metal layers of a CPLD and probing the signals inside. It’s the ground work for reverse engineering just about every piece of silicon ever made, and a great look into what major research labs and three-letter agencies can actually do.

The chip [Andrew] chose was a Xilinx XC2C32A, a cheap but still modern CPLD. The first step to probing the signals was decapsulating the chip from its plastic prison and finding some interesting signals on the die. After working out a reasonable functional diagram for the chip, he decided to burrow into one of the lines on the ZIA, the bus between the macrocells, GPIO pins, and function blocks.

Actually probing one of these signals first involved milling through 900 nm of silicon nitride to get to a metal layer and one of the signal lines. This hole was then filled with platinum and a large 20 μm square was laid down for a probe needle. It took a few tries, but [Andrew] was able to write a simple ‘blink a LED’ code for the chip and view the s square wave from this test point. not much, but that’s the first step to reverse engineering the crypto on a custom ASIC, reading some undocumented configuration bits, and basically doing anything you want with silicon.

This isn’t the sort of thing anyone could ever do in their home lab. It’s much more than just having an electron microscope on hand; [Andrew] easily used a few million dollars worth of tools to probe the insides of this chip. Still, it’s a very cool look into what the big boys can do with the right equipment.

Hacking Dell Laptop Charger Identification

March 3, 2014 by Eric Evenchick 99 Comments

If you’ve ever had a laptop charger die, you know that they can be expensive to replace. Many laptops require you to use a ‘genuine’ charger, and refuse to boot when a knock off model is used. Genuine chargers communicate with the laptop and give information such as the power, current, and voltage ratings of the device. While this is a good safety measure, ensuring that a compatible charger is used, it also allows the manufacturers to increase the price of their chargers.

[Xuan] built a device that spoofs this identification information for Dell chargers. In the four-part series (1, 2, 3, 4), the details of reverse engineering the communications and building the spoofer are covered.

Dell uses the 1-Wire protocol to communicate with the charger, and [Xuan] sniffed the communication using a MSP430. After reading the data and verifying the CRC, it could be examined to find the fields that specify power, voltage, and current.

Next, a custom PCB was made with two Dell DC jacks and an MSP430. This passes power through the board, but uses the MSP430 to send fake data to the computer. The demo shows off a 90 W adapter pretending to run at 65 W. With this working, you could power the laptop from any supply that can meet the requirements for current and voltage.

Rewriting WS2812 Driver Libraries For Optimization

February 2, 2014 by Mike Szczys 14 Comments

ws2812_compared

We like [Tim’s] drive for improvement. He wrote a WS2812 driver library that works with AVR and ARM Cortex-M0 microcontrollers, but he wasn’t satisfied with how much of the controller’s resources the library used to simply output the required timing signal for these LED modules. When he set out to build version 2.0, he dug much deeper than just optimizing his own code.

We remember [Tim] from his project reverse engineering a candle flicker LED. This time, he’s done more reverse engineering by comparing the actual timing performance of the WS2812(B) module with its published specs. He learned that although several timing aspects require precision, others can be fudged a little bit. To figure out which ones, [Tim] used an ATtiny85 as a signal-generator and monitored performance results with a Saleae logic analyzer. Of course, to even talk about these advances you need to know something about the timing scheme, so [Tim] provides a quick run-through of the protocol as part of his write-up.

Click the top link to read his findings and how he used them to write the new library, which is stored in his GitHub repository.

Fail Of The Week: Reverse Engineering A Wireless Energy Monitor

January 30, 2014 by Mike Szczys 58 Comments

fotw-wireless-energy-monitor-reverse-engineering

[Afonso] picked up a cheap energy use monitor a few years back. He really like the data it displays about his home’s electricity, using a sensor to gather this info and a display that communicates with it wirelessly. But there is no option to log or dump the data. He set out to reverse engineer the wireless protocol in order to extend the use of the system. As the name of this column implies, he failed to get this working.

The hardware above is a 433Mhz transceiver that he rigged up as test hardware. It sounds like he’s assuming the monitor works on this band, which could have been his first misstep (we really don’t know). The speaker is there to give audible confirmation that he’s receiving something from the transmitter. This is where things start to get pretty weird. White noise was coming from the speaker, but when he stepped away from the bench it stopped. He was able to measure a regular pattern to the noise, and proceeded to place the speaker next to his computer MIC so that he could record a sample for further analysis.

Fail of the Week always aims to be a positive experience. In this case we’d like to have a conversation about the process itself. We agree that connecting a speaker (or headphones) should help get your foot in the door because your ear will recognize a rhythmic pattern when it is received. But with this noise, measuring the timing and recording a sample we’re not so sure about. Given the situation, how would you have soldiered on for the best chance at successfully sniffing out the communication scheme used by this hardware? Leave a comment below!

Fail of the Week is a Hackaday column which runs every Wednesday. Help keep the fun rolling by writing about your past failures and sending us a link to the story — or sending in links to fail write ups you find in your Internet travels.

Sucking PIC Firmware Out Of An Old APC Battery Backup

January 18, 2014 by Mike Szczys 30 Comments

reverse-engineering-pic-firmware-of-APC-power-supply

Looking at this huge Uninterruptible Power Supply we are a little envious. It’s meant to hang on the wall of a utility room and power your critical devices. [Radek Hvizdos] has had it in service for quite some time, and when he started thinking of replacing the internal battery he decided to see if he could also extend the functionality. To do so he needed to get at the firmware of the chip controlling the device. And so began his adventure of dumping the firmware from the read-protected PIC 18F452.

The challenge of dumping code from a write-protected chip is in itself a fun project. But [Radek] was actually interested in fixing bugs and adding features. The wishlist feature we’d be most interested in is a kind of triage for shutting down devices as the internal battery starts to run low. Nice! But starting from scratch with the firmware is a no-go. You can see the two places where he connected to the PCB. The upper is for using a PIC programmer. The lower is an I2C connection used to dump the EEPROM with an improvised Bus Pirate.

In the end it was improper lock bit settings that opened the door to grabbing the firmware. The bootloader section of the PIC is not locked, and neither is the ability to read from FLASH at run-time. These two combined allowed him to write his own code which, when flashed to the bootloader section, dumps the rest of the firmware so that it may be combined into a complete file afterward. Since posting this fascinating article he has made a follow-up about disassembling the code.

Keeping The Family Off The Net With An Undocumented Backdoor

January 6, 2014 by Brian Benchoff 33 Comments

memetics

When [Eloi] was home for Christmas, he faced one of the most difficult problems man has ever faced: his entire family, equipped with smartphones and laptops, siphoning all the Internet through a 1Mb/s connection. For any technically minded person, the fix for this problem is to limit the bandwith for all those Facebook and Twitter-heads, while leaving [Eloi]’s battlestation unaffected. [Eloi] had originally set up the Linksys WAG200G router in the family home a few years ago but had since forgotten the overly complex admin password. No worries, then, because apparently the WAG200G is open as wide as a barn door with a completely undocumented backdoor.

Without the password to the admin panel of the router, [Eloi] needed a way in. After pointing nmap at the router, he found an undocumented service running on port 32764. Googling this observation resulted in a lot of speculation, so the only option was to download the router’s firmware, look for the service, and figure out a way in.

[Eloi] eventually got a shell on the router and wrote a very short Python script to automate the process for all WAG200G routers. As for where this backdoor came from, it appears a SerComm device on the router is responsible. This means a whole bunch of routers with this specific SerComm module also have this backdoor, and we’d assume anything with a service running on port 32764 is suspect.

If you’re looking for a fix for this backdoor, your best bet is probably installing OpenWRT or Tomato. The OpenWAG200 project, an open firmware specifically designed for [Eloi]’s router, still has this vulnerability, though.

Reverse Engineering HitClips

January 1, 2014 by Brian Benchoff 31 Comments

hitclipz

After a quick review of the Hackaday viewer demographics, we need to say the late 90s were weird. Even portable audio players were downright bizarre: MP3 players existed, but you loaded up your songs (all eight of them) over your PC’s parallel port. While helping a cousin move some furniture, [Ch00f] found a huge collection of one of the oddest music formats ever: HitClips, a tiny plastic encapsulated bit of circuitry that stores 60 seconds of terrible-sounding mono audio. Yes, this was a thing, but so was the pet rock. With no HitClips player, [Ch00f] decided he would take a swing at reverse engineering these tiny, tinny songs.

After taking apart the plastic enclosure, [Ch00f] found a very simple circuit: a few resistors, a cap, and an epoxy blob that enclosed an die with the musical data. On the back of the clip, there are eight pads for connecting to the player. With nothing to go on, [Ch00f] started poking around and found connecting one of these pins to ground caused circuit to draw 300uA of current for about 60 seconds – the same length of time as the recorded sample.

[Ch00f] originally thought the HitClip would provide audio data over an SPI or other digital protocol. What he found was much more interesting: two of the pins on the HitClip correspond to the push and pull FETs of a class D amplifier. The audio on the HitClip is digital audio, but it’s encoded so it can directly drive an analog circuit. Pretty clever engineering for a happy meal toy, if you ask us.

After dumping this data with a logic analyzer, [Ch00f] turned all the values in to .WAV file. It was, amazingly, music. A little refinement to the process to nail down the timing resulted in a 60-second clip seen (heard?) after the break.

Since [Ch00f] doesn’t want to spend $40 on eBay for a vintage HitClips player, he’s right about at the limit of what he can reverse engineer out of these cheap, crappy music chips. He has put up all his documentation, though, so if you’re up for improving on [Ch00f]’s methods, have a go.

Continue reading “Reverse Engineering HitClips” →