Hikvision Camera resetting itself

[freebsdrules]

Hi all-

I have one (of 11) Hikvision cameras that has reset itself twice in the past few weeks. The first time happened at the same time the switch supplying power (PoE) died and had to be replaced so I didn't think much of it. It's happened at least one other time since to the same camera (maybe another time too, I cannot recall). I've read some of the posts that mention there are certain vulnerabilities/attacks that can cause this but my cameras are only accessible remotely via my internal VPN. UPnP was enabled on the camera in question but there are no exposed/forwarded ports on my router (not a standard residential box). So, it doesn't appear to be caused by an external source.

Any thoughts? I have a static IP set but it gets reset with a DHCP address and the password is wiped out. Camera details below.

Camera Info:

Model: DS-2CD2142FWD-I
Firmware: V5.4.3 build 160902

 

[Karel]

Hi,
I had the same issue in a very similar setup with two hikvision DS-2DE3204W-DE cameras. Interestingly the self initiated reset occurred in both cameras at the exact same time, once every few days. One of the two is a genuine english version, the other is a non-hacked chinese version of the same model. Both were running firmware V5.4.0
Having replaced the switch that they were both attached to, and after a lot of tinkering with the way the network is structured, all to no avail, I started to upgrade firmware on the cameras to V5.5.0.
I have not done the chinese camera yet, but the english one is now problem free! The chinese continues to reset itself every day or so.

It did look like some external attack to me, but there was no evidence of that in the camera or router log files.

Whatever it was, it seems to be addressed in the latest firmware, is my conclusion

 

[freebsdrules]

Fantastic, thanks! I'll have to search around, but any good guides to upgrading firmware (with a place to download it)? Mine are genuine English versions.

 

[Karel]

In another thread, I read an interesting comment that it would be a good idea to switch off upnp in the cameras network settings - trying that now for my chinese camera
And as some are saying in other threads: Do not skip major firmware versions

 

[freebsdrules]

Just upgraded to the most recent firmware. Will see what happens. I did also disable upnp on the camera just to be safe.

 

[alastairstevenson]

I have one (of 11) Hikvision cameras that has reset itself twice in the past few weeks.

Hikvision cameras exposed to the internet with vulnerable firmware (practically all revisions below 5.4.5) are being hacked in huge numbers via the 'Hikvision backdoor'.
Loads of posts on this forum and elsewhere about it.
Hikvision backdoor? (WSJ article)

 

[schijndela]

Since a week, one Hikvision Camera (DS-2CD2532F-IS version V5.2.5 build 141201) I have two and one camera is driving me "crazy" this Camera resets its self to a default Ip-adress probably caused by the Backdoor Exploit.
Strangely and fortunately only one camera is facing this problem.

After resetting the Camera to it's Default values and disabling UPNP, Platform access using a strong password and disabling port forwarding on my router. again after a day the camera resets its self to default values.

Because I bought the Camera's on Ali Express I contacted the seller, the only advise he could give me was not to update the firmware!

Some advice from you would be helpful, because at this moment it makes the camera useless if I need to configure it everyday.
Is there a step-by-step guide how to fix this? I found several but I am missing the experiences / results

If I decide to upgrade the firmware:
Do I need to download the China Firmware versions or can I also Download the European ones?
Are there risks if the firmware update fails, defective Camera?

I will be very grateful if someone can help me with this one.

Many thanks.

 

[alastairstevenson]

I have two and one camera is driving me "crazy" this Camera resets its self to a default Ip-adress probably caused by the Backdoor Exploit.

You are not alone - there is a great deal of this type of activity right now with Hikvision cameras.

Is there a step-by-step guide how to fix this?

Fortunately for readers of this excellent forum there is a solution available that will allow a full update to firmware that does not have this particular backdoor vulnerability waiting to be exploited.

Check out the details of how to do the 'enhanced mtd hack' in the attachments here : Hikvision DS-2CD2x32-I (R0) brick-fix tool / full upgrade method / fixup roundup.
You don't need to do the 'brick-fix' as the firmware you quoted is suitable as the start point.
Don't be too daunted by it - it's not so hard as it seems, and loads of people have done this with good results.
As part of the process - also check out the contents of mtdblock1. If locations 0x0C and 0x8000C have 0 in them - change them to 1 and re-write mtdblock1.

Good luck!

 

[schijndela]

Thank you very much for your feedback, I'm going to read a few things from the link you mentioned in the message. Probably there will still be questions from this.
I'll keep you informed

 

[schijndela]

If I read all the information correctly, Do I need to make a Back-up of the current version?
In the information I read it is needed to make a Backup/copy of mtdblock1, mtdblock5 and mtdblock6 if I interpreted this correctly this will be done after the firmware upgrade?!
I also need to record the DevType (PrtHardInfo) for later purpose in mtdblock6
Unfortunately editing those files with HxD editor is not quite clear yet.

After copying I need to modify the mtdblock files locally on my PC with (HxD Editor) and copy the modified files back to the camera.
Because my camera has version 5.2.5. installed I need to upgrade first to 5.3.0 - 5.4.0 - 5.4.5 do I need to modify the mtdblocks after each firmware update?

After running PrtHardInfo on my current camera I noticed information about frontend_software_platform_5.2.7_R0 as mentioned here below, but maybe this information has nothing to do regarding the firmware Version "V5.2.5 build 141201" is also mentioned.

devType = 38932
net reboot count = 0
SD status = 0 (1:noraml;0:none)
Path: .
Working Copy Root Path: /data1/data_liwenwei/work/frontend_software_platform_5.2.7_R0
URL: https://192.0.0.140/Camera/Platform..._platform/frontend_software_platform_5.2.7_R0

 

[alastairstevenson]

In the information I read it is needed to make a Backup/copy of mtdblock1, mtdblock5 and mtdblock6 if I interpreted this correctly this will be done after the firmware upgrade?!

You need to extract mtdblock6, in order to change it and put it back, and no firmware upgrade or downgrade is required at this point as you are already on 5.2.5 which is the best to use when making the change to mtdblock6.
You should also extract mtdblock1 just to check if locations 0x0C and locations 0x8000C have the value 0 in them - if so, they should be changed to 01 and mtdblock1 re-written to the camera. This is unlikely to be needed though, it's mainly for those cameras that were labelled as originally having 5.2.8 firmware.

After copying I need to modify the mtdblock files locally on my PC with (HxD Editor) and copy the modified files back to the camera.

Yes, that is correct, for mtdblock6.

Because my camera has version 5.2.5. installed I need to upgrade first to 5.3.0 - 5.4.0 - 5.4.5 do I need to modify the mtdblocks after each firmware update?

No - mtdblock6 is modified and re-applied just once while the camera is running 5.2.5
After that has been done, the camera is now 'English / upgradeable' and can be updated via the web GUI from 5.2.5 to 5.3.0 to 5.4.0 to 5.4.5

devType = 38932

This decimal value is 9814 in hex, and gives the value that needs to be in locations 64 (14) and 65 (98) in mtdblock6.

 

[schijndela]

Hi Alastair, thanks for your update. If I am right then I only need to modify the value 0x64 and 0x65 in mtdblock6.
I also need to do something with my Checksum!?

In the enhanced_mtd_hack something is mentioned:
0x04 and 0x05 Checksum-16 bytes Set to the Checksum-16 value as calculated by HxD for the 0xF4 bytes starting from location 0x09 remembering the correct byte order, 0x04 is the least significant byte.

Only that part is unclear for me. maybe you can explain one another do I have to change some values in the range I selected? and at which point I can do this?

You also mention that I have to check mtdblock01, the Value I can find on 0x0C = 01
0x8000C this value I can't find I only see value FF!?!?

Hopefully after I modified the mtdblock, can I use the European firmware versions?

Kind regards,
Arie

 

[schijndela]

If I Look at the Checksum-16 value for 04 (value 68 Checksum value 0068) and 05 (value 0C Checksum value 000C) in mtdblock1 these value differ??
As mentioned earlier I get a bit stucked on this part, so, I need some help how to handle this. I modified some settings as you can see in the attached file.
Hopefully someone can help met with making this last step so I finally can make the firmware update.
Apologies for my ignorance.

 

[alastairstevenson]

Only that part is unclear for me. maybe you can explain one another do I have to change some values in the range I selected? and at which point I can do this?

I'm sorry for the late reply - I had forgotten that I had read this post.
In your post just above you have changed your devType correctly, and you have selected the correct number of bytes - 0xF4 hex is shown in the Length : value in the status bar.
If the checksum shown in the screenshot above (0D1E) has been calculated from the values highlighted, then all you need to do is change location 04 to 1E and location 05 to 0D and mtdblock6 is correct and ready to be used.

Your mtdblock1 looks OK in location 0x0C - with the value 01
I would therefore also expect location 0x8000C to also have the value 01
I think your mtdblock1 is OK and no changes required.

Hopefully after I modified the mtdblock, can I use the European firmware versions?

Yes, that is correct.
Make sure to upgrade using the intermediate versions, 5.2.5 to 5.3.0 to 5.4.5

Good Luck!