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.

Improve this question
7
  • 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
    Commented Sep 30, 2016 at 0:55
  • I saw similar files in Hikvision firmware, where the tar.lzma files were encrypted.
    – ebux
    Commented Sep 30, 2016 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
    Commented Sep 30, 2016 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
    Commented Sep 30, 2016 at 16:29
  • 1
    In my case, the kernel contained an initramfs, which performed the decryption using a kernel device.
    – ebux
    Commented Sep 30, 2016 at 16:37

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.