# Media Centers Based on Wyplayer/Firmware

Firmware files allow users to update this multimedia disks. They are distributed by each multimedia disk manufacturer and seem to be NOT interchangeable / compatible between different (brand) devices.

# Firmware file reverse engineer landmarks

* Knowing .wup file structure (Done)
* Knowing .wup file parts format (XML and Kernel, software not yet)
* Knowing .wup file each part function (Pending)
* Update one device with other device firmware (Pending)
* Generate our own "kernel" and install in device (Pending)
* Generate our own "software" and install in device (Pending)
* Knowing the encryption key used in software part inside update.wup for each device (Pending)
* Getting access to device intending to obtain more info while working (Pending)

## Internal structure of .wup file
### XML Code

Example:

### Kernel file

Depending on the file command output (available in *nix based systems) the kernel file is like:

#### Looking inside in code

In source code provided by wyplay exists one uboot-<version> folder Trying to guess how is compiled, inside uboot we found board folder and inside this one a sub-folder called wyplay, that may be the specifications needed to compile uboot for the different wyplay motherboards.
* Reviewing Makefile found in the main folder uboot-<version>, a different (entrada) can be found for the different wyplay boards. We are trying to configure and compile for wymdbox_config (wyplayer multimedia box) that we understand is what corresponds to this multimedia disks.
* The Make fails cause lack of SH4 compiler (¿?) That seems to be the processor architecture of multimedia disks. (Specification: http://lars.nocrew.org/computers/processors/SuperH/sh4cpu_sh1.pdf).
* toolchain has been compiled for crossed-compilation for this architecture: http://wiki.debian.org/SH4/CrossToolchain
* u-boot has been compiled for the wymdbox.
* Apparently the firmware kernel file includes u-boot and kernel.

#### Analyzing kernel file

Header magic number (0x270519) of this file shows that is u-boot type. By analyzing the rest of the file you found in offset 352 a gzip file (at least in reviewed files until now) that can be extracted with command:
By analyzing this uncompressed file we found inside (at least in majority of firmwares) two other compressed files. One of them seem to be the kernel configuration file and the other one the initramfs.cpio required during compilation (if required parameter is established).
A new script has been created to find and decompress gzip files inside other files. As input needs the file/files in which you want to find the gzip file (as input you can use something like kernel1.2*)
In this case can be used to obtain gzip file from kernel file or used to obtain gzip files inside decompressed files extracted from kernel. In order to clarify all this stuff, file hierarchy is shown below:
update.wup (use extraction script)
    header (include kernel file-size in last 4 bytes)
    kernel (use gzip extraction script)
       kernel.uncomp (use gzip extraction script)
          config (gonfig file for kernel compilation)
          initramfs.cpio (needed file for compilation)
    middle (include software file-size in last 4 bytes)
    software
    footer
    infoxml (xml information about update.wup file and device)
Note: There is a project called Tribbox. A media center with similar specifications to ours (al least the processor) with info about mounting OS, etc. Can be useful: http://www.tribbox.com/

### Software file

To date, we don't know exactly the format of software system, knowing that 'file' command gives "data" as output for this file. Guess that it is a squahfs file system and in addition is encrypted with aes-cbc-plain coding with 128 bits key. Probably the image is decrypted by dm-crypt interface of kernel linux.
By joining all the discovers made, a script has been created which, from software file obtained from firmware file (extraction script) (wup) and other file with possible password list, tries to decrypt and know the underlying file system. Known problems:
* We're not sure of encrypting system used, thats why we're hitting out blindly.
* The script gives us a lot of false positive results, since always system is decrypted. The fact that determines if has been successful or not is the output of file, we should expect something like squashfs filesystem or any thing like that.
Below, just a didactic code as an decrypting example in linux file systems and full partitions. We take no responsibility of use. Review before use is recommended.

### Extraction script

This script in bash/shell scripting allows to obtain from one firmware update file (.wup), the corresponding files of kernel, software and XML information. It is completely GPL and we take no responsibility on its use. Whoever interested in functionality or effects must analyze it. Of course, any improvement, suggestion or contribution will be appreciated.
To date, we obtain six files from .wup update file. The main files are kernel and software, infoxml has limited interest, and the other files (header_bytes, middle_bytes and footer_bytes) are the bytes without identity in different parts of the file. Has been made like that so that joining all the files we could obtain a new original file without losing information.
This script has been successfully tested on the last update files of MediaTitan, ZoltarTv and Wyplayer.

## Updating a device with other device (brand) device

One of the problems found is that one device can not be updated with a different device (brand) firmware file. It seems to be that the reason is that each device has one identifier and, in addition, the "software" part of firmware file is encrypted in different way for each device.
If this was simply like that, would be theoretically possible to create a firmware for a device with modified kernel part, and even so, update would be allowed. With each one of the 6 parts included in a update file, a new one would be built as the mixture of some different firmware files.

### Script for mixing firmware files

To test the concept of mixing the contents of two firmware files a script has been created able to generate a new .wup file from two different files. Script disassembles each of the two original (just if disassembled parts are not available in folder) and offers a number of possible combinations. This can be interesting for verifying if any of those combinations allows us to update our device. As a general rule, from all options offered by the script, we're interested in those that mixes one part from a different device and the rest from our device. And more specifically the one that takes the kernel of another ant the rest of our own device. Generated files has not been tested yet, so we recommend caution in using them.
IMPORTANT: To run this script you need to change the value of variable EXTRACT_PROGRAM and set the path to extraction script.
The operation is simple:

## Generating own "kernel" and installing in device

SH4 toolchain for crossed compiling from 386 32 bits. Download and decompress in opt: http://www.megaupload.com/?d=HSV19P40

## Generating own "software" and installing in device

SH4 toolchain for crossed compiling from 386 32 bits. Download and decompress in opt: http://www.megaupload.com/?d=HSV19P40

# Telnet access to device

In order to get telnet access to device, it is mandatory to modify one file in HD. For that, you need to get out HD from device and plug to PC to get access. Any linux distribution will allow access to HD and modify that file, even a Ubuntu Live cd or any other distribution.
The file to modify is located in partition 1 (JFS). To mount it, execute this command:
(note: sda must be changed to fit your partition data and all commands must be executed as root, i.e. by adding "sudo" before command)
Once mounted, we must edit "local_conf.py" file by adding lines below at the end of file:
Now we dismount the partition ( umount /mnt/sda1 ) and plug HD into the device again.
From now we should have telnet access to device: (if it is connected to the network, obviously)
To date, we have tested this procedure successfully on the versions below:

# Firmware file links
## O2Media ZoltarTV

* September 2009: http://www.zoltartv.com/firmware/Sep-17-2009/update.zip
* June 2009: http://www.zoltartv.com/firmware/Junio-16-2009/update.zip
* May 2009: http://www.zoltartv.com/firmware/Mayo-27-2009/update.zip
* February 2009: http://www.zoltartv.com/firmware/Febrero-02-2009/update.zip

## Wyplayer

* August 09: http://www.wyplayer.com/downloads/Wyplayer/1.3.16.8498_04.08.09/version-1.3.16.8498_1.3.16.8498_040809.zip
* June 09: http://www.wyplayer.com/downloads/Wyplayer/1.3.15.8418_11.06.09/version-1.3.15.8418_1.3.15.8418_110609.zip
* May 09: http://www.wyplayer.com/downloads/Wyplayer/1.3.15.8399_13.05.09/version-1.3.15.8399_1.3.15.8399_130509.zip
* April 09: http://www.wyplayer.com/downloads/Wyplayer/1.3.15.8379_20.04.09/version-1.3.15.8379_1.3.15.8379_200409.wup