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 :-)
Speak your mind: