Interesting, so many lzma headers with huge/inaccurate uncompressed sizes and same dictionary size. Something is not correct here and let’s have a closer look on it,
It seems that binwalk is matching the first bytes at each section to lzma compression magic numbers incorrectly. From this point on and after doing some more tests with the rest of the lzma suggested entries we will assume that binwalk’s analysis is inaccurate on that and we will not take it in consideration.
Removing the lzma entries our table will look more like this:
Starting with the gzip section, we can verify the signature,
A point of start for the moment there, let’s extract the header of the file first and we will proceed later with the gzip section.
We can see that this is the Linux bootloader running in the camera startup process. Few days ago I submitted as bug at the binwalk developers the identification of binary format files. Binwalk was not able to identify binary files properly giving false results, at the time of this writing binwalk has been updated adding a new feature, binary file identification. The results of program now verify what we found earlier,
Arm Linux bootloader on the camera.
Proceeding with the section identified as gzip we extract the data until next identified signature.
As mentioned before there is no clear mark on where is the end of the gzip section, a lot of false positives, so I go ahead and extract the section until the Zip first identified area. gunzip here was able to extract the contents with a twist,
From the initial file that was almost 9.3 Mb the extracted contents are nearly 2.7 Mb, something is not correct here either there is a lot of padding in the file or there is something more inside the contents. At this phase I was stuck, I tried different tools with no apparent results, tools that were used are deezee from matasano’s black bag ( www.matasano.com ) , signsrch from Luigi Auriemma and again binwalk.
I found a solution after a while looking at the actual hex code on the file. Using hexdump to convert the file I notice a large section inside filled with a sort of padding,
Apparently there is a section between locations 001fca20 and 00146150 filed with ff ff ff ff. Few bytes below address 001fca20, there is visible a dev.tar ( possible filesystem data ? ) entry. I cut through the file to verify that gzip compression data are still valid after chopping the tail of that contents.
Extracted area is giving a file around 1.3 MB of compressed data that expanded is still giving us the same results, trying a bit more and cutting bytes from the end I was able later even to correct the warning from gunzip about trailing garbage.
Further more, strings shows some interesting data on the file like the existence of a jffs2 filesystem and more details to ensure that this is the kernel that we are looking at
Getting the data after the kernel entry point near address 001fca20, and adding 8 bytes for cleanup
using dd again ,
file command is giving us now something
looking for the common busybox application usually found in embedded installations,
And there is the start of the jffs2 filesystem. Final part, let’s add the zip sections and mount the filesystem. In this part I could had done an easier approach but in my initial assumption the zip sections were unknown sections since I had no knowledge of the jffs2 filesystem’s location.
A bit more slice and dice,
Final cleanup of the jffs filesystem,
In order to mount the jffs2 we have two ways to do that, either
- Have a block device emulate a Memory Technology Device (MTD) via block2mtd. or
- Have kernel memory emulate a MTD via mtdram.
I choose the second way
Until next time !
Html files and cgi content for further analysis, axis