trulyspinach/sonos-fenway

Everything we know about Fenway

Sonos Fenway

Everything we know about Fenway

For general information, hacks about other class of Sonos devices please find them here.

What?

Sonos Fenway(Model 0x08) are a series of Sonos's product launched starting from 2011, including:

• Sonos Bridge[*?]
• Sonos Sub(Gen 1)[Anvil]
• Sonos Play:1[AMOEBA]
• Sonos Play:3[?]

This is not an exhaustive list.

These models support both S1, S2 controller app and all powered by MPC8314.

Toolchain

GCC cross compile toolchain can be set up to produce executable for Fenway devices, the screenshot below shows a Sonos Play:1 running Python3:

A Python3.7 with minimum standard library files required to get to REPL can be found here.

TODO: more detail on setting up toolchain.

Custom Firmware

A proof of concept for custom firmware was uploaded here.

This firmware aim to make subsequence researches easier and features the following:

• SSH and telnet for root user enabled by default with a password: fenway.
• Dumping system over http server via: http://<IP>:1400/root/<path to file>. e.g. http://<IP>:1400/root/VERSION
• Normal access to Sonos services and playback.
• Optimized setup ringtone audio.

These firmware can be flashed to the device over tftp using the upgrade command in U-boot.

Getting Shell Access

In general there are two ways for you to get root shell in these devices: UART and telnet. However, both are disabled by default in production devices. You are lucky if whichever one you are trying to hack are running diagnostic firmware, which gives you root shell over UART by default. In most cases where your device are running production firmware, good news is you can flash a diagnostic firmware at uboot(see sections below for detail) to enable shell.

So if by some chance you are in a root shell, add these flags to MDP to make subsequence access permanent:

• MDP_AUTH_FLAG_KERNEL_PRINTK_ENABLE
• MDP_AUTH_FLAG_CONSOLE_ENABLE

This can be done via: #mdputil -wfF 3 or for newer firmwares:

#mdputil -wfC 1
#mdputil -wfP 1

U-boot

Accessing the U-boot shell is as easy as hooking up the UART. The connector footprint is kinda obvious so I won't cover details here, just look for a 4 pin JST 1.25mm footprint. If you're really having a hard time locating them try searching around the internet for images. You do need to spam key presses right after device power on to interrupt autoboot.

sonosboot

Fenway uboot have a command sonosboot that warp around memory booting with a version(bootgen) and integrity check to determine which section(bootsect) to boot. If you want to boot the least fresh section do sonosboot fallback.

upgrade

You can load a partition image(not upgrade .upd file) via the upgrade command in uboot. The image is sent to the device over tftp and IP of both peers are statically assigned by uboot env variables(see printenv). The simplest setup is connect your device to a tftp server using the Ethernet port and set server's IP to 169.254.2.2 then run:

=> upgrade <partition> <file_name>

Partition name can be obtained via running ptable.

This can also help you to gain shell access to the device by flashing a diagnostic firmware then set flags using mdputil. Grab a dump from firmware/dump and serve them using tftp.

It also appears that the uboot does not perform any integrity check for the provided image, so this could protentially be a nice way to upload custom firmware.

Q&A

Where is the part that handle Sonos services in the root fs?

Look for anacapad. This huge binary handles all Sonos's related services including accessing music services, serving :1400, LED control and audio playback.

How can I test with modified files that are in rootfs which is mounted as readonly?

You can wget or ftpget the file to jffs then bind mount the target path: mount --bind <your_file> <path to replace>

How do I change device's serial number?

mdputil -wfs <serial number>

Doing so will make your signature invaild so don't do this just for fun.

Why?

While playing around with some poor Sonos Fenway devices that refuses to work due to firmware issues. I am able to gain a lot of in depth understanding of Sonos's software stack so I will try to organize what I know and share them in this repository. Hope these can be helpful and you are more than welcomed to correct me or share your knowledge about these devices by contributing to this repo!

Feel free to open up issues or reach me out!

Bonus

Listen to the pin!

sonos-fenway's Issues

NAND maybe fried

Hi, I've a Sonos Play:3 and i got uboot shell through UART
I think that NAND is fried because it give me a lot of sequential error and no boot

Machine check in kernel mode.
Caused by (from msr): regs 03f18c18 Unknown values in msr
NIP: 03FAAF24 XER: 20000000 LR: 03FA905C REGS: 03f18c18 TRAP: 0200 DAR: 00000000
MSR: 0000b002 EE: 1 PR: 0 FP: 1 ME: 1 IR/DR: 00

GPR00: 03FD2598 03F18D08 00000080 00000005 03FF93DE 00000000 03F18CF0 03FE7128
GPR08: 03FE93F8 03FA907Machine check in kernel mode.
Caused by (from Machine check in kernel mode.
Caused by (from msr): regs 03f187a8 Unknown values in msr
NIP: 03FAAEE4 XER: 20000000 LR: 03FA91E8 REGS: 03f187a8 TRAP: 0200 DAR: 00000000
MSR: 00003002 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 00

GPMachMachine check in kernel mode.
Caused by (from msr): regs 03f18338 Unknown values in msr
NIP: 03FAAEE4 XER: 20000000 LR: 03FA91E8 REGS: 03f18338 TRAP: 0200 DAR: 00000000
MSR: 00003002 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 00

Using ptable this is the output:

=> ptable
Default Partition Table
Partition Table, magic 653503e4, flags 00000000
partition-0: type 2, start 0, blocks 16
partition-1: type 16, start 16, blocks 192
partition-2: type 17, start 208, blocks 640
partition-3: type 64, start 848, blocks 2288
partition-4: type 16, start 3136, blocks 192
partition-5: type 17, start 3328, blocks 640

but when i try to upgrade it returns

=> upgrade partition-0 rootfs.gz
unknown destination partition-0
exit not allowed from main input shell.

I don't know if i'm wrong with somethings or actually the NAND is fried and the partitions are "fake partition"

With a view to bypassing the NAND i've tried to boot with tftpboot but it's expecting an .img file
I've tried renaming .upd file but obviously isn't the same as .img file

=> tftpboot
*** Warning: no boot file name; using '0101FEA9.img'
Using eTSEC1 device
TFTP from server 169.254.2.2; our IP address is 169.254.1.1
Filename '0101FEA9.img'.
Load address: 0x200000
Loading: #################################################################
         #################################################################
         #######checksum bad

So, the question is: somewhere there is a .img file that i can use to tftpboot or something that can i do if i replace the NAND with a new one?

Thanks a lot