alastairstevenson
Staff member
[MCR] Hikvision packer/unpacker for 5.3.x and newer firmware
- Thread starter montecrypto
- Start date
Hi @alastairstevenson - thanks for your help.
We are closer, but still unable to get the un-encryped zip files.
All the shown commands were successful.
But I think we're missing the final commands on how to decrypt the files.
Should I just manually run dec_ start.sh?
And also, where is the encryption key stored ?
Thanks in advance.
Please see steps below and let me know if anythings been missed:
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ file mnt1/*
mnt1/gui_res.tar.lzma: data
mnt1/new_10.bin: data
mnt1/ player.zip: Zip archive data, at least v2.0 to extract
mnt1/ start.sh: data
mnt1/sys_app.tar.lzma: data
mnt1/uImage: u-boot legacy uImage, Linux-3.10.0, Linux/ARM, OS Kernel Image (Not compressed), 3096056 bytes, Thu Jan 5 03:25:07 2017, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0xA1F39057, Data CRC: 0x870572D4
mnt1/WebComponents.exe: PE32 executable (GUI) Intel 80386, for MS Windows
mnt1/webs.tar.lzma: data
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ ../../hikpack --version
../../hikpack: invalid option -- '-'
hikpack v2.5 Hikvision firmware packer/unpacker by montecrypto
*** No expressed or implied warranties of any kind. Use at your own risk ***
Usage:
hikpack -t <fwtype> -i <src_dav_file> print dav file information
hikpack -t <fwtype> -x <src_dav_file> -o <dst_dir> extract dav file into directory
hikpack [opts] -t <fwtype> -p <dst_dav_file> -o <src_dir> pack dav file from source directory
hikpack -t <fwtype> -d <src_crypted_file> -o <dst_file> decrypt file
hikpack -t <fwtype> -g <src_crypted_cfg> -o <dst_file> decrypt configuration backup file
hikpack -t <fwtype> -G <src_file> -o <crypted_cfg_file> encrypt configuration backup file (CRC adjusted if needed)
hikpack -t <fwtype> -e <src_file> -o <dst_crypted_file> encrypt file
-t option sets firmware platform type. Currently supported: cameras: r0,r1,r6,g0 nvr: k41,k51
----- The following options are used by the pack (-p) command:
-L <1,2> set language id (1=EN, 2=CN)
-D <YYYYMMDD> set firmware date.
-V <ver> set firmware version. Use hex number, e.g.: 0x05040003 for v5.4.3
If you find this software useful, please donate to support future development:
Bitcoin: 1N9fKwsy7AphUHZJshCp4L7RJG5CvuXnAk
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ ../../hikpack -t k41 -d mnt1/ start.sh -o dec_ start.sh
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ ll
total 14333
drwxr-xr-x 3 ashutosh ashutosh 4096 Oct 2 22:44 ./
drwxrwxr-x 5 ashutosh ashutosh 4096 Sep 29 00:53 ../
-rw-rw-r-- 1 ashutosh ashutosh 14651796 Sep 29 00:51 cramfs.img
-rw-rw-r-- 1 ashutosh ashutosh 108 Sep 29 00:51 dav_header
-rw-rw-r-- 1 ashutosh ashutosh 4184 Oct 2 22:44 dec_ start.sh
drwxrwxrwx 1 root root 204 Jan 1 1970 mnt1/
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ head dec_ start.sh
#!/bin/sh
sdbg=$(/usr/bin/awk -F 'sdbg=' '{print substr($2,1,1)}' /proc/cmdline)
who=$(/usr/bin/awk -F 'who=' '{print substr($2,1,9)}' /proc/cmdline)
serverip=$(/usr/bin/awk -F: '{print $2}' /proc/cmdline)
echo "sdbg:$sdbg serverip:$serverip"
if [ "$sdbg" == "d" ];then
echo "DSP..........";
exit;
fi
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ cd mnt1/
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1/mnt1$ ls
gui_res.tar.lzma new_10.bin player.zip start.sh sys_app.tar.lzma uImage WebComponents.exe webs.tar.lzma
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1/mnt1$ file *
gui_res.tar.lzma: data
new_10.bin: data
player.zip: Zip archive data, at least v2.0 to extract
start.sh: data
sys_app.tar.lzma: data
uImage: u-boot legacy uImage, Linux-3.10.0, Linux/ARM, OS Kernel Image (Not compressed), 3096056 bytes, Thu Jan 5 03:25:07 2017, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0xA1F39057, Data CRC: 0x870572D4
WebComponents.exe: PE32 executable (GUI) Intel 80386, for MS Windows
webs.tar.lzma: data
We are closer, but still unable to get the un-encryped zip files.
All the shown commands were successful.
But I think we're missing the final commands on how to decrypt the files.
Should I just manually run dec_ start.sh?
And also, where is the encryption key stored ?
Thanks in advance.
Please see steps below and let me know if anythings been missed:
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ file mnt1/*
mnt1/gui_res.tar.lzma: data
mnt1/new_10.bin: data
mnt1/ player.zip: Zip archive data, at least v2.0 to extract
mnt1/ start.sh: data
mnt1/sys_app.tar.lzma: data
mnt1/uImage: u-boot legacy uImage, Linux-3.10.0, Linux/ARM, OS Kernel Image (Not compressed), 3096056 bytes, Thu Jan 5 03:25:07 2017, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0xA1F39057, Data CRC: 0x870572D4
mnt1/WebComponents.exe: PE32 executable (GUI) Intel 80386, for MS Windows
mnt1/webs.tar.lzma: data
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ ../../hikpack --version
../../hikpack: invalid option -- '-'
hikpack v2.5 Hikvision firmware packer/unpacker by montecrypto
*** No expressed or implied warranties of any kind. Use at your own risk ***
Usage:
hikpack -t <fwtype> -i <src_dav_file> print dav file information
hikpack -t <fwtype> -x <src_dav_file> -o <dst_dir> extract dav file into directory
hikpack [opts] -t <fwtype> -p <dst_dav_file> -o <src_dir> pack dav file from source directory
hikpack -t <fwtype> -d <src_crypted_file> -o <dst_file> decrypt file
hikpack -t <fwtype> -g <src_crypted_cfg> -o <dst_file> decrypt configuration backup file
hikpack -t <fwtype> -G <src_file> -o <crypted_cfg_file> encrypt configuration backup file (CRC adjusted if needed)
hikpack -t <fwtype> -e <src_file> -o <dst_crypted_file> encrypt file
-t option sets firmware platform type. Currently supported: cameras: r0,r1,r6,g0 nvr: k41,k51
----- The following options are used by the pack (-p) command:
-L <1,2> set language id (1=EN, 2=CN)
-D <YYYYMMDD> set firmware date.
-V <ver> set firmware version. Use hex number, e.g.: 0x05040003 for v5.4.3
If you find this software useful, please donate to support future development:
Bitcoin: 1N9fKwsy7AphUHZJshCp4L7RJG5CvuXnAk
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ ../../hikpack -t k41 -d mnt1/ start.sh -o dec_ start.sh
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ ll
total 14333
drwxr-xr-x 3 ashutosh ashutosh 4096 Oct 2 22:44 ./
drwxrwxr-x 5 ashutosh ashutosh 4096 Sep 29 00:53 ../
-rw-rw-r-- 1 ashutosh ashutosh 14651796 Sep 29 00:51 cramfs.img
-rw-rw-r-- 1 ashutosh ashutosh 108 Sep 29 00:51 dav_header
-rw-rw-r-- 1 ashutosh ashutosh 4184 Oct 2 22:44 dec_ start.sh
drwxrwxrwx 1 root root 204 Jan 1 1970 mnt1/
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ head dec_ start.sh
#!/bin/sh
sdbg=$(/usr/bin/awk -F 'sdbg=' '{print substr($2,1,1)}' /proc/cmdline)
who=$(/usr/bin/awk -F 'who=' '{print substr($2,1,9)}' /proc/cmdline)
serverip=$(/usr/bin/awk -F: '{print $2}' /proc/cmdline)
echo "sdbg:$sdbg serverip:$serverip"
if [ "$sdbg" == "d" ];then
echo "DSP..........";
exit;
fi
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1$ cd mnt1/
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1/mnt1$ ls
gui_res.tar.lzma new_10.bin player.zip start.sh sys_app.tar.lzma uImage WebComponents.exe webs.tar.lzma
ashutosh@ashutosh-Inspiron-1464:~/DVR_FW/pass3/tmp1/mnt1$ file *
gui_res.tar.lzma: data
new_10.bin: data
player.zip: Zip archive data, at least v2.0 to extract
start.sh: data
sys_app.tar.lzma: data
uImage: u-boot legacy uImage, Linux-3.10.0, Linux/ARM, OS Kernel Image (Not compressed), 3096056 bytes, Thu Jan 5 03:25:07 2017, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0xA1F39057, Data CRC: 0x870572D4
WebComponents.exe: PE32 executable (GUI) Intel 80386, for MS Windows
webs.tar.lzma: data
Last edited:
Thanks @alastairstevenson I also have both of those.
Obviously if I have a G0 v5.3.3 camera and I upgrade to v5.3.5 I will get stuck there and can't/won't be able to go backwards.
However do you think/know if I can take a G0 v5.3.3 back to v5.3.1?
Obviously if I have a G0 v5.3.3 camera and I upgrade to v5.3.5 I will get stuck there and can't/won't be able to go backwards.
However do you think/know if I can take a G0 v5.3.3 back to v5.3.1?
alastairstevenson
Staff member
I'm admittedly guessing - but on other camera series it was version 5.4.0 that first introduced the 'downgrade block'.
alastairstevenson
Staff member
The required command format was in my 'worked example', and you've already used it successfully :
That was just an easy example of how to do the decryption, as 'start.sh' is a script file and so you can easily see it's been decrypted as the resultant contents are readable. There is no reason why you'd need to manually run it.
start.sh is one of the main initialisation routines of the NVR on bootup.
It's also one of the easiest places to make changes.
In hikpack - it's inside the program that @montecrypto created.
In the NVR, it's held in the Linux kernel.
The file decryption / encryption in the NVR is conveniently handled by the Hikvision 'ded' program, see this fragment from start.sh
Code:
ded -d /home/hik/sys_app.tar.lzma /home/app/sys_app.tar.lzma
/bin/tar xaf /home/app/sys_app.tar.lzma -C /home/app/
Code:
[root@dvrdvs /root] # ded -h
Usage: ded FILEin FILEout [option]
-e encrypt file
-d decrypt file
-h help
[root@dvrdvs /root] #Sorry. Poor choice of words.
The first instance of others.... I was referring to the firmware file images. I had found in the last year a good number of them, but you had kildy provided two I did not find. One (the 5.3.3) I knew existed but had never located and I had one of the 5.3.9 versions but not the other.
In the second instance of others.... i was commenting on behalf of others members here who will likely find it helpful to have these versions readily available for their tinkering (like I am tinkering myself)
Hello everybody,
I have here 2 China camera.
DS 2CD2145F-IS
Both had the FW V5.3.6 build 151221 Multilingual.
But unfortunately no one worked.
So I had the FW for the G0 from here worried.
Thanks again.
Unfortunately the camera was only with the
> FW 5.4 revive.
Now I tried to bring the FW back to English but unfortunately without success.
As far as I understand this is no longer because the FW are signed. Is that correct.
above is the possibility to change this.
Thank you
German Text:
Hallo zusammen,
Ich habe hier 2 China Kamera.
DS-2CD2145F-IS
Die hatten beide die FW V5.3.6 build 151221 Multilingual.
Aber leider funktionierte eine nicht mehr.
Deswegen hatte ich mir die FW für die G0 von hier besorgt.
Vielen Dank nochmals dafür.
Leider ließ sich die Kamera erst mit der
> FW 5.4 wiederbeleben.
Nun habe ich versucht die FW wieder auf English zu bringen aber leider ohne Erfolg.
Soweit ich das verstanden habe geht das nicht mehr weil die FW signiert sind. ist das richtig.
ober besteht die möglichkeit dies zu ändern.
Danke Euch
I have here 2 China camera.
DS 2CD2145F-IS
Both had the FW V5.3.6 build 151221 Multilingual.
But unfortunately no one worked.
So I had the FW for the G0 from here worried.
Thanks again.
Unfortunately the camera was only with the
> FW 5.4 revive.
Now I tried to bring the FW back to English but unfortunately without success.
As far as I understand this is no longer because the FW are signed. Is that correct.
above is the possibility to change this.
Thank you
German Text:
Hallo zusammen,
Ich habe hier 2 China Kamera.
DS-2CD2145F-IS
Die hatten beide die FW V5.3.6 build 151221 Multilingual.
Aber leider funktionierte eine nicht mehr.
Deswegen hatte ich mir die FW für die G0 von hier besorgt.
Vielen Dank nochmals dafür.
Leider ließ sich die Kamera erst mit der
> FW 5.4 wiederbeleben.
Nun habe ich versucht die FW wieder auf English zu bringen aber leider ohne Erfolg.
Soweit ich das verstanden habe geht das nicht mehr weil die FW signiert sind. ist das richtig.
ober besteht die möglichkeit dies zu ändern.
Danke Euch
nithin
n3wb
- Oct 12, 2016
- 20
- 3
Hi @montecrypto,
Is it possible to make the tool work for G1 platform? Looking at the camera support, it is essentially G0 platform for ML/EN support.
Thanks in advance.
Is it possible to make the tool work for G1 platform? Looking at the camera support, it is essentially G0 platform for ML/EN support.
Thanks in advance.
It is possible, I just need to order a G1 to dump AES keys. I already have a pile of cameras I don't use...
You won't be able to do much with it, unless you gain root access or modify the uboot to accept unsigned firmware. They now check signatures everywhere:- in the bootloader
- in kernel when it runs davinci loader
- in the davinci loader
- in davinci
can anyone tell please how to decrypt the configurtion file? Ive understand that the encryption key is abcdefg but someone can give a decrypt script or tell me how to decrypt this configurtion file?
thanx
thanx
Ashutosh Naik
n3wb
- Oct 23, 2017
- 1
- 0
Hi, Where can I download the sources for the binary ded.bin ? Its not a part of the hikpack binary.
I tried running the file ded.bin posted earlier in this forum, but it was not suitable for my architecture
ashutosh@ashutosh-Inspiron-1464:~/Downloads$ ./ded.bin
bash: ./ded.bin: cannot execute binary file: Exec format error
alastairstevenson
Staff member
It's part of the Hikvision NVR firmware, so I doubt if any sources are out there.
It's an ARM32 ELF program that also depends on the Hikvision proprietary kernel module hikio to do the encrypt/decrypt.
But the @montecrypto packer/unpacker handles the 3DES encrypt/decrypt just fine, or you can use the NVR itself if you have root shell access.
Hi Monte,
Can you clarify what OS you know hikpack to run ok on? I notice its using dynamic linking and wonder if that could be why I cant get it to work properly on Ubuntu 14.04LTS.
I'm working on an NVR, say NVR_K41_BL_ML_STD_V3.4.62_160503.zip but I've found the same issue on all DVR/NVR images... I can unpack to a cramfs.img file and I can verify the MD5 sum of this matches that in the decrypted new_10.bin, so my encrypted cramfs file is fully intact. I then use hikpack to decrypt this, but the resulting decrypted output seems to be partially corrupt and hence will not untar. The decryption is working as if I test it on start.sh or new_10.bin I get plaintext output. The tar.lzma files untar upto a point... then tar bombs out....
root@virtualBox:~/hikvision/myfw/unpack# unlzma dec_sys.tar.lzma
unlzma: dec_sys.tar.lzma: Compressed data is corrupt
root@virtualBox:~/hikvision/myfw/unpack# tar -xvf dec_sys.tar.lzma
hisi/
hisi/modules/
hisi/modules/hi3535_chnl.ko
hisi/modules/hi3535_h264e.ko
<snip>
lib/libssl.so.token00000001000000020000020000000001ffffffff0000000200000000.hisi-3535.v1
lib/libtde.so
xz: (stdin): Compressed data is corrupt
tar: Child returned status 1
tar: Error is not recoverable: exiting now
It is always at the same point in the file that untar fails, even across different firmwares/dvrs, so I'm wondering if hikpack has a bug with the decryption that only shows at large file offsets, or I have an incompatible library on my computer...
Can you clarify what OS you know hikpack to run ok on? I notice its using dynamic linking and wonder if that could be why I cant get it to work properly on Ubuntu 14.04LTS.
I'm working on an NVR, say NVR_K41_BL_ML_STD_V3.4.62_160503.zip but I've found the same issue on all DVR/NVR images... I can unpack to a cramfs.img file and I can verify the MD5 sum of this matches that in the decrypted new_10.bin, so my encrypted cramfs file is fully intact. I then use hikpack to decrypt this, but the resulting decrypted output seems to be partially corrupt and hence will not untar. The decryption is working as if I test it on start.sh or new_10.bin I get plaintext output. The tar.lzma files untar upto a point... then tar bombs out....
root@virtualBox:~/hikvision/myfw/unpack# unlzma dec_sys.tar.lzma
unlzma: dec_sys.tar.lzma: Compressed data is corrupt
root@virtualBox:~/hikvision/myfw/unpack# tar -xvf dec_sys.tar.lzma
hisi/
hisi/modules/
hisi/modules/hi3535_chnl.ko
hisi/modules/hi3535_h264e.ko
<snip>
lib/libssl.so.token00000001000000020000020000000001ffffffff0000000200000000.hisi-3535.v1
lib/libtde.so
xz: (stdin): Compressed data is corrupt
tar: Child returned status 1
tar: Error is not recoverable: exiting now
It is always at the same point in the file that untar fails, even across different firmwares/dvrs, so I'm wondering if hikpack has a bug with the decryption that only shows at large file offsets, or I have an incompatible library on my computer...
alastairstevenson
Staff member
It's the way that Hikvision have compressed the files.
The exact same result occurs when a certain other unpacker is used to decrypt the file.
These were created with 2 different tools :
Code:
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ ll
total 29600
drwxrwxr-x 2 alastair alastair 4096 Nov 3 16:48 ./
drwxrwxr-x 4 alastair alastair 4096 May 18 2016 ../
-rw-r--r-- 1 alastair alastair 7020240 Nov 3 16:48 dec1_sys_app.tar.lzma
-rw-r--r-- 1 alastair alastair 7020240 Nov 3 16:48 dec2_sys_app.tar.lzma
-rw-rw-r-- 1 alastair alastair 2240328 Jan 1 1970 gui_res.tar.lzma
-rw-rw-r-- 1 alastair alastair 616 Jan 1 1970 new_10.bin
-rw-rw-r-- 1 alastair alastair 2840 Jan 1 1970 start.sh
-rw-rw-r-- 1 alastair alastair 7020240 Jan 1 1970 sys_app.tar.lzma
-rw-rw-r-- 1 alastair alastair 3183416 Jan 1 1970 uImage
-rw-rw-r-- 1 alastair alastair 3802552 Jan 1 1970 webs.tar.lzma
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ file dec*
dec1_sys_app.tar.lzma: LZMA compressed data, streamed
dec2_sys_app.tar.lzma: LZMA compressed data, streamed
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ openssl md5 dec*
MD5(dec1_sys_app.tar.lzma)= 424a628bd6a1d6b2d2fd120a06383c45
MD5(dec2_sys_app.tar.lzma)= 424a628bd6a1d6b2d2fd120a06383c45
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ openssl version
OpenSSL 1.0.2g 1 Mar 2016
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $There is a workaround for the untar complaint. Worked example here, using @montecrypto ' tool:
Code:
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ ll
total 15888
drwxrwxr-x 2 alastair alastair 4096 Nov 3 16:44 ./
drwxrwxr-x 4 alastair alastair 4096 May 18 2016 ../
-rw-rw-r-- 1 alastair alastair 2240328 Jan 1 1970 gui_res.tar.lzma
-rw-rw-r-- 1 alastair alastair 616 Jan 1 1970 new_10.bin
-rw-rw-r-- 1 alastair alastair 2840 Jan 1 1970 start.sh
-rw-rw-r-- 1 alastair alastair 7020240 Jan 1 1970 sys_app.tar.lzma
-rw-rw-r-- 1 alastair alastair 3183416 Jan 1 1970 uImage
-rw-rw-r-- 1 alastair alastair 3802552 Jan 1 1970 webs.tar.lzma
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ hikpack_2.5 -t k41 -d sys_app.tar.lzma -o dec_sys_app.tar.lzma
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ unlzma --single-stream dec_sys_app.tar.lzma
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ file *
dec_sys_app.tar: POSIX tar archive (GNU)
gui_res.tar.lzma: data
new_10.bin: data
start.sh: data
sys_app.tar.lzma: data
uImage: u-boot legacy uImage, Linux-3.4.35_hi3535, Linux/ARM, OS Kernel Image (Not compressed), 3183352 bytes, Tue Jan 5 01:46:33 2016, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x09335EB4, Data CRC: 0xF3C1D5DA
webs.tar.lzma: data
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ tar -xvf dec_sys_app.tar
hisi/
hisi/modules/
hisi/modules/hi3535_chnl.ko
hisi/modules/hi3535_h264e.ko
hisi/modules/dsp_pin.sh
hisi/modules/mmz.ko
hisi/modules/hi3535_tde.ko
hisi/modules/sysctl_hi3535.sh
hisi/modules/hi3535_base.ko
hisi/modules/hi3535_vou.ko
hisi/modules/hi3535_region.ko
hisi/modules/hi_cipher.ko
hisi/modules/hi3535_sys.ko
hisi/modules/hi3535_vpss.ko
hisi/modules/hi3535_aio.ko
hisi/modules/hi3535_jpegd.ko
hisi/modules/hi3535_rc.ko
hisi/modules/hidmac.ko
hisi/modules/hi3535_ive.ko
hisi/modules/hi3535_vdec.ko
hisi/modules/acodec.ko
hisi/modules/hi3535_hdmi.ko
hisi/modules/hi3535_jpege.ko
hisi/modules/hi3535_vfmw.ko
hisi/modules/hiuser.ko
hisi/modules/clkcfg_hi3535.sh
hisi/modules/hi3535_venc.ko
hisi/modules/hi3535_ao.ko
hisi/modules/hi3535_vgs.ko
hisi/modules/hi_rtc.ko
hisi/modules/hi3535_pciv_fmw.ko
hisi/modules/hi3535_aenc.ko
hisi/modules/hifb.ko
hisi/modules/hi3535_vda.ko
hisi/modules/hi3535_ai.ko
hisi/modules/extdrv/
hisi/modules/extdrv/sil9024.ko
hisi/modules/extdrv/tlv_320aic31.ko
hisi/modules/hi3535_adec.ko
hisi/modules/load3535
hisi/modules/hi3535_pciv.ko
exec/
exec/pppoed
exec/vca_encrypt_3535.ko
exec/iscsi/
exec/iscsi/iscsid
exec/iscsi/initiatorname.iscsi
exec/iscsi/iscsid.conf
exec/sc_hicore
exec/pppoe
exec/ntfs-3g
exec/pppd
exec/bonding.ko
exec/dvrCmd.tar.gz
exec/sc_T1
exec/ptzCfg.bin
exec/master
exec/showlogo
res/
res/ASC16
res/nolink
res/unstreamtype
res/player.zip
res/hiklogo
res/logo.jpg
res/sysVersion.bin
res/noresource
lib/
lib/libmpi.so
lib/libdspjpeg.so
lib/libmem.so
lib/libive.so
lib/libhisdkso.so
lib/libssl.so
lib/libplatform.so
lib/libssl.so.token00000001000000020000020000000001ffffffff0000000200000000.hisi-3535.v1
lib/libtde.so
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $alastairstevenson
Staff member
And just for fun - here is how it is used and works on the NVR environment itself, no obvious errors :
Code:
alastair@PC-I5 ~/cctv/NVRFirmware/3.4.62/NVR_K41_BL_ML_STD_V3.4.62_160503/contents $ telnet 192.168.1.211
Trying 192.168.1.211...
Connected to 192.168.1.211.
Escape character is '^]'.
dvrdvs login: root
Password:
BusyBox v1.16.1 (2016-06-29 13:49:45 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
psh: applet not found
[root@dvrdvs /root] # mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
udev on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
/dev/mtdblock2 on /home/hik type cramfs (ro,relatime)
192.168.1.201:/cctv1 on /mnt/tnfs00 type nfs (rw,sync,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,soft,noac,nolock,proto=udp,port=2049,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.1.201)
[root@dvrdvs /root] # cd /mnt/tnfs00/tmp
[root@dvrdvs tmp] # ll
drwxr-xr-x 2 root root 4096 Aug 27 17:11 dropbear
-rw-rw-rw- 1 503 100 7020240 Nov 3 16:54 sys_app.tar.lzma
[root@dvrdvs tmp] # ded -d sys_app.tar.lzma dec_sys_app.tar.lzma
[root@dvrdvs tmp] # ll
-rwxr-xr-x 1 root root 7020240 Nov 3 16:55 dec_sys_app.tar.lzma
drwxr-xr-x 2 root root 4096 Aug 27 17:11 dropbear
-rw-rw-rw- 1 503 100 7020240 Nov 3 16:54 sys_app.tar.lzma
[root@dvrdvs tmp] # tar -xvf dec_sys_app.tar.lzma
tar: invalid tar magic
[root@dvrdvs tmp] # tar -xaf dec_sys_app.tar.lzma
[root@dvrdvs tmp] # ll
-rwxr-xr-x 1 root root 7020240 Nov 3 16:55 dec_sys_app.tar.lzma
drwxr-xr-x 2 root root 4096 Aug 27 17:11 dropbear
drwxrwxrwx 3 root root 4096 Nov 3 16:57 exec
drwxrwxrwx 3 root root 4096 Nov 3 16:57 hisi
drwxrwxrwx 2 root root 4096 Nov 3 16:57 lib
drwxrwxrwx 2 root root 4096 Nov 3 16:57 res
-rw-rw-rw- 1 503 100 7020240 Nov 3 16:54 sys_app.tar.lzma
[root@dvrdvs tmp] #That works, thanks.
Can I decrypt start.sh, modify it to enable ssh/disable psh, recrypt (using hikpack) and reassemble an upgrade file, or will my NVR (3.4.62) reject it as not beeing encrypted/signed with the correct key?
I put a serial cable on it hoping to get a full uboot console access, but access is limited there too.
Can I decrypt start.sh, modify it to enable ssh/disable psh, recrypt (using hikpack) and reassemble an upgrade file, or will my NVR (3.4.62) reject it as not beeing encrypted/signed with the correct key?
I put a serial cable on it hoping to get a full uboot console access, but access is limited there too.
alastairstevenson
Staff member
What I've done (for my own convenience and interest) is to create a small encrypted stub of start.sh that calls a plaintext main script which has the remainder of start.sh and other changes such as getting rid of psh.
Then you can leave all the other files decrypted, add telnet or dropbear back, full busybox etc.
Then you can leave all the other files decrypted, add telnet or dropbear back, full busybox etc.