Yes, I've bought this crappy webcam... On paper, it seems to have really nice features, but in reality there are lots of bugs and not everything works as expected. So if you can buy a Foscam instead go for it, but that's not the same price :-)

If you're stuck with this webcam, you'll find a few workarounds below!

My firmware versions are 67.2.2.166/9.0.4.60, so some things may not be usable on your IP cam if your firmware differs.

You can also flash the firmware version 67.2.2.172/9.0.4.67 but you will loose telnet access, although it's easy to re-enable telnetd (see below).

General information

There's a cheap Ralink MIPS CPU running at 360Mhz, with 32MB of RAM.

# cat /proc/version
Linux version 2.6.21 (root@mailzxh-desktop) (gcc version 3.4.2) #653 Tue Nov 20 15:22:24 CST 2012
# cat /proc/cpuinfo 
system type             : Ralink SoC
processor               : 0
cpu model               : MIPS 24K V4.12
BogoMIPS                : 239.10
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : yes
hardware watchpoint     : yes
ASEs implemented        : mips16 dsp
VCED exceptions         : not available
VCEI exceptions         : not available

We have a telnet access with user root and password=123456 so we can start to play. The telnet daemon and a few other ones are started by the /system/init/ipcam.sh script:

telnetd
/system/system/bin/daemon.v5.7 &
/system/system/bin/cmd_thread &
/system/system/bin/gmail_thread &

A few interesting ports are listening:

# netstat -nap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:99              0.0.0.0:*               LISTEN      147/encoder
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      28/telnetd
tcp        0      0 0.0.0.0:8600            0.0.0.0:*               LISTEN      29/daemon.v5.7
udp      236      0 127.0.0.1:8832          0.0.0.0:*                           147/encoder
udp        0      0 0.0.0.0:3074            0.0.0.0:*                           147/encoder
udp        0      0 0.0.0.0:3076            0.0.0.0:*                           147/encoder
udp        0      0 127.0.0.1:6666          0.0.0.0:*                           147/encoder
udp        0      0 0.0.0.0:8600            0.0.0.0:*                           29/daemon.v5.7
udp        0      0 127.0.0.1:9123          0.0.0.0:*                           29/daemon.v5.7
udp        0      0 127.0.0.1:9124          0.0.0.0:*                           147/encoder
udp        0      0 0.0.0.0:32108           0.0.0.0:*                           147/encoder
udp        0      0 127.0.0.1:8812          0.0.0.0:*                           31/gmail_thread
udp        0      0 127.0.0.1:8813          0.0.0.0:*                           147/encoder
udp        0      0 127.0.0.1:8822          0.0.0.0:*                           147/encoder
udp        0      0 127.0.0.1:8831          0.0.0.0:*                           30/cmd_thread

NMAP gives the following details:

PORT     STATE SERVICE    VERSION
23/tcp   open  telnet     BusyBox telnetd
99/tcp   open  http       GoAhead-Webs httpd
8600/tcp open  tcpwrapped
3074/udp  open|filtered unknown
3075/udp  open|filtered orbix-locator
8600/udp  open|filtered unknown
32108/udp open|filtered unknown

Ok, so the encoder process is the web server. No idea about the usage of tcp port 8600 and all the other UDP ports...

Seems to be based on the "GoAhead" web server. They modified it because of various UDP ports listening.

Moreover the /system partition containing important binaries is write-enabled so the temptation to modify the firmware directly is high, but I need to do a backup first!

http://www.wanscam.com/xiazai/sdk/JW-SDK-API.zip

Fix: using a simple SMTP server for mail alerts

Wanscam is using ssmtp for mail sending. The binary is in /system/system/bin/ssmtp, and the configuration file is in /tmp/ssmtp.conf. This configuration file is generated after each reboot or when you change the email parameters, if you don't this file that's because you've entered "non-standart" parameters in the WebUI.

Well, if you tried to use a simple SMTP server without SSL/TLS and Authentication, you found that motion email alerts do not work anymore.

The trick to use it is: 1- enable SMTP authentication in 'Mail service settings' 2- but set the SMTP user to '#buggyfirmware' 3- leave the password blank

This way ssmtp.conf is properly generated:

# cat /tmp/ssmtp.conf
root=youremail@example.com
mailhub=smtp.example.com:25
rewriteDomain=
hostname=smtp.example.com:25
AuthUser=#buggyfirmware
AuthPass=
FromLineOverride=YES

Regarding this bug, the support said that only mail servers provided in the list are supported, custom mail servers cannot be used !

Bug: Mail alerts with GMail

I did not manage to get motion alerts working with GMail, with my firmware... (Only to a custom smtp server with the trick above).

Bug: Cannot set default PTZ position

On the "PTZ Settings" page, the submit button does not work with Chrome or Firefox. Starting a Javascipt console confirms a bug, you'll see the following error when clicking on the submit button:

Uncaught ReferenceError: set_ptz is not defined

Playing with the set_misc.cgi page does not seem to work either. I tried with "http://ip:99/set_misc.cgi?ptz_preset=1&loginuse=admin&loginpas=YOURPASS"

If you have another idea...let me know! That's an annoying bug since the webcam randomly reboots, and then your default surveilance position is lost!

Enabling telnetd

After upgrading to 67.2.2.172/9.0.4.6, I lost the telnet access so it was time to customize the update. The flash file format is a modified zip format not even signed so that's easy to put what you want on the webcam filesystem. Here's my update script for the system part:

#!/bin/bash

FILE=67.2.2.173.bin
zip -r system.zip system
echo -ne "wifi-camera-sys-qetyipadgjlzcbmn">$F
perl -e '$s = -s "system.zip" ;print pack("l", $s);'>>$F
cat system.zip >>$F
echo -ne "wifi-camera-end-nvxkhfsouteqzhpo">>$F

To enable telnetd, I modified /system/init/ipcam.sh this way:

#telnetd
/system/system/bin/daemon.v5.7 &
/system/system/bin/cmd_thread &
/system/system/bin/gmail_thread &
sleep 30
telnetd

So I moved telnetd near the end of the startup script, after a little delay. Indeed, when I lost the telnet access, I tried to connect to port 23 in a loop, and found that I could connect during a few seconds before the connexion was closed. After a few greps in the binaries, I found that the 'encoder' process was responsible for a 'killall telnetd'. In the same binary, you will find the string 'telnetd &' so there must be another backdoor to enable telnetd. A little RE is needed here. Anyway the sleep 30, workaround is sufficient.

You can find the modified firmware with telnet access here.

Security vulnerability: remote access, UPNP cannot be disabled

I could not disable the UPNP client on the Wanscan, so if your router/ADSL modem is UPNP compatible, it will open the port 99 to your webcam. I hope that you changed the default wanscam password, or anybody will be able to spy on you... yes that's one of many little suprises found in numerous cheap webcams...

The only way to be safe is to disable UPNP on your modem/router.

Security vulnerability: authentication

Digest authentication is enabled but the login and passwd are passed on every URL, nullifying the benefits of digest auth.

For example the following requests are done:

GET http://ip:99/set_alias.cgi?alias=IPCAM&next_url=alias.htm&loginuse=admin&loginpas=xxx

Security vulnerability: Stored XSS + CSRF

I found a stored XSS with the set_alias.cgi function. Since there is no CSRF protection on this webcam, somebody could force a victim to store an XSS on the webcam, and take control of the victim's web browser.

http://ip:99/set_alias.cgi?alias=%22;alert(1);var%20a=%22&next_url=alias.htm&loginuse=admin&loginpas=xxx

Because of the CSRF vulnerability, a firmware upgrade could also be started by a hacker. The hacker's firmware could implement more backdoors since the firmware file format is not signed and easy to RE. Anyway, if the webcam telnet port is opened on the Internet, then your network is already fully compromised :-)