1

I have several IP cameras from china, and I need to add some software to it. I have to ways how to burn my software into camera ROM using hardware programmer and using special binary what I upload into camera using camera's Web interface. I decide to use special binary.

Ok, I'd download this binary from here. The binary successfully uploaded into camera and I decide to watch inside it. I use binwalk program. binwalk tell me next:

[arhichief@arhichief-pc updates]$ binwalk di20_fl_03.upw 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
152           0x98            uImage header, header size: 64 bytes, header CRC: 0x863E2566, created: 2014-08-01 04:16:33, image size: 3091196 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0x3B8FC9B, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.0.8"
16243         0x3F73          gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
3091412       0x2F2BD4        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 7403482 bytes, 24 inodes, blocksize: 262144 bytes, created: 2015-05-10 02:32:07

The file command told me, what it is a binary image of ROM:

[arhichief@arhichief-pc updates]$ file di20_fl_03.upw 
di20_fl_03.upw: UNIF v-740431636 format NES ROM image

After extracting the parts of binary, I found that data after 0x2F2BD4 is an image of the storage with additional software and bash script to run it. Looks like, I found the way how to insert my software into camera.

Using dd, I get this part of binary, extract it, add my programs, pack it back and write back into binary file.

[arhichief@arhichief-pc updates]$ dd conv=notrunc bs=1 if=di20_fl_03.upw skip=3091412 count=7403482 of=fs.sqhsfs
7403482+0 records in
7403482+0 records out
7403482 bytes (7.4 MB, 7.1 MiB) copied, 8.7586 s, 845 kB/s

[arhichief@arhichief-pc updates]$ unsquashfs fs.sqhsfs 
Parallel unsquashfs: Using 4 processors
23 inodes (72 blocks) to write

[=================================================================================================================================================================================================================================================================|] 72/72 100%

created 23 files
created 1 directories
created 0 symlinks
created 0 devices
created 0 fifos
[arhichief@arhichief-pc updates]$ cd squashfs-root/
[arhichief@arhichief-pc squashfs-root]$ dd if=/dev/random bs=1 of=TEST.FILE count=1258291
^C234+0 records in
234+0 records out
234 bytes copied, 28.535 s, 0.0 kB/s

[arhichief@arhichief-pc updates]$ mksquashfs squashfs-root/ fs.sqhsfs -comp xz -Xdict-size 100% -b 262144
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on fs.sqhsfs, block size 262144.
[=================================================================================================================================================================================================================================================================|] 78/78 100%

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
    compressed data, compressed metadata, compressed fragments, compressed xattrs
    duplicates are removed
Filesystem size 8529.98 Kbytes (8.33 Mbytes)
    56.79% of uncompressed filesystem size (15020.30 Kbytes)
Inode table size 494 bytes (0.48 Kbytes)
    47.23% of uncompressed inode table size (1046 bytes)
Directory table size 374 bytes (0.37 Kbytes)
    87.59% of uncompressed directory table size (427 bytes)
Number of duplicate files found 0
Number of inodes 25
Number of files 24
Number of fragments 3
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 1
Number of ids (unique uids + gids) 2
Number of uids 1
    arhichief (1000)
Number of gids 1
    users (100)

[arhichief@arhichief-pc updates]$ dd if=fs.sqhsfs of=di20_fl_03_new.upw conv=notrunc bs=1 seek=3091412
8736768+0 records in
8736768+0 records out
8736768 bytes (8.7 MB, 8.3 MiB) copied, 8.81158 s, 992 kB/s

After what I match new firmware update binary with binwalk to make sure, everything is ok.

[arhichief@arhichief-pc updates]$ binwalk di20_fl_03_new.upw 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
152           0x98            uImage header, header size: 64 bytes, header CRC: 0x863E2566, created: 2014-08-01 04:16:33, image size: 3091196 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0x3B8FC9B, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.0.8"
16243         0x3F73          gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)
3091412       0x2F2BD4        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 8734702 bytes, 25 inodes, blocksize: 262144 bytes, created: 2016-06-06 07:46:09

I try to upload new firmware update binary into the camera, but camera return me an error.

Ok. I'd try to search for some solutions and found this. From answers in that thread I get a python script what extract firmware and shows the checksums of firmware parts. Good. This script show me next:

[arhichief@arhichief-pc updates]$ python2 extract_hikvision_dav_file.py di20_fl_03.upw 
Magic number:    5a4b5356
Header checksum: 0000223a
Header length:   00000098
File number:     00000002
Language:        00000001
Device class:    00000002
Calced checksum: 0000223a
75496d6167650000000000000000000000000000000000000000000000000000980000003c2b2f001d4e7b18
File name:          uImage
Start:              00000098
Length:             002f2b3c
Checksum:           187b4e1d
Calced checksum:    187b4e1d
6170702e696d6700000000000000000000000000000000000000000000000000d42b2f00000071003d7de138
File name:          app.img
Start:              002f2bd4
Length:             00710000
Checksum:           38e17d3d
Calced checksum:    38e17d3d

[arhichief@arhichief-pc updates]$ python2 extract_hikvision_dav_file.py di20_fl_03_new.upw 
Magic number:    5a4b5356
Header checksum: 0000223a
Header length:   00000098
File number:     00000002
Language:        00000001
Device class:    00000002
Calced checksum: 0000223a
75496d6167650000000000000000000000000000000000000000000000000000980000003c2b2f001d4e7b18
File name:          uImage
Start:              00000098
Length:             002f2b3c
Checksum:           187b4e1d
Calced checksum:    187b4e1d
6170702e696d6700000000000000000000000000000000000000000000000000d42b2f00000071003d7de138
File name:          app.img
Start:              002f2bd4
Length:             00710000
Checksum:           38e17d3d
Calced checksum:    38754ea4

I found that checksums in default and updated firmwares are mismatch. I have some experience in C, so, I decide to rewrite python script in C and modify it so it will correct checksums. Here is my code. So, It works well, I think. The results of python script and my code are same after my code patch checksums. But when I try to upload firmware with corrected checksums into camera, it still return error.

I don't know what I shall do next, and I think you will give me some advices.

Thanks in advance.

P.S. Please, sorry for long question. I think you will need to know all my steps to give me correct answer. I think I've made an error some there in it.

  • 2
    Reverse engineer the updater program which consumes firmware update binaries on the camera; find out which check doesn't pass. Post your findings as the answer here. – Dmitry Janushkevich Jun 6 '16 at 13:42
  • Thanks for response. Maybe there is a an information about how to get this binary file structure? – ArhiChief Jun 7 '16 at 14:41
  • download link is dead – julian Jun 24 '17 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.