unpack / repack a firmware

[recliq]

In fact it's quite stable, the reason is it simply DOES NOT FIT into flash!

[2lostkiwis]

Hello talented people,

I know this thread is quite old, but I feel it's my best shot... I am trying to break into a similar box. It's a based on the same Sigma Designs SMP8655 as the WDTV Live (1st gen). I believe it also uses the 2.0SDK. I have connected a serial console and have the boot log, but cannot log in as I don't know the root password.

The boot log: http://2lostkiwis.com/mtv/boot.txt
The firmware upgrade files: http://magictv.com/au/downloads/mtv4000_5_05AU.zip

With the pervious version of the box which was based on an SMP8635 I was able to mount the root filesystem (squashfs) from the firmware upgrade file to get access to the /etc/shadow file. From there I was able to brute force the root password and I could then log in using the serial console.

The new firmware has a cramfs root filesystem that I am trying to mount as it has the /etc/shadow file in it. Unfortunately I have not had much luck trying to mount it. If the firmware upgrade files are unzipped, the cramfs image is in the file called mtv4000_5_05AU.upg at offset 0x5C9666h.

When I used the cramfs compiled into Debian 6.0.2 and mount using loopback, it looks pretty corrupted:

Code: Select all

root@debian:~# mount -t cramfs -o loop ./cramfs.bin /mnt/tmp
root@debian:~# ls /mnt/tmp
???? ?  ????l?????Z?libencoder.so
root@debian:~#

When I used the 16k utilities I get the following error:

Code: Select all

root@debian:~# cramfs-1.1-16k/cramfsck-16k -x ./dump/ ./cramfs.bin
cramfs-1.1-16k/cramfsck-16k: file length too short
root@debian:~#

If anyone has any ideas of suggestions I'd love to hear from them
Cheers, Ian.

[recliq]

Maybe there is a checksum or hash in front of the actual filesystem (like in the WD firmware files, read first post).

A nice tool which will help you find out if so and which offset to use to get the actual filesystem is binwalk - maybe that helps

[2lostkiwis]

Maybe there is a checksum or hash in front of the actual filesystem (like in the WD firmware files, read first post).

A nice tool which will help you find out if so and which offset to use to get the actual filesystem is binwalk - maybe that helps

Thanks for the suggestion, but I have already extracted the cramfs image from the firmware. I mentioned above I found it at offset 0x5C9666h. The extracted file correctly starts with the cramfs magic number. The file sizes only differ slightly so I padded the end of the file with 0's and ignored the crc from the cramfs utility. The result was a file name similar to when I mounted the crams image directly under linux.

I am sure I'm not doing anything wrong, I think the image is not quite standard in some way - so that's what I am trying to figure out (with not much luck).

[AussieNeil]

Hi Ian,

Just came across your post after exactly duplicating what you've done on the MTV4000 - and getting equally stuck, after being inspired by your fantastic work with the mtv3600. Like you, I get exactly the same error - but I built and used cramfsck from cramfstools, sourced from http://sourceforge.net/projects/cramfs on a Fedora 16 x86_64 system. I've also been using Hacking Embedded Linux Based Home Appliances by Alexander Sirotkin to guide me. The initial problem is of course the different endian-ness, which is why you can't just examine the file structure by mounting the cramfs binary file.

Quoting Alexander Sirotkin ""In order to find the Cramfs offset inside the firmware image you will have to search for 0x28cd3d45 magic number. Note that the data is in host-endian byte order, which may not necessarily match your PC little endian byte order. In that case the magic byte order will be reversed and you won't be able to mount the image on a PC. You can still use uncramfs (or cramfsck) to extract the image content, however you won’t be able to use mkcramfs to recreate the image in the byte order different from that of your host. One of the ways to overcome this is to use QEMU to run a Linux compiled for big endian MIPS (or any other) system and make all cramfs manipulation in emulated big endian system."

When I examine the binary file, I note the magic number is indeed swapped around, i.e. 0x45 3d cd 28 at location 0x005c9666 as you also found. I don't think I've done anything other than confirm our same approach has reached the same dead end. Have you made any progress in the last couple of months? Perhaps we can join forces?

Neil

[AussieNeil]

Ian,

Have you tried the Firmware Mod Kit? http://code.google.com/p/firmware-mod-kit/wiki/Documentation. It includes many useful tools including: CramFSSwap Utility to swap the endianess of a CramFS image, which might just help. I can't build it in Fedora (no package), so will try Ubuntu.

Neil

[AussieNeil]

Ian,

Tried the Firmware Mod Kit under Ubuntu and while it looks to be a fantastic collection of utilities supported by scripts that automate much of the process of packing and unpacking different firmware file systems, I got exactly the same file structure as before for the MTV4000 cramfs file i.e.:
ls rootfs/
???? ? ????l?????Z?libencoder.so
So I suspect you are right - the image is not quite standard or is perhaps made to a very old version of cramfs?

Neil

[nir1978]

Hi All,

Im trying to unpack the official FW as well as B-Rad's 0.5.1.1 but always I get segmentation fault while using the cramfsck.

I also tried using the cramfsck-16k but I believe it requires glibc 2.8 which is quite old.

is there any other way on the newer ubuntu to do the job cos getting the older one is not possible (the repos are gone !)

kindly guide.

[mad_ady]

cramfsck that comes with ubuntu doesn't support 16k blocksizes, so it will segfault (most likely it needs a patch or something - you'd need to file a bug report on leafpad). I haven't tried to run the older version, so there might be dependency issues.

The easiest way to unpack the firmware is to do it on the wdtv, via telnet/ssh - that cramfsck supports 16k blocks.

Or, here is an alternative without cramfsck: http://wiki.wdlxtv.com/Booting_Original_FW

[nir1978]

cramfsck that comes with ubuntu doesn't support 16k blocksizes, so it will segfault (most likely it needs a patch or something - you'd need to file a bug report on leafpad). I haven't tried to run the older version, so there might be dependency issues.

The easiest way to unpack the firmware is to do it on the wdtv, via telnet/ssh - that cramfsck supports 16k blocks.

Or, here is an alternative without cramfsck: http://wiki.wdlxtv.com/Booting_Original_FW

thanks for the reply...

I somehow got it worked in debian and always got the "file extends end.." warning then i did my mod packed it the way shown along with the signature but my modded firmware doesn't work !


did i miss anything...(Using latest version of debian)