Hikvision DS-2CD2x32-I (R0) brick-fix tool / full upgrade method / fixup roundup.
- Thread starter alastairstevenson
- Start date
Best not to - as you don't really know what it's doing.
So keeping it disabled as per your screenshot (assuming it's not lying) is good.
copex
Getting the hang of it
finally got round to upgrading 2 camera, just wanted to say thanks
The original and the enhanced version are in the first post of this thread.
Here is a copy of the link in that post R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.
Here is a copy of the link in that post R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.
Any idea...
I'm curious in the hex editor with the model DS-2CD2532-IWS if you can use the devtype as per the steps for model: devtype: 1498 Model: DS-2CD2532F-IS (since this devtype is missing the W-wireless)? Does that matter?
I think there is a chance you'd lose the wireless capability by using the devType code for DS-2CD2532F-IS
Which might not be a problem if you don't use it.
But a couple of questions:
Is the existing devType code in mtd6ro_orig FF98? Or does it have a correct value already?
Are you able to run the prtHardInfo command to see the devType code?
Also - we could ask @Calumet what devType code was used, and add it to the table.
**edit**
And presumably you've seen the updated version of this fix-up method :
R0 / DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced.
Last edited:
Thank you..
This is some of the info I get from prtHardInfo:
Model: DS-2CD2532F-IWS
FW V5.3.0 build 150814
devType 0x9814 <----
So the one mentioned in the instructions looks correct then:
devType Model
1498 DS-2CD2532F-IS
Last edited:
I gave it a shot on the DS-2CD2532F-ISW. I was able to do the first load using the hikvision tftp server and the brickfixV2EN copied to digicap.dav. It appeared successful.. when I rebooted the camera, I never got a telnet connection. I retried booting the camera a few times while pinging the 192.0.0.64, and it ping about three times and then no more responses. After about 2 or 3 minutes, the camera comes up with an IP of 192.168.1.64 and only listens on port 8000 (I did a scan with nmap). I didn't try anything else though, as it got late and I had work tomorrow. Any ideas to try? Thanks 
If that's a Chinese camera running 'hacked to English firmware (otherwise why would you have to resort to the enhanced MTD hack to update it) I'd have expected it to need the brickfixV2CN version of the fixup firmware.
Was that 'file transfer complete' or 'system upgrade successful' ?
If just the file transfer, try the brickfixV2CN version.
But try it anyway.
Also - if you leave the camera powered up for 10 minutes, does it do an auto-reboot to the 192.0.0.64 IP address?
SADP will show that status without the need to alter the PC IP address to check.
If I recall correctly, it was successful transferring the file (using brickfixv2EN.dav copied to digicap.dav)... and then after the reboot to active it, I was never able to telnet in. If I set up pings to 192.0.0.64 as I reboot it, I only see about three successful pings.. and then it does not respond anymore and in trying more reboots, it never handshakes with the tftp server and won't take any digicap.dav files. After about 2 or 3 minutes, it has a pingable IP of 192.168.1.64 and only listens on port 8000. I think it remains in that state if powered up. I had 100% success on a bunch of the CCCH serial'd cameras with the brickfixv2EN... luckily. Just this one model is giving me a hard time.
If it only said 'file transfer successful' and did not after that say 'upgrade completed successfully' (or similar wording) then the firmware has been rejected and not applied. Normally that would mean a re-try with other firmware would be the way forward.
But that would not explain why it no longer 'tests the tftp server' and then connects to it.
If you are powering with PoE - it would be worth trying with a 12v DC power supply.
Here are some views I took to show the current behaviour of the camera:
First 2min after power on
- you can see for a few seconds, the 192.0.0.64 IP is pingable, but doesn't last long and the camera does not appear to make any TFTP handshakes. Also, not able to telnet to camera (since the 192.0.0.64 IP is not up for more than a few seconds).
4 Minutes after power on
- no change - no TFTP attempts
5 Min 30sec after power on
- shows up on SADP (while NIC on laptop is still set to 192.0.0.128)
11 Minutes after power on
- no change
13 minutes after power on
- Once I change my NIC to 192.168.1.128, I can ping 192.168.1.64 and it still is visible in SADP
Using iVMS 20 minutes after power on
-iVMS can see the camera, but I can't figure out the password.. 12345 doesn't work, or my original passwd.
nmap of 192.168.1.64 20 min after power on
- only port that seems open is 8000
UPDATE:
I have serial access to it now...
There's quite a few commands... tftpboot appears to force a tftp boot and load whatever digicap.dav file is in the tftp path. I detect a learning curve here
First 2min after power on
- you can see for a few seconds, the 192.0.0.64 IP is pingable, but doesn't last long and the camera does not appear to make any TFTP handshakes. Also, not able to telnet to camera (since the 192.0.0.64 IP is not up for more than a few seconds).
4 Minutes after power on
- no change - no TFTP attempts
5 Min 30sec after power on
- shows up on SADP (while NIC on laptop is still set to 192.0.0.128)
11 Minutes after power on
- no change
13 minutes after power on
- Once I change my NIC to 192.168.1.128, I can ping 192.168.1.64 and it still is visible in SADP
Using iVMS 20 minutes after power on
-iVMS can see the camera, but I can't figure out the password.. 12345 doesn't work, or my original passwd.
nmap of 192.168.1.64 20 min after power on
- only port that seems open is 8000
UPDATE:
I have serial access to it now...
There's quite a few commands... tftpboot appears to force a tftp boot and load whatever digicap.dav file is in the tftp path. I detect a learning curve here
Last edited:
Ok.. I got it.. FINALLY. I had to find a fw version that would load first .. and I think the one I used was 5.3.0(downgrader?)... and from that, I was able to use "update" from the serial connection for the first upload and from there everything worked.
I saved the serial output of all the experimenting I did.. and I'll have to review it.
I'm happy now. Serial rox.
I saved the serial output of all the experimenting I did.. and I'll have to review it.
I'm happy now. Serial rox.
Last edited:
Well done for getting there. Sigh of relief all round ...
It would be interesting to see an abridged version of that - to see what the initial problem was.
Why would it stop handshaking to the Hikvision tftp updater? Odd.
It does indeed.
My guess would be somehow the first load got corrupt (using POE, which I ended up using the adapter in the end), and it couldn't start correctly and check for the firmware availability via TFTP in the first 10 seconds? I assume that is the normal behaviour that allows for FW to be uploaded.. that it always brings up a 192.0.0.64 IP, and checks 192.0.0.128 for a digicap.dav file? Once the camera stopped doing that function, the only choice seemed to be via the serial, stop the boot (ctrl-U) and force the update from "within". I get the impression you should be able to always recover these, unless there is some sort of physical or electronic damage. I also think it would help to have a copy of the original firmware (or somehow pull the firmware off it first?) if doing this on China sourced cameras (to try and put it back in a working state to attempt again). btw, I'll upload the serial log output and provide the link.
btw.. I want to thank you too for all your work and support in helping myself and others. People like you who make genuine efforts to help others (and without expecting pay back), is what makes forums like this so valuable to electronic hobbyists, hackers, those of us who work in the Tech or IT fields who like to learn about this stuff and repair or make things better.
btw.. I want to thank you too for all your work and support in helping myself and others. People like you who make genuine efforts to help others (and without expecting pay back), is what makes forums like this so valuable to electronic hobbyists, hackers, those of us who work in the Tech or IT fields who like to learn about this stuff and repair or make things better.
Last edited:
Yes, that's correct. It emits a UDP probe packet on a specific port to 192.0.0.128 on which if the Hikvision tftp updater is listening a specific response is sent, and a handshake occurs, following which the tftp transfer is done.
Pretty well, unless u-boot itself has been compromised.
The 'update' command boots up the 'recovery' environment from flash memory, which includes a Linux kernel and all the needed routines to get, unpack, validate and apply the firmware components.
And in Hikvision's case - apply some restrictions such as blocking firmware downgrades and other tricks.
