CBX

Many of you will likely know of the current security issue involving openssl and an exploit that potentially permits hackers to sniff bits of memory from your server - or IP camera in this case. I did a test on my 5.10 cameras to see if they are vulnerable, and the version of openssl appears to be 1.0.0a which is so old it was before the vulnerability was accidentally introduced. Testing didn't show the exploit to work which is good news user@rl70:/tmp$ ./hb-test.py -p 443 -f dump 192.168.0.201 [+] Connecting... [+] Sending ClientHello for TLSv1.0 [+] Waiting for Server Hello... [+] Reveiced ServerHello for TLSv1.0 [+] Sending heartbeat request... [-] Unexpected EOF (header) Though of course if the openssl version is 1.0.0a that has other issues

If they can get into the web interface with admin rights, a hacker can do what they want, as a) the system software can be changed b) port numbers can be reconfigured. They can even brick the camera if they feel like it. But as I say, the SSL vulnerability (private server key in this case not Heartbleed) relies on sniffing data which is hard in most situations. Still doesn't mean server keys shouldn't be generated for each camera though (the public cert is!).

I'm not sure how the private keys are generated, or if they are hardcoded anyway. Might look into this at some point. EDIT: Actually a quick look shows the server private key is the same for my 2 cameras (bad) # md5sum servkey.pem 49a000398957d3029ba1c15872c0eed5 servkey.pem This isn't very good practice. I suppose you could generate your own but most people aren't going to do that (nor be aware of the need). As to whether it's important depends on whether hackers can exploit it, and what the ramifications are if they do. Probably more risk to corperations (e.g. theft, corp espianage etc).

LOL... You really do enjoy playing with the guts of your Hikvision products Well it could be quite serious if you are exposing your camera web interface to the Internet!

Though I'm not publishing my code at present I can say I based it on the below php ONVIF class written by someone else: http://www.phpclasses.org/package/7996-PHP-Control-network-video-devices-with-ONVIF-protocol.html He's got a fair few methods for PTZ operations which do not apply to me, so you can always rip those out. Also I'd recommend wireshark to find out the XML comms between your camera and the control app!

I wrote a script to automatically extract my motion detection videos from the cameras, but given that they have a 5 second pre-record period, it gets annoying to review all of them when some of them are unavoidably weather or due to car headlights etc. So I've written a script to use ffmpeg/avconv to capture a still from 8 secs in each motion detection event, and then create a video of these stills (each snapshot displayed for 2 seconds each), and then I only need to look at 1 vid per camera per day to get a sense of what happened. I have these linked to an XBMC keyboard shortcut and can then always review the full unedited motion detection video specific to the situation if needed. e.g. (create still 8 seconds in): /usr/bin/avconv -i /mnt/hdd/sd1/12-04-14/17_32___12-04-14_17_32_41_to_12-04-14_17_32_57.mp4 -r 25.0 -frames:v 1 -ss 00:00:08 /mnt/hdd/sd1/_motpic/12-04-14/17_32___12-04-14_17_32_41_to_12-04-14_17_32_57.jpg After linking the snapshot pics of the action to a sequential file list, create overview video: /usr/bin/avconv -r 1/2 -y -i /tmp/4641/temp%03d.jpg -r 30 /mnt/hdd/sd1/_motpic/12-04-14/12-04-14.mp4 Then look at the created summary file (e.g. /mnt/hdd/sd1/_motpi/12-04-14/12-04-14.mp4) and you know what happened that day, if it requires your attention and it will only take 20 seconds for 10 events (or 10 seconds if the display per snapshot is 1 second etc).

I had to recently set DST as here in the UK we've just gone to BST (British Summer Time). Set DST on the cameras so the OSD is correct, but couldn't understand why my automated video and picture extract script was producing filenames an hour out (their filenames include the time). Hikvision uses linux (POSIX) timestamps which shouldn't care about timezone, but they haven't implemented it correctly in the binary files created to store videos and pictures, such that it's not seconds since 1 Jan 1970 UTC (ignoring leap seconds) but rather what timezone you set on your camera. It could be I'm wrong re the above as I live in a country either UTC+0 or UTC+1 so it's less obvious, but it's the conclusion I've come to. As such I've had to hard code the following into my scripts: //Override possible BST as Hikvision stores timestamps wrongly date_default_timezone_set('UTC'); Annoying and while the average user won't come across this thought it was worth putting here. If I'm wrong please let me know

A different but related issue; I had to recently set DST as here in the UK we've just gone to BST (British Summer Time). Set DST on the cameras so the OSD is correct, but couldn't understand why my automated video and picture extract script was producing filenames an hour out (their filenames include the time). Hikvision uses linux (POSIX) timestamps which shouldn't care about timezone, but they haven't implemented it correctly in the binary files created to store videos and pictures, such that it's not seconds since 1 Jan 1970 UTC (ignoring leap seconds) but rather what timezone you set on your camera. It could be I'm wrong re the above as I live in a country either UTC+0 or UTC+1 so it's less obvious, but it's the conclusion I've come to. As such I've had to hard code the following into my scripts: //Override possible BST as Hikvision stores timestamps wrongly date_default_timezone_set('UTC'); Annoying and while the average user won't come across this thought it was worth putting here. If I'm wrong please let me know

Really? I'm not saying you are wrong, but I just find that hard to believe. Even if you set the IP and mask to your network details it doesn't work? Companies often use 10/8 so I would not expect this to be incompatible. Most people use something in the RFC 1918 192.168.0.0/16 range (e.g. 192.168.0.0/24) as opposed to 10.0.0.0/8 but I don't see why the latter wouldn't work. Underlying linux won't mind I'm sure. Sure - 192.0.0.0/24 initially, but you might want to check that 10/8 doesn't work.

I would try the Hikvision SADP tool or an ONVIF product to detect your camera whatever its IP. You could also try wireshark or something similar to listen to the network while you power it on (at boot time it should always be on 192.0.0.64 and look for 192.0.0.128 however it's configured). If there's nothing, and you are happy the network cable etc are all good, then really I think your options are return it or get access to the bootloader via UART/RS232. If it's under warrenty and you got it from somewhere you are happy to send it back to, the former option would likely be best.

buellwinkle is right - the files are all the same. It's the settings stored in the flash that matter which aren't touched by the firmware (at present).

You appear to understand the marketplace forces at work whereas I don't. So let's we flash the firmware with a new language code, and they decide to look for and detect that in a future firmware update. What's to stop them disabling or bricking the camera at that point? I'm not saying they would do this, but I'm a 1s and 0s linux sysadmin guy, not a business man

I've not tested this, but based on the windows writeup beullwinkle has posted, the linux patch in memory solution would be: # 5.1.2 language fix for HEX in 01 a0 a0 e3; do echo -n -e \\x$HEX done | dd of=/home/davinci seek=1536408 bs=1 conv=notrunc

Great Windows friendly writeup of my language patch by buellwinkle here: http://www.cctvforum.com/viewtopic.php?f=19&t=40240

Thanks to buellwinkle for that write up - I did the patch for me, but glad my patch is actually useful to some others too I didn't post the binary as you are posting copyrighted code, but hopefully Hikvision won't mind I don't know why they don't include an option to have day of the week in English on all cams so what do I know! The problem with changing the flash, aside from the technicial difficulties, is that it would be detected in future firmware updates if Hikvision were so minded to check. They could do anything they wanted to your camera (up to and including disabling it). Without knowing their motivation for having the day of the week limitation, and the recent added issue of all menus in Chinese (which seems an escalation of their part), I'd be reluctant to make permanent changes. Has anyone asked them why they do this? For reference the original patch info and other tech notes is here: http://www.cctvforum.com/viewtopic.php?f=19&t=39874

[lie]I completely intended that this would happen when I developed the patch[/lie]

Oh right - didn't know that. Do you mean that me patch changes the menus also, or that such a patch is needed?

It's only the day of the week in Chinese - you can always turn it off which is what some people do. I came up with the patch as I didn't want to do that but I wouldn't be worried about future firmware releases.

Yes - flashing replaces davinci so any changes you make to it would need to be done again.

The patch is designed for 5.1 so might need some alteration on 5.12 (probably just a different place which you could search for with a hex editor). To put it back, place it on your server share and copy it into /dav within telnet on the camera. Or you could put it on an SD card if applicable for your camera. Or use ftpget. If this all sounds too technical - don't attempt it

You either need to change values in flash (which as far as I know no one has attempted due to the risk to your camera) or use my patch to alter a few bytes within the camera control app davinci.

I don't think the Hikvisions support that. You could probably trigger jpg capture for motion while recording video continously. At least that would flag when motion was happening. Or you might be able to script a solution by waiting for a motion detection event, and then telling the camera to stop continous and start motion. Then set them back again. It's maybe more hassle than you are prepared for though.

ssh (dropbear) download zlib-1.2.8.tar.gz, cross compile dropload dropbear-2014.63.tar.bz2, cross compile using zlib tar up, and copy to camera. Create /dav/opt/dropbear/authorized_keys if you are using keys to authenticate for passwordless access. # cat /dav/opt/dropbear.sh mkdir /home/dropbear /dav/opt/busybox tar vxfj /dav/opt/dropbear/dropbear.tar.bz2 -C /home ln -s /home/dropbear/dropbearkey /usr/bin ln -s /home/dropbear/dbclient /usr/bin/ssh ln -s /home/dropbear/dropbear /usr/sbin ln -s /home/dropbear/dropbearconvert /usr/bin ln -s /dav/opt/dropbear /etc ln -s /home/dropbear/libz.so.1.2.8 /lib/libz.so.1 ln -s /home/dropbear/scp /usr/bin ln -s /home/dropbear/dbclient /usr/bin chmod 700 /root mkdir /root/.ssh ln -s /dav/opt/dropbear/authorized_keys /root/.ssh /usr/sbin/dropbear -R -P Test passwordless scp and login: root@rl70:/tmp# echo test > testfile root@rl70:/tmp# scp testfile ipcam1:/tmp testfile 100% 5 0.0KB/s 00:00 root@rl70:~# ssh ipcam1 BusyBox v1.19.3 (2013-11-01 10:10:26 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. # uname -a Linux Hikvision 2.6.38.8 #12 PREEMPT Thu Nov 14 12:04:07 CST 2013 armv6l GNU/Linux # cat /tmp/testfile test # scp /dav/davinci.tar.gz 192.168.0.6:/tmp root@192.168.0.6's password: Logging mkdir /var/log touch /var/log/lastlog touch /var/log/wtmp /dav/opt/busybox hostname ipcam1 /dav/opt/busybox syslogd /dav/opt/busybox klogd # last root pts/0 192.168.0.6 Wed Mar 12 12:07 still logged in root pts/0 192.168.0.6 Wed Mar 12 12:04 - 12:07 (0+00:02) wtmp begins Wed Mar 12 12:04:58 2014 # tail /var/log/messages -n 2 Mar 12 12:07:10 ipcam1 authpriv.info dropbear[3395]: Child connection from 192.168.0.6:34655 Mar 12 12:07:12 ipcam1 authpriv.notice dropbear[3395]: Pubkey auth succeeded for 'root' with key md5 5e:c8:dd:5e:26:0b:28:f<removed> from 192.168.0.6:34655 Disable telnet once tested.

Thanks I need to up date it with some more logging info, and putting ssh on it some time. Yes - I wrote that and the video extract scripts. I'm still doing some dev on them (adding the picture event types for example). When they are complete I'll think about it

If you don't mind testing the codes generated, then I'd like a DVR and NVR serial please. The code I sent was assuming an IP cam, but now I've started to actually code a generation algo, it looks like the DVR and IPcam algos are the same (though they don't look like it when looking at the ASM). Hopefully the one I sent you worked. Thanks