Soundbar Bested By Virtual Android Bluetooth Sniffer

May 2, 2021 by Tom Nardi 12 Comments

Out of the box, the Yamaha YAS-207 soundbar can be remotely controlled over Bluetooth, but only when using a dedicated application on iOS or Android. Users who want to command their hardware with their computer, or any other Bluetooth device for that matter, are left out in the cold. Or at least they were, before [Wejn] got on the case.

To capture the communication between the soundbar and the application, [Wejn] first installed Android-x86 in a virtual machine on his computer and then enabled the “Bluetooth HCI snoop log” within Developer Settings. From there, a netcat command running on the virtual Android device continually sent the contents of the btsnoop_hci.log file out to Wireshark on his Linux desktop. As he hit buttons in the Yamaha application, he could watch the data come in live. We’ve seen plenty of people use Android’s integrated Bluetooth packet capture in the past, but never quite like this. It’s certainly a tip worth mentally filing away for the future.

The Pi can now control the TOSLINK connected speakers.

From there, things move pretty quickly. [Wejn] is able to determine that the devices are communicating over a virtual serial port, and starts identifying individual command and response packets. It turns out the commands closely mirror the NEC IR codes that he’d previously decoded on a whim, which helped clear things up. Once the checksum was sorted out, writing some code that can talk to the soundbar from his Raspberry Pi media player was the next logical step.

[Wejn] combined this with the Shairport Sync project, which lets the Raspberry Pi turn on the speaker and switch the input over when he wants to stream AirPlay from his phone. But of course, the same technique could be applied to whatever source of digital audio captures your fancy.

This is one of those posts you should really read in its entirety to truly appreciate. While every device is going to be different, the basic principles and workflow that [Wejn] demonstrates in this project will absolutely be useful in your own reverse engineering adventures. If you’re more of a visual learner, we recently covered a series of YouTube tutorials that cover sniffing BLE devices that’s not to be missed as well.

Linux Fu: A Little Bit Of (Network) History Repeating Itself

April 26, 2021 by Al Williams 5 Comments

These days, embedded systems often have networks and that can make them significantly more complex. Networks are usually pretty nondeterministic and there are a variety of oddball conditions. For example, when your public-access pick and place machine gets written up on Hackaday and you suddenly get a 50X surge in traffic, how does your network stack handle it? While there’s no silver bullet for network testing, there are some tricks that can make it easier and one of those is the tcpreplay utilities that allow you to record complex network traffic and then play it back in a variety of ways. This has many benefits, especially if you manage to capture that one thing that triggers bad behavior sporadically. Being able to play it back on demand can speed up diagnostics considerably.

General Idea

You probably know that tcpdump allows you to grab packet captures from a network interface and save them to a file. If you prefer a GUI, you probably use Wireshark, which uses the same underlying library (libpcap) to grab the data. In fact, you can capture data using tcpdump and look at it with Wireshark, although there are other tools like tcptrace or Ngrep that can work with the output, also.

While the output of the command can be a little cryptic without tool support, a program called tcpreplay can take that data and feed it back in a variety of ways. Of course, you can modify the file first — there are tools to make that easier and — if you need to — you can craft your own network traffic by hand or using one of a variety of tools. This process is often called “packet crafting.”

Continue reading “Linux Fu: A Little Bit Of (Network) History Repeating Itself” →

A Crash Course On Sniffing Bluetooth Low Energy

March 23, 2021 by Tom Nardi 25 Comments

Bluetooth Low Energy (BLE) is everywhere these days. If you fire up a scanner on your phone and walk around the neighborhood, we’d be willing to bet you’d pick up dozens if not hundreds of devices. By extension, from fitness bands to light bulbs, it’s equally likely that you’re going to want to talk to some of these BLE gadgets at some point. But how?

Well, watching this three part video series from [Stuart Patterson] would be a good start. He covers how to get a cheap nRF52480 BLE dongle configured for sniffing, pulling the packets out of the air with Wireshark, and perhaps most crucially, how to duplicate the commands coming from a device’s companion application on the ESP32.

The first video in the series is focused on getting a Windows box setup for BLE sniffing, so readers who aren’t currently living under Microsoft’s boot heel may want to skip ahead to the second installment. That’s where things really start heating up, as [Stuart] demonstrates how you can intercept commands being sent to the target device.

It’s worth noting that little attempt is made to actually decode what the commands mean. In this particular application, it’s enough to simply replay the commands using the ESP32’s BLE hardware, which is explained in the third video. Obviously this technique might not work on more advanced devices, but it should still give you a solid base to work from.

In the end, [Stuart] takes an LED lamp that could only be controlled with a smartphone application and turns it into something he can talk to on his own terms. Once the ESP32 can send commands to the lamp, it only takes a bit more code to spin up a web interface or REST API so you can control the device from your computer or other gadget on the network. While naturally the finer points will differ, this same overall workflow should allow you to get control of whatever BLE gizmo you’ve got your eye on.

Continue reading “A Crash Course On Sniffing Bluetooth Low Energy” →

Arduino Serial Vs SerialUSB

March 20, 2021 by Chris Lott 18 Comments

[Andrew] wonders why the SerialUSB() function on the Cortex M3-based Arduino Due is so much faster than Serial() on the Uno or Nano, and shares his observations in this short video. He sets up an experiment with a simple sketch on both boards and uses Wireshark to evaluate the results.

Data is sent in the USB packets in groups of four characters on the ATmega-based boards, but the entire string is put in a packet on the Due board. If you look under the hood, the answer is hiding in plain sight. While the Arduino family of boards connect to your computer using a USB virtual serial port, the ATmega ones have an actual serial connection on-board. For instance, on the Nano there is an FT232RL between the USB connector and the microprocessor (on an Arduino Uno board, a small ATMEGA8U2 is used instead of an FTDI chip, but the concept is the same). On the Arduino Due, the USB connects directly to the SAM3X8E processor.

This concept doesn’t apply only to Arduino boards, of course. On any serial connection between two computers, when a virtual USB device is used on both sides of the link (no actual serial signals involved), the serial baud rate is a fictional thing — data transfer speeds depends on USB alone. We are curious why the packets contain four characters in [Andrew]’s ATmega Wireshark captures — why not 1, 2, or 10? Is this something that can be controlled by the programmer, or is it fixed by the protocol and/or the FTDI chip? If you have the answer, let us know in the comments below. Continue reading “Arduino Serial Vs SerialUSB” →

Exotic Device Gets Linux Support Via Wireshark And Rust

August 20, 2020 by Sven Gregori 10 Comments

What can you do if you have a nice piece of hardware that kinda works out of the box, but doesn’t have support for your operating system to get the full functionality out of it? [Harry Gill] found himself in such a situation with a new all-in-one (AIO) water cooling system. It didn’t technically require any operating system interaction to perform its main task, but things like settings adjustments or reading back statistics were only possible with Windows. He thought it would be nice to have those features in Linux as well, and as the communication is done via USB, figured the obvious solution is to reverse engineer the protocol and simply replicate it.

His first step was to set up a dual boot system (his attempts at running the software in a VM didn’t go very well) which allowed him to capture the USB traffic with Wireshark and USBPcap. Then it would simply be a matter of analyzing the captures and writing some Linux software to make sense of the data. The go-to library for USB tasks would be libusb, which has bindings for plenty of languages, but as an avid Rust user, that choice was never really an issue anyway.

How to actually make use of the captured data was an entirely different story though, and without documentation or much help from the vendor, [Harry] resorted to good old trial and error to find out which byte does what. Eventually he succeeded and was able to get the additional features he wanted supported in Linux — check out the final code in the GitHub repository if you’re curious what this looks like in Rust.

Capturing the USB communication with Wireshark seems generally a great way to port unsupported features to Linux, as we’ve seen earlier with an RGB keyboard and the VGA frame grabber that inspired it. If you want to dig deeper into the subject, [Harry] listed a few resources regarding USB in general, but there’s plenty more to explore with reverse engineering USB.

Reverse Engineering An RGB Keyboard Under Linux

April 14, 2020 by Tom Nardi 5 Comments

Hardware support under Linux is far better than it ever has been in the past. These days, most things “just work” out of the box, and you probably won’t have to compile any custom kernel modules. Certainly a far cry from where things were a decade ago. But that doesn’t mean everything will work to 100% of its abilities. Take for example, the Duck keyboard that [Cynthia Revström] has. Sure it works as a basic keyboard under any OS, but getting those fancy RGB LEDs working is another story entirely.

Don’t get the wrong idea here, [Cynthia] isn’t just trying to get the keyboard to flash along to music; the goal was to use the RGB lighting of the Ducky keyboard for notifications that the user can’t possibly ignore. Even the most laser-focused among us would have a hard time not noticing that the entire keyboard is blinking red. But the “DuckyRGB” software that you need to do something like that is Windows-only and apparently distributed via a sketchy Google Drive link. Yikes.

The first step to creating an alternative was to spin up a Windows VM and install DuckyRGB. From there, Wireshark could listen in between the virtual computer and the Ducky keyboard to see what the software was sending over the wire. After identifying a version number being sent in the clear, [Cynthia] was able to isolate the LED commands by searching for the hex color codes. From there, it was a relatively simple matter of writing some glue code to connect it up to an alert service and get notifications going.

There was only one problem; the keyboard didn’t work anymore. Turns out the tool that [Cynthia] wrote to control the keyboard’s LEDs was claiming the device so the kernel couldn’t access it for normal input. It took a detour with HIDAPI to get everyone playing together nicely, and now changing the color of your Ducky keyboard on Linux doesn’t turn it into a paperweight.

Even if you don’t have a Ducky keyboard, or aren’t particularly interested in having its LEDs blinked at you if you do, this project is a phenomenal example of practical USB reverse engineering. [Cynthia] says the inspiration for this project came from friend [Ben Cox], who’s write-up on creating USB userspace drivers we covered last year. If you’ve got and old USB gadget with Windows-only drivers, maybe it’s time you take a crack at unlocking it.

VGA Signal In A Browser Window, Thanks To Reverse Engineering

December 30, 2019 by Donald Papp 25 Comments

[Ben Cox] found some interesting USB devices on eBay. The Epiphan VGA2USB LR accepts VGA video on one end and presents it as a USB webcam-like video signal on the other. Never have to haul a VGA monitor out again? Sounds good to us! The devices are old and abandoned hardware, but they do claim Linux support, so one BUY button mash later and [Ben] was waiting patiently for them in the mail.

But when they did arrive, the devices didn’t enumerate as a USB UVC video device as expected. The vendor has a custom driver, support for which ended in Linux 4.9 — meaning none of [Ben]’s machines would run it. By now [Ben] was curious about how all this worked and began digging, aiming to create a userspace driver for the device. He was successful, and with his usual detail [Ben] explains not only the process he followed to troubleshoot the problem but also how these devices (and his driver) work. Skip to the end of the project page for the summary, but the whole thing is worth a read.

The resulting driver is not optimized, but will do about 7 fps. [Ben] even rigged up a small web server inside the driver to present a simple interface for the video in a pinch. It can even record its output to a video file, which is awfully handy. The code is available on his GitHub repository, so give it a look and maybe head to eBay for a bit of bargain-hunting of your own.