In recent versions Arylic has fixed several vulnerabilities and I have not found a way to "hack" into the CLI anymore. Telnet acces was still possible with version 4.2.8020 from 2020/02/20 (20th of Feb 2020) that was installed when I had bought the first devices.
The following information is specific for Arylic Up2Stream Amp v2 and Up2Stream Pro v3, but might also helpful for other devices, especially if they are also based on the Linkplay A31 module.
With Wireshark I have sniffed how the upgrade process is working and which files are required. At first the device gets a list of all (or at least many) Linkplay products
The XML file contains a list of products with their ID and more, including an URL for specific information. The example contains the two devices listed above (list was retrieved in Oct 2020):
> In previous versions the ***product.xml*** was also retrieved from silenceota.linkplay.com/wifi_audio_image and stored in the same directory as the images below.
The URLs include a "random" ID that might be mapped to the product ID and a subdirectory with the version (date) for some files. The MCU files follow a different structure with the product ID used as a subdirectory and a version number that is included in the name of the image.
| \<md5-url\> | major-version | plain text file with MD5 checksums for image files (uBoot, backup, user2, kernel) |
| \<ver-url\> | major-version | plain text file with version information and release date |
| \<layout-url\> | major-version | plain text file with layout (e.g. offset, size, version, fstype, name, size) of file system in flash (user2, user, kernel) |
| \<image-kernel\> | major-version | main binary image for kernel |
| \<image-user\> | major-version | image for user file system (persistent) - not available for download |
| \<image-user2\> | major-version | image for user file system (persistent) - not available for download |
| \<image-uboot\> | - | boot loader uBoot |
| \<image-backup\> | - | backup image |
I'm not sure if the **\<sign\>** tag is used at all and what is covered with that 'signature'. I've modified the URLs (different FQDN and path) and got no error. Only the following files are downloaded during an upgrade and in that order (verified with Up2Stream Amp v2.0 and Wireshark):
> If an upgrade is available, it may be installed automatically without any notice! In the 4Stream app you might see that a new version is highlighted with "new" and you might get a popup with a notification. I have not found out, when an update is installed automatically.
To be able to downgrade the firmware you need to modify DNS names, e.g. you may install dnsmasq on your local network and point to that DNS server from your DHCP server. To redirect the firmware up-/downgrade process to your own webserver, you can create a simple file in the /etc/dnsmasq.d directory with the following content (10.1.1.22 is the IP address of my webserver located on my MacMini)
The downgrade needs to be adjusted for newer versions, e.g. v4.6.415145, release date 20220427". If you have a device with that version, continue to read section
[Firmware Downgrade from v4.6](Downgrade.md#firmware-downgrade-v46)below.
You may modify the configuration file on your webserver to use different folders for different FQDNs. Be sure to verify any URLs from a web browser or curl. On your PC you may manually point to a public DNS server to be able to download XML files and images from the Internet.
> **Note:**
> The modification of the two FQDNs will prevent any further updates!
Here it is documented from v4.2.8826 to v4.2.8020. To get information about the product ID (project), the current version and release date you can use the "getStatusEx" command. The following output is "enhanced" / beautified with the tool "jq" (JSON processor):
At first you have to download the following XML files, install them in the appropriate directory on your webserver (you may keep the path and create the directories as required).
> There is no link to older version available. The ***products.xml*** file only contains URLs for the latest version, so you need to know (or guess) the URL for the specific ***product.xml*** file. The following URL is working for the Up2Stream Amp v2 and partially also for the Up2Stream Pro v3 (without MCU). I've added the URL for the ***products.xml*** file to the Wayback archive (https://web.archive.org) on Dec 31th 2023, so it does not work for older versions.
At first you can download the actual ***products.xml*** file, remove everything except your products, adjust the URLs (optionally) and install it on your web server:
Next you download the specific ***product.xml*** file. The following URL is for the RP0011_WB60_S product ID, but except for the MCU all images look to be the same as for product ID RP0011_WB60, UP2STREAM_PRO_V3, and others. I'm not sure, but all devices with the Linkplay A31 module might use the same firmware. You may download and compare the RP0011_WB60_S product below with your device (including MD5 checksums) and replace MCU part show below with the one from your device. It looks that older versions of the ***product.xml*** files and images are still available for download - you just need to know (or guess) the URLs.
Modify the <major-version> in the ***product.xml*** file to be one day ahead of your current release date, e.g. 20201027 if your current release date is 20201026. You may also combine the content with a different MCU (project). Be sure that the project name is exactly matching your device!
Modifiy the version number in the ***MVver*** file (first line) to be higher than your current version number, e.g. WiiMu.4.2.8027 if your current version is 4.2.8826.
Trigger an update with the following commands and verify the progress with Wireshark running on your web server. You may use "http" as a filter to see the downgrade process:
In newer versions it does not work to modifiy your DNS server to add a spoofed (local) IP address like 10.1.1.22 for silenceota.linkplay.com anymore. With Wireshark I was not able to see any http requests to the ***products.xml*** file from the Linkplay device. I'm not sure if that's due to the fact that this is a local IP address or spoofing is not allowed for silenceota.linkplay.com anymore. The following procedure has been tested with v4.6.415145, release date 2022/04/27.
To be able to prevent an automatic upgrade afterwards you need to modify DNS names or block specific DNS requests. You may either install dnsmasq on your local network and point to that DNS server from your DHCP server or block DNS requests from the Linkplay device to the Internet. To install dnsmasq follow instructions from the Internet, create a simple file in the /etc/dnsmasq.d directory with the following content (10.1.1.22 is the IP address of my webserver located on my MacMini)
The downgrade process seem only to work with plain IP addresses instead of DNS names in all config files and the SetUpdateServer command, so you may not need to run your own dnsmasq server, but you need to block DNS requests from the Linkplay devices to the Internet to prevent automatic upgrades afterwards.
The following records were created on the DNS server:
```
cat /etc/dnsmasq.d/linkplay.conf
address=/silenceota.linkplay.com/10.1.1.22
address=/ota.rakoit.com/10.1.1.22
address=/api.linkplay.com/10.1.1.22
```
Restart dnsmasq after any changes:
```
/etc/init.d/dnsmasq restart
```
You may modify the configuration file on your webserver to use different folders for different FQDNs. Be sure to verify any URLs from a web browser or curl. On your PC you may manually point to a public DNS server to be able to download XML files and images from the Internet.
> Beside of your own DNS server (typically set by DHCP), the Linkplay devices also send DNS requests to ***8.8.8.8*** and ***8.8.4.4*** (the two Google DNS servers). The device also sends DNS requests with ***firehose.eu-central-1.amazonaws.com***, ***api.linkplay.com*** as names and asks for their IP addresses. You may need to block these requests on your Internet router or point to your local web server to prevent automatic updates later on. I've blocked any DNS requests on my Internet router (Fritz!box) by using a blocking list and adding DNS service to this list. Older version (v.4.2) send DNS requests with s000.linkplay.com and avs-alexa-na.amazon.com as a name. The DNS requests may be related to the music services that are available or configured on the device.
To get information about the product ID (project), the current version and release date you can use the ***"getStatusEx"*** command. The following output is "enhanced" / beautified with the tool "jq" (JSON processor):
At first you have to download the following XML files, install them in the appropriate directory on your webserver (you may keep the path and create the directories as required).
> There is no link to older version available. The ***products.xml*** file only contains URLs for the latest version, so you need to know (or guess) the URL for the specific ***product.xml*** file. The following URL is working for the Up2Stream Amp v2 and partially also for the Up2Stream Pro v3 (without MCU). I've added the URL for the ***products.xml*** file to the Wayback archive (https://web.archive.org) on Dec 31th 2023, so it does not work for older versions.
At first you can download the actual ***products.xml*** file, remove everything except your products, adjust the URLs (optionally) and install it on your web server:
I've modified the FQDNs to point directly to the IP address of my web server and have only these three products in the list (only the 'product' in the middle with product ID ***RP0011_WB60_S*** is used in the example):
Next you download the specific ***product.xml*** file. The following URL is for the RP0011_WB60_S product ID, but except for the MCU all images look to be the same as for product ID RP0011_WB60, RP0011_WB60_S, UP2STREAM_PRO_V3, and others. I'm not sure, but all devices with the Linkplay A31 module might use the same firmware. You may download and compare the RP0011_WB60_S product below with your device (including MD5 checksums) and replace MCU part show below with the one from your device. It looks that older versions of the ***product.xml*** files and images are still available for download - you just need to know (or guess) the URLs.
Modify the <major-version> in the ***product.xml*** file to be one day ahead of your current release date, e.g. 20220428 if your current release date is 20220427. You may also combine the content with a different MCU (project). Be sure that the project name is exactly matching your device! As before I've also modified the FQDNs to point to my own domain and the subdirectory names to be more descriptive. The last two files with '.jffs2' are removed, because they were not available from the update server (actually they have an error message as a content that the file was not available).
Modifiy the version number in the ***MVver*** file (first line) to be higher than your current version number, e.g. WiiMu.4.6.415146 if your current version is 4.6.415145.
After you've downloaded the images and prepared the files as described above, you need to inform the device about your own web server. On my Mac mini it's the directory ***/Library/WebServer/Documents/linkplay*** that is accessible as http://10.1.1.22/linkplay. The ***products.xml*** file needs to be located in the main directory of that URL.
Trigger an update with the following commands and verify the progress with Wireshark running on your web server. You may use "http || dns" as a filter to see the downgrade process:
> I recommend to rename the ***products.xml*** file on your server after an up- or downgrade to something else and block or redirect any upgrade requests on the Internet. If a ***products.xml*** is found on that server in the proper directory (the default URL is pointing to http://silenceota.linkplay.com/wifi_audio_image) then an automatic upgrade may be triggered.
## Problem with Upgrade after downgrade
In v4.6 Arylic has added a command to play a notification URL from my home automation system while music is playing. The music is faded out before the notification message is played, so this is quite nice. After I had installed a permanent hook that even survives a reboot I wanted to upgrade afterwards. See [Install Persistant Hook](/persistant-hook.md) for details.
I don't know why, but an upgrade with cli commands always got stuck after the device has fetched the ***MVver_20220427*** file. The three files ***products.xml***, ***product.xml***, and ***MVver_new*** were downloaded properly and temporarily stored in ***/tmp*** directory on the device. For some reason the device believes that an upgrade is not required, so the upgrade process is stopped.
I thought that a variable in NVRAM might block the upgrade and had a closer look to them with ***ralink_init show 2860***, but could not find an answer. That's what I have tried:
```
ralink_init show 2860
nvram_set 2860 FirmwareServerVersion 4.2.8020
nvram_set 2860 Ota_Fw_New 4.2.8020
nvram_set 2860 part_ver_kernel 8020
reboot
```
I also tried
```
nvram_set 2860 FirmwareServerVersion 0
nvram_set 2860 Ota_Fw_New 0
nvram_set 2860 McuServerVersion 0
nvram_set 2860 McuSaveVersion 0
nvram_set 2860 Ota_Mcu_New 0
```
I also played around with the FQDNs (the DNS hostname or IP address) and the URLs that are used in ***products.xml***, ***product.xml***, and ***MVver*** without any luck. I tried IP addresses as well as FQDNs. I even pointed to the real update servers on the Internet, but that failed with the same result as well. So it looks that the problem must be on the device itself.
There is a simple way to work around that problem: install the upgrade via 4Stream app from you mobile phone. It was working on my iPhone (4Stream app version 2.8.11908) and I upgraded from v4.2.8020 release date 2020/02/20 to v4.6.415145, release date 2022/04/27.
