Some days ago somebody handed over an Olive Opus 4 player to me. The device is a digital music player that also streams from the internet. Since the manufacturer of the hardware folded the device would not play any internet streams any more. My suspicion was that it looks for play lists of internet streaming stations on the manfucaturer’s ressouces on the internet. As that fails it did not play any internet streams any more.
The software of the player also offered to play manually entered stream URLs but as the “internet radio” menu item was not shown any more this function was also redered useless although a manually added URL shout basically work regardsless of any lists by the manufacturer are available or not.
So I decided to analyze what the box tries to do and whether it would be possible to persuade the device to at least play manually entered and saved stream URLs. A tcpdump of the devices’s network traffic showed that it tries to ping the menufacturer using the hostname “olive.us”. Of course it did not receive a reply and due to this the menu item “internet radio” does not pop up. As a first quick and dirty hack I configured a host route for the IP 52.58.78.16 (which currently is returned when DNS looking up olive.us). As soon as the Olive player receives a ping reply it displays the “internet radio” menu item. So further motivation was to somehow implement a permanent solution so that the player can be still be used to manually configured streams.
The first solution would require external network equipment that emulates the host to be pinged by the Olive player. So first I thought about routing the device’s traffic through a Raspberry Pi or similar with the above mentioned host route and having the device answer the pings to olive.us with some iptables magic.
But as the owner of the device would have needed additional hardware I did some further research on how this could be fixed by software only. So I opened up the device after recommendation by a friend and attached the SATA hard drive to my Linux machine. After a short while 4 partitions popped up. One of those is rather small and contains a (V)FAT file system. This is obviously used for booting. Another two partitions contained and ext file system with a typical Linux folder structure. One of those partitions is probably a backup or fallback system. Changed to files in here did not have any effect.
My second idea was to have the system have a /etc/hosts entry containing the loopback IP address for olive.us. So after I edited the /etc/hosts on the second partition with a Linux folder structure the device booted and - oh wonder - displayed the “internet radio” menu item. But as suspected this did not survice a reboot. After powering down and re-powering the device the entry was gone and internet radio was disabled again.
So I tried to identify how this file is created. On the backup system I found an init script /etc/init.d/rcS that filled /etc/hosts using a here document. Apparently the startup script on the partition with the actually executed system this was different. So I added a line of code to that script like this:
$ echo "127.0.0.2 olive.us" >> /etc/hostsAnd bingo. This seemed to be a permanent solution. Internet radio now also available after re- or coldstarting the device. Another nice finding in the init script was a commented-out start of an SSH dameon:
Yeeha, after removing the comments here we have a running SSH server:
The credentials have been found in /etc/passwd on the harddisk. Fortunately I found a source ([[1]][1]) on the net which lists the decrypted root password:
user: root
pass: tj270442With this we can now login and do whatever we want on the running OS.
So now off the see where we could implement a nice hacked-by-badge :). What almost worked instantly was to edit /etc/version.xml and modifying the oemversion parameter:
Which can see on the GUI after opening the systems settings -> software information menu:
The last experiment was to hack the startup log of the box. The init script reveals that it writes raw image data /etc/olive.img to /dev/fb0 framebuffer device. So I analyzed the image file /etc/olive.img. The screen size is 480x272 pixels in RGB565 format without any header and/or footer. The raw image data be opened/imported as raw image data in Gimp using the settings “RGB565 Little Endian” with size 480x272 and offset 0. Then I added some text and exported the picture as bitmap .bmp file with “16bit R5G6B5” format. For some reason it is saved with 24bit per pixel however. Looking for a solution to save it in the same format as the original file with Gimp was not successful.
Instead I ended up with a some ffmpeg magic to convert the bmp into the correct raw format:
and found a quick ffmpeg command to convert this into a jpg picture:
$ ffmpeg -vcodec bmp -i olive.bmp -vcodec rawvideo -f rawvideo -pix_fmt rgb565 texture.rawThe output was then transferred to the Opus 4 box using scp and stored as /etc/olive.img. During booting the raw picture is then copied to the framebuffer and displayed on the screen:
References
[1]: https://www.avsforum.com/forum/153-cd-players-dedicated-music-transports/1091695-official-olive-thread-opus-4-opus-6-melody-2-olive-2-olidecrypted ve-4-4hd-06hd-76.html