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”
When you think of WiFi in projects it’s easy to get into the rut of assuming the goal is to add WiFi to something. This particular build actually brings WiFi awareness to you, in terms of sniffing what’s going on with the signals around you and displaying them for instant feedback.
[0miker0] is working on the project as his entry in the Square Inch Project. It’s an adapter board that has a footprint for the 2×4 pin header of an ESP8266-01 module, and hosts the components and solder pads for a 128×64 OLED display. These are becoming rather ubiquitous and it’s not hard to figure out why. They’re relatively inexpensive, low-power, high-contrast, and require very few support components. From the schematic in the GitHub Repo it looks like 5 resistors and 7 caps.
The video below shows off two firmware modes so far. The first is an AP scan that reads out some information, the second is a weather-display program. Anyone who’s worked with the ESP modules knows that they have the potential to gather all kinds of data about WiFi signals — one of our favorite demos of this is when [cnlohr] used it to create a 3d light painted map of his WiFi signal strength. Chuck a rechargeable LiPo on this thing, tweak the example code for your needs, and you have a new gadget for wardriving-nouveau.
Continue reading “WiFi Fob Acquaints OLED with ESP”
When it comes to large systems, there are a lot more computers than there are people maintaining them. That’s not a big deal since you can simply use a KVM to connect one Keyboard/Video/Mouse terminal up to all of them, switching between each box simply and seamlessly. The side effect is that now the KVM has just as much access to all of those systems as the human who caresses the keyboard. [Yaniv Balmas] and [Lior Oppenheim] spent some time reverse engineering the firmware for one of these devices and demonstrated how shady firmware can pwn these systems, even when some of the systems themselves are air-gapped from the Internet. This was their first DEF CON talk and they did a great job of explaining what it took to hack these devices.
Continue reading “Hacking a KVM: Teach a Keyboard Switch to Spy”
For those of us who worry about the security of our wireless devices, every now and then something comes along that scares even the already-paranoid. The latest is a device from [Samy] that is able to log the keystrokes from Microsoft keyboards by sniffing and decrypting the RF signals used in the keyboard’s wireless protocol. Oh, and the entire device is camouflaged as a USB wall wart-style power adapter.
The device is made possible by an Arduino or Teensy hooked up to an NRF24L01+ 2.4GHz RF chip that does the sniffing. Once the firmware for the Arduino is loaded, the two chips plus a USB charging circuit (for charging USB devices and maintaining the camouflage) are stuffed with a lithium battery into a plastic shell from a larger USB charger. The options for retrieving the sniffed data are either an SPI Serial Flash chip or a GSM module for sending the data automatically via SMS.
The scary thing here isn’t so much that this device exists, but that encryption for Microsoft keyboards was less than stellar and provides little more than a false sense of security. This also serves as a wake-up call that the things we don’t even give a passing glance at might be exactly where a less-honorable person might look to exploit whatever information they can get their hands on. Continue past the break for a video of this device in action, and be sure to check out the project in more detail, including source code and schematics, on [Samy]’s webpage.
Thanks to [Juddy] for the tip!
Continue reading “Keystroke Sniffer Hides as a Wall Wart, is Scary”
We’re sure that some of our readers are familiar with the difficult task that debugging/sniffing nRF24L01+ communications can be. Well, [Ivo] developed a sniffing platform based on an Arduino Uno, a single nRF24L01+ module and a computer running the popular network protocol analyzer Wireshark (part1, part2, part3 of his write-up).
As these very cheap modules don’t include a promiscuous mode to listen to all frames being sent on a particular channel, [Ivo] uses for his application a variation of [Travis Goodspeed]’s technique to sniff Enhance Shockburst messages. In short, it consists in setting a shorter than usual address, setting a fix payload length and deactivating the CRC feature. The Arduino Uno connected to the nRF24L01+ is therefore in charge of forwarding the sniffed frames to the computer. An application that [Ivo] wrote parses the received data and forwards it to wireshark, on which can be set various filters to only display the information you’re interested in.
A few weeks ago in Finland [Oona] discovered a radio data stream centered around 76KHz in a FM broadcast and she recently managed to decode it. This 16,000bps stream uses level-controlled minimum-shift keying (L-MSK) which detection can be quite tricky to implement. She therefore decoded the stream by treating the received signal as non-coherent binary FSK, which as a side effect increased the bit error probability. [Oona] then understood that the stream she was getting was the data broadcast by Helsinky buses to the nearby bus stop timetable displays. She even got lucky when she observed a display stuck in the middle of its bootup sequence, displaying a version string. This revealed that the system is called IBus and made by the Swedish company Axentia. However their website didn’t provide the specs for their proprietary protocol. After many hours of sniffing and coding, [Oona] successfully implemented the five layer protocol stack in Perl and can now read the arrival times of the nearby buses from her apartment.
[Matlo] wrote in to share his USB sniffing project using the BeagleBoard-xM. It builds on the Google Summer of Code project from 2010 that used the non-xM version of the hardware to build a pass through USB sniffer. [Matlo] couldn’t get it to work back then, but recently revisited the project. He’s cleaned up some scripts and generally made it a bit easier for others to pull off as well.
The ARM-based BeagleBoard seen above acts as man-in-the-middle. You connect your target USB device to the board and the board to a computer. The board emulates the target device, passing packets in either direction while also logging them. The captured data is in the correct format for display using WireShark, the de facto standard for making sense of captured communication packets.
This is great for figuring out how to use USB devices on non-standard systems, or vice versa.