HIKVISION mtd Brick Recovery Guide

[alastairstevenson]

OK, a couple of things to add, as the method certainly works OK given the right environment:
Wire the laptop to the switch or router, no WiFi.
Wire the camera to the same switch or router.
Ensure the digicap.dav file is in the same folder as tftpserve.exe
Check your Windows firewall Advanced Settings | Inbound Rules for allow, TCP and UDP, Private network for tftpserve.exe And Public network for good measure.
No anti-virus with network access protection, such as Symantec End-point Protection?

And in what way did it not work?
What info if any on the 'Hikvision tftp server' status screen? 'Connect' status is good.

 

[Karol Perkowski]

Already did that.

Hooked up a laptop to a switch. Turned off the wifi. Set the ethernet interface to 192.0.0.128/24. Ran the tftp server from hikvision. Made sure the digicap.dav file exist in the same folder as the tftpserver executable. Make sure the firewall was turned off. Rebooted the camera and had a continuous ping running to 192.0.0.64. Saw 3 ICMP replies and then nothing. No activily on the tftp server or on the ICMP request.

 

[Karol Perkowski]

Okay. I've been thinking and well trying a bunch of different things. Does it matter the distance of the camera? Right now it's 22-30 feet away. The other camera I was able to recover easy because it was only on a 7 foot cable to the switch. Maybe this has anything to do with it?

 

[whoslooking]

As long as it's on your local network distance does not matter.

 

[alastairstevenson]

Make sure the firewall was turned off.

May not be sufficient.

Check your Windows firewall Advanced Settings | Inbound Rules for allow, TCP and UDP, Private network for tftpserve.exe And Public network for good measure.
No anti-virus with network access protection, such as Symantec End-point Protection?

If you find any rules relating to tftpserve.exe - delete them. Then ensure the 'Allow' rules as above are applied.

 

[Karol Perkowski]

@whoslooking - Then I think this thing is fudged. @alastairstevenson - I turned off the firewall and disabled the windows firewall service. No difference. It just replies to 3 ICMP requests and goes dead.

 

[whoslooking]

Don't rely on an IP trace to see what's going on, it so hard to kill one of these baby's.
If you can try another PC it may be worth a shot, I found running the tftpfrom the C: drive can also help.

 

[Karol Perkowski]

@whoslooking - I'll give it another try. It's just weird that it will boot up in its redboot like state. Then go away for about 5 minutes before appearing on SADP as 192.168.1.64. Running a nmap scan doesn't show much of any port listening. Just like others have expressed.

 

[alastairstevenson]

As @whoslooking suggests - it is quite hard to really kill these with a firmware update.
OK, if you're into nmap then with both the camera and PC wired to a switch, and ideally with nothing else connected, and the PC IP address set to 192.0.0.128 and the tftpserver started run wireshark or similar and look for the network traffic as the camera is powered on:
The ARP request from 192.0.0.64 for the device on 192.0.0.128
Then the UDP packet that 'probes' the 192.0.0.128 device for the Hikvision tftp handshake response ("SWKH" in the payload), example fragment below:

22 10.0508867   192.0.0.64 ALASTAIR4  UDP UDP:SrcPort = 9979, DstPort = 9978, Length = 28 {UDP:6, IPv4:5}
23 10.0513239   ALASTAIR4  192.0.0.64 UDP UDP:SrcPort = 9978, DstPort = 9979, Length = 28 {UDP:6, IPv4:5}

If you see that - but nothing on the PC - then your PC is ignoring/blocking the traffic.

 

[whoslooking]

It's easy when it works and bastard when it doesn't, 9 of 10 times there is a rule somewhere in the firewall stopping this from happening, if it's visible on 192.168.1.64 it's still siting on 5.30.
It's looking for 1 of 3 packets to start the tftp connection from 192.0.0.64
But another PC normally you have never done tftp on should work 1st time.

 

[Karol Perkowski]

@alastairstevenson - I'll try this remotely from work today. I'm wondering if my switch is doing something crazy. Worst case I'm going to bring the Ethernet tap we have at work and watch the mirror port.

@whoslooking - I have other cameras (white box) that took the 5.3.0 upgrade without issues. Not sure why this POS isn't taking it and having it do this 192.168.1.64 with everything disabled is horse shit. At lease give a ssh to reset the unit.

 

[alastairstevenson]

I'll try this remotely from work today.

You can power-cycle the camera remotely? Impressive.

 

[whoslooking]

There is a possibility it's a Chinese model! have you checked the serial number to make sure it's not CCCH in the middle?

 

[whoslooking]

There is the problem, brown box = Chinese model.
You won't be able to get 5.25 or 5.28 any higher than they are. ATM
What was the original firmware version installed on the camera? (ON THE BOX AND CAMERA STICKER)

 

[Karol Perkowski]

You can power-cycle the camera remotely? Impressive.

Yes. I have a POE+ switch. I just disable and enable the poe on the port that the camera is plugged in.

- - - Updated - - -

5.25.

 

[Karol Perkowski]

@whoslooking - So what you're saying.. is that we have to wait for the successor firmware of 5.30 to fix this?

 

[whoslooking]

@whoslooking - So what you're saying.. is that we have to wait for the successor firmware of 5.30 to fix this?

No, we have ways to make it work lol.
Try this firmware 1st.

https://www.dropbox.com/s/bhyrai2kpu1bqge/ML 4 Line intrusion Downgrader.rar?dl=0

 

[Karol Perkowski]

I was going to say that sucks. OK. I'll give that a spin. BTW, looking at my switches FDB. I noticed the switch learned two mac address. Not sure if anyone finds that interesting.

 

[whoslooking]

I've seen the MAC change, model version and serial number, all change with the wrong firmware on a NVR,

 

[Karol Perkowski]

OK. BTW, no go with that firmware. I don't even see a attempt for any frames to 192.0.0.128.

192 243.579199 192.0.0.128 -> 192.0.0.64 ICMP 74 Echo (ping) request id=0x0001, seq=1126/26116, ttl=128
193 248.579399 192.0.0.128 -> 192.0.0.64 ICMP 74 Echo (ping) request id=0x0001, seq=1127/26372, ttl=128
194 253.578579 192.0.0.128 -> 192.0.0.64 ICMP 74 Echo (ping) request id=0x0001, seq=1128/26628, ttl=128
195 258.578793 192.0.0.128 -> 192.0.0.64 ICMP 74 Echo (ping) request id=0x0001, seq=1129/26884, ttl=128
196 263.578996 192.0.0.128 -> 192.0.0.64 ICMP 74 Echo (ping) request id=0x0001, seq=1130/27140, ttl=128
197 268.578116 AsustekC_10:4d:b4 -> Hangzhou_42:c9:fb ARP 42 Who has 192.0.0.64? Tell 192.0.0.128
198 268.578192 192.0.0.128 -> 192.0.0.64 ICMP 74 Echo (ping) request id=0x0001, seq=1131/27396, ttl=128
199 269.578161 AsustekC_10:4d:b4 -> Hangzhou_42:c9:fb ARP 42 Who has 192.0.0.64? Tell 192.0.0.128
200 270.578200 AsustekC_10:4d:b4 -> Hangzhou_42:c9:fb ARP 42 Who has 192.0.0.64? Tell 192.0.0.128
201 273.578383 AsustekC_10:4d:b4 -> Broadcast ARP 42 Who has 192.0.0.64? Tell 192.0.0.128
202 274.578353 AsustekC_10:4d:b4 -> Broadcast ARP 42 Who has 192.0.0.64? Tell 192.0.0.128
203 275.578398 AsustekC_10:4d:b4 -> Broadcast ARP 42 Who has 192.0.0.64? Tell 192.0.0.128