reverse engineering

412 Articles

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.

80’s Smartwatch Finally Plays Tetris

November 14, 2017 by 19 Comments

While the current generation of smartwatches have only been on the market for a few years, companies have been trying to put a computer on your wrist since as far back as the 80s with varying degrees of success. One such company was Seiko, who in 1984 unveiled the UC-2000: a delightfully antiquated attempt at bridging the gap between wristwatch and personal computer. Featuring a 4-bit CPU, 2 KB of RAM, and 6 KB of ROM, the UC-2000 was closer to a Tamagotchi than its modern day counterparts, but at least it could run BASIC.

Dumping registers

Ever since he saw the UC-2000 mentioned online, [Alexander] wanted to get one and try his hand at developing his own software for it. After securing one on eBay, the first challenge was getting it connected up to a modern computer. (Translated from Russian here.) [Alexander] managed to modernize the UC-2000’s novel induction based data transfer mechanism with help from a ATtiny85, which allowed him to get his own code on the watch, all that was left was figuring out how to write it.

With extremely limited published information, and no toolchain, [Alexander] did an incredible job of figuring out the assembly required to interact with the hardware. Along the way he made a number of discoveries which set his plans back, such as the fact that there is no way to directly control individual pixels on the screen; all graphics would have to be done with the built-in symbols.

The culmination of all this hard work? Playing Tetris, naturally. Though [Alexander] admits that limitations of the device’s hardware meant the game had to be simplified a bit, he’s almost certainly having more fun than any of the UC-2000’s original owners did with this device. He’s setup a GitHub repository for anyone who wishes to join him in this brave new world of vintage wrist computing.

[Alexander] isn’t the only one experimenting with fringe wearable computers. We’ve seen our fair share of interesting smartwatches, featuring everything from novel input methods to complete scratch-builds.

Continue reading “80’s Smartwatch Finally Plays Tetris” →

Reverse Engineering The Nintendo Switch Joy-Cons

November 6, 2017 by 26 Comments

The Switch is Nintendo’s latest effort in the console world. One of its unique features is the Joy-Cons, a pair of controllers that can either attach directly to the console’s screen or be removed and used individually. But how do they work? [dekuNukem] decided to find out.

The reverse engineering efforts begin with disassembly. Surprisingly, there is no silkscreen present on the board to highlight test points or part numbers. This is likely to conflate intended to stymie community efforts to work with the hardware, as different teams may create their own designations for components. Conversely, the chips inside still have their identifying markings present, which does ease identification somewhat.

There are some interesting choices made – the majority of the buttons are scanned in a matrix configuration by the on-board microcontroller, making it harder to spoof button presses. The controllers communicate over Bluetooth, switching to a physical serial connection when attached directly to the screen. This runs at a blistering 3,125,000 BPS after the initial handshake is completed.

Overall it’s a fairly comprehensive reverse engineering effort, and [dekuNukem] has provided excellent detail in the writeup for anyone else looking to get involved. There’s still some work left to do, like investigating the rumble messages, but it’s an excellent start and very comprehensive.

Perhaps you’re more interested in older Nintendo hardware? Check out this comprehensive effort to figure out NES console-to-cartridge security methods.

Reverse Engineering Guitar Hero

September 25, 2017 by 11 Comments

What do you do when a ten-year-old video game has a bug in it? If you are [ExileLord] you fix it, even if you don’t have the source code. Want to know how? Luckily, he produced a video showing all the details of how he tracked the bug down and fixed it. You can see the video below. You may or may not care about Guitar Hero, but the exercise of reverse engineering and patching the game is a great example of the tools and logic required to reverse engineer any binary software, especially a Windows binary.

The tool of choice is IDA, an interactive debugger and disassembler. The crash thows an exception and since [ExileLord] has done some work on the game before, he was able to find a function that was creating a screen element that eventually led to the crash.

Continue reading “Reverse Engineering Guitar Hero” →

Fake Ram: Identifying A Counterfeit Chip

August 22, 2017 by 26 Comments

[Robert Baruch‏] had something strange on his hands. He had carefully decapped 74LS189 16×4 static RAM, only to find that it wasn’t a RAM at all. The silicon die inside the plastic package even had analog elements, which is not what one would expect to find in an SRAM. But what was it? A quick tweet brought in the cavalry, in the form of chip analysis expert [Ken Shirriff].

[Ken] immediately realized the part [Robert] had uncovered wasn’t a 74 series chip at all. The power and ground pins were in the wrong places. Even the transistors were small CMOS devices, where a 74 series part would use larger bipolar transistors. The most glaring difference between the mystery device and a real LS819 was the analog elements. The mystery chip had a resistor network, arranged as an R-2R ladder. This configuration is often used as a simple Digital to Analog Converter (DAC).

Further analysis of the part revealed that the DAC was driven by a mask ROM that was itself indexed using a linear feedback shift register. [Ken] used all this information to plot out the analog signal the chip would generate. It turned out to be a rather sorry looking sine wave.

The mystery part didn’t look like any function generator or audio chip of the era. [Ken] had to think about what sort of commodity part would use lookup tables to generate an audio waveform. The answer was as close as his telephone — a DTMF “touch tone” generator, specifically a knockoff of a Mostek MK5085.

Most investigators would have stopped there. Not [Ken] though. He delved into the construction and function of the DTMF generator. You can find the full analysis on his site. This isn’t [Ken’s] first rodeo with decapped chips. He’s previously examined the Intel 8008 and presented a talk on silicon reverse engineering at the 2016 Hackaday Superconference. [Robert] has also shown us how to pop the top of classic ceramic integrated circuits.

 

Reverse Engineering A BLE Service To Control A Light Bulb

August 13, 2017 by 18 Comments

So, you buy an Internet of Things light bulb, it’s a fun toy that allows you to bathe your environment in pretty colours at the touch of an app, but eventually you want more. You start to wonder how you might do more with it, and begin to investigate its inner workings. Then to your horror you discover that far from having bought a device with a convenient API for you to use, it has an impenetrable closed protocol that defies easy access.

This was the problem facing [Ayan Pahwa] when he bought a Syska Smartlight Rainbow LED bulb, and discovered that its Bluetooth Low Energy  interface used a closed protocol. But instead of giving up, he proceeded to reverse engineer the communication between bulb and app, and his write-up makes for an interesting read that provides a basic primer on some of BLE’s workings for the uninitiated.

BLE allows a device manufacturer to define their own device service specific to their functionality alongside standard ones for common device types. Using a handy Android app from Nordic Semiconductor he was able to identify the services defined for the light bulb, but sadly they lacked any human-readable information to help him as to their purpose. He thus had to sniff BLE packets directly, and lacking dedicated hardware for this task he relied on a developer feature built into Android versions since KitKat, allowing packets to be captured and logged. By analysing the resulting packet files he was able to identify the Texas Instruments chip inside the bulb, and to deduce the sequences required to control its colours. Then he was able to use the Bluez utilities to talk directly to it, and as if by magic, his colours appeared! Take a look at the video we’ve placed below the break.

Many of us may never need to reverse engineer a BLE device. But if we are BLE novices, after reading [Ayan]’s piece we will at least have some idea of its inner workings. And that can only be a positive thing.

Continue reading “Reverse Engineering A BLE Service To Control A Light Bulb” →