mroek

It's only open because the front assembly has been disconnected. You can see the connector with the black wires in some of the other pictures.

As far as I know, the mtd layer should handle the necessary operations (erase before write etc) if the flash is accessed through either the block or the character device for the partition. If this is true, then using dd to modify data within the partition should work. Are you saying that this is not the case here? If so, the only other option I can see would be nanddump and nandwrite.

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. No, they aren't identical, per se. There is a language indicator also in the firmware file, which will prevent flashing a different version through the web interface. TFTP-flashing still works, although slightly more cumbersome. That's why it would be even better if the language indicator location(s) in the flash could be changed permanently. I'm quite sure this is fully possible, but experimenting with it is obviously risky.

Great info, good job! I can fully understand that you don't want to try modifying the flash partition, I'm also reluctant. My cameras are all installed outside my house, and taking one down to experiment with this is not something I have the time to at the moment. However, if there is some brave soul that would try it, it would certainly be interesting. If there is in fact a simple way to permanently turn a Chinese camera into a US/European one, that would be good news. I gather it should be possible to change this one byte in the mtd by using the dd-command to write to the flash instead of reading. That's what you meant, right? When will you publish the required changes to the davinci binary?

I'm curious, have you actually disassembled any of the binaries, given that you present what looks like C source code for the calls performed by prtHardInfo? While patching the davinci binary is probably a fully useable solution, it would be even more interesting to modify the actual language code in the flash, if that would permanently transform a Chinese camera to a European/US counterpart. That would then also allow for using the firmware updates posted to the US/European sites directly from the web interface. Their spelling isn't the best, but trust me, they're far better than many other Chinese manufacturers.

Appears to be accurate on my Chinese cameras, at least. I also did some digging into this at some point: viewtopic.php?f=19&t=37430&p=229583&hilit=chinese#p229583 As you can see, the command prtHardInfo outputs the same language value that you found on mtd5ro, and I'd be surprised if prtHardInfo doesn't actually just present the info from this partition in a human-readable format. In other words, it probably takes the language value from the exact same location that you found.

Works fine on my computer. Have only tried with Firefox, though. You did remember to clear the browser cache (CTRL+F5), right?

I'm just posting this in the hope that it might be useful for others: I'm using the Hikvision 3MP bullets and Synology Surveillance Station on my NAS. SS has a lot more flaws and quirks than I care for, but as long as I already have the NAS, it is the easy route. There is no native support for these cameras, so I have been using them in Onvif mode, which works. The downside is that you have to use the motion detection in SS, you can't use in-camera motion detection. This causes the NAS to spend quite a lot of CPU on motion detection, and also the motion detection options in SS leaves a lot to be desired. Then, almost by accident, I discovered that if I configure SS to talk to the cameras in PSIA-mode instead of ONVIF, it is actually possible to use in-camera motion detection in SS. This drops the CPU usage by a great deal, and you configure the motion detection sensitivity and masking area in the camera (which has a better method than the stupid way it is done in SS). While I haven't used this setup for more than a couple of hours yet, I have a good feeling that it is the better method. There is one minor downside, and that is that SS will reconfigure the camera device name to "SynoSurveillance" when you configure it from SS. However, you can just go back and rename it again from within the camera web interface afterwards.

Hi, During the night one of my HFW2100-cameras had gone wonky, and refused to supply any video stream. It was possible to get into the web interface, but no video stream there either, just some message (with a big font in the video window) in chinglish stating something along the lines of "resource limited". When trying to get into some of the other menus, popups with messages about "config read failed" appeared. My initial thought was that the internal flash memory had been corrupted, and since I saw that newer firmwares had appeared online (on this forum in the Dahua firmware thread), I tried upgrading the firmware (from the web interface). This seemed to work, at least the camera came back online with the new version, but unfortunately there were still error messages regarding the config. I then tried to reset the camera with the physical reset button on the back, which was a big mistake. The web interface is no longer available, but I can login via telnet. However, the connection is lost after a short while, probably because the camera crashes and goes into a reboot loop. I can see that it tries to start the main executable sonia, but I hink this is what kills it. This is the list of the running processes: # ps PID Uid VSZ Stat Command 1 root 2812 S init 2 root SW [posix_cpu_timer] 3 root SW [softirq-high/0] 4 root SW [softirq-timer/0] 5 root SW [softirq-net-tx/] 6 root SW [softirq-net-rx/] 7 root SW [softirq-block/0] 8 root SW [softirq-tasklet] 9 root SW [softirq-hrtimer] 10 root SW [softirq-rcu/0] 11 root SW< [desched/0] 12 root SW< [events/0] 13 root SW< [khelper] 14 root SW< [kthread] 26 root SW< [kblockd/0] 27 root SW< [cqueue/0] 28 root SW< [kseriod] 35 root SW< [khubd] 84 root SW [pdflush] 85 root SW [pdflush] 86 root SW< [kswapd0] 87 root SW< [aio/0] 88 root SW< [cifsoplockd] 89 root SW< [cifsdnotifyd] 686 root SW [mtdblockd] 692 root SW< [dm_spi.0] 774 root SWN [jffs2_gcd_mtd7] 778 root SWN [jffs2_gcd_mtd8] 819 root 2816 S /utils/telnetd 826 root SW< [motord] 830 root 2276 S /utils/upgraded 831 root 10348 S /utils/syshelper 120 964 root 2812 S /bin/sh /etc/init.d/appd 973 root 1596 S pppd 1005 root 2816 S /bin/sh 1006 root 2816 S -sh 1009 root 2816 R ps If I try to manually launch sonia, I can see that it fails with a segmentation fault: # /usr/bin/sonia [libdvr] libdvr.so Build on Dec 19 2012 at 10:36:51. [libdvr] SVN NUM: 4322. [libdvr] no new hwid scheme! 00:34:23|[libInfra] warn Some [ONVIF2.2] files are not commit to SVN server. It compied wtih local modified files. 00:34:23|[libInfra] info check include version:manager 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Component 81001 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Database 78701 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/ezutil 4497 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/gtest 42100 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Infra 94250 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Json 64221 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Lua 518 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Manager 95833 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Memory 63431 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Branches/P_Include_Ultimate_2011.05.09/NetProtocol 82093 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Pal 94690 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/RPCServer 82105 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Stream 80720 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Utils 70561 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Zlib 82304 00:34:23|[libInfra] info check include version:Infra 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Component 91309 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Infra 94250 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Memory 63431 00:34:23|[libInfra] info URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Utils 88482 00:34:23|[libInfra] error check include version failed 00:34:23|[libInfra] error manager URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Component 81001 00:34:23|[libInfra] error Infra URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Component 91309 00:34:23|[libInfra] error manager URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Utils 70561 00:34:23|[libInfra] error Infra URL: http://10.6.5.2/svnpl/Renascence/Include/Trunk/Utils 88482 00:34:23|[libInfra] error check include version failed, assert [libaudio] libaudio build @ Aug 4 2012 15:54:42 [libaudio] svn info:·¾¶: Trunk URL: http://10.6.5.2/svn/Camera_api/libaudio_DM365/Trunk °æ±¾¿â¸ù: http://10.6.5.2/svn/Camera_api °æ±¾¿â UUID: 83ec8bce-ee28-0410-b94f-c8a3b29becdd °æ±¾: 5569 ½ÚµãÖÖÀà: ?¼ ×îºóÐ?jÄ×÷Õß: wang_kefu ×îºóÐ?jI?: 5569 ×îºóÐ?jÄʱ¼ä: 2012-08-04 15:39:00 +0800 (Áù, 2012-08-04) [libaudio] FRAME_SIZE=1600 [libenc] =========libenc version @V0.06_HD@20100820 build time: Apr 17 2012:20:12:59======== [libenc] build options:tags2.0 SUP_MJEG 00:34:23|trace main( /usr/bin/sonia) 00:34:23|trace ******************app lib info****************** 00:34:23|[libInfra] info [*] Function 1.1.0.116752 Built in 2013/ 5/16 [*] 00:34:23|[libInfra] info [*] Function 1.1.0.116752 Built in 2013/ 5/16 [*] 00:34:23|[libInfra] info [*] Manager 1.0.0.105127 Built in 2013/ 3/ 9 [*] 00:34:23|[libInfra] info [*] Function 1.1.0.116752 Built in 2013/ 5/16 [*] 00:34:23|[libInfra] info [*] Storage 1.0.0.0 Built in 2013/ 5/17 [*] 00:34:23|[libInfra] info [*] Function 1.1.0.116752 Built in 2013/ 5/16 [*] 00:34:23|[libInfra] info [*] Function 1.1.0.116752 Built in 2013/ 5/16 [*] 00:34:23|trace ******************app lib info****************** 00:34:23|[libInfra] trace CThreadManager::CThreadManager()>>>>>>>>> 00:34:23|[libInfra] info [*] Infra 1.0.0.94251 Built in 2012/12/22 [*] 00:34:23|[libInfra] trace CThreadManager::CThreadManager()>>>>>>>>> 00:34:23|[libInfra] debug ThreadBody Enter name = NetFramework, id = 1011, prior = N64, stack = 0x406a1e24 00:34:23|[libInfra] debug ThreadBody Enter name = NetFramework, id = 1012, prior = N64, stack = 0x408a1e24 00:34:23|[libInfra] debug ThreadBody Enter name = NetFramework, id = 1013, prior = N64, stack = 0x40aa1e24 00:34:23|[libInfra] debug ThreadBody Enter name = NetFramework, id = 1014, prior = N64, stack = 0x40ca1e24 00:34:23|info R3Server Start @port[42323] 00:34:23|[Manager] trace CMagicBox::config '/var/tmp/pd/ProductDefinition' [libfvideo] ############: g_videoin_channels = 1 00:34:23|[libInfra] debug ThreadBody Enter name = TimerManager, id = 1015, prior = N1, stack = 0x40ffee24 [libdvr] info->deviceType:IPC-HFW2100 [libdvr] devalias:IPC-HFW2100 [libdvr] armrate = 270 [libdvr] @@@@ buf = TZC2LV05000081 [libdvr] thread_led_helper_hf3030 create success [libdvr] PID (thread_led_helper_hf3030 |pid = 1019 ): [libdvr] getproc_ifnet6:589 [libdvr] get value from /proc/net/if_inet6 [libdvr] 00000000000000000000000000000001 bef44798 bef447a4 bef447a0 bef4479c lo [libdvr] get value from /proc/net/if_inet6 [libdvr] 20010250300000010000000000010002 bef44798 bef447a4 bef447a0 bef4479c eth0 [libdvr] get value from /proc/net/if_inet6 [libdvr] fe800000000000009202a9fffe0b2e73 bef44798 bef447a4 bef447a0 bef4479c eth0 [libdvr] set success [libdvr] set success pppoe enable have Disabled! Start Upnp Mini Server success! listen port: 49152 DHBonjour: Registered service[0x4047ef00] name 'TZC2LV05000081', type '_http._tcp.', port 80 ==============> libWireless version: 1.0 - Complie time Nov 19 2012 13:33:54 SvnVersion = 4167<============= [libWifi]hotplug_thd pid=1025--../wifi_lib/wifi_api.c(3397)wlan_hotplug_thd [libWifi]watch_thd pid=1026--../wifi_lib/wifi_api.c(4284)wlan_watch_thd DHBonjour: Callback: Registered [libdisk] WARN : before---------------- [libdisk] Open /sys/bus/mmc/devices/ failed [libdisk] Find 0 device [libdisk] WARN : before---------------- [libdisk] Snap a hotplug umount: Invalid argument ==>videoout_channels=0 [libfvideo] =========libfvideo Build on May 16 2013 at 16:24:48.========= [libfvideo] SVN NUM: 9011. [libfvideo] priv->caps.multiOptions 1 ##: analyse = 1 msghander->msgkey 269422157, /tmp/msgPipe ------: msgInit Create DSpborad ---- [libfvideo]: create key sucess /tmp/msg2ato648 msgget sucess [libfvideo]: FUN-> lib_send_data_to_dsp, pthread_id : 1031 [libfvideo] priv->caps.whiteBalance 2 [libfvideo] maxWidth 1920,maxHeight 1080 [libfvideo] WARN (../../src/videoin/chips/imx03x/videoin_imx03x.c|videoin_create_series|839): Failed to open device errno=2 [libfvideo] ERROR (../../src/videoin.c|do_videoin_creat|738): videoin_create failed,fchip=3 =========================== TRACE START =================================== Tid:1010, Exception type : SIGSEGV PC:[0x0003af70] (0x0003aee8--0x0003af8b) Unknown PC:[0x402947c0] (0x0003aee8--0x0003af8b) __default_rt_sa_restorer_v2 + [0x0] PC:[0x003d845c] (0x0003aee8--0x0003af8b) Unknown PC:[0x003d89a4] (0x003d80b4--0x003d86df) Unknown PC:[0x003d8cb4] (0x003d86e0--0x003d8a1b) Unknown PC:[0x00400358] (0x003d8a1c--0x003d8ebf) Unknown PC:[0x004003f8] (0x00400338--0x004003cf) Unknown PC:[0x00035a14] (0x004003d0--0x0040042b) Unknown PC:[0x4027dbec] (0x00035104--0x00035f17) __libc_start_main + [0x104] PC:[0x00034a80] (0x4027dae8--0x4027df53) Unknown =========================== TRACE END =================================== # Any suggestions that I can try, or should I just admit defeat and shed a few tears?

On my camera, the issue is different, unfortunately. I have diconnected and reconnected all connectors, but it doesn't help. But thanks anyway!

Any more news here? Zikronix, have you been able to connect to the bootloader (with a serial connection) yet?

What Buellwinkle suggest could possibly be viable, but there are some gotchas: 1) There might be checksums that would no longer be valid (causing flashing a modified firmware to fail) 2) They might not be using unicode 3) The text could possibly be compressed in the firmware binary, making it more difficult to find and to modify The unicode string you suggested (searched in both endians) is nowhere to be found in the firmware binary, which might suggest that 2) is true.

correct which is pretty much inline with what I said above. Im sure the hardware is "identical" and it is a value flashed in the ROM of the device. In telnet there is an option under set called OPTIND with a value of 1 on a us cam. I tired setting this to 2 with no luck, not even sure that's the option but hey its worth trying! Going to look for jumpers, or bridged and un bridged solder points. I don't think this is a physical thing, I'm quite sure it is something in a special flash area (possibly protected). The OPTIND value is 1 on my genuine Chinese version also, so that's probably not related. The JP1 connector is most likely (99% sure) a serial port (like you said), and it might provide access to interesting things. Another interesting conjecture is that these cameras are much like Gopro Hero2, which uses the same Ambarella CPU/DSP. If so, then the bootloader is probably AMBOOT, and probably accessible from JP1. Another interesting thing to note is that if it is, then the Linux is actually running in a thread (almost like it is virtualized) on a different RTOS (called PrKERNEL). It might also be that to gain access to the AMBOOT bootloader, you'd have to do the same as on the Gopro Hero2, which is to short tx/rx briefly while powering up the camera. Here's a thread with some info on that: http://goprouser.freeforums.org/stickie-hero2-firmware-studies-t4961-30.html It will be interesting to see what you find out regarding JP1, zikronix. Good job so far, and interesting that the Chinese firmware was flashable through TFTP. At least that means it might be possible for us with Chinese cameras to flash the Euro/US version through that method to avoid the language mismatch error. It will not fix the weekday problem, but at least we can use the publicly available updates.

I haven't flashed this firmware myself, because my distributor said it was the same that was factory installed on my cameras. And as I said, a binary compare to the V5.0.0.build.130412 downloaded from Hikvision Europe is almost identical (except the three bytes as mentioned).

Yes, the TFTP-process is part of the bootloader, and runs before the actual boot. There is a guide (and software) to the TFTP-process at Hikvisions site: http://www.hikvisioneurope.com/portal/index.php?dir=Z%20OLD/Technical%20Materials/Special%20Tools/TFTP-Auto-Update/ You have to download each file separately, as they haven't bothered to put them in an archive. That's useless. If you modify those three bytes to match the US, then it will be binary identical to the US, and thus will not flash to the camera. The TFTP IP is 192.0.0.128 (a rather odd address), but you will find all the details in the document at the link I posted. I have a copy of the Chinese v5 firmware if you want it, but I don't want to post it in public, so PM me with your email and I'll send it to you.

The question is whether the language indicator is embedded within the firmware itself (could be consistent with the microscopic difference between the firmwares), in which case it could be changed if only it was possible to trick the currently running firmware to accept the US/Euro firmware. The size difference you are referring to, is compressed vs uncompressed. The actual firmware binary is around 18 Mb, and if you zip that it shrinks to around 12 MB (thus it is highly compressible).

I have done that too, and a comparison between the US/Euro and the Chinese v5 firmware shows that there are three bytes that have different values, so clearly the firmware is actually the same, but that there is some kind of ID that tells the camera whether to accept or reject it.

I have actually done that too, but I didn't have access to a picture of one of the sides of the main CPU board of the other camera, but everything else looked exactly the same. It is not uncommon to store information that is supposed to be unchangeable somewhere in flash memory. After all, it is the manufacturer that controls what is written where, and thus they can avoid overwriting such a special area. Keep in mind that the serial number is also stored somewhere, and I didn't see any other storage devices besides the flash memory.

I'm quite sure it can be worked around, because as Buellwinkle said, the hardware is the same. However, it is possible that there could be some hardware id that prevents it, although I doubt it. The simplest test would be to check if the Euro/US-firmware (which are identical) could be loaded through the TFTP-method instead of doing it through the web interface. There is a slim chance that this method bypasses the language check, but there is of course also a slim chance that the camera will be bricked (which is why I haven't tried it). If you telnet to the camera, there is a command to show some interesting info: # prtHardInfo Start at 2013-08-03 23:46:19 Serial NO :DS-2CD2032-I0120130723CCRRxxxxxxxxx V5.0.0 build 130412 hardwareVersion = 0x0 hardWareExtVersion = 0x0 encodeChans = 1 decodeChans = 1 alarmInNums = 0 alarmOutNums = 0 ataCtrlNums = 0 flashChipNums = 0 ramSize = 0x4000000 networksNums = 1 language = 2 devType = 38917 SD status = -1 (0:noraml;none-0:timeout) Towards the bottom of the list there is a language id. This is from my Chinese version, but on Euro/US-cameras, this will be 1. If we could find out where this is read from, then we might also be able to change it. I'm guessing it is stored in a special section of the flash along other non-modifiable variables (like the camera serial number). This could also be in a protected sector, which would make it hard to actually change. Feel free to chime in with ideas.

Not that I know of. I have been too busy to experiment more with this, and since the cameras work fine as they are, there isn't a strong incentive to do so, either.

The IR-leds are clearly under software control on these cameras (unlike on some Dahuas), so I'm fairly certain that it would be a minor issue for Hikvision to add a separate IR on/off-option. It is a pity they haven't done so, but perhaps it is possible to ask them to? Anyone have some good contact info?

Interesting, but I guess this is just a slightly more complicated way of achieving the same thing. Or does this give you any additional benefits over just using PSIA mode?

This is sound advice. My take is that I'm rolling the dice, and hope I'm lucky with the cameras I get directly from China. Returns will be so expensive and cumbersome, that I choose to live with the risk.That said, the Aliexpress supplier that I have used, is both responsive and communicates well in English, so I wouldn't be too afraid. I wouldn't hesitate to buy from them again. Regarding the firmware issue, it is true that there is something in there that is China specific, but I'm not sure it is just the firmware. Maybe it is, maybe it isn't. It is also possible that they have some regional setting/id in the hardware itself, which is then read by the firmware. From a functional point of view, the only sacrifice you make is that the weekday display is in Chinese, and therefore unuseable (and must be turned off). Everything else is OK, and the same as the Euro/U.S-versions. The other downside is that when Hikvision releases a new firmware to their U.S or European site for public download, you'd have to get the firmware elsewhere. However, the Aliexpress distributor has access to the firmware files for the Chinese version, and promptly sent me the file when I asked.

That's because they are unbranded Hikvision that came from Hikvision USA, different than ones destined for the Asian market. Yes, but the strange thing is that the firmwares are actually the same. The firmware files only differ in three (3) bytes near the beginning of the file, so I suspect there is some other kind of tomfoolery going on. It is also strange that absolutely everything else is in English on these Chinese versions, the only thing that remains in Chinese is the weekday display. Not really a big thing, since you can just turn it off, but it is still very strange.

The file from the Korean site is actually NOT the same as the Chinese version. My supplier has now sent me the real Chinese version, and it is nearly identical to the European file. It differs only in three bytes near the top of the file, which tells me that the firmware is actually the same. My supplier insists that it is impossible to load the European firmware on a Chinese camera, but this last finding tells me that the firmwares aren't really different (except for some apparent regional info in the proprietary file header). And also, given that everything else is correctly translated, I'm wondering if this might be just a bug, and that even genuine European cameras has it. Does anyone here have genuine European (or US) cameras? Is the weekday text correct? There might be some hardware regional indicator within the camera itself, and that will of course make this whole exercise a moot point, unfortunately.