{"id":477,"date":"2010-04-30T03:57:14","date_gmt":"2010-04-29T19:57:14","guid":{"rendered":"http:\/\/www.computersolutions.cn\/blog\/?p=477"},"modified":"2013-01-04T22:50:38","modified_gmt":"2013-01-04T14:50:38","slug":"ip-cam-hacking-pt4","status":"publish","type":"post","link":"https:\/\/www.computersolutions.cn\/blog\/2010\/04\/ip-cam-hacking-pt4\/","title":{"rendered":"IP Cam Hacking – pt#4"},"content":{"rendered":"

Spent a while checking out the different binaries available for the different OEM versions.
\nSome interesting things I’ve found.<\/p>\n

If I take a look at a sample kernel – eg
\nlr_cmos_11_14_1_46.bin<\/p>\n

ls -al lr_cmos_11_14_1_46.bin
\n-rw-r--r-- 1 lawrence staff 1350539 Mar 15 13:47 lr_cmos_11_14_1_46.bin
\n<\/code><\/p>\n

Our file size for the file i have is 1350539 bytes.<\/p>\n

A hexdump of the header shows:<\/p>\n

00000000 42 4e 45 47 01 00 00 00 01 00 00 00 77 cb 0b 00 |BNEG……..w…|
\n00000010 00 d0 08 00 50 4b 03 04 14 00 00 00 08 00 3a 2e |….PK……..:.|
\n00000020 87 3b 3b e7 b8 16 03 cb 0b 00 bc d9 18 00 09 00 |.;;………….|<\/p>\n

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

On the offchance it contained a zip file, I tried unzipping from the start of the PK.<\/p>\n

We can totally misuse dd to write from an offset of 20 bytes to a test.zip file as follows:<\/p>\n


\nlawrence$ dd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0x14 bs=1 <\/p>\n

(check I actually did that right)
\nlawrence$ hexdump -C test.zip |more
\n00000000 50 4b 03 04 14 00 00 00 08 00 3a 2e 87 3b 3b e7 |PK........:..;;.|
\n00000010 b8 16 03 cb 0b 00 bc d9 18 00 09 00 00 00 6c 69 |..............li|<\/p>\n

<\/code><\/p>\n

Unfortunately this didn’t unzip.<\/p>\n

However… <\/p>\n

zipinfo test.zip
\nArchive: test.zip 1350519 bytes 1 file
\n-rw------- 2.0 fat 1628604 b- defN 7-Dec-09 05:49 linux.bin
\n1 file, 1628604 bytes uncompressed, 772867 bytes compressed: 52.5%<\/code><\/p>\n

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.<\/p>\n

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<\/p>\n

ZIP end of central directory record <\/p>\n

Offset \tBytes \tDescription[4]
\n\u20070 \t4 \tEnd of central directory signature = 0x06054b50
\n\u20074 \t2 \tNumber of this disk
\n\u20076 \t2 \tDisk where central directory starts
\n\u20078 \t2 \tNumber of central directory records on this disk
\n10 \t2 \tTotal number of central directory records
\n12 \t4 \tSize of central directory (bytes)
\n16 \t4 \tOffset of start of central directory, relative to start of archive
\n20 \t2 \tZIP file comment length (n)
\n22 \tn \tZIP file comment<\/code><\/p>\n

If we search the file for that, we get:
\n000bcb70 78 2e 62 69 6e 50 4b 05 06 00 00 00 00 01 00 01 |x.binPK………|<\/p>\n

So, from our Start PK 03 04 through to PK 05 06 we’re at position 0x14 through 0x0bcb79<\/p>\n

If we write that out now –
\ndd if=lr_cmos_11_14_1_46.bin of=test.zip skip=0x14 bs=1 count=0x0bcb79<\/p>\n

Then try unzip test.zip – we have a winner!<\/p>\n

lawrence$ unzip test.zip
\nArchive: test.zip
\n inflating: linux.bin
\nlawrence$ ls -al test.zip
\n-rw-r--r-- 1 lawrence staff 772985 Apr 30 03:28 test.zip
\nlawrence$ ls -al linux.bin
\n-rw-------@ 1 lawrence staff 1628604 Dec 7 05:49 linux.bin
\n<\/code><\/p>\n

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.<\/p>\n

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<\/p>\n

000bcb79 00 00 00 00 01 00 01 00 37 00 00 00 2a cb 0b 00 |……..7…*…|
\n000bcb89 00 00 2d 72 6f 6d 31 66 73 2d 00 08 cf a0 98 16 |..-rom1fs-……|
\n000bcb99 76 dd 72 6f 6d 20 34 62 31 63 62 36 38 66 00 00 |v.rom 4b1cb68f..|
\n000bcba9 00 00 00 00 00 49 00 00 00 20 00 00 00 00 d1 ff |…..I… ……|
\n000bcbb9 ff 97 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
\n000bcbc9 00 00 00 00 00 60 00 00 00 20 00 00 00 00 d1 d1 |…..`… ……|
\n000bcbd9 ff 80 2e 2e 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
\n000bcbe9 00 00 00 00 00 c9 00 00 00 80 00 00 00 00 8c 88 |…………….|
\n000bcbf9 9d 47 73 77 61 70 00 00 00 00 00 00 00 00 00 00 |.Gswap……….|<\/p>\n

…<\/p>\n

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

In fact it looks like more files…<\/p>\n

bFLT is our flat ELF header…, and the other bits in-between look suspiciously like more files, and folders.
\nSo, we probably have a filesystem in there.<\/p>\n

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.<\/p>\n

Just had another thought though – if you recall, our romfs size was 0x0008D000<\/p>\n

Image: 6 name:romfs.img base:0x7F0E0000 size:0x0008D000 exec:0x7F0E0000 -a<\/p>\n

What do we see here – in our header? 00000010 00 d0 08 00 <\/p>\n


\n00000000 42 4e 45 47 01 00 00 00 01 00 00 00 77 cb 0b 00 |BNEG\u2026\u2026..w\u2026|
\n00000010 00 d0 08 00 50 4b 03 04 14 00 00 00 08 00 3a 2e |\u2026.PK\u2026\u2026..:.|
\n<\/code><\/p>\n

Seem to have a match, no? 0x 08 d0 00
\nI’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.<\/p>\n

Its highly probable I’ve miscounted something with the offset, and thats going to turn out to be the zip file size.<\/p>\n

Now I’ve gotten this far, I’m too excited to go to sleep (its 4am here now!)<\/p>\n

Lets try the filesystem from where we left off (aka from 0x0bcb79)
\ndd if=lr_cmos_11_14_1_46.bin of=unsure_what_filesystem.img skip=0x0bcb79 bs=1 <\/p>\n

mount -r unsure_what_filesystem.img
\nmount: unsure_what_filesystem.img: unknown special file or file system.<\/p>\n

Nope.<\/p>\n

Kyle’s blog comment has this gem in <\/p>\n

however the \u2018-romfs-\u2019 tag is offset by 0\u00d714<\/p>\n

so I used the line<\/p>\n

fx 6 romfs.img 0x7f0a0000 0x7f0a0014 -a<\/p>\n

the system then rebooted correctly\u2026\u201d<\/p><\/blockquote>\n

Lets use that as the start.<\/p>\n

hexdump -C unsure_what_filesystem.img |more
\n00000000 00 00 00 00 01 00 01 00 37 00 00 00 2a cb 0b 00 |……..7…*…|
\n00000010 00 00 2d 72 6f 6d 31 66 73 2d 00 08 cf a0 98 16 |..-rom1fs-……|
\n00000020 76 dd 72 6f 6d 20 34 62 31 63 62 36 38 66 00 00 |v.rom 4b1cb68f..|<\/p>\n

-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…
\n 0x0bcb79 – 2 = 0x0bcb77, which is what the previous header said, so that really makes me think thats the filesize now! <\/p>\n

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!]<\/p>\n

Write that out to another file:
\ndd if=unsure_what_filesystem.img of=still_unsure.img skip=0x12 bs=1 <\/p>\n

Still doesn’t mount on my Mac, however, some more googling for rom1fs uclinux got me here<\/p>\n

http:\/\/romfs.sourceforge.net\/<\/p>\n

Which specifically mentions – <\/p>\n

Embedded projects using romfs<\/p>\n

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. <\/p><\/blockquote>\n

ROMFS looks like:<\/p>\n

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

struct romfs_super_block
\n{<\/p>\n

__u32 word0;<\/p>\n

__u32 word1;<\/p>\n

__u32 size;<\/p>\n

__u32 checksum;<\/p>\n

char name[0]; \/* volume name *\/<\/p>\n

};<\/p>\n

Which looks to be a *very* good match for what that header has!
\nSo, its in ROMFS format from the -rom1fs- start header.<\/p>\n

(Mostly from here – http:\/\/zhwen.org\/?p=articles\/romfs<\/a>) <\/p>\n

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

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

Booted up my Debian VM, and tried again.
\n
\ndebian:\/mnt\/hgfs\/FI8908\uff0cFI8908W# mount -o loop -t romfs still_unsure.img \/mnt\/test -r
\ndebian:\/mnt\/hgfs\/FI8908\uff0cFI8908W# cd \/mnt\/test\/
\ndebian:\/mnt\/test# ls -al
\ntotal 4
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 .
\ndrwxr-xr-x 4 root root 4096 2010-04-29 16:19 ..
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 bin
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 dev
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 etc
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 flash
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 home
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 proc
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 swap
\ndrwxr-xr-x 1 root root 32 1969-12-31 18:00 usr
\n<\/code><\/p>\n

We have a winner!<\/p>\n

Full file listing below:<\/p>\n

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

13 directories, 97 files<\/code><\/p>\n

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.<\/p>\n

debian:\/mnt\/test\/bin# cat init
\nmount -t proc none \/proc
\nmount -t ramfs none \/usr
\nmount -t ramfs none \/swap
\nmount -t ramfs none \/var\/run
\nmount -t ramfs none \/etc
\nmount -t ramfs none \/flash
\nmount -t ramfs none \/home
\ncamera&
\nsh
\n<\/code><\/p>\n

debian:\/mnt\/test\/bin# file camera
\ncamera: BFLT executable - version 4 ram gzip
\n<\/code><\/p>\n

Looking *very* good.<\/p>\n

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 \ud83d\ude41<\/p>\n

Next step, actually doing that, and testing.<\/p>\n

I’m definitely going to bed now – its 5:30am.<\/p>\n

Tomorrow is a holiday though (in China), so happy May holidays!<\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[252,25],"tags":[256,253,197,245,240,255,254,247],"class_list":["post-477","post","type-post","status-publish","format-standard","hentry","category-ip-cam","category-technical-mumbo-jumbo","tag-bflt","tag-bneg","tag-firmware","tag-foscam","tag-ipcam","tag-linux-bin","tag-pkzip","tag-uclinux"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/477","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/comments?post=477"}],"version-history":[{"count":12,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/477\/revisions"}],"predecessor-version":[{"id":919,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/posts\/477\/revisions\/919"}],"wp:attachment":[{"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/media?parent=477"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/categories?post=477"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.computersolutions.cn\/blog\/wp-json\/wp\/v2\/tags?post=477"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}