[MCR] Hikvision packer/unpacker for 5.3.x and newer firmware

jokobct · Oct 28, 2021

alastairstevenson said:
Have you tried connecting the cameras as ONVIF devices to the NVR?
That can work without the 'language mismatch' error on the earlier camera firmware.

When i set it up before, changing the protocol from hikvision to custom resolve that error.

I don't remember if i tested ONVIF or not. It's been 2 years.

Because some of the NVR function is only useable with the HIKVISION protocol,
I needed to try the custom firmware in order to change the protocol without causing error.

ipcamuser11 · Nov 10, 2021

I can use @montecrypto's hikpack 2.5 to unpack the R7 firmware, using r6 as the platform type. So I guess R6 and R7 platform must share the same encrypt key? But without any modification to the unpacked files, I got two warnings when repacking the firmware.

I haven't tried to update the re-packed firmware to camera yet, as I'm not sure if the uboot will verify signature of the firmware, I'm afraid to get it bricked

Bash:

./hikpack -t r6 -x digicap.dav -o output
Magic   : 484b3230
hdr_crc : 00002745 (OK)
frm_flg : 1210050031141110021
Magic   : 484b3330
hdr_crc : b21da707 (OK)
version : 05060000
lang_id : 00000002
date    : 190507
frm_flg : 1210050031141110021
File: _cfgUpgClass, CRC OK
File: uImage, CRC OK
File: hik_ar9331.bin, CRC OK
File: hik_ar9331_1.bin, CRC OK
File: initrun.sh, CRC OK
File: sysVersion.bin, CRC OK
File: r7_modules.tgz, CRC OK
File: IEfile.tar.gz, CRC OK
File: WebComponents.exe, CRC OK
File: r7_app.tar.gz, CRC OK
File: sound.tar.gz, CRC OK
File: help.tar.gz, CRC OK
File: SoftwareLicense.txt, CRC OK
File: cap.json, CRC OK
File: MOTOR_APP, CRC OK
File: MOTOR_APP1, CRC OK
File: MOTOR_APP2, CRC OK

Bash:

./hikpack -t r6 -p new.dav -o output
File: _cfgUpgClass, CRC OK
File: uImage, CRC OK
File: hik_ar9331.bin, CRC OK
File: hik_ar9331_1.bin, CRC OK
File: initrun.sh, CRC OK
File: sysVersion.bin, CRC OK
File: r7_modules.tgz, CRC OK
File: IEfile.tar.gz, CRC OK
File: WebComponents.exe, CRC OK
File: r7_app.tar.gz, CRC OK
File: sound.tar.gz, CRC OK
File: help.tar.gz, CRC OK
File: SoftwareLicense.txt, CRC OK
File: cap.json, CRC OK
File: MOTOR_APP, CRC OK
File: MOTOR_APP1, CRC OK
File: MOTOR_APP2, CRC OK
*** WARNING *** HK30 header is missing firmware flags
Magic   : 484b3330
hdr_crc : 67e38523 (OK)
version : 05060000
lang_id : 00000002
date    : 190507
frm_flg : 1210050031141110021
*** WARNING *** HK20 record header is missing firmware flags
Magic   : 484b3230
hdr_crc : 000025d8 (OK)
frm_flg : 1210050031141110021

Alexey_Astashov · Nov 10, 2021

gmv36 said:
так я хочу удалить веб компоненту совсем, чтобы уменьшить размер прошивки.

У вас получилось сломить прошивку и перешить камеру? у меня камеры DS-2CD2023G0-I, платформа G1 v.5.6.2build 191226, проблема отвязать её от Rostelecom. (Камеры, которые по распоряжению правительства вынуждены были купить у Ростелеком, причем за полную стоимость, для наблюдения за тем. чтобы все носили маски). Теперь Ростелеком не продлил контракт и порекомендовали просто выбросить камеры. Они даже не брендировали коробки.

Alexey_Astashov · Nov 10, 2021

iTuneDVR said:
Что дальше будет?
Чем мешает компонента?

Приветствую, need help, сослались на вас в другом месте, понимая, что вы в теме, спрошу у вас, быть может вы сможете подсказать как отучить камеры DS-2CD2023G0-I (платформа G1) от Ростелеком? (описания постом выше)
SADP камеру видит
nmap говорил следующее:
PORT STATE SERVICE
554/tcp open rtsp
7681/tcp open unknown
all other ports are filtered

Камеру переактивировал, ресетнул её без сети Internet, потом зашел SADP и сделал свой пароль, но как-то это мало помогает.

(UART-TTL модуль я потерял, новый пока не пришел), пока просто собираю информацию.

iTuneDVR · Nov 11, 2021

Alexey_Astashov said:
У вас получилось сломить прошивку и перешить камеру? у меня камеры DS-2CD2023G0-I, платформа G1 v.5.6.2build 191226, проблема отвязать её от Rostelecom. (Камеры, которые по распоряжению правительства вынуждены были купить у Ростелеком, причем за полную стоимость, для наблюдения за тем. чтобы все носили маски). Теперь Ростелеком не продлил контракт и порекомендовали просто выбросить камеры. Они даже не брендировали коробки.

С G1 серией нет проблем возврата назад. Делалось такое спокойно из консоли возврат к оригиналу.

Alexey_Astashov · Nov 11, 2021

iTuneDVR said:
С G1 серией нет проблем возврата назад. Делалось такое спокойно из консоли возврат к оригиналу.

т.е. беру UART-TTL, прошивку оригинальную, загружаю на SD карту и обновляю?

iTuneDVR · Nov 11, 2021

Я делал без SD через TFTP

Alexey_Astashov · Nov 11, 2021

iTuneDVR said:
Я делал без SD через TFTP

Ok, TTL кабель ведь всё-равно нужен? (по адресу 192.168.0.128 и 192.168.1.128 нет обращений)

iTuneDVR · Nov 11, 2021

Да, автообновления нет.

Alexey_Astashov · Nov 11, 2021

iTuneDVR said:
Да, автообновления нет.

Понял, спасибо, жду UARTы.

iTuneDVR · Nov 11, 2021

Пожалуйста

yolo1602 · Nov 11, 2021

Hi guys, i have a little problem with my ds-7608ni-k2 by getting complete root access

i used montecrypto's hikpack 2.5 to unpack successfully but unfortunately i can't manage to repack with the proper order the structure of the firmware. (i'm trying to substitute PSH restricted shell with the /bin/sh)

an original firmware comes like this :

Code:

Magic   : 484b5753
hdr_crc : 00004933 (OK)
lang_id : 00000001
date_hex: 20200320
devclass: 0000003d
File: headEx, CRC OK
File: uImage, CRC OK
File: start.sh, CRC OK
File: sys_app.tar.lzma, CRC OK
File: gui_res.tar.lzma, CRC OK
File: webs.tar.lzma, CRC OK
File: new_10.bin, CRC OK
=== Tail record:
File: new_20.bin, CRC OK

instead once i repack the firmware it becomes:

Code:

Magic   : 484b5753
hdr_crc : 00004202 (OK)
lang_id : 00000001
date_hex: 20200320
devclass: 0000002a
File: gui_res.tar.lzma, CRC OK
File: headEx, CRC OK
File: start.sh, CRC OK
File: sys_app.tar.lzma, CRC OK
File: uImage, CRC OK
File: webs.tar.lzma, CRC OK
=== Tail record:
File: new_20.bin, CRC OK

so essentially, for some reason it swaps the resources.

and i can see (via uart) that there's a problem exactly because of this. is there any way i can give the proper order while packing ?

or...
do you know if there's an easier way to achieve full root access to the nvr ?

alastairstevenson · Nov 11, 2021

yolo1602 said:
i can see (via uart) that there's a problem exactly because of this

What do you see exactly that shows this?

I suspect though that the real reason for the rejection of the modded firmware is the use of k41 instead of the needed k51 for the platform type.

yolo1602 · Nov 11, 2021

alastairstevenson said:
What do you see exactly that shows this?

I suspect though that the real reason for the rejection of the modded firmware is the use of k41 instead of the needed k51 for the platform type.

Hey i tried both by passing -t k41 and -t k51 as argument in the hikpack tool but the result is essentially the same.

I'm trying to upload the firmware from the web interface ( is that correct ? or i have to do it in another way ? tftp or whatever, i don't know.)

this is what i get:

Code:

INFO : checkFuncList() :317:version[0x20200320]
INFO : checkFuncList() :320:name[gui_res.tar.lzma],len[3638040]

ERR : checkFuncList() :324:err filename

ERR : sys_upg_net_extend() :5537:checkFuncList error

appVirAddr 0x72b2d000,  size 46505984 FREE OK!!!
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
AllocDispRegion:invalid region param x:0 y:0 w 0 h 0 screenw 1920 screenh 1080
[app_lib.c] 1.DSP process host cmd err, return err!
file:src/pal_api.c,line:399, *********undefine fun:pal_open_all_chan_display*********
INFO : sys_upg_net_extend() :5807:prev_schedule_reopen_screen OK

INFO : sys_upg_net_extend() :5830:iRetVal is [-1]

INFO : sys_upg_step() :744:*******************sys curr upg step=255

INFO : sys_upgrade() :8252:sys_upgrade iRetVal[-1]

alastairstevenson · Nov 11, 2021

yolo1602 said:
Hey i tried both by passing -t k41 and -t k51 as argument in the hikpack tool but the result is essentially the same.

The platform type should be k51 so that the correct devClass is in the header.

What version of firmware is this?
And what version of firmware is running?
And what exactly did you modify?

I'm guessing it's around V4.40.xx
Around this point, that file name changed to gui_res.tar.gz

alastairstevenson · Nov 11, 2021

yolo1602 said:
INFO : checkFuncList() :320:name[gui_res.tar.lzma],len[3638040]

And the gui_res.tar.xx filesize is around 8 or 9MB

yolo1602 · Nov 11, 2021

alastairstevenson said:
The platform type should be k51 so that the correct devClass is in the header.

What version of firmware is this?
And what version of firmware is running?
And what exactly did you modify?

I'm guessing it's around V4.40.xx
Around this point, that file name changed to gui_res.tar.gz

Ok, fine for the k51 but as i said unfortunately it didn't work neither.

regarding your questions:

Firmware version: V4.32.110 build 211009

I modified as i said the uImage file by changing the PSH with /bin/sh and trying to repack it

What are you saying regarding the new name it's a bit weird since when i extract it the name is actually gui_res.tar.lzma and not gui_res.tar.gz

when i do the packing if i delete the gui_res.tar.gz it successfully extract the file till there, so my guess is that as i said, i have the order swapped because it's expecting headEx as first instead i have gui_res.tar.lzma

EDIT

also by checking the logs while updating with the ORIGINAL firmware, the length of the gui_res.tar.lzma is correct.

alastairstevenson · Nov 11, 2021

yolo1602 said:
What are you saying regarding the new name it's a bit weird since when i extract it the name is actually gui_res.tar.lzma and not gui_res.tar.gz

OK, maybe that's a red herring. But odd.

yolo1602 said:
also by checking the logs while updating with the ORIGINAL firmware, the length of the gui_res.tar.lzma is correct.

Yes, you are right.
I didn't have the specific firmware you quoted, so was looking at a similar version from about the same time.
That file is nearly 3 times the size there, the firmware has been significantly restructured.
But I've now grabbed a copy of the version you quoted and the filesize is as your transcript shows, and I've unpacked it.

yolo1602 said:
I modified as i said the uImage file by changing the PSH with /bin/sh and trying to repack it

I'm quite intrigued and impressed by this as it's quite a tricky and advanced thing to do.
The kernel itself is held in compressed form, then the root file system, in which /bin/psh resides, is held in cpio form.
So to get a usable modified result there are a few technical reversal hoops to jump through.
But check your 'Conversations' for a simpler and interesting alternative method.

kk_2 · Jan 8, 2022

Hi guys! As I understand it, there is no way to get the hik_repack software. I've been posting @leecher on the forum and email. But I received no answer. Can anyone unpack this firmware?

alastairstevenson · Jan 8, 2022

There are copies attached somewhere in this large thread.

Search

[MCR] Hikvision packer/unpacker for 5.3.x and newer firmware

jokobct

n3wb

Attachments

ipcamuser11

Getting the hang of it

Alexey_Astashov

n3wb

Alexey_Astashov

n3wb

iTuneDVR

Pulling my weight

Alexey_Astashov

n3wb

iTuneDVR

Pulling my weight

Alexey_Astashov

n3wb

iTuneDVR

Pulling my weight

Alexey_Astashov

n3wb

iTuneDVR

Pulling my weight

yolo1602

n3wb

alastairstevenson

yolo1602

n3wb

alastairstevenson

alastairstevenson

yolo1602

n3wb

alastairstevenson

kk_2

n3wb

Attachments

alastairstevenson