Lawrence Sheed // 30 Apr 2010 // 12 Comments

Spent a while checking out the different binaries available for the different OEM versions.
Some interesting things I’ve found.

If I take a look at a sample kernel – eg
lr_cmos_11_14_1_46.bin

ls -al lr_cmos_11_14_1_46.bin
-rw-r--r-- 1 lawrence staff 1350539 Mar 15 13:47 lr_cmos_11_14_1_46.bin


Our file size for the file i have is 1350539 bytes.

A hexdump of the header shows:

00000000 42 4e 45 47 01 00 00 00 01 00 00 00 77 cb 0b 00 |BNEG……..w…|
00000010 00 d0 08 00 50 4b 03 04 14 00 00 00 08 00 3a 2e |….PK……..:.|
00000020 87 3b 3b e7 b8 16 03 cb 0b 00 bc d9 18 00 09 00 |.;;………….|

PK is the standard file header for Zip compression (as Zip was invented by Phil Katz)
Zip fingerprint in hex is – 0x04034b50, which matches nicely in our second line – 50 4b 03 04

On the offchance it contained a zip file, I tried unzipping from the start of the PK.

We can totally misuse dd to write from an offset of 20 bytes to a test.zip file as follows:


lawrence$ dd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0x14 bs=1

(check I actually did that right)
lawrence$ hexdump -C test.zip |more
00000000 50 4b 03 04 14 00 00 00 08 00 3a 2e 87 3b 3b e7 |PK........:..;;.|
00000010 b8 16 03 cb 0b 00 bc d9 18 00 09 00 00 00 6c 69 |..............li|

Unfortunately this didn’t unzip.

However…

zipinfo test.zip
Archive: test.zip 1350519 bytes 1 file
-rw------- 2.0 fat 1628604 b- defN 7-Dec-09 05:49 linux.bin
1 file, 1628604 bytes uncompressed, 772867 bytes compressed: 52.5%

Says there is a valid zip file there, so we’re getting somewhere. It should be something like 772867 bytes + whatever Zip header / footer file bits in size.

If we take a look at the Zip file format, it says that the end of directory (aka end of zip file) marker is 0x06054b50

ZIP end of central directory record

Offset Bytes Description[4]
 0 4 End of central directory signature = 0x06054b50
 4 2 Number of this disk
 6 2 Disk where central directory starts
 8 2 Number of central directory records on this disk
10 2 Total number of central directory records
12 4 Size of central directory (bytes)
16 4 Offset of start of central directory, relative to start of archive
20 2 ZIP file comment length (n)
22 n ZIP file comment

If we search the file for that, we get:
000bcb70 78 2e 62 69 6e 50 4b 05 06 00 00 00 00 01 00 01 |x.binPK………|

So, from our Start PK 03 04 through to PK 05 06 we’re at position 0×14 through 0x0bcb79

If we write that out now –
dd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0×14 bs=1 count=0x0bcb79

Then try unzip test.zip – we have a winner!

lawrence$ unzip test.zip
Archive: test.zip
inflating: linux.bin
lawrence$ ls -al test.zip
-rw-r--r-- 1 lawrence staff 772985 Apr 30 03:28 test.zip
lawrence$ ls -al linux.bin
-rw-------@ 1 lawrence staff 1628604 Dec 7 05:49 linux.bin


So, we know that the file has a header, then a zip file (which uncompresses to linux.bin, and has our linux binary), then more data.

If we take a look at what follows – ie the rest of the data in the original file after the end of the zip, it doesn’t look compressed

000bcb79 00 00 00 00 01 00 01 00 37 00 00 00 2a cb 0b 00 |……..7…*…|
000bcb89 00 00 2d 72 6f 6d 31 66 73 2d 00 08 cf a0 98 16 |..-rom1fs-……|
000bcb99 76 dd 72 6f 6d 20 34 62 31 63 62 36 38 66 00 00 |v.rom 4b1cb68f..|
000bcba9 00 00 00 00 00 49 00 00 00 20 00 00 00 00 d1 ff |…..I… ……|
000bcbb9 ff 97 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
000bcbc9 00 00 00 00 00 60 00 00 00 20 00 00 00 00 d1 d1 |…..`… ……|
000bcbd9 ff 80 2e 2e 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
000bcbe9 00 00 00 00 00 c9 00 00 00 80 00 00 00 00 8c 88 |…………….|
000bcbf9 9d 47 73 77 61 70 00 00 00 00 00 00 00 00 00 00 |.Gswap……….|

…

000bd969 50 7d 64 68 63 70 63 00 00 00 00 00 00 00 00 00 |P}dhcpc………|
000bd979 00 00 62 46 4c 54 00 00 00 04 00 00 00 40 00 01 |..bFLT…….@..|
000bd989 11 70 00 01 37 60 00 01 50 e8 00 00 28 00 00 01 |.p..7`..P…(…|
000bd999 37 60 00 00 02 b5 00 00 00 05 00 00 00 00 00 00 |7`…………..|
000bd9a9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
000bd9b9 00 00 1f 8b 08 00 f4 6b 45 3f 02 03 dc 5b 0f 70 |…….kE?…[.p|
000bd9c9 14 d7 79 7f bb 77 a7 bf 07 9c fe f0 c7 48 a0 95 |..y..w.......H..|
000bd9d9 50 88 5c 23 b3 02 19 64 23 e0 84 30 76 72 b8 9c |P.\#...d#..0vr..|
000bd9e9 31 50 6c 2b 58 06 d7 25 84 d6 ea 80 6d 02 8c 7d |1Pl+X..%....m..}|
000bd9f9 48 02 64 17 b0 00 91 12 17 fb b6 29 ed 60 86 c6 |H.d........).`..|
000bda09 4c aa 74 34 0e 71 0e 90 03 d3 d2 54 fc 51 87 30 |L.t4.q.....T.Q.0|

In fact it looks like more files...

bFLT is our flat ELF header..., and the other bits in-between look suspiciously like more files, and folders.
So, we probably have a filesystem in there.

Its late, and thats all for today, but it looks like we might even get to play around with both the linux image and the web UI image.

Just had another thought though - if you recall, our romfs size was 0x0008D000

Image: 6 name:romfs.img base:0x7F0E0000 size:0x0008D000 exec:0x7F0E0000 -a

What do we see here - in our header? 00000010 00 d0 08 00


00000000 42 4e 45 47 01 00 00 00 01 00 00 00 77 cb 0b 00 |BNEG……..w…|
00000010 00 d0 08 00 50 4b 03 04 14 00 00 00 08 00 3a 2e |….PK……..:.|


Seem to have a match, no? 0x 08 d0 00
I'm going to bet that our 0x 00 0b cb 77 also has some meaning too in our header 20 bytes, especially as the linux.bin zip file size is close to that at 0x00 0b cb 79.

Its highly probable I've miscounted something with the offset, and thats going to turn out to be the zip file size.

Now I've gotten this far, I'm too excited to go to sleep (its 4am here now!)

Lets try the filesystem from where we left off (aka from 0x0bcb79)
dd if=lr_cmos_11_14_1_46.bin of=unsure_what_filesystem.img skip=0x0bcb79 bs=1

mount -r unsure_what_filesystem.img
mount: unsure_what_filesystem.img: unknown special file or file system.

Nope.

Kyle's blog comment has this gem in

however the ‘-romfs-’ tag is offset by 0×14

so I used the line

fx 6 romfs.img 0x7f0a0000 0x7f0a0014 -a

the system then rebooted correctly…”

Lets use that as the start.

hexdump -C unsure_what_filesystem.img |more
00000000 00 00 00 00 01 00 01 00 37 00 00 00 2a cb 0b 00 |........7...*...|
00000010 00 00 2d 72 6f 6d 31 66 73 2d 00 08 cf a0 98 16 |..-rom1fs-......|
00000020 76 dd 72 6f 6d 20 34 62 31 63 62 36 38 66 00 00 |v.rom 4b1cb68f..|

-rom1fs- starts at position 0x12 [which is another indicator that I'm off by 2 bytes somewhere - as they mention 0x14 bytes, and the 12bytes prefix I have prior to the -rom1fs- are going to be from our second file header, I'll bet...
0x0bcb79 - 2 = 0x0bcb77, which is what the previous header said, so that really makes me think thats the filesize now!

Our ROMFS works out to be 577 536 bytes, which is 0x8D000, which is also what the boot loader said, so getting a lot of good confirmation on these figures!]

Write that out to another file:
dd if=unsure_what_filesystem.img of=still_unsure.img skip=0×12 bs=1

Still doesn’t mount on my Mac, however, some more googling for rom1fs uclinux got me here

http://romfs.sourceforge.net/

Which specifically mentions –

Embedded projects using romfs

uClinux, the microcontroller Linux, is a port of the kernel, and selected user-space programs to capable, embedded processors, like some “smaller” Motorola m68k, and ARM systems.

ROMFS looks like:

offset content
+—+—+—+—+
0 | – | r | o | m | \
+—+—+—+—+ The ASCII representation of those bytes
4 | 1 | f | s | – | / (i.e. “-rom1fs-”)
+—+—+—+—+
8 | full size | The number of accessible bytes in this fs.
+—+—+—+—+
12 | checksum | The checksum of the FIRST 512 BYTES.
+—+—+—+—+
16 | volume name | The zero terminated name of the volume,
: : padded to 16 byte boundary.
+—+—+—+—+
xx | file |
: headers :

struct romfs_super_block
{

__u32 word0;

__u32 word1;

__u32 size;

__u32 checksum;

char name[0]; /* volume name */

};

Which looks to be a *very* good match for what that header has!
So, its in ROMFS format from the -rom1fs- start header.

(Mostly from here – http://zhwen.org/?p=articles/romfs)

Unfortunately my OSX box appears to be missing romfs support, so I can’t check it without going back to the office.

mount -o loop -t romfs still_unsure.img /mnt
mount: exec /System/Library/Filesystems/romfs.fs/Contents/Resources/mount_romfs for /mnt: No such file or directory

Booted up my Debian VM, and tried again.

debian:/mnt/hgfs/FI8908，FI8908W# mount -o loop -t romfs still_unsure.img /mnt/test -r
debian:/mnt/hgfs/FI8908，FI8908W# cd /mnt/test/
debian:/mnt/test# ls -al
total 4
drwxr-xr-x 1 root root 32 1969-12-31 18:00 .
drwxr-xr-x 4 root root 4096 2010-04-29 16:19 ..
drwxr-xr-x 1 root root 32 1969-12-31 18:00 bin
drwxr-xr-x 1 root root 32 1969-12-31 18:00 dev
drwxr-xr-x 1 root root 32 1969-12-31 18:00 etc
drwxr-xr-x 1 root root 32 1969-12-31 18:00 flash
drwxr-xr-x 1 root root 32 1969-12-31 18:00 home
drwxr-xr-x 1 root root 32 1969-12-31 18:00 proc
drwxr-xr-x 1 root root 32 1969-12-31 18:00 swap
drwxr-xr-x 1 root root 32 1969-12-31 18:00 usr


We have a winner!

Full file listing below:

.
|-- bin
| |-- camera
| |-- dhcpc
| |-- ifconfig
| |-- init
| |-- iwconfig
| |-- iwpriv
| |-- mypppd
| | |-- chap-secrets
| | |-- options
| | |-- pap-secrets
| | `-- pppd
| |-- route
| |-- rt73.bin
| |-- sh
| |-- wetctl
| `-- wpa_supplicant
|-- dev
| |-- console
| |-- display
| |-- dsp -> dsp1
| |-- dsp0
| |-- dsp1
| |-- fb0
| |-- hda
| |-- hda1
| |-- hda2
| |-- hdb
| |-- i2c0
| |-- i2c1
| |-- key
| |-- keypad
| |-- lp0
| |-- mixer -> mixer1
| |-- mixer0
| |-- mixer1
| |-- mouse
| |-- mtd0
| |-- mtd1
| |-- mtdblock0
| |-- mtdblock1
| |-- nftlA1
| |-- nftla
| |-- null
| |-- ppp
| |-- ppp1
| |-- ptmx
| |-- pts
| |-- ptyp0
| |-- ptyp1
| |-- ptyp2
| |-- ptyp3
| |-- ptyp4
| |-- ptyp5
| |-- ptyp6
| |-- ptyp7
| |-- ptyp8
| |-- ptyp9
| |-- ptz0
| |-- rom0
| |-- rom1
| |-- rom2
| |-- sda
| |-- sda1
| |-- sda2
| |-- sdb
| |-- sdb1
| |-- sdb2
| |-- smartcard0
| |-- smartcard1
| |-- tty
| |-- tty1
| |-- ttyS0
| |-- ttyS1
| |-- ttyS2
| |-- ttyS3
| |-- ttyp0
| |-- ttyp1
| |-- ttyp2
| |-- ttyp3
| |-- ttyp4
| |-- ttyp5
| |-- ttyp6
| |-- ttyp7
| |-- ttyp8
| |-- ttyp9
| |-- urandom
| |-- usb
| | |-- lp.sh
| | |-- lp0
| | |-- lp1
| | |-- lp2
| | |-- lp3
| | |-- lp4
| | |-- lp5
| | |-- lp6
| | |-- lp7
| | |-- lp8
| | `-- lp9
| |-- usi
| |-- video0
| `-- video1
|-- etc
|-- flash
|-- home
|-- proc
|-- swap
|-- usr
`-- var
`-- run

13 directories, 97 files

While I obviously can’t run any binaries locally, I can look at the text files to confirm that the ROMFS hasn’t just gotten the filesystem correct.

debian:/mnt/test/bin# cat init
mount -t proc none /proc
mount -t ramfs none /usr
mount -t ramfs none /swap
mount -t ramfs none /var/run
mount -t ramfs none /etc
mount -t ramfs none /flash
mount -t ramfs none /home
camera&
sh


debian:/mnt/test/bin# file camera
camera: BFLT executable - version 4 ram gzip


Looking *very* good.

Thats all for tonight, but it looks like we can easily add bits to the firmware using genromfs, dd, and a hex editor, or just genromfs, and someone willing to test a rebuilt user rom with an extra binary. Probably going to be telnetd as ssh requires a kernel recompile

Next step, actually doing that, and testing.

I’m definitely going to bed now – its 5:30am.

Tomorrow is a holiday though (in China), so happy May holidays!