How to Fix a Bricked Hikvision IP Camera Firmware

How to Fix a Bricked Hikvision IP Camera firmware by using Wireshark to discover the camera’s IP address and update the firmware via TFTP. My Hikvision DS-2CD6412FWD-10 1.3MP Covert Network Camera bricked (i.e. inoperable) after upgrading the firmware. All standard recovery methods failed including a Factory Reset, TFTP server and USB-to-RS232 serial port session. The trick was using Wireshark to discover the camera’s rogue IP address after performing a factory reset to downgrade the firmware with TFTP.

How to Fix a Bricked Hikvision IP Camera Firmware

I’d purchased an authentic “red box” USA version Hikvision HD Covert Network Camera. The camera has a UL Listed sticker on the bottom of the unit:

HikVision HD Covert Network Camera DS-2CD6412FWD

HikVision HD Covert Network Camera DS-2CD6412FWD

The red box label states the camera’s factory default IP address is 192.0.0.64. This should be the IP address after pressing the camera Reset button to force a factory reset:

HikVision DS-2CD6412FWD-10 1.3MP Covert Network Camera

HikVision DS-2CD6412FWD-10 1.3MP Covert Network Camera

The normal process to recover a bricked camera after a failed firmware upgrade is to downgrade to a known working firmware version using TFTP. However, TFTP always failed for me. It was confounding because I set my laptop IP address to 192.0.0.128 expecting the camera to be at 192.0.0.64 after a factory reset. Moreover, I could *briefly* ping the camera at 192.0.0.64 after it powered-up, then the unit was dead. Nor could the Hikvision SADP Tool could not find the camera.

I’ve installed about 1/2 dozen Hikvision IP cameras and a Hikvision NVR. All units are authentic USA versions and I’ve had no issues upgrading the firmware until now.

EdgeRouter Lite Home Network Wall Rack

EdgeRouter Lite Home Network Wall Rack

Hikvision Serial Port Console Recovery Method

Taking a cue from the UART connection to recover Hik cameras at ipcamtalk.com, I bought a USB to TTL Serial Cable from Amazon.com to make a three wire (Ground, Transmit and Receive) serial connection (115200, 8, N, 1, no flow control) to the camera. The PuTTY session was helpful but the camera would not respond to keyboard input, so I couldn’t interrupt the boot process by pressing Ctrl+u to run TFTP from the command line:

U-Boot 2010.06-113941 (Feb 03 2015 - 11:17:39)

ARM clk: 1000MHz
DDR clk: 533MHz
L3 clk: 240MHz
IVA clk: 410MHz (HDVICP)
ISS clk: 480MHz
DSS clk: 240MHz
DSP Default OFF

I2C: ready
DRAM: 512 MiB
Hit Ctrl+u to stop autoboot: 0
link up on port 0, speed 100, full duplex
|NUL ethaddr| not found tftpserver
load kernel to 0x80007fc0 ... Done!
## Booting kernel from Legacy Image at 80007fc0 ...
Image Name: Linux-2.6.37_DM385_IPNC_3.00.00
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3010864 Bytes = 2.9 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty '': '/etc/init.d/rcS'

init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty '': '/etc/init.d/rcS'
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty Starting udev: '': '/etc/init.d/rcS'
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty Starting udev: '': '/etc/init.d/rcS'
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty Starting udev: '': '/etc/init.d/rcS'
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty Starting udev: '': '/etc/init.d/rcS'
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty Starting udev: '': '/etc/init.d/rcS'
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)
starting pid 51, tty Starting udev: '': '/etc/init.d/rcS'
[ OK ]
init started: BusyBox v1.19.3 (2015-10-29 17:44:21 CST)

==================== ====================

starting pid 51, tty Starting udev: '': '/etc/init.d/rcS'
route: ioctl 0x890c failed: No such process

BusyBox appears to be stuck in a start-up loop. Also notice the line:

|NUL ethaddr| not found tftpserver

This means the camera was trying to contact a TFTP server but couldn’t find it at the expected IP address. My PC was running the TFTP server at 192.0.0.128 but the camera couldn’t reach it.

Bricked Hikvision IP Camera Recovery with Wireshark

I setup an isolated network using an unmanaged PoE switch between my laptop and the camera. The laptop has the following tools and files:

  • Wireshark – network protocol analyzer and packet capture
  • Win10Pcap – Ethernet packet capture library for Windows 10.
    Wireshark includes the older WinPcap library however it’s not Windows 10 compatible.
  • Hikvision SADP Tool
  • Hikvision TFTP server
    The Hikvision TFTP server software is no longer officially distributed. You can also use your favorite TFTP server software.
  • Hikvision Firmware for your camera.
    USA firmware is at ftp://ftp.hikvisionusa.com/
    User name: hikfirmware
    Password: Hikvision123
Fix Bricked HikVision IP Camera - Firmware Upgrade Downgrade Network Diagram

Fix Bricked HikVision IP Camera – Firmware Upgrade Downgrade Network Diagram

The PoE switch, IP camera and laptop per the above network diagram:

Isolated Network to Fix Bricked Hikvision IP Camera Firmware

Isolated Network to Fix Bricked Hikvision IP Camera Firmware

My camera was shipped with firmware V5.3.0 build 150513. Hikvision says that firmware upgrades must be applied sequentially. I found that downgrading to V5.1.7 140904 works fine, re-installing V5.3.0 build 150513 is good but upgrading to V5.3.6 151031 or v5.3.6 160218 mid FW in any sequence always bricks the camera. The cryptic note in the FTP directory “Please upgrade the mid FW first before v.5.3.6.txt” didn’t work as I tried that too:

HikVision USA FTP Firmware Listing - DS-2CD6412FWD-C2

HikVision USA FTP Firmware Listing – DS-2CD6412FWD-C2

The good news is with the solution I describe here I can downgrade the firmware at will and recover the camera.

Use Wireshark to Discover the Camera’s Actual IP Address

Wireshark is a free network packet capture and protocol analyzer. The beauty of Wireshark is it will capture all network traffic on an Ethernet interface, including traffic not in the same IP subnet as your computer. A basic Ethernet port capture is easy – see this tutorial if you’re new to Wireshark.

The steps to using Wireshark are:

  1. Unplug the laptop network cable, disable WiFi and all anti-Virus and Windows firewalls to eliminate possible problems, then plug the laptop cable into the PoE switch and set the laptop IP address to 192.0.0.128, which should be in the same subnet as the factory default camera IP address of 192.0.0.64.
  2. Copy the desired camera firmware digicap.dav file to the same directory as the TFTP.exe application on the laptop.
  3. With the camera powered Off (unplugged from the PoE switch), I started Wireshark and selected the laptop Ethernet port to begin the packet capture. No “filters” are required because there’s minimal traffic on the isolated network.
  4. Plug the camera Ethernet cable into the PoE switch to boot it.
    If you haven’t already performed a factory reset, press and hold the Reset button for at least 10 seconds when plugging in the Ethernet cable.
Camera IP Address is 192.168.1.64 instead of Factory Default 192.0.0.64

The Wireshark packet trace revealed the camera was using the IP address 192.168.1.64 instead of the expected 192.0.0.64 address after performing a factory reset! Recall that during camera startup, it would *momentarily* be pingable at 192.0.0.64 which led me to believe my laptop was set the correct IP address/subnet. Why was the camera booting at the factory default IP then changing it’s IP address to something else? I’ve never had the 192.168.1.0/24 subnet on my network! Furthermore, the NetGear GS728TP switch I’m using was factory reset and has a default IP address of 192.168.0.239 nor does it have a DHCP server to assign an IP address to the camera.

In the following Wireshark capture, the I see the Hikvision camera is “Hangzhou” at 192.168.1.64:

Fix Bricked Hikvision IP Camera after Firmware Update - Wireshark Packet Capture

Fix Bricked Hikvision IP Camera after Firmware Update – Wireshark Packet Capture

A Google search for “Hikvision 192.168.1.64” reveals that IP address is the factory default for some cameras. Another hint is this thread at ipcamtalk.com where a knowledgeable person states:

“The camera has gone into the ‘minimum system mode’ where it’s running with a bare kernel only, usually because an incorrect version of firmware has been applied and it can no longer fully boot.”

Now I know to do:

  1. Change my laptop IP address to 192.168.1.128 so it’s in the same subnet as the camera.
  2. Close and restart the TFTP application.
  3. Power cycle the camera to reboot it by unplugging the Ethernet cable, then plug it back into the Ethernet switch.

With my laptop, TFTP server and camera all in the same subnet, the camera found the TFTP server and downloaded the digicap.dav firmware image:

Hikvision IP Camera - TFTP Server Firmware Update Successful

Hikvision IP Camera – TFTP Server Firmware Update Successful

Tip: To view the full size images, click the image to display it in a pop-up window. Then right-click on the image and select “View Image” (FireFox) or “Open image in new tab” (Chrome).

Scrolling through the Wireshark packet capture also shows the TFTP transfer from my laptop [“Dell” at 192.168.1.128 to the camera [“Hangzhou” at 192.168.1.64]:

Hikvision IP Camera - TFTP Server Firmware Upgrade or Downgrade WireShark Packet Trace

Hikvision IP Camera – TFTP Server Firmware Upgrade or Downgrade WireShark Packet Trace

With the laptop and camera are both in the same 192.168.1.x subnet, the SADP Tool finds the camera:

Hikvision SADP Tool Finds IP Camera

Hikvision SADP Tool Finds IP Camera

When finished upgrading the camera, remember to re-enable your anti-Virus and Windows firewall before connecting to WiFi or the Internet.

Hikvision IP Camera Firmware Upgrade & Downgrade

Now that I know how to fix the bricked camera, I experimented with various firmware version upgrade & downgrades. I learned that:

  • Using Wireshark to discover the actual camera IP address, I can install any firmware version without restrictions via the TFTP server running on my laptop.
  • For the DS-2CD6412FWD-10 model that I have, TFTPing any firmware v5.3.6 always bricked the camera even when doing sequential version upgrades.
  • When the camera is not bricked, I can upgrade firmware via the camera web GUI yet all 5.3.6 versions brick the camera.
  • When the camera is bricked, the TFTP firmware downgrade always works.
  • Numerous factory Resets didn’t change the camera behavior: when bricked it boots at 192.0.0.64, changes to 192.168.1.64 and dies.

So I’m stuck at firmware version V5.3.0 build 150513. I’ll try upgrading to a newer version (5.4?) when available.

Some cameras users are of the opinion “if it ain’t broke don’t fix it”. Unfortunately that prevents you from taking advantage of new features and security patches. Because IoT devices have a generally poor record of security vulnerabilities and my general lack of trust in IoT devices, I isolated my cameras and NVR behind a firewall and VLAN which blocks all traffic to the Internet and other VLANs. Internet remote access via Port forwarding is disabled/blocked and I only access my cameras through an encrypted OpenVPN tunnel. Therefore I can live with outdated firmware if it’s my only option.

Best,

Bob

Copyright © 2017 HandymanHowTo.com   Reproduction strictly prohibited.

No comments yet.

Leave a Reply