Hikvision DS-2CD2x32-I (R0) brick-fix tool / full upgrade method / fixup roundup.

Before I fix my cam I wanted to make sure I'm good to go and make sure I'm on the right track. I have a working DS-2CD2732F-IS, Chinese version the email no longer works but other than that it works as it is supposed to. It is stock firmware v5.1.0 build 131202 with a devType =38926.

# prtHardInfo
Start at 2017-07-23 18:23:11
Serial NO :DS-2CD2732F-IS20140426CCCH462100013
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 = 2
devType = 38926
SD status = -1 (0:noraml;none-0:timeout)

According to the mtd hack txt file my cam should have a devtype of... 0E98 (model DS-2CD2732F-IS)

I was able to extract mtdblock6 and in HxD editor it appears that all I need to change is 0x10 to a value of 01.
The devtype and checksum already look correct.

CheckSum HIGHLIGHTED.jpg

My questions are this...

1-My camera is not bricked and has a static ip... 192.168.1.xx, with a port of 8400. Can I use the current ip instead of 192.0.0.64?
2- Can I leave cam on my existing LAN or put it on a separate switch w pc.
3- will cam maintain configuration I have it set with? Can I restore a config backup or will I have to manually setup cam again?
4- After brickfixv2EN.dav is processed what FW version will my cam be on?
5- what FW do you recommend I take the cam up to?
6- Is hikvisioneurope.com a suitable source for getting FW for a cam used in the USA?

I would have been happy to leave it at FW v5.1.0, but email no longer worked after port 25 was compromised and yahoo, gmx and gmail stiffened things up.
 
Last edited:
Some good questions.
It does look like you have been looking at the updated brickfixV2 method - this older brickfix method has been superseded with an easier to use method of brickfixV2.

devType = 38926
SD status = -1 (0:noraml;none-0:timeout)

According to the mtd hack txt file my cam should have a devtype of... 0E98 (model DS-2CD2732F-IS)
Yes, that is correct, decimal 38926 = hex 980E
1-My camera is not bricked and has a static ip... 192.168.1.xx, with a port of 8400. Can I use the current ip instead of 192.0.0.64?
For the bootloader / brickfixV2 operations? No, that 192.168.1.x IP address is only valid when the full app system is running.
The tftp updater within the bootloader / min-system mode uses the default IP address of 192.0.0.64 and expects to find the tftp updater on 192.0.0.128
2- Can I leave cam on my existing LAN or put it on a separate switch w pc.
You can leave it and the PC on the LAN. Just make sure no other Hikvision devices reboot while you have the Hikvision tftp updater running or they will pick up on it.
3- will cam maintain configuration I have it set with? Can I restore a config backup or will I have to manually setup cam again?
The configuration will be wiped, it will need to be manually re-established, the structure varies with firmware version.
4- After brickfixv2EN.dav is processed what FW version will my cam be on?
It will be on the brickfixV2 custom firmware. After the first power-cycle after brickfixV2 the camera will reboot into min-system mode until the final firmware update is applied.
5- what FW do you recommend I take the cam up to?
You can go direct to the latest version, 5.4.5, from here : DOWNLOAD PORTAL
6- Is hikvisioneurope.com a suitable source for getting FW for a cam used in the USA?
Yes, it's fine.

And finally -
I was able to extract mtdblock6 and in HxD editor it appears that all I need to change is 0x10 to a value of 01.
The devtype and checksum already look correct.
Not quite - when you change the language byte to 01, you will also need to change the checksum as it will no longer match. It will reduce by 1.
As a FYI - the brickfixV2 fixup.sh script extracts mtdblock6 for you, and also imports the modded version, automatically.
 
  • Like
Reactions: marku2
Oh this is great information THANK YOU

Should I change the IP to 192.0.0.64 and http port to 80 in the gui before starting the process or will that happen when tftp updater puts cam in min-system mode

tcpip.jpg port.jpg
 
Happy Report! All went smooth as silk. Now I just have to manually input my config.
Took about 10 minutes start to finish. READING, READING, READING took a few hours, well worth it!!

!GRACIAS!
 
  • Like
Reactions: marku2
Happy Report! All went smooth as silk. Now I just have to manually input my config.
Took about 10 minutes start to finish. READING, READING, READING took a few hours, well worth it!!
That's good to hear. Well done!
Yes, there is quite a lot to take in. But easy enough to do once you've figured it out.
I've done lots, just about on auto-pilot.
 
strange.

every day or so the unit takes a crap. Non responsive to ping or gui or ssh no reply to reboot via curl

and requires a cold boot

turned off "cross the detection line" as it was a new feature I enabled, made no difference

any ideas or just put on digital timer to reboot it daily
 
every day or so the unit takes a crap. Non responsive to ping or gui or ssh no reply to reboot via curl
and requires a cold boot
There have been some posts where Hikvision cameras can be unreliable after customising the HTTP port away from 80, cause unknown.
That might be worth an experiment.
 
Would have never made that connection!
Settings modified and will monitor stability. And report results.

Previous....
HTTP Port 8400
RTSP Port 8402
HTTPS Port 8401
Server Port 8403

Current....
HTTP Port 80
RTSP Port 8402
HTTPS Port 443
Server Port 8403
 
BJ78

I am happy you got your cam working as well, It really is a good cam despite all this mayhem.

I am sad to report, in my case at least, that the crashing/lockup has continued, even after putting the GUI back on port 80. My solution, unless somebody comes up w something better, was to put the POE injector on a digital timer to repower the cam 2x daily. Once at 1pm and once at 1am. This way if it crashes it will come back on repower.
 
I am sad to report, in my case at least, that the crashing/lockup has continued, even after putting the GUI back on port 80.
That is odd, as the 5.4.5 firmware is very solid, when there is steady traffic flow that stops the 'network_deamon' kicking in because it things the connection has frozen.
We have had posts where people have seen reliability problems with customised HTTP ports - resolved by going back to defaults.
Yours seemed promising too for a while.
The customised ports imply you are allowing inbound access from the internet - is that the case?
I'm wondering if some external activity may be the cause of the problem.
If so, can you isolate (ie no port forwarding) one camera from internet access as an experiment?
 
yes I do have port forwards for rtsp on the HQ video feed and for gui access. It it not constantly streaming or hitting the gui. only when I remote in to see what's going on on the property.

i set http and https back, are there default ports for the server and rtsp? I dont recall as I changed them day one when installed WAAAY back.

HTTP Port 80
RTSP Port 8402
HTTPS Port 443
Server Port 8403

i turned off SNMP as well

I can pause the forwarded ports as well if resetting all ports has no effect
 
It it not constantly streaming or hitting the gui. only when I remote in to see what's going on on the property.
It's not so much what you are doing to externally access the camera - it's more about what every other internet device or user can do to your cameras that's the risk here.
If you 'port forward' your cameras you are certainly putting them in the firing line.

are there default ports for the server and rtsp?
RTSP default port=554.
Hikvision 'server' default port=8000
 
will give a try when I return home. Can do remotely from vacation home, but access is via a homebrew WISP that can be sketchy sometimes and dont want to screw the pooch remotely.