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.