Browsing all articles in IP Cam

May
6

IP Cam Hacking – pt#6

I’ve uploaded a zip of my built test image here. I’ve only included telnetd, and ftpd, as the sshd binary is very large, and won’t fit into our rom image space!

If someone is willing to test, feel free.

Test Rom with FTPD and TELNETD binaries added

This rom is 700k+- vs the normal 550kb. So this may / may not overwrite the web ui.

As China’s firewall is being particularly obnoxious this week as to what I can view on the web, I can’t actually get to the info I need to see where they typically write the UI to in rom.

In theory, we should be able to write to the same base address via the boot loader.

The original rom is written here -

Image: 6 name:romfs.img base:0×7F0E0000 size:0×0008D000 exec:0×7F0E0000 -a

And I’m pretty sure that the UI gets written somewhere after this, and not as a separate image. I’d have to run Windows and a sniffer to test this though (using their firmware update software).

Our boot logs show that linux blkmem driver is set to view the whole area from 0×7F0E0000 through to 0x7F16D3FF, so we should easily have 200kb to waste^Hplay with.

From my boot logs:

Blkmem 1 disk images:
0: 7F0E0000-7F16D3FF [VIRTUAL 7F0E0000-7F16D3FF] (RO)

Obstensibly, this should be a matter of going to the bootloader over serial, then uploading our img file.
Suggest rename from testrom.img to romfs.img to be consistent.

It should be something like this:

bootloader > del 6
(delete the current romfs.img)

bootloader > fx 6 romfs.img 0x7f0e0000 0x7f0e0000 -a
Waiting for download
Press Ctrl-x to cancel … (while it waits, you have to select Transfer > Send File in Hyperterminal menu, choose the Xmodem protocol and select my rom image)
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
Flash programming …

bootloader> boot

Then see what happens in the logs.

It should boot, then attempt to run telnetd and ftpd.
That probably WON’T work just yet, as they’ll complain about missing /etc/ config files.

You might also be missing the UI (as I think this gets written somewhere after our romfs.img in flash)

Send me the serial logs in the comments, and I can fix that up, and repackage.

I also know why the alleged clones (NB they’re not f..king clones sigh, they’re all made by 1 manufacturer here for different people, including FOSCAM) don’t work. The linux.bin for older firmware is set to boot from 0x7f0D0000 as opposed to 0x7f0e0000, so image 6 and 7 both need to be reflashed.

Also of note is that the newer units have gone cheaper, and use 2M flash, previous units had 4M.
uCLinux reports 8M, but its not talking about Flash, just RAM

Be prepared to brick (not completely, as we have a bootloader, and can reflash the original firmware) if it doesn’t work.

If my rom above doesn’t work initially for you, try flashing this linux.zip before reverting, and see if that helps it boot.

eg
bootloader> del 7


bootloader> fx 7 linux.zip 0x7f020000 0x8000 -acxz

Waiting for download

Press Ctrl-x to cancel ...  (while it waits, you have to select Transfer > Send File in Hyperterminal menu, choose the Xmodem protocol and select my linux.zip)

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

Flash programming ...

bootloader> fx 6 romfs.img 0x7f0e0000 0x7f0e0000 -a Waiting for download Press Ctrl-x to cancel ... (while it waits, you have to select Transfer > Send File in Hyperterminal menu, choose the Xmodem protocol and select my rom image) CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Flash programming ...

Why aren’t I doing this?

Mostly as I don’t currently have a good serial connection, I’m waiting on headers. Currently I have to hold the serial ports onto the board with fingers, and thats less than reliable!

I should get around to fixing that soonish though, I’m interested in testing this myself…

I’d also appreciate the French contingent adding some info. I’m particularly interested in paillassou’s board photos, and any other firmware people have found for these so I can compare.

I can’t get to Picasa, GadgetVictims, IrishJesus now in China. Grrr.

Yes, I know, use a VPN or proxy… Unfortunately what we do precludes doing so, as I’d probably get told off by our beloved government here, and thats not worth the risk…

Comments please.

May 6, 2010 // IP Cam // 64 Comments // Tags: arm7, debian, howto, nc745, nuvoton, uclinux

Apr
30

IP Cam Hacking – pt#4

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:

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

…

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.

-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