Airship rebranded Hikvision ds-7216-HGHI-SH

elbartek

elbartek

n3wb
Oct 17, 2018
11
0
Montreal, QC
Hi all!

First of all, I am an electronics enthusiast and currently finishing studies in computer engineering.
I have a pretty complete lab at home with oscilloscopes, logic analyzer and different lab tools that allow me to debug pretty well many systems. That will just help you know at what level I am and help you give me any recommendations.

So, I got this Airship ds-7216-hghi-sh unit from *bay at a great price, stating that it is functionnal and new, and it actually seems new when I got it...

So, hey, no output from VGA/HDMI when I booted it up.. tried many things... and then well after a few hours of reading / testing. I got fed up and decided to debug it with console, tftp and the common...

I have tried to tftp/change firmware with like 10 different versions of firmware for Hikvision ds-7216-hghi-sh...

But no success... The digicap.dav file is transfered with u-boot (fastboot) over tftp... Flash is erased, Flash is written, Flash is checked, unit is rebooted and...

I get a data abort pretty fast and the cpu is rebooted... each time it boots on every digicap.dav I tried... right after the Kernel loading...

So, my question is..

Is the Airship rebranded device (which is a hikvision for 99.99999%, same case, same pcb, same model number, etc..) using some protection in uboot that prevents firmware upgrades with real hikvision firmware? or is the airship firmware any different? if so, where can I get it?

I cannot seem to interrept uboot, it is in fastboot mode and only lets ctrl-u to upgrade firmware, I cannot get into a prompt to get more information about what is going on ...


Anyone had any experience with airship rebranded hikvision units?

I am ready to go as far as to reflash the flash chip completely if anyone could provide the complete hex file for my model... or even resolder a new flash chip. The hardware I think is 100% hikvision ds-7216-hghi-sh (turbo hd 1.0)

So if anyone has that model and could read the flash chip and send me a copy, that would be great! as I think the problem lies in the bootloader ... and hell, airship doesnt seem to be in business anymore, I can't find any firmware / support and their new site is BS.

Thanks all!
 
elbartek said:
it is in fastboot mode
Click to expand...
It won't be - that's a hard-coded low-level all-else-fails recovery mode for the SoC.
I'd guess that you are seeing Hikvision's modified u-boot.
elbartek said:
only lets ctrl-u to upgrade firmware,
Click to expand...
Not sure about the specific model - but on others there are some hidden commands at the 'Control-U to update firmware' prompts.
Try using a b (for bootloader).
If that works, use help and printenv
But don't try the f (for format the flash).
elbartek said:
I have tried to tftp/change firmware with like 10 different versions of firmware for Hikvision ds-7216-hghi-sh...
Click to expand...
From where? Could be for the wrong model.
Turbo 1.0 seems to be here - but doesn't match the model number you quoted : DOWNLOAD PORTAL
The model number is better matched here : DOWNLOAD PORTAL
 
Hi, I really appreciate your input! Thanks.

It is in fastboot mode, since Uboot on boot has the (fastboot mode) suffix... so I guess it is in recovery mode (the SoC).

I will try to paste the console output tomorrow so you can clearly view what I see.

I tried many keys and combinations... u, U, f and others... all combinations seem only to lead to firmware update.

If you look closely it does in fact match my model the turbo 1.0... it is suffixed by HGHI-SH (not HGHI-Ex or any other that is found in the second folder you suggested... I went thru all the folders and the -SH model seems to be the first model, turbo 1.0)

The data abort after Loading Kernel seems in fact to point to an incompatible firmware, but I didn't debug the breakpoint ... I might jtag it and step into the code if by any means possible...
The old version of the firmware doesn't seem to be encrypted, I could extract the files... Maybe I could dissassemble and follow and step into execution and perhaps harvest more info on what is happening... but I don't want to go there yet as there may be a better easier solution... as perhaps at least reflashing the chip with the original dump... which I don't have duh.

Do you know which SOC it is, what arch? I didn't remove the heatsinks yet... And I'm trying to avoid having to mingle with code..I am hoping that someone knows which firmware will go thru ...
is that a common break (data abort after kernel loading...) seen on incompatible firmware?
 
Well,

I did disassemble the oldest Turbo HD 1.0 firmware... after decompressing all the files..
I disassembled both uImage (the uboot image) and then hicore file..

IDA seems to point us to an ARMv7 architecture...
 

Attachments

  • arch-info.PNG
    arch-info.PNG
    10.3 KB · Views: 17
I tried and mounted the flash...
Did check the printenv variables...
on bootm ... the kernel crashes at the same address and constantly loops... probably wrong firmware??

when I try cramfsload, it gives me a CRAMFS load error... error while decompressing...

That makes me wonder... so cramfsload tries to decompress the lzma compressed image to ram right? now might it be that the compressed firmware I have stored doesn't match the decryption cramfsload uses ?

Could you provide me any useful uboot command line guidance for these dvrs?
is there a way to probe and test the RAM / flash?

I am still under the impression this might be just a firmware mismatch... and perhaps that airship has included a "magic" number or check somewhere in their own firmware... and therefore I'd just love to find a full flash dump and burn it

If that isn't the case, maybe the decompression error is effectively a symptom of a hardware failure in the RAM ? because the flash seems to be erased, written and checked OK.
 
elbartek said:
on bootm ... the kernel crashes at the same address and constantly loops... probably wrong firmware??
Click to expand...
Pretty likely, I believe.
elbartek said:
when I try cramfsload, it gives me a CRAMFS load error... error while decompressing...
Click to expand...
What are you trying to load?
elbartek said:
cramfsload tries to decompress the lzma compressed image to ram right?
Click to expand...
What image? Not the Hikvision firmware, it's not that simple.
elbartek said:
doesn't match the decryption cramfsload uses
Click to expand...
It doesn't use decryption.
elbartek said:
Could you provide me any useful uboot command line guidance for these dvrs?
Click to expand...
That's where the help command would come in.
It varies a lot, depending on which Hikvision team last tweaked it.
update is useful, as is upgrade.
With a working uImage, bootargs usually provides some chances to change what happens on boot.
elbartek said:
perhaps that airship has included a "magic" number or check somewhere in their own firmware
Click to expand...
The firmware header that Hikvision use has an OEM field - that could be used in various ways.
But I'd doubt that extends to the bootloader.
 
Thanks for the info.

So, in practice

cramfsload 0x80400000 uImage ---> decompresses uImage from flash to ram on boot
this gives the following output:

error -5 while decompressing...
CRAMFS Load error <ffffffff> ...

(The system doesn't break here)

Loading legacy kernel from 0x80400000

Loading kernel...

and...

data abort
(here we have the display of registers)
resetting cpu...

Sorry I will copy the exact output soon, its on my other computer and I cannot copy paste right now...

BTW, it seems that when you use 'cramfsload' it defaults to 'cramfsload 0x80400000 uImage ... meaning I'd be trying to load the uImage
I have good knowledge of linux, but by no means am I an expert... did some embedded linux in the past, but didn't play too much with the bootloaders from a reverse engineering perspective.

The files from the oldest firmware available on the hik portal are just compressed and not encrypted (you can decompress, view start.sh and dissassemble code)... the newer firmwares are lzma compressed and encrypted... you can decompressed the digicap.dav, but after that they are hashed or encrypted or?
 
elbartek said:
cramfsload 0x80400000 uImage ---> decompresses uImage from flash to ram on boot
Click to expand...
uImage is not a cramfs image - it's a pure binary executable with it's own built-in uncompressor front end.
That's what gives the log 'Uncompressing the kernel .. done'
Nothing to do with cramfs.
 
but the log shows a CRAMFS error... the cramfs algorithm is in uboot right? so the error would be from a mismatched compression format that cramfs uses vs. the compressed image... or the image is corrupted and cannot be decompressed? or there is a checksum or something going wrong?
 
elbartek said:
Yes you are right... but uImage is compressed in digicap.dav and gets uncompressed to the ram with cramfs no??
Click to expand...
No - uImage is loaded into RAM by the bootloader, the hardware environment is initiallised, then uImage is started at the specified address.
The uImage uncompressor runs and expands and relocates the code.
When done, it transfers to the specified start address and the kernel boots up.
How uImage is held in the firmware is irrelevant as it gets extracted and written to the flash in its final-use form.
 
I'm extrapolating from what I've seen in later NVRs - the structure and layout may be quite different in your earlier model DVR, so may be best not to take my comments as absolute.
 
Ok thanks for the brief tutorial. It's about the same I had in mind, its clearer now.
I am just trying to guess what would be the preferable approach to debug the system... and the only real useful information the board spits out to guide me
is the CRAMFS error at boot (error while uncompressing -5)... and then the data abort
 
You must log in or register to reply here.
Top Bottom