[nor] dump complete and converted to bin image
http://www.mediafire.com/?1tcdqu616xpfofe (EDIT: corrected URL)
Excellent job. You deserve a pint!
The next stage is to identify and separate the components in the flash image.
These components will include the bootloader itself, the Linux kernel image(s), the file system image(s), and usually an area for storing non-volatile configuration data.
From the Linux kernel boot log that you posted earlier, we can see that the kernel was compiled with drivers for the
SquashFS file system, and for the
JFFS2 file system:
squashfs: version 3.2-r2 (2007/01/15) Phillip Lougher
squashfs: LZMA suppport for slax.org by jro
JFFS2 version 2.2. (NAND) (SUMMARY) (C) 2001-2006 Red Hat, Inc.
SquashFS is a read-only file system. It was designed by
Phillip Lougher, an expert embedded developer from Wale's.
SquashFS is often used as the root flash file system in MIPS-based routers, including the
Huawei HG612.
JFFS2 is a read-write file system. It was written especially for flash devices and includes wear-levelling to mitigate the weakness in NAND (and NOR) flash storage.
The next task is to identify the boundaries of those components in the flash image. One way to do this is to search for the '
magic numbers' that are stored at the beginning of those firmware components.
SquashFS uses several different magic numbers in the superblock of a file system. These indicate the 'endianness' of the file system (big- or little-endian) and the compression scheme used.
We can use the Linux tool '
grep' to discover those magic numbers:
$ xxd eciflash.bin | grep -A2 'qshs\|sqsh\|hsqs\|shsq'
01410c0: 7173 6873 0000 034c 0000 0000 0d69 6910 qshs...L.....ii.
01410d0: 0000 0000 0000 0008 4001 a000 0003 0000 ........@.......
01410e0: 0f94 0010 c002 014d 58cf 3e00 0000 0015 .......MX.>.....
--
04e10c0: 7173 6873 0000 034c 0000 0000 0d69 6910 qshs...L.....ii.
04e10d0: 0000 0000 0000 0008 4001 a000 0003 0000 ........@.......
04e10e0: 0f94 0010 c002 014e 40aa 1700 0000 0015 .......N@.......
$
It finds two Big Endian
SquashFS file systems in the firmware that use LZMA compression. Those compressed file systems start at flash offsets 0x14,10c0 and 0x4e,10c0.
The presence of two file systems (and two kernels), a master and a slave, is a fail-safe mechanism.
The size of each squash file system image is needed now. A tool originally written by
Goundoulf, lead developer for the French
OpenBox project [1], can be fettled to work with the ECI flash image [2]:
$ ./ecisquash-extract eciflash.bin
Size of firmware 'eciflash.bin' : 5856192 octets
---------------------------------------------------------------
Signature of SquashFS found:
---------------------------------------------------------------
Signature : 0x71736873 ('qshs')
Format : LZMA-Big Endian
Offset : 0x1410c0
Version SquashFS : 3.0
Octets utilised : 2641669 octets
Date of creation : Mon Feb 14 06:44:14 2011
---------------------------------------------------------------
Signature of SquashFS found:
---------------------------------------------------------------
Signature : 0x71736873 ('qshs')
Format : LZMA-Big Endian
Offset : 0x4e10c0
Version SquashFS : 3.0
Octets utilised : 2642454 octets
Date of creation : Tue Aug 9 04:31:35 2011
---------------------------------------------------------------
The Linux tool '
dd' is used to isolate those SquashFS images into separate files:
$ dd if=eciflash.bin of=ecirootfs1 bs=1 skip=$((0x1410c0)) count=2641669
2641669+0 records in
2641669+0 records out
2641669 bytes (2.6 MB) copied, 5.69564 s, 464 kB/s
From the boot log, we can see that Junjiro Okajima's patch (JRO) for LZMA compression was applied to the squashfs kernel driver.
We must now search for a compatible version of the unsquashfs tool for the PC to decompress the file system, in readiness for unlocking it.
cheers, a
[1]
http://svn.gna.org/svn/openbox4/trunk/tools/nb4-extract/[2]
https://docs.google.com/open?id=0B....
