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”
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…
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.
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!
[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.
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.
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.