TFTP updating latest OEM Hikvision devices (manufacture date 05/2021)

Well, I'll be damned... I have been making things way more complicated that they were!

For whatever reason, the camera is indeed asking for a firmware with a filename flag*23b05_1, and of course I can not give it that name under Windows. But the Python updater has a --filename parameter!
$ sudo ./hikvision_tftp.py --server-ip=172.9.18.80 --filename=digicap.mav
github.com

hikvision-tftpd/README.md at master · scottlamb/hikvision-tftpd

Unbrick a Hikvision device (NVR or camera) via TFTP - scottlamb/hikvision-tftpd
github.com github.com

So I just copied the digicap.dav as flag*23b05_1, and there we go, the camera got updated.
Captura.JPG

In case someone wants me to check anything over the serial console with the original firmware, let me know. For now I will be keeping the camera with the connector for the cable with the original firmware.
 
  • Like
  • Wow
Reactions: alastairstevenson and watchful_ip
Very chatty!

Not a lot of new info on the tftp updater attempt, except to confirm the 'filename' apparently being requested.
I suspect this needs a modified version of the tftp updater program, that responds in a different way from the old Hikvision one.

It would be interesting to interrupt the bootloader, with Control-U and see what the help command shows for the available commands, and what the printenv command shows for the variables values.
There might just be an update command that works with a normal tftp server.
Though even if there was, the implication would be the non-ideal requirement to use the serial console to apply that firmware.
 
  • Like
Reactions: Securame
alastairstevenson said:
It would be interesting to interrupt the bootloader, with Control-U and see what the help command shows for the available commands, and what the printenv command shows for the variables values.
There might just be an update command that works with a normal tftp server.
Though even if there was, the implication would be the non-ideal requirement to use the serial console to apply that firmware.
Click to expand...

It did work with the Python TFTP updater, it just wasn't looking for the right filename.

Here is "help" and "printenv.
Code: 
HKVS # help
?       - alias for 'help'
erase   - erase flash except bootloader area
format  - format app_pri app_sec cfg_pri cfg_sec partition
go      -
god     - start application at address 'addr'
gos     -
gpio    - set the gpio
help    - print command description/usage
loadk   - load kernel to DRAM
loadlos - update LiteOS.bin
upbs    - update u-boot via serial
upc     - format cfg0 and cfg1 (factory use) via ethernet
update  - update digicap.dav via ethernet
updateb - update u-boot via ethernet
updatebnet- update u-boot_net via ethernet
updatebusb- update u-boot via usbnet
upf     - update firm, format and update (factory use) via ethernet
upfusb  - update firm, format and update (factory use) via usbnet
upla_jffs2- update sensor configuration file
upla_yaffs2- update sensor configuration file
upm     - update minisystem via ethernet
upmusb  - update minisystem via usbnet
?       - alias for 'help'
bootm   - boot application image from memory
help    - print command description/usage
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
reset   - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv  - set environment variables
HKVS # printenv
arch=arm
baudrate=115200
board=hi3516ev300
board_name=hi3516ev300
bootargs=console=ttyAMA0,115200n8 KRN_PRT=pri mdio_intf=mii phy_addr=<NULL> mac=08:a1:89:9b:1e:3d rst_flag=0 bld_rev=1028266 flash_type=spinor flash_size=16MB dram_size=128MB devtype=0x23b05 chip_id=0x1 trspt_mode=0x0
bootcmd=loadlos;bootm
bootdelay=3
cpu=armv7
dbg=0
ethact=eth0
ethaddr=08:a1:89:9b:1e:3d
gatewayip=192.168.1.254
ipaddr=192.168.1.64
mdio_intf=mii
netmask=255.255.255.0
serverip=192.168.1.128
soc=hi3516ev300
stderr=serial
stdin=serial
stdout=serial
trspt=0
trspt_mode=0
vendor=hisilicon
verify=n

Environment size: 628/65532 bytes
HKVS #

On the original firmware, other commands like ps, top, netstat, diag, prtHardInfo, all of them give an "Unknown command" error.

Before:
Firmware Version: V5.5.111 build 210120
Encoding Version: V7.3 build 200825
Web Version: V4.0.1 build 210119
Plugin Version: 3.0.7.16
Firmware Version Property: C-R-E7S-0

After:
Firmware Version: V5.5.111 build 200908
Encoding Version: V7.3 build 200825
Web Version: V4.0.1 build 200730
Plugin Version: 3.0.7.16
Firmware Version Property: B-R-E7S-0
 
  • Like
Reactions: alastairstevenson and watchful_ip
This has been a really great insight in to what this camera actually is inside.
 
  • Like
Reactions: Securame
Doesn't look like you even get a shell from the bootlog output.
 
Actually I've looked in to this more.

This is LiteOS, which is tiny (10Kb or so apparently). It doesn't have a linux shell but rather a SerialShellTask that offers a limited shell equivalent. It is actually pretty horrible to use and extremely limited.

You can get an idea of the commands from here:

usermanual.wiki

Developer Guide Lite OS V200R001C10

User Manual:
usermanual.wiki

It isn't running SSH.

Thanks again to Securame who was kind enough to field a number of questions and requests for help when I asked :) :)
 
  • Like
Reactions: Securame and alastairstevenson
Securame said:
It surely looks like there is something weird there,

Code: 
TFTP from server 192.168.1.128; our IP address is 192.168.1.64
Filename 'flag*23b05_1'.
Load address: 0x42800000
Loading: *
TFTP error: 'Invalid argument' (0)
Starting again

error: tftp.(error!)
error: digicap oversize. -1
TFTP server not found

I am able to stop the boot process with CTRL+U, and a "help" shows me the following commands available.
View attachment 97458

Is there anyway I can force the TFTP update from a given filename (digicap.dav) instead of "flag*23b05_1"?
Click to expand...
Well basicly TFTP sends the file however its called in same directory. Never had weird names.

Also G0E models works fine with my TFTP with given command update via serial. Never had any issue so far, and i pretty much unbrick about 5-10 devices per day.
Sometimes simple update wont work, but you can go with setenv ';update'
 
trempa92 said:
Well basicly TFTP sends the file however its called in same directory. Never had weird names.
Click to expand...
The point is that Hikvision have crudely attempted to put an obstacle in the way of using the tftp updater with those devices, by tweaking the dialogue to use a filename that is illegal under Windows.
Pointless in reality though, as the creative work of users allows the attempted obstacle to be sidestepped.
 
I had to update another two different OEM models, and I had to do the same process.

Another E7S series camera, manufactured on 03/21. It is a different camera than the one I used previously. And this time the filename it looks for is flag*23b06_1 instead of flag*23b05_1.
tmp1.jpg
tmp2.jpg

G5 series camera, this one manufactured on 07/21. And this one is looking for a digicap_G5.dav.
It is strange that at first Hikvision's TFTP actually tried to send the firmware; but since it only works with firmwares up to 32MB and this one is bigger, I guess it never finishes. The camera did not come back to live even after a reboot, but then I was able to happily updated it with the python TFTP updater.
tmp3.jpg
tmp4.jpg

So I guess that the firmware name might change quite often.
 
  • Like
Reactions: watchful_ip and alastairstevenson
Interesting stuff - thanks for that great info :)

The Hikvision TFTP server isn't good with large files. So I always use something else.

I wonder why the filename incremented - was this cam just 1 month newer than last time?
 
Had a look at this and looks like the filename is based on data in the bootparams (the device information table of the camera).

So it can change from camera to camera even with the same bootloader version.
 
  • Like
Reactions: alastairstevenson
watchful_ip said:
Had a look at this and looks like the filename is based on data in the bootparams (the device information table of the camera).

So it can change from camera to camera even with the same bootloader version.
Click to expand...

the question is what the camera is asking for when run update cmd ... if it ask for digicap.dav everything is fine.

also its no news that you need jounin tftpd to send bigger files...
 
You must log in or register to reply here.
Top Bottom