reverse engineering

417 Articles

Capture The Flag Challenge Is The Perfect Gift

January 18, 2018 by 7 Comments

Nothing says friendship like a reverse engineering challenge on unknown terrain as a birthday present. When [Rikaard] turned 25 earlier this year, his friend [Veydh] put together a Capture the Flag challenge on an ESP8266 for him. As a software guy with no electronics background, [Rikaard] had no idea what he was presented with, but was eager to find out and to document his journey.

Left without guidance or instructions, [Rikaard] went on to learn more about the ESP8266, with the goal to dump its flash content, hoping to find some clues in it. Discovering the board is running NodeMCU and contains some compiled Lua files, he stepped foot in yet another unknown territory that led him down the Lua bytecode rabbit hole. After a detour describing his adjustments for the ESP’s eLua implementation to the decompiler he uses, his quest to capture the flag began for real.

While this wasn’t [Rikaard]’s first reverse engineering challenge, it was his first in an completely unknown environment outside his comfort zone — the endurance he demonstrated is admirable. There is of course still a long way down the road before one opens up chips or counts transistors in a slightly more complex system.

How To Reverse Engineer Silicon

January 16, 2018 by 19 Comments

A few semesters back, [Jordan] was in an Intro to Hardware Security course at CMU. The final project was open ended, and where some students chose projects like implementing a crypto algorithm or designing something on an FPGA, [Jordan] decided to do something a little more ambitious. He wanted to decapsulate and reverse engineer an IC. No, this isn’t taking a peek at billions of transistors — [Jordan] chose a 74-series Quad XOR for this project — but it does show what goes into reverse engineering silicon, and how even simple chips can be maddeningly confusing.

The first step to reverse engineering a chip is decapsulation, and for this [Jordan] had two options. He could drop acid, or he could attack a ceramic package with an endmill. While hot nitric acid is effective and fun, it is a bit scary, so [Jordan] mounted a few chips in a 3D printed holder wedged in the vice on his mill. By slowly bringing the Z axis down a few thou at a time, he was able to find the tiny 1 mm square bit of silicon embedded in this chip. With the help of a grad student and the cleanroom, this square of sand was imaged with a very nice microscope.

Now that [Jordan] had an image of the silicon itself, he had to reverse engineer the chip. You might think that with less than a dozen transistors in there, designing an XOR out of transistors is something anyone with a bit of Minecraft experience can do. This line of thinking proved to be a trap. Technically, this wasn’t an XOR gate. It was a transmission gate XNOR gate with a big inverter on the output. Logically, it’s the same, but when it comes to silicon fabrication, the transmission gate XNORs aren’t able to sink or source a lot of current. By designing the chip as an XNOR with an inverter, the chip designers were able to design a simple chip that could still meet the spec.

While [Jordan] managed to reverse engineer the chip, this was quite possibly the simplest chip he could reverse engineer. The Quad XOR is just the same silicon repeated four times, anyway. This is the baseline for all efforts to reverse engineer silicon, and there were still a few confusing traps.

Learn To Reverse Engineer X86_64 Binaries

January 6, 2018 by 16 Comments

Opening up things, see how they work, and make them do what you want are just the basic needs of the average hacker. In some cases, a screwdriver and multimeter will do the job, but in other cases a binary blob of random software is all we have to work with. Trying to understand an unknown binary executable is an exciting way to discover a system’s internal functionality.

While the basic principles of software reverse engineering are universal across most platforms, the details can naturally vary for different architectures. In the case of the x86 architecture, [Leonora Tindall] felt that most tutorials on the subject focus mostly on 32-bit and not so much on the 64-bit specifics. Determined to change that, she ended up with an extensive introduction tutorial for reverse engineering x86_64 binaries starting at the very basics, then gradually moving forward using crackme examples. Covering simple string analysis and digging through disassembled binaries to circumvent fictional security, the tutorial later introduces the Radare2 framework.

All example source code is provided in the accompanying GitHub repository, although it is advised to avoid looking at them to keep it more interesting and challenging. And in case you are looking for more challenges later on, or generally prefer a closer connection to the hardware, these MSP430 based capture the flag online challenges might be worth to look at next.

Making A Classic Chip From Discretes

December 31, 2017 by 11 Comments

A hackspace discussion of voltage regulators within our earshot touched on the famous μA723, then moved on to its competitors. Kits-of-parts for linear regulators were ten-a-penny in the 1970s, it seems. A rambling tale ensued, involving a Lambda power supply with a blown-up chip, and ended up with a Google search for the unit in question. What it turned up was a hack from 2014 that somehow Hackaday missed at the time, the replication by [Eric Schlaepfer] of an out-of-production regulator chip using surface-mount semiconductors when his Lambda PSU expired.

Lambda were one of those annoying electronics companies with a habit of applying their own part numbers to commonly available chips in an effort to preserve their spares sales. Thus the FBT-031 in this Lambda PSU was in fact a Motorola MC1466, a dirt-cheap common part in the 1970s. Unfortunately though unlike the 723 the MC1466 has long passed out of production, and is rarer than the proverbial hen’s tooth.

Happily, these chips from the early 1970s were often surprisingly simple inside. The MC1466 schematic can be found on its data sheet, and is straightforward enough to replicate with surface-mount discrete components. He thus created a PCB that replicated the original pin layout even though it overlapped the original footprint. A few parts were slightly unusual, dual transistor arrays and a matched triple diode, but the result proved to be a perfect replacement for a real MC1466. Of course a project like this is almost too simple for [Eric], who went on to build the incredible Monster 6502.

If the data sheet lacks a schematic, never fear. You can always try reverse engineering the chip directly.

34C3: Using Your Car As Video Game Controller

December 30, 2017 by 6 Comments

Despite the presence of human drivers, modern cars are controlled by computers. In his talk at the Chaos Communication Congress [Guillaume Heilles] and [P1kachu] demonstrate the potential of taking control of a car’s computer. This of course leads to the natural conclusion of emulate an Xbox controller and using the car to play computer games.

His research was limited by the fact that the only cars they had access to were the daily drivers of different members of [P1kachu]’s family, which meant that all tinkering had to be strictly non-destructive. Despite this, they achieved impressive results and deliver a great introduction into reverse engineering.

[P1kachu] used a RasPi and an OBD-II adapter to access the car’s CAN bus and begins the presentation with a quick overview of the protocol. He then briefly touches on security measures that he ran into, which are optional and their implementation varies widely between manufacturers. His first attempt to access the CAN bus was successfully blocked by a challenge-response algorithm doing its work. His mother’s convertible however provided no such obstacles and gaining access allowed him to map the position of the steering wheel and pedals to a game controller, using the car to play video games.

After this, [Guillaume] steps in and walks us through the teardown of a gadget that plugs into the OBD-II port and claims to do amazing things for your car’s mileage by reprogramming the ECU. The device was not brand specific and after having seen the variations in the ways different manufacturers implement the protocol, [Guillaume] and [P1kachu] doubted that the gadget was capable of even holding the information required to modify every known implementation out there. Listening to the output of the device, along with a quick analysis of the circuit followed by decapping the single chip they found, showed that their doubt was justified. The lecture closes with an extended Q&A that adds more information on car hacking. Those that don’t have access to a car can instead tear down hot glue guns, doppler modules or antique calculators.

Continue reading “34C3: Using Your Car As Video Game Controller” →

34C3: Fitbit Sniffing And Firmware Hacking

December 29, 2017 by 19 Comments

If you walked into a gym and asked to sniff exercise equipment you would get some mighty strange looks. If you tell hackers you’ve sniffed a Fitbit, you might be asked to give a presentation. [Jiska] and [DanielAW] were not only able to sniff Bluetooth data from a run-of-the-mill Fitbit fitness tracker, they were also able to connect to the hardware with data lines using test points etched right on the board. Their Fitbit sniffing talk at 34C3 can be seen after the break. We appreciate their warning that opening a Fitbit will undoubtedly void your warranty since Fitbits don’t fare so well after the sealed case is cracked. It’s all in the name of science.

There’s some interesting background on how Fitbit generally work. For instance, the Fitbit pairs with your phone which needs to be validated with the cloud server. But once the cloud server sends back authentication credentials they will never change because they’re bound to to the device ID of the Fitbit. This process is vulnerable to replay attacks.

Data begin sent between the Fitbit and the phone can be encrypted, but there is a live mode that sends the data as plain text. The implementation seemed to be security by obscurity as a new Bluetooth handle is used for this mode. This technique prevents the need to send every encrypted packet to the server for decryption (which would be for every heartbeat packet). So far the fix for this has been the ability to disable live mode. If you have your own Fitbit to play with, sniffing live mode would be a fun place to start.

The hardware side of this hack begins by completely removing the PCB from the rubber case. The board is running an STM32 and the team wanted to get deep access by enabling GDB. Unfortunately, the debug pins were only enabled during reset and the stock firmware disables them at startup (as it should). The workaround was to rewrite the firmware so that the necessary GPIO remain active and there’s an interesting approach here. You may remember [Daniel Wegemer] from the Nexmon project that reverse engineered the Nexus 5 WiFi. He leveraged the binary patching he used on Nexmon to patch the Fitbit firmware to enable debugging support. Sneaky!

For more about 34C3 we have a cheatsheet of the first day and for more about Fitbit security, check out this WAV file.

Continue reading “34C3: Fitbit Sniffing And Firmware Hacking” →

Reverse Engineering The Nintendo Wavebird

December 14, 2017 by 21 Comments

Readers who were firmly on Team Nintendo in the early 2000’s or so can tell you that there was no accessory cooler for the Nintendo GameCube than the WaveBird. Previous attempts at wireless game controllers had generally either been sketchy third-party accessories or based around IR, and in both cases the end result was that the thing barely worked. The WaveBird on the other hand was not only an official product by Nintendo, but used 2.4 GHz to communicate with the system. Some concessions had to be made with the WaveBird; it lacked rumble, was a bit heavier than the stock controllers, and required a receiver “dongle”, but on the whole the WaveBird represented the shape of things to come for game controllers.

Finding the center frequency for the WaveBird

Given the immense popularity of the WaveBird, [Sam Edwards] was somewhat surprised to find very little information on how the controller actually worked. Looking for a project he could use his HackRF on, [Sam] decided to see if he could figure out how his beloved WaveBird communicated with the GameCube. This moment of curiosity on his part spawned an awesome 8 part series of guides that show the step by step process he used to unlock the wireless protocol of this venerable controller.

Even if you’ve never seen a GameCube or its somewhat pudgy wireless controller, you’re going to want to read though the incredible amount of information [Sam] has compiled in his GitHub repository for this project.

Starting with defining what a signal is to begin with, [Sam] walks the reader though Fourier transforms, the different types of modulations, decoding packets, and making sense of error correction. In the end, [Sam] presents a final summation of the wireless protocol, as well as a simple Python tool that let’s the HackRF impersonate a WaveBird and send button presses and stick inputs to an unmodified GameCube.

This amount of work is usually reserved for those looking to create their own controllers from the ground up, so we appreciate the effort [Sam] has gone through to come up with something that can be used on stock hardware. His research could have very interesting applications in the world of “tool-assisted speedruns” or even automating mindless stat-grinding.