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

[alastairstevenson]

is it possible to get a shell through that port then? i assumed it was output only.

Generally it's a full console access to the bootloader and the running system.
What can be done with it varies with how much or how little remains in the bootloader, and what restrictions have been imposed in the running system.
But generally it provides quite a few opportunities to get inside the system and mess with it.

 

[knedit2]

ahh nice, i'll give that a go then, hopefully what im trying to change isnt too complicated.
does anyone know / share the knowledge on how to actually extract the firmware keys? id give that a go too if i knew.

 

[alastairstevenson]

i'll give that a go then, hopefully what im trying to change isnt too complicated.

Start with a full transcript of the device from power on, and see what is available if any at the final prompt.

Then interrupt the bootloader, and use 'printenv' and 'help' to list the variables and available commands.
Save that so the start point is preserved.
Quite often, changing the bootargs variable can get the kernel to drop to a root shell.

 

[knedit2]

Start with a full transcript of the device from power on, and see what is available if any at the final prompt.

Then interrupt the bootloader, and use 'printenv' and 'help' to list the variables and available commands.
Save that so the start point is preserved.
Quite often, changing the bootargs variable can get the kernel to drop to a root shell.

hello again! ive finally got the correct cables and have managed to get into the bootloader, i have got a HKVS # prompt and have added init=/bin/sh to my bootargs so they are now "console=ttyAMA0,115200 KRN_PRT=pri mac=00:00:23:34:45:66 bld_rev=937437 hardware_id=0x1 init=/bin/sh", however this is still giving me the protected shell when i boot the device. what else do i need to add? thanks

 

[alastairstevenson]

Another option to try would be to append 'single' to the bootargs variable instead.

 

[knedit2]

no luck with that sadly, still stuck here


heres everything from printenv


i noticed most other devices have "root=/dev/ram" in there somewhere, is that needed?

i also tried /bin/bash but got the same result

 

[mrpeenut24]

On one device I've checked, /bin/bash and /bin/sh both link to /bin/psh. Try /bin/ash, that's the one I've had luck with, though I've never been able to get bootargs to persist.

 

[knedit2]

On one device I've checked, /bin/bash and /bin/sh both link to /bin/psh. Try /bin/ash, that's the one I've had luck with, though I've never been able to get bootargs to persist.

nothing there either
this device didnt have any init bootarg before this, could it be getting it from somewhere else?

 

[alastairstevenson]

no luck with that sadly, still stuck here

Not looking very promising!
As they are exposed and used, Hikvision tends to close off these useful defaults that used to come as standard.

Another bootarg option that sometimes gives a root shell is 'loglevel=9'
And loglevel=8 usually expands the level of detail in the serial console.
Also 'debug'

 

[knedit2]

Not looking very promising!
As they are exposed and used, Hikvision tends to close off these useful defaults that used to come as standard.

Another bootarg option that sometimes gives a root shell is 'loglevel=9'
And loglevel=8 usually expands the level of detail in the serial console.
Also 'debug'

nothing on any of those either
guess they patched everything we know about

 

[knedit2]

Not looking very promising!
As they are exposed and used, Hikvision tends to close off these useful defaults that used to come as standard.

Another bootarg option that sometimes gives a root shell is 'loglevel=9'
And loglevel=8 usually expands the level of detail in the serial console.
Also 'debug'

have you ever seen the hardware_id=0x01 parameter before? i couldnt find any info on it and its one of the only ones that actually does anything lol

 

[alastairstevenson]

No, I don't think I've seen that environment variable in other devices.

 

[rearanger]

have you ever seen the hardware_id=0x01 parameter before? i couldnt find any info on it and its one of the only ones that actually does anything lol

(i assume the recent CVE vulnerability will not work on it )
What's the chipset on that camera? i notice it uses uImage . It may let you get root by using a similar method used on the G0 cams.

 

[bugmenot01]

Hey, I've just started looking at hikvision as a potential research target.

I'm a fairly experienced binary reverse engineer, but I hadn't expected hv's firmware format to be such a convoluted cluster.

I'm particularly interested in patch-diffing for CVE-2021-36260 (for which there is a public PoC) as a jumping off point.

I've downloaded a copy of the firmware from immediately before the patch and then the patched firmware. I was hoping to be able to decrypt the dav files and unpack them into some kind of filesystem.

I don't have a physical camera right now (procurement problems where I am...), so I was going to just start looking at it statically.

I've tried decrypting the first firmware image (

https://www.hikvisioneurope.com/eu/portal/?dir=portal/Technical Materials/00 Network Camera/00 Product Firmware/G5 platform(2xx3G2 2xx6G2(C) 2xx7G2(C) 3xx6G2(C) 3xx7G2(C) 1x83G0)/3xxxG2(C)/V5.5.800_210628

)

but hikpak 2.5 reports that it's not encrypted. When I try to unpack it as follows:

?> ./hikpack -t r6 -d ./firmwares/digicap.dav -o ./unpacked/decrypted
File not encrypted.

?> ./hikpack -t r6 -x ./firmwares/digicap.dav -o ./unpacked
Magic   : 484b3230
hdr_crc : 0000214c (OK)
frm_flg : 2400050051111140011

but the 'unpacked' directory only contains a short hearder file.

I'm not against diving into how hikpack works to try and figure this out, but I suspect someone here might be able to provide some guidance and let me know how best to proceed.

Thanks.

 

[alastairstevenson]

but hikpak 2.5 reports that it's not encrypted. When I try to unpack it as follows:

It's 'x' for unpack the firmware - 'd' is just for encrypted files.
However - hikpack 2.5 does not support the G5 firmware that you've linked to. It doesn't know about the structure or have keys for that series.

Unfortunately - I don't think hikpack_2.5 is going to help you in your quest.

 

[bugmenot01]

It's 'x' for unpack the firmware - 'd' is just for encrypted files.
However - hikpack 2.5 does not support the G5 firmware that you've linked to. It doesn't know about the structure or have keys for that series.

Unfortunately - I don't think hikpack_2.5 is going to help you in your quest.

Thanks for your reply, that's too bad - given the tool was outputting what looked like a clean output with no error code I had assumed it was something I was doing wrong.

I now see hikpack supports r0, r1, r6, g0, k41, and k51

It looks as though I need one of E{0-7}, G{3, 5}, H{1,5,8}, or R2.

I don't suppose you know of a tool that will unpack one of the above firmware davs?

If not I presume I'll have to get a hold of camera and use it as a decryption oracle and then hope to pull the files at run-time somehow? (I'm not a hardware guy, chip de-soldering is probably gonna brick anything I touch)

 

[antondanielvv]

Is there a source code available for hikpack 2.5?

 

[alastairstevenson]

Nope, not in public.

 

[brainslayer]

if is able to provide me a g5 flash dump i can extract the keys. i have the hik repack source btw

 

[ahl123]

Hi everyone, I have successfully unpacked firmware for terminal, but face off with encrypted script file - start.sh. Give me advise on how to solve the issue.
The file has been attached.
Thanks in advance.