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!)<\/p>\n
As we recall from previous work, the main binary for the IPCam runs off a file called “camera”.<\/p>\n
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).<\/p>\n
So, lets take a look at the executable to see what interesting bits we can find out from it.<\/p>\n
#file camera tells us – BINFLT file format. Fileflags: RAM GZIP.
\nSo we know its a compressed bflt elf – bflt stands for binary flat file, and it uses gzip compression. It also sits in ram.<\/p>\n
A hex dump of camera shows this for the first few bytes:<\/p>\n
[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. bFLT headers consist of 4 bytes identifier, then 4 bytes for the version number. If we take a look at the header file source for bflt at the uclinux site we see the below layout.<\/p>\n It doesn’t match up properly, as the sizes or code don’t make sense (yet).<\/p>\n If we take a closer look, the header file has this to say:<\/p>\n Ahah!<\/p>\n So, all but the header is compressed for a version 4 file.<\/p>\n Lets check this out, and see if its correct. 1F 8B 08<\/p>\n Those of you familiar with gzipped files will recognize that – its the gzip header identifier. So, so far, so good. 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.<\/p>\n See below for some perl to safely uncompress our binary , taken from here – http:\/\/www.openwiz.org\/wiki\/BWFWTools_Release<\/a><\/p>\n =pod<\/p>\n =head1 NAME<\/p>\n gunzip_bflt - convert gzip-compressed bFLT executable files into uncompressed bFLT<\/p>\n =head1 SYNOPSIS<\/p>\n gunzip_bflt zipped_blflt_files...<\/p>\n =head1 DESCRIPTION<\/p>\n Convert gzipped bFLT files into an uncompressed bFLT files. =head1 PREREQUSITES<\/p>\n Uses packages C =cut<\/p>\n use strict; # gunzip_bflt zipped_blflt_files...<\/p>\n use IO::Uncompress::Gunzip qw\/gunzip $GunzipError\/; # Read and return the BFLT header sub get_bflt_hdr($$) { \t\t# Write the header \t\t# Align the buffered file handle with the unbuffered \t\t# Ungzip from the compressed file into the uncompressed \t\tclose BFLTZ; # Expand the arguments...<\/p>\n foreach my $bfltZ (@ARGV) { If we run that on our ‘camera’ executable, we should have an uncompressed bFLT file as output ‘camera.unz’. Some interesting things of note:<\/p>\n From the variables list below, looks like there is a way to turn off the LED…<\/p>\n \nled_mode We also have a full list of the internal cgi functions now, which might prove useful…<\/p>\n \nsnapshot.cgi You can see that Maverick decided to fake the X-Mailer smtp header (Foxmail is a commonly used Mail Program in China).<\/p>\n \nMIME-Version: 1.0 I’m interested in why the firmware reboots on some firmwares though, so lets take a deeper look at the code.<\/p>\n To do so, we’ll need to decompile it. Luckily there is a free windows decompiler called arm2html available here.<\/a> 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:<\/p>\n (excerpted piece below) 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. We know from our boot log that my camera in this model is a Sonix288.<\/p>\n dvm usb cam driver 0.0.0.0 by Maverick Gao in 2006-8-12 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.<\/p>\n We don’t have the source for our particular camera though (its secret, much like the data sheets, grrr…). http:\/\/read.pudn.com\/downloads127\/sourcecode\/unix_linux\/539050\/zc030x\/zc030x_cameras.c__.htm 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.<\/p>\n So, we need to know what our USB VID and PID’s are.<\/p>\n Generally all devices from a given manufacturer will have a single VID as issued by the USB Forum.<\/p>\n If we search through the code for Sonix, it appears that Sonix’s VID is 0x0c45<\/p>\n The Linux UVC page confirms this http:\/\/www.ideasonboard.org\/uvc\/<\/a>.<\/p>\n (Listings of webcams excerpted – note the VID of 0c45)<\/p>\n 0c45:6310 \tUSB 2.0 Camera (Trust Chat Webcam) \tSonix Technology Ideally at this point, I’d have a data sheet for the Sonix288 chip, but the #$%#$ people at Sonix<\/a> don’t seem to publish one for us mere mortals.<\/p>\n So, we’ll use the next best thing, and use one for their other chipsets.<\/p>\n SN9C1xx PC Camera Controllers – 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.<\/p>\n \nImage sensor \/ SN9C1xx bridge | SN9C10[12] SN9C103 SN9C105 SN9C120 Interesting… Hmm, so it seems that Sonix uses a SN9Cxxx for its product names. Bingo.<\/p>\n From here – www.lh-invest.com\/en\/showpro.asp?id=308&proid=3<\/a><\/p>\n \n* MCU: SONIX SN9C288 Seems our chipset is finally getting some details. Further googling reveals it can also be paired with the MI-0360 (which is listed above).<\/p>\n SN9C288+MI0360<\/p>\n This page also gives us a possible pid:<\/p>\n http:\/\/forums.lenovo.com\/t5\/SL-Series-ThinkPad-Laptops\/camera-problem-in-all-windows-Creation-of-the-Video-preview\/m-p\/163019\/highlight\/true<\/a><\/p>\n \n“Device Name: ?USB Video Device<\/p>\n PnP Device ID: VID = 0C45 PID = 62C0 Device Type: Standard USB device – USB2.0 High-Speed<\/p>\n Chip Vendor: SONiX In Microsoft parlance, this looks like this USB\\VID_0C45&PID_62C0<\/p>\n Googling that gives us a product with windows drivers (HP) and more.<\/p>\n http:\/\/www.downloadwindowsdrivers.info\/usb\/vid_0c45\/pid_62c0\/mi_00\/<\/a><\/p>\n Also says that these product drivers also work. 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 \ud83d\ude41<\/p>\n Sonix has datasheets for some of their other products available though (SN9C2028AF).<\/p>\n First, a quick overview of UVC devices (snarfed from elsewhere).<\/p>\n 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 \u201cDevice Descriptor\u201d 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 \u201cInterface Descriptors\u201d. <\/p>\n The device descriptor for Video is 13.<\/p>\n #define USB_DEVICE_CLASS_VIDEO 0x0E<\/p>\n 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.<\/p>\n 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. <\/p>\n 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.<\/p>\n 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.<\/p>\n Further googling reveals that there is no special driver for it, its a plain UVC 1.0 device.<\/p>\n usb 1-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 Further heavy baidu’ing in Chinese sites finds that the SN9C213 and SN9C288 are the same pretty much.<\/p>\n \u5176\u5185\u90e8\u7f16\u53f7\u662fSN9C213\uff0c\u529f\u80fd\u5b8c\u5168\u548cSN9C288\u4e00\u6837\u3002From http:\/\/ep.cbifamily.com\/2007\/04\/44\/87819.html<\/a><\/p>\n David McCullough very nicely also compiled in usb debug support on his kernel and ran some tests too:<\/p>\n > > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 The uvc driver status is obviously an issue as we’re on a 2.4 Kernel. No uvc support on 2.4. With that, you have some background on things.. Well, the hardware is different, so the hardware isn’t seen by the driver. So far I have seen these: vid_0c45\/pid_62c0<\/strong> – (Our driver is compiled for this)<\/p>\n 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.<\/p>\n If someone twisted my arm I could probably oblige…<\/p>\n References:<\/strong>62 46 4C 54 00 00 00 04 | bFLT . . . . <\/code><\/p>\n
Lesson learned, always save stuff elsewhere before posting.<\/span>]<\/p>\n
\nIn this case, its a version 4 bFLT file.<\/p>\n
\n struct flat_hdr {
\n \tchar magic[4];
\n \tunsigned long rev; \/* version *\/
\n \tunsigned long entry; \/* Offset of first executable instruction with text segment from beginning of file *\/
\n \tunsigned long data_start; \/* Offset of data segment from beginning of file *\/
\n \tunsigned long data_end; \/* Offset of end of data segment from beginning of file *\/
\n \tunsigned long bss_end; \/* Offset of end of bss segment from beginning of file *\/
\n \t\/* (It is assumed that data_end through bss_end forms the bss segment.) *\/
\n \tunsigned long stack_size; \/* Size of stack, in bytes *\/
\n \tunsigned long reloc_start; \/* Offset of relocation records from beginning of file *\/
\n \tunsigned long reloc_count; \/* Number of relocation records *\/
\n \tunsigned long flags;
\n \tunsigned long filler[6]; \/* Reserved, set to zero *\/
\n };
\n<\/code><\/p>\n
\n #define FLAT_FLAG_RAM 0x0001 \/* load program entirely into RAM *\/
\n #define FLAT_FLAG_GOTPIC 0x0002 \/* program is PIC with GOT *\/
\n #define FLAT_FLAG_GZIP 0x0004 \/* all but the header is compressed *\/
\n<\/code><\/p>\n
\nExcluding the initial file identifier (bFLT), our header consists of 10 longs. Thats 40 bytes long.
\nLets jump to offset 40 in the file, and see what we have there.<\/p>\n
\nCompressed files aren’t very useful to us, as they don’t show much text content.
\nSo, we could unzip the file to take a look at whats inside.<\/p>\n
\n#!\/usr\/bin\/perl<\/p>\n
\nThe unzipped bFLT files have B<.unz> added to their file names.
\nIf the file is already ungzipped bFLT, it isn't converted,
\nbut a warning is printed.<\/p>\n
\nuse warnings;<\/p>\n
\nuse POSIX;<\/p>\n
\n# prints a warning and returns undef on error.
\n# $bfltZfh is the BFLT file handle,
\n# $bfltZ is the BFLT file name (for error messages)<\/p>\n
\n my ($bfltZfh, $bfltZ) = @_;
\n my $buf;
\n my $res = sysread $bfltZfh, $buf, 64;
\n if(!defined($res)) {
\n\twarn \"$bfltZ: $!\\n\";
\n\treturn undef;
\n }
\n if($res < 64) {\n\twarn \"$bfltZ: Too short!\\n\";\n\treturn undef;\n }\n # Align the buffered file handle with the unbuffered\n seek $bfltZfh, sysseek($bfltZfh, 0, SEEK_CUR), SEEK_SET;\n return $buf;\n}\n\n# Expand a gzipped BFLT intoi an ungziped BFLT\n\nsub expand_blftZ($) {\n my ($bfltZ) = @_;\n my $bflt = $bfltZ . '.unz';\n if(!open BFLTZ, '<' . $bfltZ) {\n\twarn \"$bfltZ: $!\\n\";\n\treturn;\n }\n my $hdr = get_bflt_hdr(\\*BFLTZ, $bfltZ);\n if(!defined $hdr) {\n\treturn;\n }\n if(substr($hdr, 0, 4) eq 'bFLT') {\n\t# Pack\/unpack template for the BFLT header, 4 bytes ACSII,\n\t# 15 little-endian words\n\tmy $hdrFmt = 'a4 N15';\n\n\tmy @unpHdr = unpack $hdrFmt, $hdr;\n\n\t# Test the header flags 'gzipped' bit\n\tif($unpHdr[9] & 4) {\n\n\t # Unset the header flags 'gzipped' bit, and make a new header\n\t $unpHdr[9] &= ~4;\n\t $hdr = pack $hdrFmt, @unpHdr;\n\n\t if(open BFLT, '>' . $bflt) {<\/p>\n
\n\t\tsyswrite BFLT, $hdr;<\/p>\n
\n\t\tseek BFLT, sysseek(BFLT, 0, SEEK_CUR), SEEK_SET;<\/p>\n
\n\t\t# file
\n\t\tgunzip \\*BFLTZ => \\*BFLT
\n\t\t or die \"gunzip failed: $GunzipError\\n\";<\/p>\n
\n\t } else {
\n\t\twarn \"$bflt: $!\\n\";
\n\t\treturn;
\n\t }
\n\t} else {
\n\t warn \"$bfltZ: Not a compressed bFLT file, not gunzipped\\n\";
\n\t return;
\n\t}
\n } else {
\n\twarn \"$bfltZ: Not a bFLT file\\n\";
\n }
\n close BFLT;
\n}<\/p>\n
\n expand_blftZ($bfltZ)
\n}
\n<\/code><\/p>\n
\nLets run strings on ‘camera.unz’, to see what interesting text content is in there.<\/p>\n
\nptz_center_onstart
\nptz_auto_patrol_interval
\nptz_auto_patrol_type
\nptz_patrol_h_rounds
\nptz_patrol_v_rounds
\nptz_patrol_rate
\nptz_patrol_up_rate
\nptz_patrol_down_rate
\nptz_patrol_left_rate
\nptz_patrol_right_rate\n<\/p><\/blockquote>\n
\nget_status.cgi
\nget_camera_params.cgi
\ndecoder_control.cgi
\ncamera_control.cgi
\nreboot.cgi
\nrestore_factory.cgi
\nupgrade_firmware.cgi
\nupgrade_htmls.cgi
\nget_params.cgi
\nset_alias.cgi
\nset_datetime.cgi
\nset_users.cgi
\nset_devices.cgi
\nset_network.cgi
\nset_wifi.cgi
\nset_pppoe.cgi
\nset_upnp.cgi
\nset_ddns.cgi
\nset_ftp.cgi
\nset_mail.cgi
\nset_alarm.cgi
\nvideostream.cgi
\nvideo.cgi
\ntest_ftp.cgi
\ntest_mail.cgi
\nset_misc.cgi
\nget_misc.cgi
\nset_p2p.cgi
\nget_p2p.cgi
\nset_forbidden.cgi
\nget_forbidden.cgi
\nset_decoder.cgi
\ncomm_write.cgi
\nwifi_scan.cgi
\nget_wifi_scan_result.cgi
\nget_log.cgi
\ncheck_user.cgi
\ncheck_user2.cgi
\nbackup_params.cgi
\nrestore_params.cgi
\nerase_allparams.cgi
\nset_mac.cgi
\ndo_cgi: unknown cgi\n<\/p><\/blockquote>\n
\nContent-Type: multipart\/mixed;
\nboundary=”smtp_msg_boundary”
\nX-Mailer: Foxmail
\n–smtp_msg_boundary
\nContent-Type: image\/jpeg;
\nname=”%s(%s)_%c%s.jpg”
\nContent-Transfer-Encoding: base64
\n–smtp_msg_boundary–\n<\/p><\/blockquote>\n
\nThe better equipped than me will probably use something like the nice ARM decompiler plugin for IDA-Pro called Hex-Ray<\/a>. Unfortunately that costs $$$, and I’m just a hobbyist.<\/p>\n
\narm2html 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.<\/p>\n
\n02588: e1a0c00d\tmov\tip, sp
\n00258c: e92dd810\tstmdb\tsp!, {r4, fp, ip, lr, pc}
\n002590: e24cb004\tsub\tfp, ip, #4\t; 0x4
\n002594: e24dd00c\tsub\tsp, sp, #12\t; 0xc
\n002598: e59f023c\tldr\tr0, [pc, #572] ; [0027dc]\t\"\/dev\/i2c0\"
\n00259c: e3a01002\tmov\tr1, #2\t; 0x2
\n0025a0: eb00c9b8\tbl\t034c88(c9b8)
\n0025a4: e1a04000\tmov\tr4, r0
\n0025a8: e3540000\tcmp\tr4, #0\t; 0x0
\n0025ac: aa000003\tbge\t0025c0(3) ; jump
\n0025b0: e59f0228\tldr\tr0, [pc, #552] ; [0027e0]\t\"%s: can not open i2c device\"
\n0025b4: e59f1228\tldr\tr1, [pc, #552] ; [0027e4]\t\"zoom_test\"
\n0025b8: eb00bc86\tbl\t0317d8(bc86)
\n0025bc: e91ba810\tldmdb\tfp, {r4, fp, sp, pc} ; return<\/code><\/p>\n
\nSuccess proceeds to setting up the camera. <\/p>\n
\nusb.c: registered new driver dvm
\ndvm usb cam driver 0.1 for sonix288 by Maverick Gao in 2009-4-20
\nusb.c: registered new driver dvm usb cam driver for sonix288<\/p><\/blockquote>\n
\nWhat to do?
\nLinux generally uses spcaxxx (and UVC) drivers for talking to camera’s, so lets start taking a look there.<\/p>\n
\n<\/a>
\nhttp:\/\/www.hackchina.com\/r\/54654\/zc030x_i2c.c__html<\/a><\/p>\n{USB_DEVICE(0x0c45, 0x607c)}, \/* Sonix sn9c102p Hv7131R *\/ <\/code>
\n(from http:\/\/linux.downloadatoz.com\/linux-kernel-webcams-driver-gspca-spca5xx\/ )<\/p>\n
\n0c45:63e0 \tSonix Integrated Webcam (Dell notebooks) \tSonix Technology
\n0c45:63ea \tLaptop Integrated Webcam 2M (Dell Studio 1555 notebooks) \tSonix Technology
\n0c45:6409 \tUSB 2.0 Camera (Nokia Booklet 3G netbooks) \tSonix Technology
\n0c45:6415 \tLaptop Integrated Webcam 1.3M (Dell Inspiron 13z notebooks) \tSonix Technology<\/p><\/blockquote>\n
\nhttp:\/\/ww2.cs.fsu.edu\/~rosentha\/linux\/2.6.26.5\/docs\/video4linux\/sn9c102.txt<\/a><\/p>\n
\n——————————————————————————-
\nHV7131D Hynix Semiconductor | Yes No No No
\nHV7131R Hynix Semiconductor | No Yes Yes Yes
\nMI-0343 Micron Technology | Yes No No No
\nMI-0360 Micron Technology | No Yes Yes Yes
\nOV7630 OmniVision Technologies | Yes Yes Yes Yes
\nOV7660 OmniVision Technologies | No No Yes Yes
\nPAS106B PixArt Imaging | Yes No No No
\nPAS202B PixArt Imaging | Yes Yes No No
\nTAS5110C1B Taiwan Advanced Sensor | Yes No No No
\nTAS5110D Taiwan Advanced Sensor | Yes No No No
\nTAS5130D1B Taiwan Advanced Sensor | Yes No No No\n<\/p><\/blockquote>\n
\nLets google for SN9C288 instead, and see if we get any results.<\/p>\n
\n* Sensor: MICRON K14 1,300,000 pixels CMOS
\n* 5-glass lens,can reach 30 frames\/sec. under 640*480
\n resolutions,software insertion value 1,300,000 pixels
\n* Focus range: 3CM to infinitude farness
\n* Dynamic video resolutions: 1280*960 pixels(max.)
\n* Support microsoft UVC driver-free function
\n* Support RGB24 and YUY2 two kinds of image formats
\n* USB 2.0 port,support plug and play
\n* Human face tracking function\n<\/p><\/blockquote>\n
\nMax resolution, video modes, face tracking capability, etc
\nWe also know that it can be paired with a Micron K14 image sensor.<\/p>\n
\nSerial Number: 6&&2BCAFCF3&&0&&0000
\nRevision: (Information not returned)<\/p>\n
\nChip Part-Number: SN9C288PFG<\/p>\n<\/blockquote>\n
\nUSB\\VID_0C45&PID_62C0 ;SN9C211\/213\/230<\/p>\n
\nusb 1-2: Product: USB 2.0 Camera
\nusb 1-2: Manufacturer: Sonix Technology Co., Ltd.
\nLinux video capture interface: v2.00
\nuvcvideo: Found UVC 1.00 device USB 2.0 Camera<\/p><\/blockquote>\n
\n> > > D: Ver= 2.00 Cls=ef(unk. ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
\n> > > P: Vendor=0c45 ProdID=62f1 Rev= 1.00
\n> > > S: Manufacturer=Sonix Technology Co., Ltd.
\n> > > S: Product=USB 2.0 Camera
\n> > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
\n> > > I: If#= 0 Alt= 0 #EPs= 1 Cls=0e(unk. ) Sub=01 Prot=00 Driver=(none)
\n> > > E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=6ms
\n> > > I: If#= 1 Alt= 0 #EPs= 0 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
\n> > > I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
\n> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 128 Ivl=1ms
\n> > > I: If#= 1 Alt= 2 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
\n> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 256 Ivl=1ms
\n> > > I: If#= 1 Alt= 3 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
\n> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 512 Ivl=1ms
\n> > > I: If#= 1 Alt= 4 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
\n> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 600 Ivl=1ms
\n> > > I: If#= 1 Alt= 5 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
\n> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 800 Ivl=1ms
\n> > > I: If#= 1 Alt= 6 #EPs= 1 Cls=0e(unk. ) Sub=02 Prot=00 Driver=(none)
\n> > > E: Ad=81(I) Atr=05(Isoc) MxPS= 956 Ivl=1ms<\/p>\n
\nSo…, we either compile 2.6 with UVC support, and reflash, or we continue to use Mavericks driver in lieu of any source.<\/p>\n
\nNow, why does this cause a reboot on some machines?<\/p>\n
\nFrom looking at a few different boards I have seen a few devices id’s used.<\/p>\n
\nvid_0c45\/pid_62f1<\/strong> – (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)<\/p>\n
\nhttp:\/\/www.beyondlogic.org\/uClinux\/bflt.htm<\/a> – bFLT file format details.
\nhttp:\/\/www.garykessler.net\/library\/file_sigs.html<\/a> – Common file format headers
\nhttp:\/\/www.openwiz.org\/wiki\/BWFWTools_Release<\/a> – bFLT unzip and other tools
\nhttp:\/\/www.hex-rays.com<\/a> – IDA Pro and Hex-Ray ARM Decompiler
\nhttp:\/\/www.sigmaplayer.com\/filebase.php?d=1&id=13&c_old=5&what=c&page=1<\/a> – Arm Decompiler
\nhttp:\/\/www.ideasonboard.org\/uvc\/<\/a>
\nhttp:\/\/read.pudn.com\/downloads127\/sourcecode\/unix_linux\/539050\/zc030x\/zc030x_cameras.c__.htm<\/a>
\nhttp:\/\/www.hackchina.com\/r\/54654\/zc030x_i2c.c__html<\/a>
\nhttp:\/\/linux.downloadatoz.com\/linux-kernel-webcams-driver-gspca-spca5xx\/<\/a>
\nhttp:\/\/ww2.cs.fsu.edu\/~rosentha\/linux\/2.6.26.5\/docs\/video4linux\/sn9c102.txt<\/a><\/p>\n