This Thermal Printer Has Serious Game

April 18, 2018 by Brian McEvoy 11 Comments

[Dhole], like the fox, isn’t the first to connect his computer to a Game Boy printer but he has done a remarkable job of documenting the process so well that anyone can follow. The operation is described well enough that it isn’t necessary to scrutinize his code, so don’t be put off if C and Rust are not your first choices. The whole thing is written like a story in three chapters.

The first chapter is about hacking a link cable between two Game Boys. First, he explains the necessity and process of setting the speed of his microcontroller, a NUCLEO-F411RE development board by STMicroelectronics. Once the rate is set, he builds a sniffer by observing the traffic on the cable and listens in on two Game Boys playing Tetris in competition mode. We can’t help but think that some 8-bit cheating would be possible if Tetris thought your opponent instantly had a screen overflowing with tetrominoes. Spying on a couple of Game Boys meant that no undue stress was put on the printer.

Chapter two built on the first chapter by using the protocol to understand how the printer expects to be spoken to. There is plenty of documentation about this already, and it is thoughtfully referenced. It becomes possible to convince a Game Boy that the connected microcontroller is a printer so it will oblige by sending an image. Since there isn’t a reason to wait for printing hardware, the transfer is nearly instantaneous. In the image above, you can see a picture of [Dhole] taken by a Game Boy camera.

The final chapter, now that all the protocols are understood, is also the climax where the computer and microcontroller convince the printer they are a Game Boy that wants to print an image. In the finale, we get another lesson about measuring controller frequency without an oscilloscope. If you are looking for the hack, there it is. There is a handful of success in the form of old receipts with superimposed grayscale images since virgin thermal printer paper by Nintendo costs as much as a used printer.

This story had a happy ending but grab your reading glasses for the smallest Game Boy and here’s someone who wrote their own Game Boy color game.

34C3: Fitbit Sniffing And Firmware Hacking

December 29, 2017 by Brian McEvoy 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” →

WiFi Fob Acquaints OLED With ESP

October 16, 2015 by Mike Szczys 17 Comments

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” →

Hacking A KVM: Teach A Keyboard Switch To Spy

August 8, 2015 by Mike Szczys 11 Comments

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” →

Keystroke Sniffer Hides As A Wall Wart, Is Scary

January 14, 2015 by Bryan Cockfield 79 Comments

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” →

Sniffing NRF24L01+ Traffic With Wireshark

August 5, 2014 by Mathieu Stephan 6 Comments

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.

Sniffing Data From Radio-Controlled Bus Stop Displays

November 25, 2013 by Mathieu Stephan 63 Comments

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.