Custom Firmware Downgrader 5.3.0 Chinese to 5.2.5 English

[Jack B Nimble]

Hi, I've bricked my camera and hoping for some help

It was a DS-2CD2332-I which was running 5.2.0 build 140721. (CH cam from aliexpress with English language).

It had the CBX hack which I thought allowed me to update the firmware. So I tried to update to 5.3.0 build 151016 and am now getting "firmware language mismatch" error preventing me from logging in and accessing the camera.

After reading lots of posts on here, I tried following the TFTP downgrade procedure Custom Firmware Downgrader 5.3.0 Chinese to 5.2.5 English but I keep getting errors with TFTP Server.

• PC IP set to 192.0.0.128 mask 255.255.255.0
• Firewall turned off
• Antivirus turned off
• Camera and PC connected to POE switch (other cameras still connected)
• TFTP installed at C:\TFTP-Update

When I run TFTP, the initialisation message appears, then I get a 'connect client failure,0' message until I plug back in the camera, I then get 'Device[192.0.0.64] test tftpserver' message and then it goes back to 'connect client failure,0' and continues to keep giving the same error.

I've tried the digcap.dav file at the start of the thread and have also tried using 5.1.6 and the same messages appear.

Any ideas would be most appreciated.

Cheers
Alex

I had same issue and the upload was not working so the result was that must save the digcap.dav file as digicap.dav not the initial error that said digcap.dav as you wrote and mentioned above. I had a 3132 that was heading to garbage can ( who am I kidding I don't throw away anything) and it worked great with the instructions other than the mispelled dig(i)cap.dav. I was on Skype with the seller for 1 hour ( who knows what they were up too ?) and they resolved nothing. The IP was 192.0.0.64 which after I plugged into my NVR was recognized right away. Now when my wife gets home I can say I "saved $ 100 camera" and go buy another one lol.

 

[alexf40]

Awesome thanks Jack, that fixed it straight away

 

[Jack B Nimble]

Awesome thanks Jack, that fixed it straight away

Your welcome !

 

[istreich]

I have a 2732 and have had no luck with this fix. But to be honest, I am not 100% sure what my problem is. About a year ago, I remember trying to upgrade the firmware and thought I bricked the camera. It had some strange behaviors (don't remember). Anyway, today it comes on and off intermittently with some strange image. I have attached pic. I am completely lost on what the problem can be and what I can do about it. That specific camera was bought via NewEgg marketplace from a chinese vendor.
I have a second one, identical but to which I did nothing and it works fine.
Thanks a lot for any help you may bring!

 

[Tim Veer]

Hello all,
Had an issue of a lost password on a DS-2CD3335-I. The seller has been more that helpful in getting the encrypted password reset files, but after several attempts, the unit still fails to reset the password. As there is no firmware 5.3.8 build 160108 floating around in the wild, I'm left wondering... what's next??

Will this downgrading work from 5.3.8 to the 5.2.x? And if I do this will it still work with my DS-7732 NVR running firmware v3.4.6?

Thanks for the insights of "the gurus"
Tim

 

[alastairstevenson]

The DS-2CD3335-I is a China region camera - maybe with hacked firmware if you have English menus?

As there is no firmware 5.3.8 build 160108 floating around in the wild,

The CN 5.3.8 160108 firmware is available here, section #12 : http://www1.hikvision.com/cn/download_more_714.html
But it will likely cause the camera menus to revert to Chinese, and be rejected as Language Mismatch by the NVR, even connected as ONVIF.

 

[Tim Veer]

Sorry, I shoukd have clarified. The cameras and NVR are chinese ones hacked with English menus. I was looking for a hacked 5.3.8 build 160108 with English menus. If the firmware isn't available, can I downgrade (as per the above) and still work with the NVR? If not, I've got a relatively ugly paperweight.
Cheers

 

[Enabler]

Hello all,
Had an issue of a lost password on a DS-2CD3335-I. The seller has been more that helpful in getting the encrypted password reset files, but after several attempts, the unit still fails to reset the password. As there is no firmware 5.3.8 build 160108 floating around in the wild, I'm left wondering... what's next??

Will this downgrading work from 5.3.8 to the 5.2.x? And if I do this will it still work with my DS-7732 NVR running firmware v3.4.6?

Thanks for the insights of "the gurus"
Tim

I haven't read the whole thread and this might have already been covered. But just in case:

1) You can't restart your camera between creating the export.xml password reset, and feeding back the import.xml

It won't be accepted if you do as the export.xml changes every restart. Leave camera connected for as long as it takes to get response from Hikvision/seller. If you have and still doesn't work maybe do the export.xml again and compare to the one you already sent - it should be the same. If it's not the camera restarted without you knowing.

2) TFTP stock firmware won't help. Some Hikvision cameras will reset their password activation status if you do - but 2xx5/3xx5 DO NOT so even if firmware changes, it will still be expecting whatever password was set before.

Hope that's slightly helpful.

 

[Enabler]

Sorry, I shoukd have clarified. The cameras and NVR are chinese ones hacked with English menus. I was looking for a hacked 5.3.8 build 160108 with English menus. If the firmware isn't available, can I downgrade (as per the above) and still work with the NVR? If not, I've got a relatively ugly paperweight.
Cheers

Don't change the firmware for the cameras unless there's no other choice - it will not fix password issue and camera will be Chinese.

If you do change it you might as well change the NVR to Chinese also so at least the devices will talk to each other (which they won't if one identifies as Chinese and the other as English).

 

[alastairstevenson]

2) TFTP stock firmware won't help. Some Hikvision cameras will reset their password activation status if you do - but 2xx5/3xx5 DO NOT so even if firmware changes, it will still be expecting whatever password was set before.

Interesting - I didn't know that. tftp update does not clear the whole configuration including passwords?
So for a 'grey market' 2xx5/3xx5 if you don't have the password you are unable to recover it?

 

[Tim Veer]

I haven't read the whole thread and this might have already been covered. But just in case:

1) You can't restart your camera between creating the export.xml password reset, and feeding back the import.xml

It won't be accepted if you do as the export.xml changes every restart. Leave camera connected for as long as it takes to get response from Hikvision/seller. If you have and still doesn't work maybe do the export.xml again and compare to the one you already sent - it should be the same. If it's not the camera restarted without you knowing.

2) TFTP stock firmware won't help. Some Hikvision cameras will reset their password activation status if you do - but 2xx5/3xx5 DO NOT so even if firmware changes, it will still be expecting whatever password was set before.

Hope that's slightly helpful.

Hey Enabler, thanks for the info.

I think part of my problem is that the camera is already acting weird. It was set to DHCP, and if I leave it connected to the router (with a xx.xx.xx.2 - xx.xx.xx.200 range), the camera seems to reset itself automatically and get assigned a new IP address every 12 - 15 minutes. The idea about comparing the xml before resetting it is a good one, this way I can get an idea what's happening.

So, the bottom line though is that a forgotten & unrecoverable password renders the camera toast! Nice system Hik - that's yet another way to make friends!

 

[Tim Veer]

1) You can't restart your camera between creating the export.xml password reset, and feeding back the import.xml

It won't be accepted if you do as the export.xml changes every restart. Leave camera connected for as long as it takes to get response from Hikvision/seller. If you have and still doesn't work maybe do the export.xml again and compare to the one you already sent - it should be the same. If it's not the camera restarted without you knowing.

Just to follow up, I did a small export.xml test and even if the camera is not reset, every time I export the xml (whether it be 5 seconds or 5 minutes apart) they are always different). So I am left wondering (and for the benefit of others in this position), does the camera issue a new xml every time it is exported? In this case, I think you can only export the xml once, leave the camera ON and connected and then import the encrypt.xml file without trying to create another xlm for comparison.

 

[Enabler]

Just to follow up, I did a small export.xml test and even if the camera is not reset, every time I export the xml (whether it be 5 seconds or 5 minutes apart) they are always different). So I am left wondering (and for the benefit of others in this position), does the camera issue a new xml every time it is exported? In this case, I think you can only export the xml once, leave the camera ON and connected and then import the encrypt.xml file without trying to create another xlm for comparison.

Hmm.. looks like I'm wrong on that part then. A random number is included in the reset .xml file - but it's generated every time you export - even though it should only be set once per camera boot in my opinion. Or even more sensible the date should be used, and the reset code valid for 7 days so doesn't matter if device restarts.

OK, in that case only export once, and send that to Hikvision/seller. Though you need to make sure the camera doesn't restart first though otherwise no point.

If you keep a ping -t <ip> going to your camera, does it still reboot periodically?

I've seen cameras where they reboot if they don't get network data for a long time. They think they are being helpful.

 

[Tim Veer]

Hey, good thought on the continuous pinging, never thought of that. I'll give it a whirl tomorrow and report back.
Don't you just love helpful hardware.....
Cheers

 

[Enabler]

Hey, good thought on the continuous pinging, never thought of that. I'll give it a whirl tomorrow and report back.
Don't you just love helpful hardware.....
Cheers

Yeah on some cameras there's a daemon called network_deamon

Usage:./network_deamon [-d diagnose_item] [-r repair_way] [-t interval]
-d(hex): 0x00(def): check link status.
0x01(bit1): check whether rx packets change or not.
0x02(bit2): check whether tx packets change or not.
0x04(bit3): check whether err packets change or not.
0x08(bit4): check whether interrupts change or not.
0x10(bit5): check whether duplex is right or not.
-r(hex): 0x00(def): repair by reset netdev.
0x01(bit1): repair by reboot after the times of reset network more than 3.
0x02(bit2): repair by reboot.
0x04(bit3): repair by setting netdev mode to 10M/FULL.
-t(dec): check network status every interval senconds, default 30.
-f(str): specify log file.
-v: print version.
-h: help.
Example:./network_deamon -d 0x0f -r 0x01 -t 30 &

Then it gets run (on my IPC_R6) with

/bin/network_deamon -d 0x0f -r 0x01 -t 60 &

So it reboots if no data received for some time. I guess it's trying to be helpful in thinking there's something wrong so lets restart to fix.

Your camera is IPC_G0 but the same principle probably applies.

They seem to have learned this is stupid though as in later IPC_R6 firmware

/bin/network_deamon -d 0x0e -r 0x00 -t 60 &

A much more reasonable setting. Only check TX packets which should be going up in normal operation even if nothing on network because of heartbeats etc, and if there's a problem just restart the interface not the whole camera.

So the upshot is, generate the DeviceKey.xml only once, don't restart and make sure to keep your camera alive with a continuous ping until you get back the import.xml - a good chance of actually fixing your problem.

Check I'm right that ping -t fixes the restart issue. Assuming I am you might want to let your seller know this so other people that have the same problem can apply the same solution.

 

[Tim Veer]

Hey, good thought on the continuous pinging, never thought of that. I'll give it a whirl tomorrow and report back.

So, here's the report, it's just weird. More and more I am wondering if the camera is just hooped!

So, I logged the pings to a notepad and them looked at them in Excel. Interesting is that the device will return 360 pings before doing one of two things. Here's a little snippet, bear in mind that there have been exactly 360 return pings and then I get (the cameras IP is 172.16.10.3), also this is using Windows ping command.(I've tried a few other PING utilities giving more granularity over the responses, but this seems to be a cleaner benchmark to work with)

Reply from 172.16.10.3: bytes=32 time<1ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 172.16.10.3: bytes=32 time=2001ms TTL=64
 ... and this carries on for another 360 pings...

But every now and again instead of the above I get:

Reply from 172.16.10.3: bytes=32 time<1ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 172.16.10.2: Destination host unreachable.
Request timed out.
Request timed out.
Reply from 172.16.10.3: bytes=32 time<1ms TTL=64

So, in essence we are keeping the camera alive and preventing it from jumping to a new IP, but there is something definite happening every 360 pings.

I wonder what the camera will look like as an underwater reef in the fish aquarium....

Cheers

 

[alastairstevenson]

So, in essence we are keeping the camera alive and preventing it from jumping to a new IP

It may be worth adding an IP reservation for the camera MAC address in your DHCP server / router to fix the IP address.

but there is something definite happening every 360 pings.

Isn't it just in a bootloop, rebooting regularly?

 

[Tim Veer]

That's what I did with the IP address already, otherwise it kept incrementing every reboot. Still though it seems every reboot changes the xml expecyed response.

As for the bootlop, I am wondering if that isbthe problem with the xml reset file. My seller can't get me the xml fast enough before the bootloop reboot and it seems that the xml he sends me doesn't do the trick.

 

[Enabler]

Yes if it reboots the .xml will automatically be invalid.

Can you timestamp the pings? If you are losing only 10 seconds worth that is not enough for the camera to reboot so .xml should be valid.

If on the other hand the camera disappears for like a minute then it's probably rebooting. You could confirm by having a ping -t 192.0.0.64 (and your PC able to see that IP) at the same time and if you get a few hits it's a camera rebooting.

 

[Tim Veer]

Can you timestamp the pings? If you are losing only 10 seconds worth that is not enough for the camera to reboot so .xml should be valid.

If on the other hand the camera disappears for like a minute then it's probably rebooting. You could confirm by having a ping -t 192.0.0.64 (and your PC able to see that IP) at the same time and if you get a few hits it's a camera rebooting.

I was able to timestamp pings using hrPing and it looks like we're losing the camera for 30 - 40 seconds. Tomorrow I'll try pinging 192.0.0.64 and see what happens.

Thanks