Hikvision DS-2032-I Console Recovery

[whoslooking]

Ok this is covered in this post on how to recover your bricked camera this covers all firmwares upto 5.2.8
See this post.http://www.ipcamtalk.com/showthread.php/3408-HIKVISION-mtd-Brick-Recovery-Guide?highlight=brick+recovery.

 

[dknabe]

It seems that uITRON PrKernel is running underneath everything on the camera. I'll bet uITRON is the system responsible for TFTP boot process that we all use. The PrKernal seems to be in mtdblock2. Does anyone have more information on how all this works? I've heard that Linux runs as a process in uITRON for other cameras (goPro?). So we are only getting part of the story if we look at Linux only on the HIKVison Raptor series.

 

[alastairstevenson]

I presume you are getting that from this string in the Das u-boot bootloader:

...USB download ...Version 0.1.Built @ ....Jul 16 2014. ..16:51:38....Download 1 firmware programming file....firmware program is loaded......Download 4 kernel files.....Prkernel is loaded......code is loaded......memd is loaded......default_bin is loaded

Maybe it's a component of u-boot, I haven't looked. Yet.

 

[dknabe]

See https://gist.github.com/cr3ative/8340001. The Drift HD Ghost "camera also runs on the Ambarella A5S chipset, which appears to run PrKERNEL (implementing uItron): http://www.esol.com/embedded/prkernelv4.html, then boots Linux as a process inside the uItron OS". So if U-Boot is the startup boot loader on the DS-2032, it kicks off the uITRON PrKernel. My guess is that the PRKernel actually does the SWKH handshaking on port 9978 for detecting a HIKVision TFTP server, then downloads digicap.dav via TFTP on port 69 into the /dav mtdblock. Once the the check for TFTP server presence is compete, it then kicks off the Linux kernel as a process of uItron. uITron manages some low level watchdog timers for different processes and will actually reboot the machine if it detects something is not right. For example, if the davinci process is killed from the command line, the uItron watch dog reboots the machine after a while. This description may not be exactly correct, but I'll bet I'm close. I'm working on understanding it better.

 

[alastairstevenson]

But isn't it u-boot that loads the ramdisk image and starts up the Linux kernel as a uImage, passing the needed command-line options and environment variables?

 

[dknabe]

Yes, u-boot does seem to boot Linux. And it defnitely takes care of the tftp download itself, or it works in conjunction with uITRON before Linux is ever started. Here's a console log when the DS-2032 camera is powered up with the HIKvision tftp server at 192.0.0.128. tftp is taken care of before the Linux kernel boots. There is no time lag after the 2 sec u-boot delay to the first [INFO][MIN] statement. Also, when the console is connected, it does not seem to reboot automatically after the tftp download process. If I give the u-boot command, "boot", it does then boot Linux. I still have a sneaking suspicion that uItron is lurking underneath - otherwise, why would the uItron code be there in mtd2?. Like I said, I'm still trying to figure this out. I would like to be able to trace execution through u-boot from initial start until the u-boot command prompt. Do you know the starting address of u-boot execution at power on?

DS-2032 RS232 console log at boot with tftp server active:

U-Boot 1.3.4-100728 (Nov 11 2014 - 13:58:34)
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 2^MHit Ctrl+u to stop autoboot: 1^MHit Ctrl+u to stop autoboot: 0
[ INFO][MIN]FORMAT: Formatting Flash
[ INFO][MIN]FORMAT: ...................................
[ INFO][MIN]FORMAT: Format Flash [OK]
[ INFO][MIN]TFTP: TFTP from server 192.0.0.128
[ INFO][MIN]TFTP: Filename: 'digicap.dav'
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################
[ INFO][MIN]TFTP: Download File [OK]
[ INFO][MIN]BURN: File size is 18862850 bytes (18420 KB)
[ INFO][MIN]BURN: Writing Flash
[ INFO][MIN]BURN: ....................................................
[ INFO][MIN]BURN: Write Flash [OK]
***** UPDATE COMPLETE *****

#

 

[alastairstevenson]

Sorry, I don't know the start address of u-boot at power-on. Its presumably built into the bootstrap.

So - does your camera fully boot now if it doesn't find a TFTP server, or if you issue the boot command manually? It certainly seems to be functional.

 

[alexander.omiz]

There is file named Hroot.img in the firmware 5.3.0, delte the first 64 bytes of it. Then extract the intrid file from it and you can found there is a comand to run psh before run ash. I was finding a way to inject telnet demone, but failed because of the hroot compress problems.

 

[alastairstevenson]

What I did on the NVR (using the really handy Hiktools to split / modify / create the firmware), was to rename psh and create a new symlink for psh to busybox.
And for the telnet access, modify startup.sh to activate telnet.
I expect something similar could be done on the cameras.

echo "-----------------<inhibit the busybox protected shell>---------------"
mv /bin/psh /bin/psh_orig
ln -s busybox /bin/psh

cp busybox-armv7l /bin
ls -al /bin
echo "-----------------<Add new Busybox commands to supplement existing>---------------"
/bin/busybox-armv7l --install -s /bin
# ls -al /bin Far too many to list!

 

[dknabe]

I'm still evaluating the situation with my DS-2032. I have rs232 connected, and can also telnet in at times and start ftpd - only if it is booted into the minisystem. I have also been able to run busybox-armv6l (obtained from http://www.busybox.net/downloads/binaries/latest/). The Ambarella A5S is an ARM v6 architecture, not an ARM v7. Something strange happened to my mtd5 block. Notice that something wrote the text "digicap.dav' to a location 0x0a (10) bytes higher, and was recovered by a partial overwrite in the correct location. (evidence is the left over gicap.dav) It's possible that the 5.3.0 firmware is the culprit, but I'm not at all sure of that. Right now I'm trying to craft the correct mtd5 and 6 blocks keeping checksum 16 correct, and using original mac addresses. I have 1 good camera that was purchased at the same time as the other 2, so I can do a lot of comparisons.

Corrupted mtd5 on DS-2032

0000000: 34b9 0d38 c000 0040 c000 0080 0000 0000  4..8...@........
0000010: ffff ff00 c056 e368 6ee6 ffff 0000 00c2  .....V.hn.......
0000020: 6469 6769 6361 702e 6461 7600 6769 6361  digicap.dav.gica
0000030: 702e 6461 7600 0000 0000 0000 0000 0000  p.dav...........
0000040: 6e75 6c6c 0000 0000 0000 0000 0000 0000  null............

 

[csm]

Hello
Has jemad the Serial port assignment of the camera.
An image Währe helpful.
Where man finds the Port

 

[alastairstevenson]

That does look a bit suspicious.
Are the 'hardware descriptor blocks' in both mtdblock5 and mtdblock6 all still intact?

I've not experimented much with the 5.3.0 firmware yet.
As far as I've been able to tell, the older firmware updates (ie 5.2.3 and below) don't write to mtdblock5 & 6, but 5.3.0 has additional anti-tamper features.
You will have noticed on other threads that on 2015 manufactured cameras the original span of the Checksum-16 checksum on the 'hardware descriptor block' has been changed. It's still a simple sum, as you can add and subtract contents successfully, but the full coverage isn't clear.

 

[alastairstevenson]

@csm http://www.ipcamtalk.com/showthread.php/2666-UART-connection-to-recover-Hik-cameras?highlight=uart

 

[dknabe]

Here are disassembly photos and pinout info for the rs232 port of the DS-2032.
http://www.cctvforum.com/viewtopic.php?f=19&t=37006&sid=2d97de12796dda691fc4c4e1e803abe2&start=15
See previous page for photos.

 

[dknabe]

OK, I finally got around to editing mtd5 and mtd6 to change the language to English per whoslooking's post. Thanks very much to whoslooking as well as alastairstevenson.

The complete camera console log to steady state is attached.

Not sure why I'm getting this in the log.

start!!!!!! HostSetAesSecretKey  !!!!!!!!
<CMD> ERR:(HostSetAesSecretKey not Enable!)
[05-26 19:06:07][pid:841][DSP][ERROR]Initial: the permanent code is disable.

 

[alastairstevenson]

So is the camera back into a fully working state?
That's quite a lot to interpret. And I'm always surprised at the quantity of errors that are treated as non-fatal. In an ideal world these should be cleaned up.
The content does seem different from that of earlier firmware versions, I'm assuming it's changed in 5.3.0. I have not yet applied the 5.3.0 firmware and a serial cable to my 'experimental' camera - I've got further exploration to do before progressing to a potential 'point of no return'. I don't see any mentions of Aes in my existing kernel logs, though there is an encryption key setting in Live View parameters on the NVR, maybe for protecting clips.

Here is a thing to try if you haven't already done so:
I know that in the 5.3.0 release notes it says 'telnet not available', but is SSH still available, and is the enable tickbox still in the web GUI?
I had a look in the 5.3.0 firmware contents and during initialisation it also creates the firewall 'DROP' rule for SSH, but still has 'dropbear' installed. In my running 5.2.5 dropbear always runs, it's simply the firewall rule that gets added or removed to activate or disable SSH.
So if SSH is not working on your 5.3.0 camera, try via the serial console '/sbin/iptables -F' to flush all the rules.

 

[dknabe]

I should have been more explicit in the earlier post. The DS-2032 camera is fully working on v5.2.5 in English. I modified mtd5 and 6 to change to Region 1 (English) from region 2. I changed the serial number (date area) to maintain checksum-16. For some strange reason, I wanted to keep the original mac address. It seems to work tho.

The date string starting at 0x685 in mtd5 (and other places in mtd6) is actually part of the serial number. However, even when I changed location 0x654 in mtd5 (and other places in mtd6) the system page still shows CCCH in the serial number - like DS-2CD2032-I20150123CCCH500xxxxxx. Based on my sample of 4 cameras from 2 Chinese vendors, I think the 500 after CCCH is the vendor ID. I have one camera from vendor 500 and one from vendor 503.

It seems that HIKVision firmware is full of hidden gotchas that will brick the average consumer's camera when they innocently try to upgrade firmware to the latest version. There are no warnings on the firmware upgrade page to warn people about the regional distributor battles and lockouts.

I'm hesitant to try upgrading to 5.3.0 since everyone says it won't work with Chinese cameras. If you think I should try 5.3.0, let me know before I disconnect my serial port console access.

 

[dknabe]

So I tried upgrading my DS-2032 camera from v5.2.5 to v5.3 via the maintenance page. I checked the digicap-v5.3.dav file with the hiktools.exe utility and it reports region 1. The camera also was region 1 per above mtd5,6 changes. The upgrade to v5.3 failed by refusal. At least the camera was not bricked again. The Maintenance page reported "Status ! The version of upgrade file mismatches."

Here's the console log during the upgrade: I'm not sure if the intial few statements are associated with the upgrade or not.

[05-27 07:25:20][pid:841][CGI][ERROR]Regionclip is not supported.
[05-27 07:25:20][pid:841][PSIA][ERROR]not support preview link num.
[05-27 07:25:20][pid:841][CGI][ERROR]isapi_get_preview_link_num failed.
No auth info req->url = /SDK/MutualCap
hikcgi_handler(): GET /SDK/MutualCap
[05-27 07:25:20][pid:841][UNI_IF][ERROR]mount type cfg is not supported.
[05-27 07:25:20][pid:841][PSIA][ERROR]uni_get_mount_type_cfg error
[05-27 07:25:27][pid:841][PSIA][ERROR]not supported hdd
[05-27 07:25:27][pid:841][PSIA][ERROR]selfext_storage:psia_gethddlistxml error!
[05-27 07:26:04][pid:841][PSIA][ERROR]************* PSIA Upgrading BEG **************
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_upglib_init][2179]:HIK CUR iDevType = 0x9805
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_upglib_init][2180]:HIK CUR SoftVers = 0x5020000
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_upglib_init][2181]:HIK CUR SoftDate = 0xe0c01
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_parts_init][1140]:firm upg part[1]: eUpgPrity=0x2,eFirmPart=0x2,eBkupPart=0x1
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_parts_init][1140]:firm upg part[2]: eUpgPrity=0x1,eFirmPart=0x1,eBkupPart=0x2
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_parts_init][1146]:ePartRun=0x1,ePartMain=0x1,ePartBakup=0x2,eUpgRdPart=0x0,iPartsNum=0x2
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_parts_init][1149]:eRetMain=0x0,iVersionFlg=0x10000,iUpgSuccCnt=0x1,iUpgFailCnt=0x0
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_parts_init][1152]:eRetBkup=0x0,iVersionFlg=0x10000,iUpgSuccCnt=0x1,iUpgFailCnt=0x0
UBI device number 2, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_upglib_proc][2135]:Firm iPackIdx=0 upgrade beg.
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_head_check][1275]:devs dev class=0x2,firm dev class=0x2.
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_head_check][1281]:devs oem class=0x1,firm oem class=0x1.
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_head_check][1299]:szDevsFlg=114005003111111001,szFirmFlg=1140050031111110011.
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_head_check][1347]:HIK UPG SoftVers = 0x5020003
[UPG][DEBUG_NOTICE][src/sys_firm_upgrade.c][firm_head_check][1348]:HIK UPG SoftDate = 0x226e0
[UPG][RT_ERROR][src/sys_firm_upgrade.c][firm_head_check][1356]:[UPG_ASSERT] pUpgInfo->pFirmHead->iFirmVers >= pUpgInfo->tUpgCaps.iVersnMin fail to eRetVal UPG_STAT_MISMATCH_VERSION=0x00000031!
[UPG][KEY_WARN][src/sys_firm_upgrade.c][firm_dev_check][1680]:[UPG_ASSERT] UPG_STAT_OK == (pUpgInfo->eMapStat = firm_head_check(pUpgInfo)) fail to WarnVal pUpgInfo->eMapStat=0x00000031!
[UPG][RT_ERROR][src/sys_firm_upgrade.c][firm_srcs_read][2007]:[UPG_ASSERT] UPG_STAT_OK == pUpgInfo->eMapStat fail to eRetVal pUpgInfo->eRetStat=0x00000031!
[UPG][RT_ERROR][src/sys_firm_upgrade.c][firm_upglib_proc][2144]:[UPG_ASSERT] UPG_STAT_OK == (eRet = firm_srcs_read(pUpgInfo)) fail to eRetVal eRet=0x00000031!
[UPG][KEY_WARN][src/sys_firm_upgrade.c][firm_upglib_exec][2334]:[UPG_ASSERT] UPG_STAT_OK == (eRet = firm_upglib_proc(pUpgInfo)) fail to WarnVal eRet=0x00000031!
[05-27 07:26:08][pid:841][UNI_IF][ERROR][UPG_ASSERT] UPG_STAT_OK == (eRet = firm_upglib_exec(&tUpgExec)) fail to eRetVal eRet=0x00000031!
[05-27 07:26:08][pid:841][UNI_IF][ERROR][UPG_ASSERT] UPG_STAT_OK == (eRet = firm_upgrade_lib(pUpgInfo)) fail to eRetVal eRet=0x00000031!
[05-27 07:26:08][pid:841][PSIA][ERROR]************* PSIA Upgrading END **************,iRet=-48

 

[alastairstevenson]

Well done! I'm impressed with how far you've got with this exploration from a standing start.
I too have puzzled over where the CCCH comes from. But there are many parts of the 'hardware descriptor blocks' with as yet unknown associations.
I've started a basic empirical test of what areas are covered by the Checksum-16, by changing a single byte and seeing if it notices. But quite a tedious activity with all the recovery. And all it needs is something like a byte that redirects to somewhere else for part of the values summed to make it pretty well impossible to guess the pattern, especially if there is camera-specific content in the mix. In practice, though, the subtract what you add and don't touch the checksum is a neat enough loophole.

I'm going to try 5.3.0 sometime on the 3332 that I recently bought - it's labelled 5.2.8 and 03/2015 so should be a candidate for the problems when a 5.3.0 upgrade is tried. I've created a modified version of 5.3.0 in preparation.
But I need to exhaust the existing explorations before I move on.

*edit* So you jumped! I'll digest the log later. Thanks for sharing!

 

[dknabe]

Thanks. It was a standing start for the HIKVision, but I've been doing embedded Linux ever since NSLU2 in 2004. I'm actually running Debian 7 now on my 135 MHz NSLU2. I also use Debian exclusively at home.