2

We are trying to examine a firmware download for a product we have running on our local network. Using the command

binwalk -Me filename

we generated a folder that contains the following content:

184A46C.cramfs
276466C.cramfs
6C.cramfs
C2426C.cramfs
cramfs-root/
cramfs-root-0/
cramfs-root-1/
cramfs-root-2/

Binwalk appears to have opened the CramFS just fine. So navigating into cramfs-root and running the file command, we see the following:

app.tar.lzma:    data
copy_logo:       data
cramfs.img:      empty
dvrCmd.tar.gz:   data
hicore.tar.lzma: data
hisi.tar.lzma:   data
logo.tar.lzma:   data
misc.tar.lzma:   data
new_10.bin:      data
player.bin:      PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed
start.sh:        data
uImage:          u-boot legacy uImage, Linux-3.0.8, Linux/ARM, OS Kernel     Image (Not compressed), 2854980 bytes, Tue Apr 14 10:16:02 2015, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x6C502F38, Data     CRC: 0xE9307D6E
version:         ASCII text
webs.tar.lzma:   data

Other than the uImage file, which apparently contains a linux kernel, most of the files here are apparently .tar.lzma files. Attempting to open one of them as a normal .tar.lzma is not working for us.

tar --lzma -xvf logo.tar.lzma
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Trying something else:

unlzma logo.tar.lzma
unlzma: Decoder error

lzmainfo seems to think it is valid, however, but it is calculating it as a laughably large, multi-petabyte file. I am quite sure it is not.

lzmainfo logo.tar.lzma

logo.tar.lzma
Uncompressed size:             8351652399384 MB (8757342266336797407 bytes)
Dictionary size:               525 MB (2^29 bytes)
Literal context bits (lc):     0
Literal pos bits (lp):         2
Number of pos bits (pb):       4

I've uploaded the file here if you care to look at it.

  • We can infer that, ultimately, there is an image file somewhere in there. So is there a known-plaintext technique that can be used to break the "encryption" (non-standard compression)? Thanks. – secure to a fault Sep 30 '16 at 0:55
  • I saw similar files in Hikvision firmware, where the tar.lzma files were encrypted. – ebux Sep 30 '16 at 15:10
  • @ebux How do you know that the files were actually encrypted, rather than merely compressed in a non-standard way? Is there a tool you can use to detect encryption, determine the cypher used, etc.? – secure to a fault Sep 30 '16 at 16:21
  • @ebux Also: although the .tar.lzma files are un-openable, the linux kernel is clearly visible in plain text. Wouldn't it be possible to run the linux kernel in an emulator, and use the emulator to read the file system? I opened the chassis, looked at the board, and googled the part numbers for chips I saw. I didn't see any crypto devices on the board, so I'm going to assume that the decryption is implemented in the firmware image itself, in the plaintext portion. – secure to a fault Sep 30 '16 at 16:29
  • 1
    In my case, the kernel contained an initramfs, which performed the decryption using a kernel device. – ebux Sep 30 '16 at 16:37

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.