Search This Blog

To adblock users

Hello! If you see this, you are most likely using an ad blocker. (Or maybe you have JavaScript disabled. Or maybe my web server is down.) I have no problem with ad blockers; in fact I use one myself. If a site tries to deny me access unless I disable it, I just find a way to circumvent that. But if a site politely asks me to do so, but still allows access to the site, I disable it for the site. I am asking you to please do the same for this site. I can't make you, but I would appreciate it. Thank you! :-)

Sunday, September 28, 2014

Hacking the Bose Soundtouch, and its Linux-based OS

Did you know that the Bose SoundTouch line of home stereo systems runs on an embedded Linux system, complete with a shell? It does, and I figured out how to access said shell. Keep in mind that I take absolutely no responsibility for any damage you may do, and while if you know what you're doing I don't see how anything could go wrong, I still don't take any responsibility if you do manage to mess something up.

First of all, you're going to need a telnet client. I use PuTTY myself, but if you're on a Mac or Linux, you can just open a terminal and use the telnet command. Now figure out your device's IP address. It will tell you this when you set up your device in the Soundtouch app.

The first step is to telnet to the device on port 17000. You should see a "->" prompt. At this prompt, type "remote_services on" without quotes (you shouldn't include quotes for anything in this tutorial.) The device will respond with "remote services on". At this point you can simply close the connection, but there's also some other interesting stuff you can do here. You can type "help" to get a list of all the commands this prompt supports, or click here to see it on Pastebin.

Anyway, that command you just typed enabled remote shell access to the device. According to the aforementioned help screen, that command is "volatile", which I assume means if you restart the device you'll have to re-enter the command on port 17000 to re-enable shell access.

But from here accessing the shell is simple. Just telnet to the device again, this time on port 23, the default telnet port. You'll see the following screen:

 _______ __           __ __
|     __|  |--.-----.|  |  |--.--.--.
|__     |     |  -__||  |  _  |  |  |
|_______|__|__|_____||__|_____|___  |


Simply type "root" and press Enter. Some information will be printed, and then you'll be greeted with "root@lisa:root#". (I wonder who Lisa is?)

Enjoy your newfound freedom to hack your device!

EDIT: Upon first suspecting the existence of a shell after looking at a firmware update file in a hex editor, I contacted support to ask how to access the shell. Shortly after I figured out this method on my own. But then they emailed me back and said they weren't allowed to tell me because the information was "proprietary in nature." Good thing I'm not bound by the same contractual restrictions as their support personnel!


phillips321 said...

Nice, lets just hope they don't issue a firmware 'update' that sets the root password. Although i guess if they do that you could just diff the firmware image with the previous in order to identify where the changes are. Find the hash and either replace it with a known or crack it. (Make sure you store a copy of the vulnerable firmware as they'll likely remove it)

Mark Smith said...

As pointed out by some Hackaday commenters, aren't they bound by the GPL to present the license and source code of the GPL-based software? Are you sure it's Linux and not some other *nix? If it is indeed GPL, they don't mention it in the user manual, and you might want to pass this on to the FSF.

Flarn2006 said...

@Mark Smith, it is indeed Linux, as there are references to "linux" in filenames, like what I believe is the kernel. A quick look through the PDF manual doesn't show anything about the GPL, but there is at least one copy stored on the unit. Don't know of any accessible through officially-documented means though.

Anonymous said...

Output from 'uname -a' should settle the matter. If you are lucky, cd to /etc and see if there are any *release* files.

Chris said...

I don't know if this helps but it looks like it might be an old install of openlinux 2.2 here is a post of the bug.

Anonymous said...

_______ __ __ __
| __| |--.-----.| | |--.--.--.
|__ | | -__|| | _ | | |
|_______|__|__|_____||__|_____|___ |

login: root
eth0 Link encap:Ethernet HWaddr 00:0C:8A:B3:0C:E9
inet addr: Bcast: Mask:
lo Link encap:Local Loopback
inet addr: Mask:
usb0 Link encap:Ethernet HWaddr 8A:86:27:19:D5:E8
inet addr: Bcast: Mask:
root@spotty:root# uname -a
Linux spotty 3.2.0+ #50 Wed Aug 13 19:20:17 EDT 2014 armv7l GNU/Linux

Anonymous said...

I think the latest update has shut this down - looks like the only command that works at "->" is "help" (which I have to enter twice for some odd reason - the first attempt is not recognised as valid). "remote_services on" is also invalid, so doesn't seem to be the way to enable remote access any more.

Flarn2006 said...

@Anonymous, can you please pastebin the output of the help command on the updated version?

Anonymous said...

I'm not the same Anonymous but I can confirm that my new system does not have the same remote_services command anymore. Here is a pastebin of the new help:

I don't think the other commands are changed. I'm guessing they removed the command from the help and probably just changed it to something else.

The 'sys ver' command yields "BoseApp version: epdbuild.trunk.hepdswbld05.2014-12-11T22:02:14"

Anonymous said...

Could you run 'scm list' through the port 17000 connection and post the resulting process list after turning on remote_services? If something unique shows up, it may be able to be started with 'scm restart '

Flarn2006 said...

Here's the output from "scm list":

Anonymous said...

There was no difference with 'scm list'.

I've been messing with the port 17000 terminal a lot with little success. I haven't been able to find any commands that printf bad input buffers directly, which would be helpful to poke around the memory addressses.

I have a feeling there is a potential buffer overflow. The update package doesn't seem to include this program though (none of the strings are present). Could you (or anyone!) find and upload a copy of the program(s) that run on this port?

It likely is a single program that forks itself or another client program for each connection. If the telnet shell has something like 'ps' or 'top', it should be somewhat easy to determine which program is being spawned after making several connections.

Flarn2006 said...

I just remembered something. Someone told me in an email that there's another way to access the shell. I haven't tested it myself though. Buy this cable (, you can probably find a cheaper one somewhere else) and plug it into your computer and the port on the back of the unit labeled "SERVICE". It'll appear on your computer as a serial port; use the settings 115200 8 N 1 N. Connect to it with a terminal like PuTTY and it should give you the shell prompt. If you try it, let me know if it works so I can post it here!

Bose Soundtouch said...

Did you know that the Bose SoundTouch line of home stereo systems runs on an embedded Linux system, complete with a shell? It does, and I ...

Anonymous said...

Try local_services on instead

Anonymous said...

You do know that cable won't actually connect to anything on a Bose Soundtouch ? The service port is a micro USB, not a 3.5mm socket ...

Alex Oneccie said...

it has active service called "BTLESerial" - is it something related to Bluetooth console probably?

Antonio Serrata said...

Been a while on this. But is it possible to hack in the ability to add more Virtually Invisible speakers to the Soundtouch 300? Based on the fact these devices are all controlled by the same apps, the Soundtouch 300 would have the same ability to entry. I'd love to be able to add 2 more Virtually Invisibles seeing how good it sounds with the pair already.

Flarn2006 said...

@Anonymous: On mine it's a 3.5mm socket. If yours is a micro USB, try connecting it to your computer with a standard micro USB cable and see what it shows up as.

Lauro Moreno said...

Connecting through USB just brings up an enthernet interface. I'm gonna try to do a nmap scan on it later when it's not 4:50 in the morning.
(God I need sleep)

Alessandro Fulgini said...

Has anyone had a chance to access the shell after the recent firmware updates? I remember I managed to get access back in 2016, but now there's no such command as remote_services in the shell at port 17000 anymore

jakunar said...


I got the same problem, or maybe even worse.
For me 'help' results in:

Command not found

some command however still work, e.g.: scm list, key