Modifying small devices
FirmwareTour
Examining ASUStek O!Play Firmware
Outdated MaterialThe information presented here is on an old firmware version and is not complete.
The procedures presented here are still good practices to follow when examining any firmware image.
See the more recent Firmware Comparison Wiki page for a complete example.
Incomplete MaterialThis page does not show the expansion of the yaffs2 file system image which is the one actually used by the O!Play.
A detailed, step-by-step tour of a firmware image using tools common on
a Linux desktop system.
1. Our victim image and its two checksum files:
HDP_R1_FW_113NTSC.md5 HDP_R1_FW_113NTSC.sha1 HDP_R1_FW_113NTSC.zip
The two checksum files are not provided by ASUStek, but by this site.
2. Be certain you have a full, complete, exact copy of the file:
/wiki$ md5sum -c HDP_R1_FW_113NTSC.md5 HDP_R1_FW_113NTSC.zip: OK /wiki$ sha1sum -c HDP_R1_FW_113NTSC.sha1 HDP_R1_FW_113NTSC.zip: OK
Use either one or both of the checks as shown above.
3. The filename extensions can not be considered reliable, check it:
/wiki$ file HDP_R1_FW_113NTSC.zip HDP_R1_FW_113NTSC.zip: Zip archive data, at least v2.0 to extract
In this case, the filename extension is correct.
4. ZIP archives support multiple types of compression, check it:
/wiki$ unzip -l -v HDP_R1_FW_113NTSC.zip Archive: HDP_R1_FW_113NTSC.zip Length Method Size Ratio Date Time CRC-32 Name -------- ------ ------- ----- ---- ---- ------ ---- 253199 Defl:X 217514 14% 10-27-09 09:56 c8fb8049 how to update firmware.pdf 91893776 Defl:X 36810119 60% 10-26-09 17:01 fa5adaeb install.img -------- ------- --- ------- 92146975 37027633 60% 2 files
This archive used the Deflate compression method.
We would need to know that if we had to re-create this archive.
5. Make a new directory for the files and copy the archive into it:
/wiki$ mkdir work /wiki$ cp -a *.zip work /wiki$ cd work
6. Extract the files in the archive, restoring the UID/GID info:
/wiki/work$ unzip -X HDP_R1_FW_113NTSC.zip Archive: HDP_R1_FW_113NTSC.zip inflating: how to update firmware.pdf inflating: install.img
7. Check what sort of file the install.img file is:
/wiki/work$ file install.img install.img: POSIX tar archive (GNU)
8. Unarchive the image file, GNU-tar will do the right thing
/wiki/work$ tar -v --extract --file=install.img arial.ttf audio_firmware.install.bin configuration.xml flash_erase install_a mkfs.jffs2 nandwrite package1/ package1/vmlinux.develop.avhdd.mars.bin.lzma package1/bluecore.audio.lzma package1/usr.local.etc.tar.bz2 package1/bluecore.video.lzma package1/squashfs1.img package2/ package2/vmlinux.develop.avhdd.mars.nand.bin package2/yaffs2_2.img package2/video_firmware.bin package2/yaffs2_1.img package2/bluecore.audio video_firmware.install.bin
9. That configuration.xml file looks interesting; the contents:
/wiki/work$ cat configuration.xml
<?xml version="1.0" encoding="ISO-8859-1" ?>
<packageFile>
<info>
<company>ASUSTEK Corp.</company>
<description>HDP-R1</description>
<version>01.13N</version>
<releaseDate>10/26/09 17:01</releaseDate>
<signature>MARS AVHDD on NAND</signature>
</info>
<installerAP>
<fileName>install_a</fileName>
</installerAP>
<package>
<info>
<description>This is Mars AVHDD on NOR</description>
<version>N/A</version>
</info>
<flash>
<image type="linuxKernel">
<fileName>package1/vmlinux.develop.avhdd.mars.bin.lzma</fileName>
<targetAddress>0x80100000</targetAddress>
<version>SVN:</version>
</image>
<image type="audioKernel">
<fileName>package1/bluecore.audio.lzma</fileName>
<targetAddress>0x81b00000</targetAddress>
<version>N/A</version>
</image>
<image type="videoKernel">
<fileName>package1/bluecore.video.lzma</fileName>
<targetAddress>0x81d80000</targetAddress>
<version>N/A</version>
</image>
<image type="squash">
<fileName>package1/squashfs1.img</fileName>
<mountPoint>/</mountPoint>
</image>
<image type="jffs2">
<fileName>package1/usr.local.etc.tar.bz2</fileName>
<sizeBytesMin>0x50000</sizeBytesMin>
<mountPoint>/usr/local/etc</mountPoint>
</image>
</flash>
</package>
<installerAP>
<fileName>install_a</fileName>
</installerAP>
<package>
<info>
<description>This is Mars AVHDD on NAND</description>
<version>N/A</version>
</info>
<nand>
<image type="linuxKernel">
<fileName>package2/vmlinux.develop.avhdd.mars.nand.bin</fileName>
<targetAddress>0x80100000</targetAddress>
<version>SVN:</version>
</image>
<image type="audioKernel">
<fileName>package2/bluecore.audio</fileName>
<targetAddress>0x81b00000</targetAddress>
<version>N/A</version>
</image>
<image type="videoKernel">
<fileName>package2/video_firmware.bin</fileName>
<targetAddress>0x81d80000</targetAddress>
<version>N/A</version>
</image>
<image type="yaffs2">
<fileName>package2/yaffs2_1.img</fileName>
<mountPoint>/</mountPoint>
</image>
<image type="yaffs2">
<fileName>package2/yaffs2_2.img</fileName>
<mountPoint>/usr/local/etc</mountPoint>
<sizeBytesMin>0x2800000</sizeBytesMin>
</image>
</nand>
</package>
</packageFile>
I wonder why the NAND version does not have the squashfs filesystem?
ANS: The age of the toolchain and kernel used. yaffs2 was NAND only.
The ASUStek O!Play uses NAND flash, so the files that will be loaded
are those listed in the <description>This is Mars AVHDD on NAND</description> portion
of the configuration file:
9.1. package2/vmlinux.develop.avhdd.mars.nand.bin
The kernel, most likely in the ROM Loader format. Worth checking.
9.2. package2/bluecore.audio
Probably the binary blob for the Realtek audio DSP on-chip. Worth keeping.
9.3. package2/video_firmware.bin
Probably the binary blob for the Realtek video DSP on-chip. Worth keeping.
9.4. package2/yaffs2_1.img
The image of the runtime filesystem root.
- note: found this unyaffs
which extracts both yaffs2 images perfectly for me.
- Super! Will get back to completing this tour RSN.
9.5. package2/yaffs2_2.img
The image of the user writable portion of the runtime filesystem.
10. Examine all of the file types in this directory:
/wiki/work$ file *
Which gives us this information:
| arial.ttf: | TrueType font data |
| audio_firmware.install.bin: | data |
| configuration.xml: | XML document text |
| flash_erase: | ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped |
| HDP_R1_FW_113NTSC.zip: | Zip archive data, at least v2.0 to extract |
| how to update firmware.pdf: | PDF document, version 1.3 |
| install_a: | ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, stripped |
| install.img: | POSIX tar archive (GNU) |
| mkfs.jffs2: | ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped |
| nandwrite: | ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, stripped |
| package1: | directory |
| package2: | directory |
| video_firmware.install.bin: | data |
11. Examine all file types in the package1 directory:
/wiki/work/package1$ file *
| bluecore.audio.lzma: | data |
| bluecore.video.lzma: | data |
| squashfs1.img: | Squashfs filesystem, little endian, version 3.0, 2171250 bytes, 339 inodes, blocksize: 65536 bytes, created: Mon Oct 26 04:01:26 2009 |
| usr.local.etc.tar.bz2: | bzip2 compressed data, block size = 900k |
| vmlinux.develop.avhdd.mars.bin.lzma: | data |
11.1. Details of package1 vmlinux
11.2. Details of package1 Bluecore.video
11.3. Details of package1 Bluecore.Audio
12. Examine all file types in the package2 directory:
/wiki/work/package2$ file *
| bluecore.audio: | data |
| video_firmware.bin: | data |
| vmlinux.develop.avhdd.mars.nand.bin: | data |
| yaffs2_1.img: | VMS Alpha executable |
| yaffs2_2.img: | VMS Alpha executable |
13. Root filesystem.
As seen in the configuration file, that squashfs image will become the
root filesystem (in the NOR type flash version), pry it open:
/wiki/work/package1$ unsquashfs -li squashfs1.img created 103 files created 85 directories created 151 symlinks created 0 devices created 0 fifos
Full listing.
14. Busybox references:
[http://busybox.net/|Busybox HomePage|n]
The [http://busybox.net/downloads/BusyBox.html|full help text|n] (current version, not the one in the firmware.)
Also browse the Related Links which leads to the library and build systems.
15. Pry open the additional filesystem tree:
/wiki/work/package1$ file usr.local.etc.tar.bz2 usr.local.etc.tar.bz2: bzip2 compressed data, block size = 900k /wiki/work/package1$ tar -v --extract --bzip2 --file=usr.local.etc.tar.bz2 dvdplayer/ dvdplayer/dmem.bin group hdd hdd.old/ hdd.old/dvdvr/ hdd.old/fat32/ hdd.old/root/ hdd.old/root/recovery/ hdd.old/root/lock/ hdd.old/livepause/ ld.so.conf magic passwd profile rcS
Note that the some of the /usr/local/etc files will be overwrtten above.
16. Boot order
The Linux kernel is a stand-alone program written in the C language.
Stand-Alone in the sense that it makes no external references.
Like most programs, it accepts command line arguments.
When it completes its own startup chores, it will then execute an external
program. Unless directed otherwise by command line arguments, the program
file: /linuxrc in this case.
In the full listing of the squashfs image, you see that file is linked
to Busybox. This causes BB to act as if it where init.
I.E: It executes the commands in /etc/init.d/rcS
The full text of that file:
#!/bin/sh /etc/init.d/rcS1>/dev/console& echo "Welcome to Realtek Linux"
Translation, It feeds another set of commands into the terminal console.
Contributors to this page: mikez
,
rmbell
and
admin
.
Page last modified on Sunday 14 of February, 2010 01:31:47 CST by mikez.