Hikvision DS-7716NI-I4/16P(B) won't update over TFTP

[mattip]

Hello, I have been following the guidance on this forum and others to try and reflash my DS-7716NI-I14/16P(B). I purchased it from a site that auctions off Amazon returns and someone else had activated it. I have a few other Hikvision NVRs and cameras but didn't realize there wasn't a simple (e.g. hold a button down for 15 seconds) to factory reset them. I've read that forcing an update over TFTP can cause it to return to the unactivated state so I have been trying that unsuccessfully for several evenings now.

NVR stats from SADP:
DS-7716NI-I4/16P(B)
192.168.2.10
V4.51.025build 210927
DS-7716NI-I4/16P1620211206CCRRJ19971110WCVU

I'm currently running the Scott Lamb tftp server on a linux box and it seems to serve up firmware just fine. I've noticed mine calls for a file named "uImage" instead of digicap.dav so I have been renaming the firmwares downloaded.

The uploading seems to work but the NVR never updates.


Here is the serial (RS232) console output. Sometimes, it seems like the NVR crashes after the TFTP completes such as here:

U-Boot 2010.06-svn60600 (May 07 2021 - 19:23:56)

Hit ctrl+u to stop autoboot:  0
HKVS $ setenv ';tftp'
timeout for link [4999]!
MAC:   24-0F-9B-04-61-3D
TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Download Filename 'uImage'.
Download to address: 0x40008000
Downloading: #  [ Connected ]
################################        [16.000 MB]
################################        [32.000 MB]
################################        [48.000 MB]
###############
done
Bytes transferred = 58703908 (37fc024 hex)
MAC:   24-0F-9B-04-61-3D
undefined instruction
pc : [<43006ed8>]          lr : [<4dc194f4>]
sp : 4dafed78  ip : 4dafed54     fp : 00000000
r10: 00000000  r9 : 4dafee59     r8 : 4dafffe0
r7 : 4dc4dab8  r6 : 4dc3fc7c     r5 : 43011734  r4 : 00000001
r3 : 00000000  r2 : 4dc3c124     r1 : 00000002  r0 : 00000000
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

resetting ...


U-Boot 2010.06-svn60600 (May 07 2021 - 19:23:56)

Hit ctrl+u to stop autoboot:  0
Mounting yaffs2 mount point/partnum: nand/0
Configures yaffs mount nand success!
Copy /nand/uImage to 0x42000000...      [DONE]
   Verifying RSA ... OK
## Booting kernel from Legacy Image at 42000000 ...
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] need to Authorization
[    4.819466] init(1) called reboot syscall, cmd: 0x0.
[    8.773754] libphy: 1:07 - Link is Up - 1000/Full

if I reboot it and then try to run the update command, it looks like it starts and then immediately goes into a normal boot:

U-Boot 2010.06-svn60600 (May 07 2021 - 19:23:56)

Hit ctrl+u to stop autoboot:  0
HKVS $ setenv ';update'
using update v3...
Mounting yaffs2 mount point/partnum: nand/0
Configures yaffs mount nand success!
Copy /nand/uImage to 0x42000000...      [DONE]
the uImage support update_v3.
   Verifying RSA ... OK
## Booting kernel from Legacy Image at 42000000 ...
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] need to Authorization
[    4.819486] init(1) called reboot syscall, cmd: 0x0.
[    8.773767] libphy: 1:07 - Link is Up - 1000/Full

Here are the commands available and environment variables:

U-Boot 2010.06-svn60600 (May 07 2021 - 19:23:56)

Hit ctrl+u to stop autoboot:  0
HKVS $ setenv ';help'
?       - alias for 'help'
bootm   - boot application image from memory
ddr     - ddr training function
getinfo - print hardware information
go      - start application at address 'addr'
help    - print command description/usage
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mw      - memory write (fill)
nand    - NAND sub-system
nboot   - boot from NAND device
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
tftp    - tftp  - download or upload image via network using TFTP protocol
version - print monitor version
HKVS $ setenv ';printenv'
bootcmd=tftp 0x42000000 $(bootfile);bootm 0x42000000;
bootdelay=1
baudrate=115200
ipaddr=192.0.0.64
serverip=192.0.0.128
gatewayip=192.0.0.1
netmask=255.255.255.0
bootfile=uImage
ver=U-Boot 2010.06-svn60600 (May 07 2021 - 19:23:56)
hik_ver=verison V2.0-60479-60600 (build 20210507192422 root)
passwd=qhd8+R+/+bA3LAxq5mKUm2XoOMpMiRbdRJt/slrzq7A=
stdin=serial
stdout=serial
stderr=serial
phyaddr0=1
phyaddr1=7
mdio_intf=rgmii
ethaddr=24:0f:9b:04:61:3d
sec=tftp 0x42000000 Ky2015-1-H3536-uImage_sec;bootm 0x42000000;
default=y2mount /nand;y2rdm /nand/uImage 0x42000000;
verify=n
tftpblocksize=8192
bootargs=mem=1148M console=ttyS0,115200n8 auth=1

Here are the firmwares I have tried, all from Hikvision Europe Portal

• V4.51.025 build210927 (currently loaded firmware)
• V4.60.000 build211129
• V4.60.005 build220108
• V4.61.010 build220527
• V4.61.025 build220905 (latest)

All cause a similiar result. Any suggestions to get this NVR deactivated?

Thanks,

Matt

 

[mattip]

Here's the TFTP output that wouldn't fit in first post:

TFTP server output:

Setting block size to 512
Serving 58703908-byte uImage (block size 512, 114657 blocks)
Thu Mar 23 13:08:58 2023: received unexpected tftp bytes '0001646967696361702e646176006f637465740074696d656f7574003100626c6b73697a650038313932006f66667365740030006c656e677468003134373200' from 192.0.0.64:41630
read request options: {'tsize': '0', 'blksize': '8192', 'timeout': '1'}
Setting block size to 8192
Serving 58703908-byte uImage (block size 8192, 7167 blocks)
Thu Mar 23 13:12:21 2023: sending options ack
Thu Mar 23 13:12:21 2023:     1 /  7167 [                                                     ]
...
Thu Mar 23 13:12:39 2023:  7167 /  7167 [#####################################################]
Thu Mar 23 13:12:39 2023: done!
Setting block size to 512
Serving 58703908-byte uImage (block size 512, 114657 blocks)
Thu Mar 23 13:16:12 2023: received unexpected tftp bytes '0001646967696361702e646176006f637465740074696d656f7574003100626c6b73697a650038313932006f66667365740030006c656e677468003134373200' from 192.0.0.64:55653
Thu Mar 23 13:35:39 2023: received unexpected tftp bytes '0001646967696361702e646176006f637465740074696d656f7574003100626c6b73697a650038313932006f66667365740030006c656e677468003134373200' from 192.0.0.64:36963
Thu Mar 23 13:37:17 2023: received unexpected tftp bytes '0001646967696361702e646176006f637465740074696d656f7574003100626c6b73697a650038313932006f66667365740030006c656e677468003134373200' from 192.0.0.64:58124

 

[mattip]

If anyone can get my DS-7716 working, I'll send you my DS7604NI-SE/P that I'd like to replace with the new NVR. Just pay shipping. Unlocked of course

 

[alastairstevenson]

Renaming digicap.dav to uImage (ie the Linux kernel) won't work as it's packed firmware, not an executable file.

A neat way to extract an admin password from a Hikvision NVR is to connect an Inactive camera that has firmware from 5.3.0 to 5.4.0 to an NVR PoE port.
By default (unless a savvy user has used the option to separate the passwords) the camera is Activated using the NVR admin password.
Then, if the camera has the 'Hikvision backdoor' vulnerabilty (most except G0 series) the configuration file can be extracted with no authentication.
When decrypted and decoded the password is available in plain text.

Alternative way of recovering HikVision NVR password

The firmware on the camera is V3.0 FP10. I just managed to get the camera back working. It is a Interlogix TVW-5305. I took it off the wall when it stopped responding. The reason I could get into the camera was because the default admin password was left on this one. (1234) So I did a...

ipcamtalk.com

 

[mattip]

Thanks for the reply! I have a pair of decommissioned DS-2CD2332-I cameras. I'll check the firmware on them tonight

 

[mattip]

I actually found 3 old cameras, 2 hikvision and one white label hikvision. I couldnt connect to any or see them in SADP. They're probably configured with a static IP that conflicts with other cameras. Will set up a segregated network later.

 

[mattip]

I don't know what happened but I can't connect to any of the three older cameras I found. I know they were all working when I removed them from service. When connected to my main POE switch, I could see the IR light come on but they never showed up in SADP or a network scan. I grabbed a 4 port switch and POE injector and connected the camera to my laptop directly (isolated from rest of network) and still nothing on SADP or a network scan. I did see one of the cameras reaching out to 192.0.0.128 on startup with Wireshark so I used the Hikvision TFTP server to push 5.4.0 and that appeared to be successful based on messages from TFTP but I don't have serial access to the camera to know for sure. Still nothing after the update. I also plugged all 3 cameras one by one into a spare port on my old 4 channel NVR and configured it for plug n play but still no dice. To add insult to injury, i rebooted the old NVR to see if that could help it find the camera and it isn't coming back online so who knows what is going on there!

I noticed in one of the password reset pages for the new DVR there was a masked email address. Do you know of a way to unmask it so i could try emailing the previous owner?

 

[alastairstevenson]

I can't connect to any of the three older cameras I found. I know they were all working when I removed them from service.

Despite that it seems you know what you are doing - it does seem odd that all 3 previously working cameras don't show in SADP.
With no insult intended, I'd look for a common cause other than the cameras.
But from what you've tried and described, it's not obvious what, except maybe some aggressive network protection app on the laptop getting in the way.
SADP is pretty good at finding Hikvision devices whatever the IP address segment they are configured on.

I used the Hikvision TFTP server to push 5.4.0 and that appeared to be successful based on messages from TFTP

'Firmware update successful' ?
If so - these older cameras would likely move to a default IP address of 192.168.1.64 after a power cycle.

Also - if the old NVR works again - check if that model has the 'Quick add' button in the web GUI when a camera is connected to one of it's PoE ports.
That does an SADP-like search for Hikvision devices.

 

[mattip]

I'm hoping the old NVR wasn't booting because I forgot to shut down the TFTP server on my linux box. I went and looked at the console output from the TFTP server and saw that the old NVR tried to connect but it didn't look like anything was pushed to it. At the time, I didn't think to shutdown the TFTP server and reboot the NVR so I'll give that a try tonight. I wasn't even getting something on the HDMI output for it so it is failing to boot for some reason.

If I never get the old NVR and cameras sorted out, is there another path in to the new NVR? You'd mentioned before:

Renaming digicap.dav to uImage (ie the Linux kernel) won't work as it's packed firmware, not an executable file.

Can I issue a command over serial to initiate a proper firmware update?

 

[alastairstevenson]

the TFTP server on my linux box.

The Hikvision tftp updater - and the Scott Lamb clone of it, and SADP - are Windows applications.
Are you running Windows in a VM on it to provide the environment for SADP and the tftp updater?
If so - could that be the reason why SADP doesn't find the Hikvision devices?

Does the DS-7716NI-I4 NVR show in SADP?

Can I issue a command over serial to initiate a proper firmware update?

On all the Hikvision NVRs that I've seen the first thing that comes up on the serial console when keeping Control-U pressed at power-on is the firmware update dialogue, like this :

U-Boot 2010.06-svn (Aug 14 2015 - 14:50:25)

Hit ctrl+u to stop autoboot:  0

This program will upgrade software.
*******************************************************
*  ATTENTION!! PLEASE READ THIS NOTICE CAREFULLY!     *
*  Don't reset machine,or anything that interrupt it. *
*  The upgrade process must finish in 10 minutes!     *
*  If this program fails,machine might be unusable,   *
*  and you will need to reflash again.                *
*  If you find this too risky,power off machine now.  *
*******************************************************

Now press [u/U] key to upgrade software:

 

[mattip]

The Hikvision tftp updater - and the Scott Lamb clone of it, and SADP - are Windows applications.
Are you running Windows in a VM on it to provide the environment for SADP and the tftp updater?
If so - could that be the reason why SADP doesn't find the Hikvision devices?

The Scott Lamb clone of it runs in python2 and was designed to be run in linux but should run anywhere. I just ran it on a linux box because it was easier to "sudo apt install python2" then go find and download it for Windows (I only had python3 at the time). The rest of my work (including trying the Hikvision TFTP server) were done on two Windows 10 machines. Nothing was done in a VM. On my W10 desktop, I was using what I think to be the latest version of SADP from the Hikvision Tools page.

Does the DS-7716NI-I4 NVR show in SADP?

Yes, the 7716 NVR showed up right away in SADP and I am able to connect to the web interface by manually changing my IP address to be on the 192.168.0.x subnet.

On all the Hikvision NVRs that I've seen the first thing that comes up on the serial console when keeping Control-U pressed at power-on is the firmware update dialogue, like this :

U-Boot 2010.06-svn (Aug 14 2015 - 14:50:25)

Hit ctrl+u to stop autoboot:  0

This program will upgrade software.
*******************************************************
*  ATTENTION!! PLEASE READ THIS NOTICE CAREFULLY!     *
*  Don't reset machine,or anything that interrupt it. *
*  The upgrade process must finish in 10 minutes!     *
*  If this program fails,machine might be unusable,   *
*  and you will need to reflash again.                *
*  If you find this too risky,power off machine now.  *
*******************************************************

Now press [u/U] key to upgrade software:

That did not show up for me, I just get this:

U-Boot 2010.06-svn60600 (May 07 2021 - 19:23:56)

Hit ctrl+u to stop autoboot:  0
HKVS $

I just get a prompt and I have to prepend every command with setenv ";<command>"

Can I maybe upload an older version of U-boot that'll prompt to update the firmware?

 

[alastairstevenson]

Ok, that's clear.
The NVR is unusual in not having the update dialogue in the bootloader.

Odd about the cameras though.

I'm struggling to suggest anything useful.

 

[mattip]

I appreciate you taking the time to think about it!

 

[mattip]

Since the issue with the NVR not going into update mode automatically happens at the u-boot level and running the tftp command from the u-boot shell seems to try and update u-boot itself, would a u-boot image from another NVR help restore the tftp firmware update capability? Can a u-boot image be extracted from a working NVR or is there a copy online somewhere?

 

[liam5542]

Since the issue with the NVR not going into update mode automatically happens at the u-boot level and running the tftp command from the u-boot shell seems to try and update u-boot itself, would a u-boot image from another NVR help restore the tftp firmware update capability? Can a u-boot image be extracted from a working NVR or is there a copy online somewhere?

i had this on one of mine what i did in bootmenu is type
setenv ';help'
it should bring up all the stuff you can do in the bootmenu

then i do all the stuff that had to do with boots, flahing, cpu etc

i got my nvr into a state where it wouldnt boot and it was just more or less bricked, once nvr was bricked i turned it off and on let it full try boot till it failed then turn it off go into putty and click ctrl+u

then update through tftp and use tftp64 to send the file

i noticed afew things like the nvr wouldnt let me update unless it knew it was F****d, also i noticed if sending the file fails it wont let you send another until you reboot let nvr full boot then reboot and go into putty to try send it again

 

[mattip]

@liam5542 Are you saying that you intentionally bricked it and then that let you use the recovery options? If so that might be something to try. Do you recall how you got that to work? Thanks!