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.
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.
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.
You’re likely familiar with the old tale about how Steve Jobs was ousted from Apple and started his own company, NeXT. Apple then bought NeXT and their technologies and brought Jobs back as CEO once again. However, Jobs’ path wasn’t unique, and the history of computing since then could’ve gone a whole lot different.
In 1990, Jean-Louis Gassée, who replaced Jobs in Apple as the head of Macintosh development, was also fired from the company. He then also formed his own computer company with the help of another ex-Apple employee, Steve Sakoman. They called it Be Inc, and their goal was to create a more modern operating system from scratch based on the object-oriented design of C++, using proprietary hardware that could allow for greater media capabilities unseen in personal computers at the time.
Slack is either an online collaboration tool, or a religion, depending on who you talk to. Naturally, it’s accessible across all manner of modern platforms, from Windows and MacOS to smartphones. However, some prefer to go further back. At a recent company hackathon, [Yeo Kheng Meng] decided to create a Slack client for Windows 3.1.
Programming for an older OS, in this case, Windows For Workgroups 3.11, requires setting up a viable development environment. Visual C++ 1.52 was pressed into service in this case, being the last version capable of targeting Windows 3.11. The development environment is run on a Windows 2000 virtual machine running on a Mac laptop. This was chosen for its ability to run 16-bit apps, and its Samba compatibility with both Windows 3.11 and Windows 10 and modern Macs.
There were several challenges to face along the way. Old school Windows simply isn’t capable of dealing with HTTPS, necessitating a proxy to handle the exchange of packets with Slack servers. Additionally, memory management was a hassle due to the limits of the 16-bit architecture. Thankfully, an old programming manual from the era was of great help in this regard.
At the end of the hackathon, a usable Slack client was up and running, complete with garish colors from the early Windows era. There’s a few key features missing, such as the ability to resolve user IDs, but overall, the concept works. We’ve seen [Yeo]’s work with this vintage OS before too. Video after the break.
If you have your ear even slightly to the ground of the software community, you’ll have heard of Docker. Having recently enjoyed a tremendous rise in popularity, it continues to attract users at a rapid pace, including many global firms whose infrastructure depends on it. Part of Docker’s rise to fame can be attributed to its users becoming instant fans with evangelical tendencies.
But what’s behind the popularity, and how does it work? Let’s go through a conceptual introduction and then explore Docker with a bit of hands-on playing around.
PCI pass through is the ability of a virtualized guest system to directly access PCI hardware. Pass through for dedicated GPUs has just recently been added to the Linux kernel-based virtual machine. Soon afterward, users began to find that switching on nested page tables (NPT), a technology intended to provide hardware acceleration for virtual machines, had the opposite effect on AMD platforms and slowed frame rate down to a crawl.
Annoyed by this [gnif] set out to to fix the problem. His first step was to run graphics benchmarks to isolate the source of the problem. Having identified the culprit in the GPU, [gnif] began to read up on the involved technology stack. Three days of wrapping his head around technical docs allowed [gnif] to find the single line of code that resulted in a faulty memory set up and to implement a basic fix. He then passed the work on to [Paolo Bonzini] at patchwork.kernel.org, who released a more refined patch.
The bug affecting PCI pass through had been around for ten years and had received little attention from the manufacturer. It gained prominence when graphics cards were affected. In the end it took one very dedicated user three days to fix it, and then another day to roll out a patch for Open Source operating systems. In his notes [gnif] points out how helpful AMDs documentation was. With the right to repair in debate, DRMed technical docs and standards locked behind paywalls, [gnif]’s story is a reminder of the importance of accessible quality documentation.
In the last couple of decades we have become used to the browser taking over so many of the desktop functions for which we used to rely on stand-alone software. Email clients, calendars, office suites and much more can now be found in the cloud, courtesy of the usual technology companies.
With only a 100-cell memory and dependent entirely upon the processing power available to the host browser, this machine is not likely to set the world on fire. He gives full instruction set details, there are a couple of demo programs, a Fibronacci sequence generator and a factorial generator, but its general lack of power is not really the point. Instead its value lies in an elegant demonstration for its own sake that a virtual computer can be built in the unlikeliest of places, and for those interested enough to peer into its code, some idea how that might be achieved.