Its been a while since I did any IPCam stuff, but I’ve now got most of the bits I needed together again, as well as a new laptop for dev work (curse the thieves that stole my last one!)

As we recall from previous work, the main binary for the IPCam runs off a file called “camera”.

As some people have discovered, it likes to reboot the equipment when its not happy (eg when the camera is unplugged, it has issues talking to hardware, or when someone has flashed the wrong firmware).

So, lets take a look at the executable to see what interesting bits we can find out from it.

#file camera tells us – BINFLT file format. Fileflags: RAM GZIP.
So we know its a compressed bflt elf – bflt stands for binary flat file, and it uses gzip compression. It also sits in ram.

A hex dump of camera shows this for the first few bytes:

62 46 4C 54 00 00 00 04 | bFLT . . . .

[Note – I had about 4 pages of #$%# work done on this, and WordPress decided to flake once finished due to an errant pasted 0x0 null byte above, cutting off the rest of my post, so this is going to be shorter and angrier than it was originally written.
Lesson learned, always save stuff elsewhere before posting.]

bFLT headers consist of 4 bytes identifier, then 4 bytes for the version number.
In this case, its a version 4 bFLT file.

If we take a look at the header file source for bflt at the uclinux site we see the below layout.


struct flat_hdr {
char magic[4];
unsigned long rev; /* version */
unsigned long entry; /* Offset of first executable instruction with text segment from beginning of file */
unsigned long data_start; /* Offset of data segment from beginning of file */
unsigned long data_end; /* Offset of end of data segment from beginning of file */
unsigned long bss_end; /* Offset of end of bss segment from beginning of file */
/* (It is assumed that data_end through bss_end forms the bss segment.) */
unsigned long stack_size; /* Size of stack, in bytes */
unsigned long reloc_start; /* Offset of relocation records from beginning of file */
unsigned long reloc_count; /* Number of relocation records */
unsigned long flags;
unsigned long filler[6]; /* Reserved, set to zero */
};


It doesn’t match up properly, as the sizes or code don’t make sense (yet).

If we take a closer look, the header file has this to say:


#define FLAT_FLAG_RAM 0x0001 /* load program entirely into RAM */
#define FLAT_FLAG_GOTPIC 0x0002 /* program is PIC with GOT */
#define FLAT_FLAG_GZIP 0x0004 /* all but the header is compressed */


Ahah!

So, all but the header is compressed for a version 4 file.

Lets check this out, and see if its correct.
Excluding the initial file identifier (bFLT), our header consists of 10 longs. Thats 40 bytes long.
Lets jump to offset 40 in the file, and see what we have there.

1F 8B 08

Those of you familiar with gzipped files will recognize that – its the gzip header identifier. So, so far, so good.
Compressed files aren’t very useful to us, as they don’t show much text content.
So, we could unzip the file to take a look at whats inside.

There are a number of ways we can unzip this (zcat, gzip -d etc), but I’m going to be lazy, and use someone elses premade code.

See below for some perl to safely uncompress our binary , taken from here – http://www.openwiz.org/wiki/BWFWTools_Release


#!/usr/bin/perl

=pod

=head1 NAME

gunzip_bflt - convert gzip-compressed bFLT executable files into uncompressed bFLT

=head1 SYNOPSIS

gunzip_bflt zipped_blflt_files...

=head1 DESCRIPTION

Convert gzipped bFLT files into an uncompressed bFLT files.
The unzipped bFLT files have B<.unz> added to their file names.
If the file is already ungzipped bFLT, it isn't converted,
but a warning is printed.

=head1 PREREQUSITES

Uses packages C and C.

=cut

use strict;
use warnings;

# gunzip_bflt zipped_blflt_files...

use IO::Uncompress::Gunzip qw/gunzip $GunzipError/;
use POSIX;

# Read and return the BFLT header
# prints a warning and returns undef on error.
# $bfltZfh is the BFLT file handle,
# $bfltZ is the BFLT file name (for error messages)

sub get_bflt_hdr($$) {
my ($bfltZfh, $bfltZ) = @_;
my $buf;
my $res = sysread $bfltZfh, $buf, 64;
if(!defined($res)) {
warn "$bfltZ: $!\n";
return undef;
}
if($res < 64) { warn "$bfltZ: Too short!\n"; return undef; } # Align the buffered file handle with the unbuffered seek $bfltZfh, sysseek($bfltZfh, 0, SEEK_CUR), SEEK_SET; return $buf; } # Expand a gzipped BFLT intoi an ungziped BFLT sub expand_blftZ($) { my ($bfltZ) = @_; my $bflt = $bfltZ . '.unz'; if(!open BFLTZ, '<' . $bfltZ) { warn "$bfltZ: $!\n"; return; } my $hdr = get_bflt_hdr(\*BFLTZ, $bfltZ); if(!defined $hdr) { return; } if(substr($hdr, 0, 4) eq 'bFLT') { # Pack/unpack template for the BFLT header, 4 bytes ACSII, # 15 little-endian words my $hdrFmt = 'a4 N15'; my @unpHdr = unpack $hdrFmt, $hdr; # Test the header flags 'gzipped' bit if($unpHdr[9] & 4) { # Unset the header flags 'gzipped' bit, and make a new header $unpHdr[9] &= ~4; $hdr = pack $hdrFmt, @unpHdr; if(open BFLT, '>' . $bflt) {

# Write the header
syswrite BFLT, $hdr;

# Align the buffered file handle with the unbuffered
seek BFLT, sysseek(BFLT, 0, SEEK_CUR), SEEK_SET;

# Ungzip from the compressed file into the uncompressed
# file
gunzip \*BFLTZ => \*BFLT
or die "gunzip failed: $GunzipError\n";

close BFLTZ;
} else {
warn "$bflt: $!\n";
return;
}
} else {
warn "$bfltZ: Not a compressed bFLT file, not gunzipped\n";
return;
}
} else {
warn "$bfltZ: Not a bFLT file\n";
}
close BFLT;
}

# Expand the arguments...

foreach my $bfltZ (@ARGV) {
expand_blftZ($bfltZ)
}


If we run that on our ‘camera’ executable, we should have an uncompressed bFLT file as output ‘camera.unz’.
Lets run strings on ‘camera.unz’, to see what interesting text content is in there.

Some interesting things of note:

From the variables list below, looks like there is a way to turn off the LED…

led_mode
ptz_center_onstart
ptz_auto_patrol_interval
ptz_auto_patrol_type
ptz_patrol_h_rounds
ptz_patrol_v_rounds
ptz_patrol_rate
ptz_patrol_up_rate
ptz_patrol_down_rate
ptz_patrol_left_rate
ptz_patrol_right_rate

We also have a full list of the internal cgi functions now, which might prove useful…

snapshot.cgi
get_status.cgi
get_camera_params.cgi
decoder_control.cgi
camera_control.cgi
reboot.cgi
restore_factory.cgi
upgrade_firmware.cgi
upgrade_htmls.cgi
get_params.cgi
set_alias.cgi
set_datetime.cgi
set_users.cgi
set_devices.cgi
set_network.cgi
set_wifi.cgi
set_pppoe.cgi
set_upnp.cgi
set_ddns.cgi
set_ftp.cgi
set_mail.cgi
set_alarm.cgi
videostream.cgi
video.cgi
test_ftp.cgi
test_mail.cgi
set_misc.cgi
get_misc.cgi
set_p2p.cgi
get_p2p.cgi
set_forbidden.cgi
get_forbidden.cgi
set_decoder.cgi
comm_write.cgi
wifi_scan.cgi
get_wifi_scan_result.cgi
get_log.cgi
check_user.cgi
check_user2.cgi
backup_params.cgi
restore_params.cgi
erase_allparams.cgi
set_mac.cgi
do_cgi: unknown cgi

You can see that Maverick decided to fake the X-Mailer smtp header (Foxmail is a commonly used Mail Program in China).

MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=”smtp_msg_boundary”
X-Mailer: Foxmail
–smtp_msg_boundary
Content-Type: image/jpeg;
name=”%s(%s)_%c%s.jpg”
Content-Transfer-Encoding: base64
–smtp_msg_boundary–

I’m interested in why the firmware reboots on some firmwares though, so lets take a deeper look at the code.

To do so, we’ll need to decompile it.
The better equipped than me will probably use something like the nice ARM decompiler plugin for IDA-Pro called Hex-Ray. Unfortunately that costs $$$, and I’m just a hobbyist.

Luckily there is a free windows decompiler called arm2html available here.
arm2html doesn’t handle compressed bFLT files though, so you’ll need to point it at the freshly ungzipped code you got from the perl script above.

As we know that the camera executable reboots after issuing i2c errors, the first piece of decompiled code I wanted to look at was the first piece of code related to i2c:

(excerpted piece below)
02588: e1a0c00d mov ip, sp
00258c: e92dd810 stmdb sp!, {r4, fp, ip, lr, pc}
002590: e24cb004 sub fp, ip, #4 ; 0x4
002594: e24dd00c sub sp, sp, #12 ; 0xc
002598: e59f023c ldr r0, [pc, #572] ; [0027dc] "/dev/i2c0"
00259c: e3a01002 mov r1, #2 ; 0x2
0025a0: eb00c9b8 bl 034c88(c9b8)
0025a4: e1a04000 mov r4, r0
0025a8: e3540000 cmp r4, #0 ; 0x0
0025ac: aa000003 bge 0025c0(3) ; jump
0025b0: e59f0228 ldr r0, [pc, #552] ; [0027e0] "%s: can not open i2c device"
0025b4: e59f1228 ldr r1, [pc, #552] ; [0027e4] "zoom_test"
0025b8: eb00bc86 bl 0317d8(bc86)
0025bc: e91ba810 ldmdb fp, {r4, fp, sp, pc} ; return

The full piece of code essentially loops 7 times trying to open the i2c sensor to call the zoom_test code. If it fails, it calls for a reboot.
Success proceeds to setting up the camera.

We know from our boot log that my camera in this model is a Sonix288.

dvm usb cam driver 0.0.0.0 by Maverick Gao in 2006-8-12
usb.c: registered new driver dvm
dvm usb cam driver 0.1 for sonix288 by Maverick Gao in 2009-4-20
usb.c: registered new driver dvm usb cam driver for sonix288

The Sonix288 is a chipset SoC that will talk to an attached image sensor via i2c. I think that the Sonix288 is probably a standard USB 1.1/2.0 compatible UVC (USB Video Class) chipset from a bit of googling about it.

We don’t have the source for our particular camera though (its secret, much like the data sheets, grrr…).
What to do?
Linux generally uses spcaxxx (and UVC) drivers for talking to camera’s, so lets start taking a look there.

http://read.pudn.com/downloads127/sourcecode/unix_linux/539050/zc030x/zc030x_cameras.c__.htm

http://www.hackchina.com/r/54654/zc030x_i2c.c__html

Taking a look at some spcaxxx driver header files and code shows that i2c is setup by first getting the USB VID, USB PID of the hardware, then talking to the i2c device on that hardware.

So, we need to know what our USB VID and PID’s are.

Generally all devices from a given manufacturer will have a single VID as issued by the USB Forum.

If we search through the code for Sonix, it appears that Sonix’s VID is 0x0c45

{USB_DEVICE(0x0c45, 0x607c)}, /* Sonix sn9c102p Hv7131R */
(from http://linux.downloadatoz.com/linux-kernel-webcams-driver-gspca-spca5xx/ )

The Linux UVC page confirms this http://www.ideasonboard.org/uvc/.

(Listings of webcams excerpted – note the VID of 0c45)

0c45:6310 USB 2.0 Camera (Trust Chat Webcam) Sonix Technology
0c45:63e0 Sonix Integrated Webcam (Dell notebooks) Sonix Technology
0c45:63ea Laptop Integrated Webcam 2M (Dell Studio 1555 notebooks) Sonix Technology
0c45:6409 USB 2.0 Camera (Nokia Booklet 3G netbooks) Sonix Technology
0c45:6415 Laptop Integrated Webcam 1.3M (Dell Inspiron 13z notebooks) Sonix Technology

Ideally at this point, I’d have a data sheet for the Sonix288 chip, but the #$%#$ people at Sonix don’t seem to publish one for us mere mortals.

So, we’ll use the next best thing, and use one for their other chipsets.

SN9C1xx PC Camera Controllers –
http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/video4linux/sn9c102.txt

There is a lot of good useful info in that particular file. We don’t know how much is useful yet, but generally chipsets are quite similar for a given range.

Image sensor / SN9C1xx bridge | SN9C10[12] SN9C103 SN9C105 SN9C120
——————————————————————————-
HV7131D Hynix Semiconductor | Yes No No No
HV7131R Hynix Semiconductor | No Yes Yes Yes
MI-0343 Micron Technology | Yes No No No
MI-0360 Micron Technology | No Yes Yes Yes
OV7630 OmniVision Technologies | Yes Yes Yes Yes
OV7660 OmniVision Technologies | No No Yes Yes
PAS106B PixArt Imaging | Yes No No No
PAS202B PixArt Imaging | Yes Yes No No
TAS5110C1B Taiwan Advanced Sensor | Yes No No No
TAS5110D Taiwan Advanced Sensor | Yes No No No
TAS5130D1B Taiwan Advanced Sensor | Yes No No No

Interesting… Hmm, so it seems that Sonix uses a SN9Cxxx for its product names.
Lets google for SN9C288 instead, and see if we get any results.

Bingo.

From here – www.lh-invest.com/en/showpro.asp?id=308&proid=3

* MCU: SONIX SN9C288
* Sensor: MICRON K14 1,300,000 pixels CMOS
* 5-glass lens,can reach 30 frames/sec. under 640*480
resolutions,software insertion value 1,300,000 pixels
* Focus range: 3CM to infinitude farness
* Dynamic video resolutions: 1280*960 pixels(max.)
* Support microsoft UVC driver-free function
* Support RGB24 and YUY2 two kinds of image formats
* USB 2.0 port,support plug and play
* Human face tracking function

Seems our chipset is finally getting some details.
Max resolution, video modes, face tracking capability, etc
We also know that it can be paired with a Micron K14 image sensor.

Further googling reveals it can also be paired with the MI-0360 (which is listed above).

SN9C288+MI0360

This page also gives us a possible pid:

http://forums.lenovo.com/t5/SL-Series-ThinkPad-Laptops/camera-problem-in-all-windows-Creation-of-the-Video-preview/m-p/163019/highlight/true

“Device Name: ?USB Video Device

PnP Device ID: VID = 0C45 PID = 62C0
Serial Number: 6&&2BCAFCF3&&0&&0000
Revision: (Information not returned)

Device Type: Standard USB device – USB2.0 High-Speed

Chip Vendor: SONiX
Chip Part-Number: SN9C288PFG

In Microsoft parlance, this looks like this USB\VID_0C45&PID_62C0

Googling that gives us a product with windows drivers (HP) and more.

http://www.downloadwindowsdrivers.info/usb/vid_0c45/pid_62c0/mi_00/

Also says that these product drivers also work.
USB\VID_0C45&PID_62C0 ;SN9C211/213/230

That means we can take a look at their inf file and see if anything useful in there. Unfortunately I did, and there isn’t much 🙁

Sonix has datasheets for some of their other products available though (SN9C2028AF).

First, a quick overview of UVC devices (snarfed from elsewhere).

USB devices are required by the USB specification to respond to the Host device (the computer) with a stream of data describing the device and the interface to the device. This “Device Descriptor” includes vendor, product, and version IDs specific to the manufacturer, the product, and the version of the product. In addition to the device information, the descriptor also includes information on how to talk to the device through a series of “Interface Descriptors”.

The device descriptor for Video is 13.

#define USB_DEVICE_CLASS_VIDEO 0x0E

In addition to the end points described in the interface descriptors, all USB devices support a control pipe to end point 0. This is used to manipulate some of the low level functions of the device such as power, and error status queries.

The USB Video specification describes two interfaces, a control interface to manage the camera, and a stream interface to send or receive video information from the camera.

The control interface is used to manipulate the camera parameters such as brightness and contrast as well as to negotiate a valid set of the video format, frame size, frame rate, and compression rates parameters that describe a video stream. In addition, the control interface can ask the camera for still frame.

In the datasheet for the 2028, it basically states that they use end point 0 for STD Commands, with a maximum packet size of 64 bytes.

Further googling reveals that there is no special driver for it, its a plain UVC 1.0 device.

usb 1-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
usb 1-2: Product: USB 2.0 Camera
usb 1-2: Manufacturer: Sonix Technology Co., Ltd.
Linux video capture interface: v2.00
uvcvideo: Found UVC 1.00 device USB 2.0 Camera

Further heavy baidu’ing in Chinese sites finds that the SN9C213 and SN9C288 are the same pretty much.

其内部编号是SN9C213，功能完全和SN9C288一样。From http://ep.cbifamily.com/2007/04/44/87819.html

David McCullough very nicely also compiled in usb debug support on his kernel and ran some tests too:

> > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> > > D: Ver= 2.00 Cls=ef(unk. ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> > > P: Vendor=0c45 ProdID=62f1 Rev= 1.00
> > > S: Manufacturer=Sonix Technology Co., Ltd.
> > > S: Product=USB 2.0 Camera
> > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
> > > I: If#= 0 Alt= 0 #EPs= 1 Cls=0e(unk. ) Sub=01 Prot=00 Driver=(none)
> > > E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=6ms
> > > I: If#= 1 Alt= 0 #EPs= 0 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
> > > I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=1ms
> > > I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 256 Ivl=1ms
> > > I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 512 Ivl=1ms
> > > I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 600 Ivl=1ms
> > > I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 800 Ivl=1ms
> > > I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 956 Ivl=1ms

The uvc driver status is obviously an issue as we’re on a 2.4 Kernel. No uvc support on 2.4.
So…, we either compile 2.6 with UVC support, and reflash, or we continue to use Mavericks driver in lieu of any source.

With that, you have some background on things..
Now, why does this cause a reboot on some machines?

Well, the hardware is different, so the hardware isn’t seen by the driver.
From looking at a few different boards I have seen a few devices id’s used.

So far I have seen these:
vid_0c45/pid_62f1 – (The Sonix Chipset allows you to write pid’s into the device, so this can be changed, or alternately change the driver from 62c0 to 62f1 on these models)

vid_0c45/pid_62c0 – (Our driver is compiled for this)

For those of you with rebooting machines, remove ‘camera &’ from the boot sequence, recompile the kernel with USB verbose debug message logging, and start posting your vid/pid’s here so we can compare, and add to the list.

If someone twisted my arm I could probably oblige…

References:
http://www.beyondlogic.org/uClinux/bflt.htm – bFLT file format details.
http://www.garykessler.net/library/file_sigs.html – Common file format headers
http://www.openwiz.org/wiki/BWFWTools_Release – bFLT unzip and other tools
http://www.hex-rays.com – IDA Pro and Hex-Ray ARM Decompiler
http://www.sigmaplayer.com/filebase.php?d=1&id=13&c_old=5&what=c&page=1 – Arm Decompiler
http://www.ideasonboard.org/uvc/
http://read.pudn.com/downloads127/sourcecode/unix_linux/539050/zc030x/zc030x_cameras.c__.htm
http://www.hackchina.com/r/54654/zc030x_i2c.c__html
http://linux.downloadatoz.com/linux-kernel-webcams-driver-gspca-spca5xx/
http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/video4linux/sn9c102.txt

Files from this post:
(arm2html.exe, bFLT gunzip perl script, original camera bFLT, uncompressed camera bFLT, and camera asm source )
Camera Disassembly, unpacked bFLT and Tools

Finally got a chance to play around with the second ipcam I bought.

This one is a little bit smarter than the previous one – its running off an ARM5ARM7 CPU (Nuvoton NUC745ADN), so has a bit more oomph. 16M ram is a whole lot more to play with for a start! The last device only had 16KB, so this puppy can be taught to do some tricks!

Serial was a little bit trickier to solder on this time – my initial connectors were too small, so had to resolder with larger ones, and I managed to mess up a tad. Never said my soldering was any good 😉
Getting it to talk to the computer was a bit painful too – eventually I settled on 115,200 8,n,1, xon/xoff which should have worked the first time around, but I was getting garbage.

Probably flow control (xon/xoff), as fiddling with the connections got it going eventually.

First output from the board is below – this is from a clean boot (with no ethernet or wifi).


W90P745 Boot Loader [ Version 1.1 $Revision: 1 $ ] Rebuilt on Dec 10 2009
Memory Size is 0x1000000 Bytes, Flash Size is 0x200000 Bytes
Board designed by Winbond
Hardware support provided at Winbond
Copyright (c) Winbond Limited 2001 - 2006. All rights reserved.
Boot Loader Configuration:

MAC Address : 0E:F2:B3:DC:08:05
IP Address : 0.0.0.0
DHCP Client : Enabled
CACHE : Enabled
BL buffer base : 0x00300000
BL buffer size : 0x00100000
Baud Rate : -1
USB Interface : Disabled
Serial Number : 0xFFFFFFFF

For help on the available commands type 'h'

Press ESC to enter debug mode ......
Cache enabled!
Processing image 1 ...
Processing image 2 ...
Processing image 3 ...
Processing image 4 ...
Processing image 5 ...
Processing image 6 ...
Processing image 7 ...
Unzip image 7 ...
Executing image 7 ...
Linux version 2.4.20-uc0 (root@maverick-linux) (gcc version 3.0) #1013 Èý 12ÔÂ 2 13:17:32 CST 2009
Processor: Winbond W90N745 revision 1
Architecture: W90N745
On node 0 totalpages: 4096
zone(0): 0 pages.
zone(1): 4096 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/rom0 rw
Calibrating delay loop... 39.83 BogoMIPS
Memory: 16MB = 16MB total
Memory: 14376KB available (1435K code, 288K data, 40K init)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Winbond W90N745 Serial driver version 1.0 (2005-08-15) with no serial options enabled
ttyS00 at 0xfff80000 (irq = 9) is a W90N745
Winbond W90N7451 Serial driver version 1.0 (2005-08-15) with no serial options enabled
ttyS00 at 0xfff80100 (irq = 10) is a W90N7451
I2C Bus Driver has been installed successfully.
Blkmem copyright 1998,1999 D. Jeff Dionne
Blkmem copyright 1998 Kenneth Albanowski
Blkmem 1 disk images:
0: 7F0E0000-7F16D3FF [VIRTUAL 7F0E0000-7F16D3FF] (RO)
AM29LV160DB Flash Detected
01 eth0 initial ok!
which:0
PPP generic driver version 2.4.2
Linux video capture interface: v1.00
Winbond Audio Driver v1.0 Initialization successfully.
usb.c: registered new driver hub
add a static ohci host controller device
: USB OHCI at membase 0xfff05000, IRQ 15
hc_alloc_ohci
usb-ohci.c: AMD756 erratum 4 workaround
hc_reset
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver audio
audio.c: v1.0.0:USB Audio Class driver
usb.c: registered new driver serial
usbserial.c: USB Serial Driver core v1.4

_____ ____ _ ____
|__ / _| _ \ / \ / ___|
/ / | | | | | |/ _ \ \___ \
/ /| |_| | |_| / ___ \ ___) |
/____\__, |____/_/ \_\____/
|___/
ZD1211B - version 2.24.0.0
usb.c: registered new driver zd1211b
main_usb.c: VIA Networking Wireless LAN USB Driver 1.13
usb.c: registered new driver vntwusb
usb.c: registered new driver rt73
dvm usb cam driver 0.0.0.0 by Maverick Gao in 2006-8-12
usb.c: registered new driver dvm
dvm usb cam driver 0.1 for sonix288 by Maverick Gao in 2009-4-20
usb.c: registered new driver dvm usb cam driver for sonix288
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
VFS: Mounted root (romfs filesystem) readonly.
Freeing init memory: 40K
BINFMT_FLAT: bad magic/rev (0x74202d74, need 0x4)
BINFMT_FLAT: bad magic/rev (0x74202d74, need 0x4)
Shell invoked to run file: /bin/init
Command: mount -t proc none /proc
Command: mount -t ramfs none /usr
Command: mount -t ramfs none /swap
Command: mount -t ramfs none /var/run
Command: mount -t ramfs none /etc
Command: mount -t ramfs none /flash
Command: mount -t ramfs none /home
Command: camera&
[8]
Command: sh
no support

Sash command shell (version 1.1.1)
/> hub.c: connect-debounce failed, port 1 disabled
new USB device :80fd7e04-fed640
hub.c: new USB device 1, assigned address 2
dvm cmos successfully initialized
dvm camera registered as video0
new USB device :80fb0204-fed640
hub.c: new USB device 2, assigned address 3
idVendor = 0x148f, idProduct = 0x2573

Wait for auto-negotiation complete...ResetPhyChip Failed
video0 opened
1
1
1
1
1
1
set resolution 5
set brightness 144
set contrast 3
set sharpness 3
set mode 2
__pthread_initial_thread_bos:34c000
manage pid:16
audio_dev.state not AU_STATE_RECORDING
wb_audio_start_record
=> usb_rtusb_open
retide_ddns.c: can not get server dns.camcctv.com ip
ntpc.c: can not resolve ntpserver(time.nist.gov)'s ip
get oray info
upnp get ip error
inet_sr.c INET_rinput 321
action===1
options==33
inet_sr.c INET_setroute 75
*args===255.255.255.255
*args===netmask
*args===eth1
inet_sr.c INET_rinput 321
action===1
options==33
inet_sr.c INET_setroute 75
*args===default
*args===gw
*args===eth1
MlmeAssocReqAction(): WPA2/WPA2PSK fill the ReqVarIEs with CipherTmp!
3
3
3
3
3
3


Initially I had the board setup on its own without the camera attached, but the boot scripts require it connected, otherwise they reboot..
Ostensibly, this is the same hardware as the fi8908w (who are just reselling the OEM version with marginally different firmware as far as I can tell).

Next step is to setup a cross compiler for uclinux so I can make some binaries, and test.
Luckily all the available tools are open source / free. Yay!

I’m in contact with the factory, and they’ll be sending an SDK over at some point soonish, although its only in Chinese.
Luckily for me, that shouldn’t be a problem, as i’m reasonably capable at groking both code, and simplified chinese 🙂

ucLinux should be easy enough to build a rom image for though – tons of examples, and I already have a few firmware files to compare.

It shouldn’t be too hard for me to roll another firmware with ssh installed, so that we can get in without serial, that would be more useful for others too.

I’ve had a quick look inside the folders in the device from the device itself – fairly minimal, pretty much the only binaries are the necessary ones.
My initial aim is to redo the UI to a nicer one, and fix some of the more glaring bugs. The factory people are at a trade show in Taiwan this week, so hopefully next week I’ll get some dev tools (otherwise its reverse engineering, bleh…).

Some more people are playing with these as well (links below):

http://irishjesus.wordpress.com/2010/03/30/hacking-the-foscam-fi8908w/

http://www.gadgetvictims.com/2009/12/bring-your-fi8908w-paperweight-back-to.html

Unfortuanately for me, both are variably accessible. WordPress is available this week woohoo, but its an on / off dealio with the GFW…, so I might have to stop commenting there once the government decides if WordPress is “teh evil” again.

The irishjesus blog guy has done some of the harder bits like file extraction already (although not strictly necessary, as there are existing tools for that kind of thing).

—

Updates

Have some docs from the factory now, see attached file for the CGI spec.

IP Camera CGI 应用指南-1.11

I have others, but not so relevant especially for those than don’t read Chinese!

Data sheet for the Chip and build instructions here –

http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ConsumerElectronicsIC/ARMMicrocontroller/ARMMicrocontroller/NUC745A.htm

I’ve finally received my 2nd camera, so I can now start working properly on it (assuming I get some free time too!)

High resolution photos of the board are below:

Main parts used are:

RAM – Winbond W9812G61H-6 (2M)
According to the data sheet, that 2M X 4 BANKS X 16 BITS SDRAM @ 3.3V / 166MHz/CL3
Data sheet is here – http://jp.ic-on-line.cn/IOL/datasheet/w9812g6ih_4223255.pdf

Flash – Spansion S29AL016D (2M)
Other boards are populated with different providers – some people have Samsung flash…
Mine has the Spansion onboard both units. Its programmable onboard (via the uBoot)
Data sheet here – http://www.datasheetpro.com/259722_view_S29AL016D_datasheet.html

Sound Card – ALC203
This is obviously used as the BSP for the Novotel provides sample code for that card, making their life easier…
Data sheet here – http://realtek.info/pdf/alc203.pdf

Wired Ethernet – Davicom DM9161AEP (10/100 Ethernet)
Data sheet here –
http://www.davicom.com.tw/userfile/24247/DM9161AEPProductBrief_v1.0.pdf

8 Port Relay Driver (for the motors etc) – ULN2803
Data sheet here – http://www.rentron.com/Files/uln2803.pdf
More info / explanation here – http://wiki.answers.com/Q/What_is_Relay_driver_ULN2803

Wifi – RALINK 2571 (on daughterboard). Wireless G
This is a USB based chipset, so we’re using 4 usb connector pins for this one.
No datasheet, as Ralink are dicks.

CPU – ARM7 N745CDG (Arm 7 by Nuvoton)
Lot of info for chip available at Nuvoton.

W90N745 makes use of the ARM7TDMI microprocessor core of ARMR and 0.18um production to achieve standard operation at 80MHz. 128-Pin LQPF packing is also used to save electricity and lower costs. The built-in 4KBytes I-Cache and 4KBytes D-Cache of W90N745 can also be set as On-Chip RAM according to the needs of product developers. With regards to system integration, W90N745 is suitable for network-related applications such as management switch, IP cameras, VoIP and printer servers.
Features
* One Ethernet MAC
* One USB 2.0 full speed Host controller
* One USB 2.0 full speed Host/Device controller
* AC97/I2S
* 4 UARTs
* I²C Master
* 31 GPIOs
* Power Management

Data sheets – http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/ConsumerElectronicsIC/ARMMicrocontroller/ARMMicrocontroller/NUC745A.htm
The uclinux sample distribution and files can be downloaded here – http://www.metavert.com/public/NO-SUPPORT/NUC700%20Series%20MCU%20uCLinux%20BSP.zip

I’m just waiting on a JLINK USB adaptor, then I’m ready to roll.

[Updates]

David M from comments at http://irishjesus.wordpress.com/2010/03/30/hacking-the-foscam-fi8908w/#comments provided his rom sizing from his device, I’ve got some notes on that here.

MAC Address : 00:30:10:C1:D0:39
IP Address : 0.0.0.0
DHCP Client : Enabled
CACHE : Enabled
BL buffer base : 0×00300000
BL buffer size : 0×00100000
Baud Rate : -1
USB Interface : Disabled
Serial Number : 0xFFFFFFFF

For help on the available commands type ‘h’

Press ESC to enter debug mode …

bootloader > ls
Image: 0 name:BOOT INFO base:0x7F010000 size:0×00000038 exec:0x7F010000 -af
Image: 7 name:linux.bin base:0x7F020000 size:0x000BB334 exec:0×00008000 -acxz
Image: 6 name:romfs.img base:0x7F0E0000 size:0x0008D000 exec:0x7F0E0000 -a

My notes:

Image: 0 name:BOOT INFO base:0x7F010000 size:0×00000038 exec:0x7F010000 -af

[Image 0 is 38 bytes (small!).
Boot info is not the bootloader – 38bytes is way too small for that.
It actually stores our bootloader config settings.
eg ip address, cache setting, boot loader buffer address etc.
Our initial settings are below:

MAC Address : 00:30:10:C1:D0:39 (should be changed, this Mac range belongs to Cisco!)
IP Address : 0.0.0.0 (unset)
DHCP Client : Enabled (pulls ip from dhcp..)
CACHE : Enabled (onboard chip cache)
BL buffer base : 0×00300000
BL buffer size : 0×00100000
Baud Rate : -1 (unset / so defaults to 115,200,8,n,1)
USB Interface : Disabled (NC745 has no USB for bootloader)
Serial Number : 0xFFFFFFFF (unset)

-af indicates Active (a) , and is a Filesystem image (f)]

Image: 7 name:linux.bin base:0x7F020000 size:0x000BB334 exec:0×00008000 -acxz
[Image 7 is our OS – Linux 2.4.20 ucLinux Not sure why Maverick didn’t build on 2.6, there is more hardware support. Probably time dependant – 2.6 may not have been available, plus the Nuvoton sample code is also 2.4 based…

-axcz says active (a) executable (x) copied to ram (c) compressed (z) ]

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

[Our rom image – aka userland stuff. This is where we’ll be putting our own code. Looks like its stuck quite high up in the flash, although doesn’t need to be given size of the Linux rom. We have plenty of room available.

We’ll need to make appropriate changes to Image 6 size on flashing

-a says active partition.]

When I was younger, I used to like taking things apart.  I still do that, but they tend to work better these days, hehe

This last few weeks I’ve been playing with IP Camera’s for a pet project that started off as a request over Skype for info about surveillance.
As the ever useful Taobao is full of vendors selling the same 4 or 5 camera’s for reasonable prices I ordered a couple to take a peek at.

I’ve only taken one apart so far – the really really cheap one that I installed in the office so I can get a look at who comes up the stairs without having to move my fat ass out of the chair.  A quick shortcut in FF, and it works quite nicely as a separate browser window in the corner of the desktop.

Onto the discovery phase 🙂

I had a quick spin with NMAP, but other than discovering that they rather naughtily misuse a Mac Address assigned to the evil Cisco, not much help.
Also nothing appeared to be running on any other ports than the web port 🙁
nmap -A 192.168.0.88

Starting Nmap 5.00 ( http://nmap.org ) at 2010-04-13 19:27 CST
Interesting ports on 192.168.0.88:
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http?
|_ html-title: IPCamera
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port80-TCP:V=5.00%I=7%D=4/13%Time=4BC45529%P=i686-pc-linux-gnu%r(GetReq
SF:uest,2E1,"HTTP/1\.1\x20200\x20OK\r\nExpires:\x200\r\nConnection:\x20clo
SF:se\r\ncache-control:\x20no-cache\r\n\r\n\r\n
SF:IPCamera\r\n\r
SF:\n\r\n\r\n\r\n\r\n
SF:\r\n\r\n\r\n\r\n\r\n\r\n\r\n<BODY\x20onLoad=\" SF:doPop\(\);\">\xb6\xd4\xb2\xbb\xc6\xf0\xa3\xac\xc4\xfa\xb5\xc4\xe4\xaf\x
SF:c0\xc0\xc6\xf7\xb2\xbb\xd6\xa7\xb3\xd6\xbf\xf2\xbc\xdc\xa3\xa1</BODY></ SF:NOFRAMES>\r\n</FRAMESET>\r\n\r\n</HTML>\r\n")%r(FourOhFourRequest,1DF,"
SF:HTTP/1\.1\x20200\x20OK\r\nConnection:\x20close\r\ncache-control:\x20no-
SF:cache\r\n\r\n<HTML>\r\n<HEAD>\r\n<TITLE></TITLE>\r\n<meta\x20http-equiv SF:=\"Content-Type\"\x20content=\"text/html;\x20charset=gb2312\"></HEAD>\r
SF:\n<BODY\x20BGCOLOR=\"#C4CEEF\"\x20onLoad=\"window\.status='\xbb\xb6\xd3 SF:\xad\xca\xb9\xd3\xc3\xcd\xf8\xc2\xe7\xc9\xe3\xcf\xf1\xbb\xfa!';return\x SF:20true;\">\r\n\r\n
<TABLE\x20WIDTH=140\x20BORDER=0\x20CELLSPACING=0\x20C SF:ELLPADDING=0>\r\n
<TR>\r\n\t
<TD\x20HEIGHT=80\x20ALIGN=center\x20BGCOLOR= SF:\"#C4CEEF\"><FONT\x20color=\"#FF6633\"\x20size=\"\+2\"\x20FACE=\"Arial\ SF:"><B>IP\x20Camera</B></FONT></TD>

\r\n</TR>

\r\n</TABLE>

\r\n\r\n</BODY>\r
SF:\n</HTML>\r\n");
MAC Address: 00:0A:42:33:66:54 (Cisco Systems)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
OS fingerprint not ideal because: Missing a closed TCP port so results incomplete
No OS matches for host
Network Distance: 1 hop


Next up is the usual dissection. I had done some minor googling on the device I bought, which is basically this below:

As its an OEM product, this is available under a whole bunch of different names – mostly with IP-510 or similar in the title, eg LTI-510 etc.

For a cheap OEM product, it actually seems to be reasonably well made though – the Case is an nice and solid aluminium sheath that looks like its been repurposed from something else, and the board itself is suprisingly well diagrammed. Its almost made for hacking!

Chips onboard are as follows:

25.0618mhz crystal from TXC – bonus points for why its 25mhz. Reply in the comments 🙂
Davicom DM9008AEP, TRC9016NLE (both for Ethernet. imho Davicom is a second-rate Realtek)
ViMicro VC0528BRVC (Camera processor / CCD Controller)
And last, but not least, our CPU, which is an 8051, although not from ATMEL.
Part number on that is C8051F340. My first guess is that it incorporates some integrated flash on there for firmware. Unfortunately its likely to be all C and Assembler, and the last time I did embedded 8051 stuff was in the early 90’s.

Google confirms it – basically its an all in one controller with 32 or 64KB onboard, and roughly 4k ram. Woohoo!

Datasheet here – http://www.alldatasheet.com/datasheet-pdf/pdf/182721/SILABS/C8051F340.html

Good news is that the board has serial out clearly labeled on the top left side. Better news is that the chip has an onboard debug mode, so I don’t even need any ICE (In Circuit Emulation) tools should I want to take a look. Bad news is that I’m probably going to be too lazy to do it, as its more work and less fun than the second one I bought, which has Linux running on it.

That said, this one is cheap. Real cheap. Cheap enough that its probably worth knocking out a decent firmware, and reselling it with a better UI, and more features.
Might be possible, although anything more than whats there is probably stretching it given the ram / storage constraints. Looks like its all offboard processing/streaming for this model!

There are also some unpopulated spots on the board, which I strongly suspect would be for audio, given the board has a MIC input and no Mic, and the main controller is a ViMicro, which supports MP3 output also…

I’ll see if I can find a firmware file, and do a disassembly, or more probably see what I get out of the serial port connection in the near future.

Photos below. [Excuse the pasty white hands, its still winter for some reason in Shanghai, despite being April… Oh global warming. Where art thou, when I needest thee!]:

Some further files for the curious here –

http://kuklin.ru/ip400cam