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.
Seems like a hassle to emulate Android-x86 Dev Mode in a VM then sniff Bluetooth. Just plug a bootable copy of the Kali pen-test Linux distro on a USB stick into a machine and follow any number of examples online about snooping Bluetooth. Here’s one for-example:
https://blog.hackerassociate.com/how-to-snoop-with-kali-linux-on-bluetooth-devices/
There are lots of other tutorials out there too. BTW Here’s a link to Kali Linux:
https://www.kali.org/
Perhaps there are benefits to the approach (which actually worked) that spending 30 seconds on google hasn’t revealed?
Only read the Head article, but I would assume that the Android-x86 was necessary to have an Android system in an otherwise Android free household. Otherwise, the same could have been done on an actual Android phone/tablet. In essence, Kali would have just added another level of complexity, since it would have required a second machine to do what you’d otherwise do directly in Android.
Might just be me, but if the app in question is something I’d consider to be on the level of Spyware or malware, I’d only consider to throw it in a VM while it gets reverse engineered.
Bose’s app for their noise canceling headphones (which are the only way to properly set them up) is definitely Spyware tier, so I would’ve done the same as in the article if I didn’t take the nuclear approach and asked for a refund & left a scalding product review.
For starters, this covers BLE sniffing. Bluetooth Classic is a a different beast.
I can use a search engine, and actually prefer to do that over reinventing a wheel. And in the articles I actually talk about how I started trying to sniff it over BLE, and only when it failed went to look for a better way.
But if you can show me how to sniff classic BT on a cheap dongle (hey, maybe there’s a way), I’d appreciate that. A lot.
ooh, the author is here =) thank you for the impressive hack!
*Blush.* Thank you.
Is this a joke? None of this is remotely useful in this context.
How is it not useful? This could be used as part of a universal remote, for example. IR blasters have multiple issues, like line of sight.
Clueless’s comment is not addressing the article, but an another comment instead, read carefully.
No way did you actually read the linked article if you thought this was a worthwhile comment. It even goes over the use of several of these tools. But none of that is going to help you sniff the coms between the app and speaker.
It’s a shame that all the comments (even this one, I realize) are just responses to this first comment. it should be deleted because it’s so far off the mark, but that would take all the responses with it.
this interests me because I have a bluetooth enabled device but the official software sucks and i was wondering if it was possible to interface with it and either get the same funcionality or more from it.