CBX

Did a search and if we're talking about a constant multiplied by some date fields I have to say that's pretty poor security. At least Hikvision actually use the serial so the unlock code is tied to your device as well as the date - and this doesn't work via an exposed tcp 80 port. The algo is also more complex (though obviously breakable).

Youtube vid of official reset procedure:

Hi All You may be aware that imported Hikvision cameras show the day of the week in a non English language that I am going to refer to as Chinese (though I know that is not it's proper name). For some this doesn't matter, just ignore the sqiggles, or turn off day of the week. For me and some others, we would prefer everything in English. There is a language flag set at least once in the flash which is not changed by firmware updates. You can see which yours is set to with this command: VAR=`dd if=/dev/mtd5ro skip=1620 bs=1 count=1 2>/dev/null` ; if [ $VAR == $'\002' ]; then echo Chinese ; elif [ $VAR == $'\001' ]; then echo English ; else echo Unknown; fi Changing the flash is optimal, but dangerous. Therefore, I've made a patch to the 5.1 davinci program that does all the cameras functions, and doesn't present this risk. This might work on < 5.1 firmware, but I've not tested this. I ACCEPT NO RESPONSIBILITY FOR THE CONSEQUENCES OF YOU APPLYING THIS CHANGE WHICH YOU DO AT YOUR OWN RISK. IF YOU BREAK YOUR CAMERA, YOUR CROPS FAIL TO GROW OR YOUR CAMERA ROBOTICALLY TRANSFORMS INTO A DECEPTICON AND TAKES OVER THE WORLD DO NOT BLAME ME. Right, firstly you need to get your davinci binary off your camera. You can do this via FTP, CIFS, NFS, SD card etc. I'll use NFS. Telnet into your camera (enable first if needed). # cp /dav/davinci.tar.gz /mnt/nfs00 I would recommend keep this original just in case. Open the file and extract davinci (on Windows winrar would work). root@rl70:~# mv davinci.tar.gz davinci.tar.gz.original root@rl70:~# tar zvfx davinci.tar.gz.original davinci root@rl70:~# md5sum davinci 22ebe5d2eb30af43d030122138ee2f5f davinci Use a hex editor (e.g. HxD) to search for the following bytes in davinci. 8a 30 dd e5 38 a0 9d e5 53 90 c4 e5 14 90 9d e5 There should only be one match at 0x001738b0. Change 38 a0 9d e5 to 01 a0 a0 e3 8a 30 dd e5 01 a0 a0 e3 53 90 c4 e5 14 90 9d e5 Save. You can verify the md5sum matches the below if you want to be sure you made the change correctly. root@rl70:# md5sum davinci e3b54d9de5ce40edfcf47f998935e541 davinci Create new davinci.tar.gz (keep the original) root@rl70:/# tar -c davinci | gzip > davinci.tar.gz You should get a file around 4.4Mb bytes in size. It's worth checking this, and that it contains a 9.9Mb davinci file because if you've messed up you will stop your camera booting and will need to recover using TFTP. Once you are sure all is well, overwrite /dav/davinci.tar.gz on your camera with this new davinci.tar.gz. Reboot ! Please post how you get on, and if all well an OK or similar even if others have already done this. Be interesting to see how many people actually use this patch. NOTE Hikvision could if they wanted block this in future firmware updates, or even detect this change (though you could replace the original davinci.tar.gz before upgrading). I doubt they will care but what do I know.

Thanks for the positive feedback all.

Due to the mounting number of patches I've applied to the davinci binary (to make it NAS server for other cameras, SD card improvements, NFS enhancements etc), I've changed to a patch in memory solution for each patch which might be easier for people. # Day of week patch for HEX in 01 a0 a0 e3; do echo -n -e \\x$HEX done | dd of=/home/davinci seek=1521844 bs=1 conv=notrunc This needs to be added in a script called from /dav/initrun.sh, or in /dav/initrun.sh itself near the bottom. When I make changes, I like to add in a safety window where the change won't take effect if the code is being run at 50 -59 secs past the minute. That way if you stop the camera booting you just have to power it on at the right time to get back in, rather than resorting to TFTP recovery. Direct example using safety window (excerpt bottom of /dav/initrun.sh): # Day of week patch [ `date +%S` -lt 50 ] && { for HEX in 01 a0 a0 e3; do echo -n -e \\x$HEX done | dd of=/home/davinci seek=1521844 bs=1 conv=notrunc } # End of patch #Original script if [ -f "/home/usage232" ]; then tar -zx -f /dav/IEfile.tar.gz -C /home echo "IEfile uncompressed." /home/davinci else /home/davinci& fi Direct example without safety window: # Day of week patch for HEX in 01 a0 a0 e3; do echo -n -e \\x$HEX done | dd of=/home/davinci seek=1521844 bs=1 conv=notrunc # End of patch # Original script if [ -f "/home/usage232" ]; then tar -zx -f /dav/IEfile.tar.gz -C /home echo "IEfile uncompressed." /home/davinci else /home/davinci& fi This way no need to change /dav/davinci.tar.gz as it's patched in memory before being run. More than happy for someone to write a firmware flash solution instead

Has this patch actually been used by anyone? If not I wasted a load of time writing all that up!

You're welcome Glad you got it working - well done

I'm glad Chrome and debugging helped. So not a network connectivity issue then. On 5.1, there are email options such as authentication, enable SSL and sender address to play with. i would try sender address camera@102.102.102.102 where 102.102.102.102 is your public IP address. Yahoo may consider you are trying to spoof an email address otherwsie. Though authentication should resolve that, but you might need to set the sender address as the same as your yahoo account. Or a different email provider.

I'm saying there is complexity depending on a variety of factors. Both in terms of changing the values in the flash memory correctly, and the ramifications of doing so. You may change the flash memory only to find it fails checksum at bootloader stage, the kerlel load or davinci load. Then your camera may not boot, and TFTP may or may not be an option. I'm not saying it can't be done, but I am sounding a note of caution. If I started putting up commands I think may work someone may brick their camera - I'm not going to do that. Even if it's done correctly, if Hikvision take exception they could detect this upon future firmware upgrades and do who knows what. I've no idea if they care or not. But good luck to anyone who wants to take this on!

Sorry for not being clear before. Yes the filename, time stamp and language flag in the firmware files are different, and they are hosted in different places. But the content of the firmware (filesystems etc) are identical, and offer no advantage over another. Thus there is no reason to flash different versions because the are not different in any meaningful way - at least not unless Hikvision start to release different software for the different language zones.

Haven't tested that as it wasn'y my goal - doubt it. But it's worth noting that the EU, US and Chinese firmware are all identical so there's no compelling reason to flash with a different version.

Now posted. Also, just to let you know the language flag also seems to be set in mtd6 also. Specifically, VAR=`dd if=/dev/mtd6ro skip=16 bs=1 count=1 2>/dev/null` ; if [ $VAR == $'\002' ]; then echo Chinese ; elif [ $VAR == $'\001' ]; then echo English ; else echo Unknown; fi As to how to write this to flash, I think I'll keep quiet on that. If you don't know how, you shouldn't be doing it

Thanks Now we seem to have confirmed things I hope to post today. Will do so in a new thread as this one has wandered a bit

I've debugged the binary while it is running on the camera. Unfortunately that mostly means dealing with raw ASM rather than nice C The output I posted is from strace. I'm currently playing with sending the camera different commands to see whats possible. root@rl70:/tmp# echo -n -e '\x00\x00\x00\x0c\x00\x00\x00\x00\x00\x00\x00\x00' | nc 192.168.0.202 7001 Start at 2014-02-12 21:08:08 Serial NO :<removed> V5.1.0 build 131202 hardwareVersion = 0x0 hardWareExtVersion = 0x0 ..snip root@rl70:/tmp# echo -n -e '\x00\x00\x00\x0c\x00\x00\x00\x0c\x00\x00\x00\x00' | nc 192.168.0.202 7001 Interface : eth0 IP address : 192.168.0.202 Subnet mask: 255.255.255.0 IPv6 address: <removed> IPv6 Subnet mask: ffff:ffff:ffff:ffff:: Just to see what is possible outside of the commands already in the /bin partition. I'm curious Yes, it would be better to change the language flag in the flash, and the commands for doing so are already on the camera. Then no need to change davinci. But I won't be doing that as I don't know what the ramifications are. To anyone that wants to try I would advise you nanddump all mtds to a server first and have access to the bootloader via UART just in case. As you can see from the command I posted the language flag looks to be at 0x0654 in /dev/mtd5. Overwriting it with 0x01 may work, not work or brick your camera. I'll stick with my davinci change as that won't kill that camera

Interesting - never read that thread Good to hear this patch is actually wanted by people (though I did it for my own amusement more than anything). prtHardInfo actually only connects to the davinci binary on port 7001 and runs a command. This is like what setDebug does also and is indicative of how davinci does everything. connect(3, {sa_family=AF_INET, sin_port=htons(7001), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 write(3, "\0\0\0\f\0\0\0\0\0\0\0\0", 12) = 12 recv(3, "Start at 2014-02-12 12:38:55\nSer"..., 4096, 0) = 363 On my Chinese 2732 camera, reading mtd5 gives: # VAR=`dd if=/dev/mtd5ro skip=1620 bs=1 count=1 2>/dev/null` ; if [ $VAR == $'\002' ]; then echo Chinese ; elif [ $VAR == $'\001' ]; then echo English ; else echo Unknown; fi Chinese i.e. language code 2 Whereas my patched davinci binary responds with a language code of 1 when queried by prtHardInfo: # prtHardInfo Start at 2014-02-12 20:15:41 Serial NO :<removed> V5.1.0 build 131202 hardwareVersion = 0x0 hardWareExtVersion = 0x0 encodeChans = 1 decodeChans = 1 alarmInNums = 1 alarmOutNums = 1 ataCtrlNums = 0 flashChipNums = 0 ramSize = 0x4000000 networksNums = 1 language = 1 devType = 38926 SD status = -1 (0:noraml;none-0:timeout) Funny how they've spelt normal Anyway, that's a posivitive sign that the code change I made in davinci is correct, if it's responding to Hikvision's own tools that the language code is English rather than the actual Chinese flag in the flash.

For reference it looks like the language flag is set in mtd5 (though it may be other locations also). Could a few people run this on their cameras and confirm the output matches their camera language please? VAR=`dd if=/dev/mtd5ro skip=1620 bs=1 count=1 2>/dev/null` ; if [ $VAR == $'\002' ]; then echo Chinese ; elif [ $VAR == $'\001' ]; then echo English ; else echo Unknown; fi Assuming all is as expected I'll post the needed change to the davinci binary.

It's the way Linux is anyway - on my Ubuntu server: root@rl70:~# uname -v #41-Ubuntu SMP Thu Jun 14 16:45:14 UTC 2012 root@rl70:~# strings `which date` | grep DAY SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY YESTERDAY TODAY Though of course a proper Linux installation will have options to change languages/codepages etc. And on embedded systems things tend to get compiled together into as fewer files as possible to improve performance.

The ONVIF standards are all online. You can create a script (bash, php, perl etc) to connect to your camera and subscribe to ONVIF alerts via http. Yes, more than one device can connect to the ONVIF handler on your camera.

Not sure what you mean about a lot of work - do you mean me sending 2 emails to them or the day of the week issue? If the latter I've already resolved that without the kernel source. I posted the emails I sent as someone suggested a GPL request which I'd already done. I was primiarily interested in the kernel source as I wanted to turn my 2732 into a NAS server for my 2032 so they can record to the same SD card (the 2032 doesn't have an SD card slot), and I don't need to have a power hungry NAS/PC server with hard disk on all the time. Just to 2 cameras and the switch is all that is needed. That means I needed to compile kernel modules etc. As it turned out I managed to do by getting another Ambarella 2.6.8 linux kernel source released by a company of a different product who actually do abide by GPL V2 conditions. The point is they should release the linux kernel sources upon request. Whether in China or no they accepted the license conditions by putting linux on their products. They should abide by that license irrespective of any enforcement issues. It should be noted that they have companies in other legal jurisdictions such as EU and US. They haven't refused as of yet, but not yet provided them so we'll see.

I've already made a request: Had some email exchanges but not got anywhere yet. By all means others make a GPL request (mine was via Hikvision EU) Though a GPL request won't provide the source to the main camera binary davinci anyway. But I have a solution I'll post soon - I reversed the binary to fix the days of the week language issue.

I've not seen any evidance that OTP flash areas would be present, particularly as there is no real device security to speak of. You don't need to change the firmware before flashing, just the davinci binary on the file system. I could change the language values in the flash, but for all I know there are checksums which need to be changed and I would prefer to simply change a binary than risk bricking the camera.

i would monitor the camera via ONVIF with a script to trigger actions when motion is detected. Then you can control what actions to take (e.g. SMS) and how often they are sent. I use this to optionally show alerts on my TV, XBMC, mute the volume, beep speaker when motion is detected etc. You can write bash scripts on the camera but it doesn't have perl, php etc on it. You could cross compile these and store them on your NAS or SD card though. If you have a server I would run the montior script on that instead. Email alerts are handled by the camera control binary davinci (which does pretty much everything).

It's not that simple. Everything is contained in a large binary file which has both English and Chinese day names contained within it along with everything else needed to control the camera. Also, you don't need to wait to look at the filesystem or the davinci binary (in the /dav folder). You can download the firmware and extract it if you want to play before your cams arrive (I did). buellwinkle: No, this is unlikely to permit flashing different zone firmware, but there is no point in doing this anyway as they are all the same. Lapheus: As far as I know German is not in the davinci binary, but you could overwrite the English day of week array string with a hex editor. There are a few strings - you'll have to do a bit of testing to find out which one you need to change. Doing other camera dev at the moment - will post day of week changes once done a bit more testing.

I'd echo what was said above - Chrome should also work with the ActiveX controls You could also try the free ONVIF Device Manager which doesn't use ActiveX. If you are happy with linux, you could also telnet in to the camera (enable first if needed). Then try ftpput -P 25 . It will try to upload a ftp via FTP to your SMTP email server which obviously won't work (and is a little messy) - but it will show if it was able to connect to tcp port 25 which may be useful if you are network testing. Below port 25 works but 26 doesn't as an example: # ftpput 192.168.0.6 -P 25 ftpput ftpput: unexpected server response to USER: 502 5.5.2 Error: command not recognized # ftpput 192.168.0.6 -P 26 ftpput ftpput: can't connect to remote host (192.168.0.6): Connection refused # This shows up in my postfix log: Feb 7 19:30:40 rl70 postfix/smtpd[5796]: connect from ipcam1[192.168.0.201] Feb 7 19:30:40 rl70 postfix/smtpd[5796]: lost connection after UNKNOWN from ipcam1[192.168.0.201] Feb 7 19:30:40 rl70 postfix/smtpd[5796]: disconnect from ipcam1[192.168.0.201] You could also check out my thread on enabling debugging on the camera.

One share on one partition always seems to work. Multiple shares on one partition doesn't always (if ever?) work. I know this is annoying.