alastairstevenson
Staff member
With apologies in advance for the TL;DR aspect:
Unfortunately, not an improvement to their already quite good video analytics, but a cynical and nasty trap put in place to deliberately and permanently brick a camera where the 'mtd hack' has been attempted by a customer trying to make best use of the Hikvision product that they have acquired.
I had not seen this before, but suspect that, like various other changes they have made in response to what's been posted in public on ipcamtalk.com and other sites, this is a deliberate attempt to counter the benefits that ipcamtalk forum members have seen by doing the 'mtd hack'.
But it goes further and attempts to punish the user and permanently disable the camera.
I'd offered to take a look (for the learning experience) at a Hikvision DS-2CD2032-I camera that had been innocently bricked by a 5.4.5_170123 EN upgrade to a CN region camera, leaving it in an inconsistent language mismatch state with no web access, as has been seen a few times on this forum.
The update attempt was in response to the Hikvision statement about this firmware release fixing the recent 'Hikvision backdoor' high-severity vulnerability.
I've recently started tinkering with the camera firmware, and had a version ready for testing, which I applied.
The camera came straight to life, operating normally with EN/ML menus.
A good (and a bit surprising) result!
So I thought - why don't I do the 'mtd hack' before sending it back, so the user can update as required in the future.
Bad idea!
It turns out that Hikvision have added code to specifically trap any writes to mtdblock6, which sets a flag as a signal to routines in the normal kernel, the recovery kernel, and the bootloader that the camera should be disabled.
The consequence is that the camera permanently bootloops, and whatever firmware is applied via the tftp updater or the bootloader, the trap has been sprung and stays closed. The bootloader and the Linux kernel are primed to recognise this, and to block any recovery attempts.
Not nice.
Here is a sample error from the bootloader startup, and app startup, showing that the trap exists even at a low level:
(that was before I managed to fix it, quite simply actually, after all sorts of strange and devious attempts.)
Unfortunately, not an improvement to their already quite good video analytics, but a cynical and nasty trap put in place to deliberately and permanently brick a camera where the 'mtd hack' has been attempted by a customer trying to make best use of the Hikvision product that they have acquired.
I had not seen this before, but suspect that, like various other changes they have made in response to what's been posted in public on ipcamtalk.com and other sites, this is a deliberate attempt to counter the benefits that ipcamtalk forum members have seen by doing the 'mtd hack'.
But it goes further and attempts to punish the user and permanently disable the camera.
I'd offered to take a look (for the learning experience) at a Hikvision DS-2CD2032-I camera that had been innocently bricked by a 5.4.5_170123 EN upgrade to a CN region camera, leaving it in an inconsistent language mismatch state with no web access, as has been seen a few times on this forum.
The update attempt was in response to the Hikvision statement about this firmware release fixing the recent 'Hikvision backdoor' high-severity vulnerability.
I've recently started tinkering with the camera firmware, and had a version ready for testing, which I applied.
The camera came straight to life, operating normally with EN/ML menus.
A good (and a bit surprising) result!
So I thought - why don't I do the 'mtd hack' before sending it back, so the user can update as required in the future.
Bad idea!
It turns out that Hikvision have added code to specifically trap any writes to mtdblock6, which sets a flag as a signal to routines in the normal kernel, the recovery kernel, and the bootloader that the camera should be disabled.
The consequence is that the camera permanently bootloops, and whatever firmware is applied via the tftp updater or the bootloader, the trap has been sprung and stays closed. The bootloader and the Linux kernel are primed to recognise this, and to block any recovery attempts.
Not nice.
Here is a sample error from the bootloader startup, and app startup, showing that the trap exists even at a low level:
(that was before I managed to fix it, quite simply actually, after all sorts of strange and devious attempts.)
Code:
U-Boot 1.3.4-71557 (Apr 3 2014 - 13:08:34)
ERR: status & (FIO_DMASTA_RE | FIO_DMASTA_AE)
status=0x%x05000800
FIO_DMASTA_RE=0x%x04000000
FIO_DMASTA_AE=0x%x02000000
ERR: status & (FIO_DMASTA_RE | FIO_DMASTA_AE)
status=0x%x05000800
FIO_DMASTA_RE=0x%x04000000
FIO_DMASTA_AE=0x%x02000000
ERR: status & (FIO_DMASTA_RE | FIO_DMASTA_AE)
status=0x%x05000800
FIO_DMASTA_RE=0x%x04000000
FIO_DMASTA_AE=0x%x02000000
init_boot_param:nand_read_data failed
ue
ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2015-03-20 17:37:48 CST)
starting pid 375, tty '': '/etc/init.d/rcS'
Starting udev: [ OK ]
Code:
[04-15 07:33:08][pid:853][HW_IF][ERROR]ioctl error errno=5
[04-15 07:33:08][pid:853][SYSINIT][ERROR]hwif_getsecinfo failed.
[04-15 07:33:08][pid:853][SYSINIT][ERROR]sys app init failed to reboot!
davinci receive cmd_query_davinci_param.
S: cmd_query_davinci_param
