Rooting MCI730/12 device

Promised post about getting root on Philips MCI730/12 media center. As always – no warranty, anything could happens with your device, you are doing this on your own risk.

  1. You will need USB flash formatted to FAT or FAT32.
  2. Put file firmware2010_102h.tgz to the root folder of the disk. This is not a real firmware and it will not modify your device. Only purpose of this package is to provide root access on boot.
  3. Unplug AC cord to power off the device. Insert USB flash in the device. Press and hold EJECT key then plug AC cord. After some time device will start booting in the “Rescue” mode.
  4. If everything done right you will see something like this: Image
  5. To telnet device you need to connect to the Ethernet port. Device address is 192.168.101.211/255.255.255.0, telnetd is running on standard port (23). Password is root/root.
  6. If you want to start telnetd in normal (non-rescue) mode permanently add line
    “/usr/sbin/telnetd -p 23 &” to the /usr/local/etc/mnetwork.conf file using command
    echo '/usr/sbin/telnetd -p 23 &' >> /usr/local/etc/mnetwork.conf
  7. Reboot the device. Telnet will be running on standard (e.g. DHCP) device address, on port 23, with root/root login.

Some background information:

File firmware2010_102h.tgz emulate firmware update. When device booting in the “rescue” mode it extracting content of this file to the temporary directories and starts ./install shell script. In normal update tarball this script re-flashing device, but in our case it just configuring network interface and starting telnetd. I am using /usr/local/etc/mnetwork.conf to start telnetd because it only file located on r/w partition. This file is included by /etc/netinit.sh from the read-only (cramfs) rootfs. Also it is used by mediabolic server, but it seems that it silently ignoring this line, so this hack works fine.

About these ads
Tagged , , , ,

32 thoughts on “Rooting MCI730/12 device

  1. Jos says:

    I tried this with my MCI298, which is very similar to the MCI730, and it worked. My main purpose is to get the device to work reliably, and stay connected, even if it is only on the wired connection. Any tips on how to do this?

    • sammczk says:

      Hi. Currently you can download mplayer package. I do not have a lot of time to work on this now.
      For me device is work mostly reliable if using wired, please tell me more about your issues.

  2. Jos says:

    My issue is:
    1) I do a factory reset, and don’t do network configuration
    2) I can play FM radio, no problem for days.
    -3) As soon as I connect to the network by sticking in the network cable, no configuration, the MCI298 seems to acquire a network address.
    4) After a number of minutes / hours, the network connection seems to temporarily fail, the MCI comes out of standby mode or whatever it is doing, and shows the media library screen.
    5) Any menu option selected through the remote results in a reboot.

    What I would like to ask:
    - Can I force a re-download of the firmware for instance by changing the version in ECD_key? This in case there is corruption in the loaded image.
    - Alternatively, can you tell me how to load the firmware from the Philips Site on a USB stick so I can reflash (when I brick the device)?
    - The firmware versions for MCI730 and MCI298 are the same, but the CD version of mine is different, MCI298 has a slot loading drive. I doubt that the firmware contains anything related to the CD. So maybe you can make your USB image available.to me?
    - My hope for a “simple” solution is to find the offending software module, verify that it is not required, make sure this software does not get loaded, and use the machine on the Ethernet connection. Any thoughts?

    I am determined to get this baby to work. Your help is greatly appreciated.

    • sammczk says:

      Symptoms looks strange and it is VERY unlikely that it is related to broken firmware. I would assume that something wrong is with networking, may be DHCP server is not answering, or smth. like that. My recommendation is to:

      1) enable telnet access to device, as notices in my post.
      2) Run ping from the same network to device.
      3) Check if device has IP address when problem occurs. If you can access to it via telnet or not. This will help to understand the reason of problem. Also i am recommending to unload wifi module completely to make sure that networking is not broken by it. It is buggy, anyway.

  3. Jos says:

    I have done as you said. I have done:
    ifconfig eth1 down
    killall -9 wpa_supplicant
    rmmod vntwusb

    The problem still occurs. When it occurs the network indicator on the screen is red, but I can just telnet into the device. I have compared the running processes, but see little difference, except for DHCP seems to have restarted:
    1168 root [start_udhcp]
    1177 root /sbin/udhcpc -b -p /var/run/udhcpc-eth0.pid -i eth0 -s /etc/default.script -T 5 -t 5

    System log does not report anything.
    It seems that ./mgfxclient gets upset by some (temporary) networking problem and this results in the media library screen popping up. When interacting with the program through the remote it abends. I think reboot on the line after the call of ./mgfxclient in appinit.sh causes the reboot.

    I still don’t know why it is that ./mgfxclient gets her knickers in a twist.
    I am going to set a fixed IP address and kill dhcpd as well and se what that does. The annoying thing is that it can take some hours for the error to occur.

    Thanks for your help so far

    • sammczk says:

      Ok, please let me know if it makes a difference. BTW, i did a custom firmware which boots from USB, has SSH and allows to restart mgfxclient. I can share it if you want.

      • Jos says:

        Ok,
        Problem still there, but I noticed that setting a manual IP address (canceling when acquiring an address and setting IP manually) shows up in the status as manual, but after switching of the device, it shows up as automatic again. Looks like it checks if a DHCP server is present and switches manual off. Will further investigate. A custom firmware is interesting and might allow me to do some more rigorous changes without too much risk, so yes please!

      • sammczk says:

        I will try to release it on a weekends. BTW, i am not switching my device to off state and using standby instead. It consume minimum electricity and my wife like a big clock on LCD :)

        P.S. On boot it always loading this shity wifi module, etc. That is why i did custom firmware from USB.

  4. Jos says:

    Still eagerly awaiting your custom firmware. Found out that the fixed ip sticks if I set router etc by hand as well. It does not solve the problem though. So it is not DHCP related. I hope you find time soon.

    • sammczk says:

      Can`t promise – need to solve some time to clean up image, prepare manual,etc. Also i do have a problem – it not always loads. I assume that there are some bugs in kernel related to USB mass media, so sometime it just hanging on load. Need to do serial cable to debug. Before i will do this i can provide you small howto about restarting mgfxclient.
      As you found it is not possible to restart mgfxclient by killing it – init will restart device. But there is a funny hack to avoid this – mgfxclient is started by catchsegv. Sop you can “hang” this prorcess and kill mgfxclient. Something like

      killall -STOP catchsegv
      and then you can kill mgfxclient and start it again (you will need also to do “export LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/local/lib/modules:/usr/local/lib/mediaserver” in the console).

      If mgfxclient is started in console it will produce a lot of debug messages. I hope this will help you to find and fix a problem. Write me if it helps

      • Jos says:

        Thanks for the how-to. Using it I saw that mgfxclient crashes because of too many open files. Further investigation revealed that every couple of minutes about 20 extra files get opened until it reaches the threshold of 1024. That is when it hangs/crashes.
        The file being opened is always the same one: /tmp/uuid. This files hold some descriptor of the MCI298. I found that the incrementing of open files stops when I stop the standard mediaserver on my Synology.

        When I start the Twonky mediaserver on the Synology, the incrementing does not occur, or at least at a much slower rate. The media server UPnPlayer on my iPad behaves bad. Windows7 Mediaplayer behaves well.

        My conclusion is that the mediaservers announce themselves periodically, and some cause mgfxclient to allocate resources that are not released.

        I prefer to use the Synology mediaserver. Have you any pointers to a solution? I have tried changing permissions on /tmp/uuid with no result.

      • sammczk says:

        Interesting finding. I am currently do not have upnp server running, but do have positive experience with Logitech Media Server. Also i do not have ipad, so it is hard for me to check.
        Some recommendations:
        1) Try to change limits (ulimit) to see if it will stop growing at some point (ulimit -n 64000)
        2) Its interesting if removing of this file will help or not
        3) Unfortunately there is no source code of the [buggy] mgfxclient. one of the workaround is to watchdog this process and kill it if needed.

        Please share results with me, it is interesting.

  5. Jos says:

    I have spent a lot of time on this with the following result:
    Using Wireshark I saw that the MCI298 follows the UPNP standards as defined in http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf
    It advertises itself with a set of UDP multicast messages on 239.255.255.250:1900. The advertisement expiration time in the messages is 1801 seconds.
    It refreshes the advertisement every 30 seconds. This period is a lot shorter than the advised one-half of the advertisement expiration time.
    The advertisement message also contains the address where interested UPNP nodes can find the UPNP description of the MCI298. This is at address http://{mci298}:8888/upnp_descriptor_0
    When a UPNP node accesses this address the MCI298 serves the UPNP descriptor XML message. This is also when the file /tmp/uuid is recreated and left open.
    Mediaservers like Twonky sparingly access the descriptor. Other mediaservers access the descriptor for every advertisement of a service they are interested in. In my case this means that the threshold of 1024 open files is reached after about 4 hours.
    It can be easily tested with the following script after inserting the right ip address:

    #!/bin/sh
    i=1
    while [ $i -le 1024 ]
    do
    echo $i
    i=`expr $i + 1`
    wget -O /dev/null http://{mci298}:8888/upnp_descriptor_0
    done

    Try navigating through the menus on your MCI after running this and it will crash / reboot.

    Some of the possible solutions I thought of:

    1) Submit the issue to Philips / Mediabolic with threat to file for revocation of the DLNA certificate. (I doubt if they will be impressed)
    2) Patch the descriptor URL in the multicast message to point to a non-existing / pre-defined page on a known server with the right data on it.
    The descriptor URL can changed by patching the program or mangling the message with an IPTABLES rule on a router.
    3) Stop the multicast from reaching the servers, so no query for the descriptor page is issued. Filtering the multicast message can again be done in a router.

    I have tried option 2 and 3, but to no avail. I can elaborate on how I tried if you want.
    I hope you have some fresh ideas

    • sammczk says:

      Thank you for a very detailed report. I see another possible solution – do LD_PRELOAD wrapper for open and return fail if /tmp/uuid is requests. I hate such closes-source mess, really.

      BTW, you can try to contact support for this, but i think this device is not _really_ supported. E.g. wifi bug is VERY easy to proof, but nobody care. About DLNA Certification – may be it could be an option, no idea. I will try provided batch script tomorrow and will tell you results.
      P.S. i am currently formatted flash to ext2 and boot process seems to be much more reliable. Before i was using vfat + loopback device with ext2 and boot was very problematic. I will probably upload my image on the weekend.

    • sammczk says:

      I just tested your script with my device and i`m unable to reproduce this crash. So it possible that it is fixed in my build. I will upload my firmware on weekends to SF.net storage, so you will be able to try mine version.

      • Jos says:

        I am surprised that you were unable to reproduce the crash. Maybe my code got mangled. In the meantime I have managed to put a router running DD-WRT between the player and the rest of my network, and use iptables / ebtables to filter out the broadcasts. This is a workaround, but after 8 days of uptime I now have /tmp/uuid open 87 times. So I think the reboot will only occur every two to three months. For the rest the unit works fine now.

  6. Ferenc says:

    Hi Jos,

    I have the exactly same problem, what you described above re MCI298 restarts. As I understand well, the workaround is to block the upnp packets from your Synology to Philips? I have QNAP NAS (almost the same), enabled Twonky and enabled Multimedia Station. As I have only one router, there is no way to block these upnp packets (my router can not do it). Any other idea, how can I get back my Philips working?

    Thanks,
    Ferenc

    • Ferenc says:

      Another thing: I’ve tried the orignal boot process as described in the beginning of this page, but can not access the device via telnet. The MCI298 shows the MCI hackfw picture, but cannot get via telnet. Maybe it is the problem, that I have total different network setup, I’m using 192.168.1.x IP address and this 192.168.101.211 is not reachable from my PC. Any chance to change this 101.211 IP?
      Many thanks in advance for any kid of help, I’m really interested to get this device working again :-)

    • sammczk says:

      Please write more details, lets see what we can do.

      • Ferenc says:

        Hi,

        if my device is connected to a network (using wire or wifi), it is randomly rebooting, or just loosing the network connection (small red network icon in the top right corner of the LCD). In my network, there is a QNAP NAS, providing music/films via UPnP (Twonky server). The repair center could not do anything, from their prespective, the device is fully functional (they can not reproduce the network loss).
        I’m quite newby in Linux, but any proposal would be welcome, as the device has really good sound qualitif, we love it, but this behavior is quite ugly and boring, always restart and suffering with the network connection.
        First I’ll try to modify the script, as you wrote above, let see the telnet will works after reboot or not.

      • sammczk says:

        Just in case – wifi in this device is buggy and will not work, so for stable connection you SHOULD use the wired port.
        BTW now i`m using very interesting configuration: raspberry as wifi client + upnp server connected to ethernet port of philips. It is still work in progress, i am planning to make a blog post about this one day.

  7. AndyLillo says:

    Hello friend,
    I need your help to reload the firmware on my MCI730/12 to connect power red led but pressing goes off and does not start after a few minutes the screen goes blank, I think the solution is to load the firmware again .
    It should be right through serial cable?

    • sammczk says:

      Have you tried to start it in recovery mode using rootkit from this article? If it works you don`t need a serial cable to restore device.

  8. Ferenc says:

    Hi,

    I’ve tried to modify the mnetwork.conf file based on the guide at the top of this page, but no success :-(
    I’ve copied the text from the comment (echo ‘/usr/sbin/telnetd -p 23 &’ >> /usr/local/etc/mnetwork.conf), put to the command prompt, after I’ve checked the content of the file with the cat command, and in the last line I could see this telnet related line. After a restart, the telnet is not running,
    I’ve checked again the content of the mnetwork.conf file, and there is no telnet related line… Maybe I had to save somehow the mnetwork.conf file somehow, after performing that echo… command? Sorry for these questions, I’m newby in Linux :-)

  9. Ferenc says:

    Hi,

    now it’s clear, the issue is with the upnp on the network. If any upnp devices exists on the network, the Philips behaves strange, reboot, loosing the network etc… Now I’ve separated the Philips to another network, it works well, except the network media player, as it rely on the upnp, but upnp doesnot work between different subnets. Do you have any idea, how can I play music files stored on my NAS without having upnp access?

    Or another idea: if I connect an USB drive to the Philips, it is possible to reach this USB drive somehow from the network via Samba or NFS service? In this case I can copy the music files remotely (maybe automatical) from the NAs to this USB, and I can reach the same music files via USB. How it sounds?

    • sammczk says:

      Yes, I do. Kernel supports NFS mount so you can mount your nas using NFS to USB disk mount location. I tested and it works, at least for me.

      • Ferenc says:

        Hi,

        can you provide me a detailed user guide, how can I implement this feature too? Actually I’m suffering to enabel the permanent telnet on the device, in this topic a detailed user guide would be nice and really appreciated. As I mentioned above, I’ve tried to enter that commands, what you’ve been desribed, it seemed to accepted, but after the restart, there is no telnet running on the device. Many thanks!

  10. Manel says:

    Perfect,

    I modified my /usr/local/etc/mnetwork.conf, adding:

    /usr/sbin/telnetd -p 23 &
    mkdir /tmp/sda1
    mount -t nfs 192.168.1.106:/mnt/md1/storage/ /mnt/sda1

    to mount my NAS by nfs…

    simply BRUTAL!!!

    Thanks a lot!!!

    • sammczk says:

      Nice to know that it works for you :) I`m also did some tweaks with device by using Raspberry PI as wifi bridge + UpNP server. Not 100% completed, will share result when done.

  11. David says:

    Dear Sammczk,
    Would you recommend me to try this firmware on my MCi300?
    Thank you very much for your consideration!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 253 other followers

%d bloggers like this: