Jffs2 Extract

[Luciana]

UpdateA few people were kind enough to correct me on some of my terminology. Where appropriate, 'decompiling' has been replaced with 'extracting'. My apologies if that confused or mislead anybody :)

The software downloads as a ZIP, and when extracted reveals an executable. Extracting the .exe shows the HDR files mentioned on the website, but what is an HDR file? I was expecting something like a .bin, and running file just shows they are data files. Not a lot of help.

Starting from a software update, and some critical thinking, I was able to extract the firmware update for my Honeywell Tuxedo. As a result, I have access to the proprietary binaries, and additional components that make up the device. My next two approaches are:

You can find the firmware images of the Xiaoyi camera online, typically in a ZIP file. I have provided links to this at the end. Unpacking the ZIP file gives you a single file called home. Running the file command reveals that this is a U-Boot image with the file system image tacked on:

An idea was to guess the block size from the JFFS2 image but that meant I needed to understand JFFS2 image format first. It was relatively straightforward and I wrote a Python script to parse the image. After poring through the script output, I noticed a pattern:

After the free space (0xffff), the starting offset would always be a multiple of 0x10000 (or 65,536). It seemed like a nice round number for the flash erase size and too much of a coincidence that there was free space immediately before it. After specifying 64KiB as the erase size, block2mtd now complains that the file size must be a multiple of the block size, which somewhat makes sense. Note that the size of the JFFS2 image extracted above (7,974,512) is definitely not a multiple of 65,536. To fix this, I added functionality in the script to pad the image with 0xFF until it becomes a multiple of a specified block size.

As you probably can guess, the Xiaoyi camera uses a very popular chipset, the HiSilicon Hi3158 HD IP Camera SoC. If you search around, you can find the SDK as well as various code samples and projects that can run on this SoC. This is essentially an ARM device that has acceleration for video encoding and processing, and best of all it runs Linux.

Hi, as you have already extracted the u-boot and rootfs can you share a download link?. I have bricked my camera and and finds out if I have u-boot, rootfs, conf , env and home images I might be able to unbrick it.

I recently extracted the firmware (u-boot system) from an old Sagemcom router and analyzed it using the binwalk utility for a personal reverse engineering project.

Despite identifying a root filesystem (likely JFFS2 based on string analysis), binwalk was unable to recognize or extract it.

I know that the filesystem is JFFS by examining the boot info, and performing strings analysis on my dump. (You can check the git repo given further down)

From what I can see in the logs you posted, you've actually done fine. Your issue appears to be that most everything lives inside of ubi volumes. You can use something like the UBI reader python utility on your full nand binary to pull them out.

Nope. Just use ubireader on your full (decompressed) "nand-65535-bin". Leave binwalk out of it at this point. I just tried it myself and it worked fine. Note, this will not pull out the other non ubi mtd sections.

No problem. An additional note, even though the tool has labeled the segments it had found as ubifs, they may not be. If they are ubifs, the ubi reader tools can also be used to extract the ubifs contents. For ones that are not, some manual analysis, or a tool like binwalk, will likely tell you what they are.

Thanks to your advices, I finally managed to extract the whole filesystem from the different partitions (operational & rescue).

Since my objective is to reverse engineer the router i've targeted /etc/passwd and ./etc/shadow files.

Unfortunately the contents of these files show me that the authentication system for root has been delegated to a system other than the default Linux system.

Is it common pratice for U-boot and does the password hash has been moved somewhere else ? Or may i assume that the router was probably configured via network by using LDAP, NIS, ... letting me nearly no hope for getting this password has ?

Thank as always for your response.

I can't really say I have any advice there, other than to say that sounds unusual, particularly for attempting to log in via a serial console. If you can't find those files you may want to check for an additional compressed filesystem packed with the kernel image.

The touch screen test simply means that when you touch the screen it flips through the pictures that it would have displayed normally, it does not output anything on the console. Note that the way it is configured out of the box the screen will go out if nothing is done on the terminal for a few seconds (it goes into a low power state) so if your LCD is currently blacked out you may be able to get it to come back by touching a key on your serial terminal. When the touch screen test completes it just goes to a blank screen, at that point just press another button to run some other test or display an image (like S9).

In general on a SD card you would not use the jffs2 filesystem image, this is what you would normally use in a on board flash situation, the ramdisk is possible but I would normally recommend a separate partition on the SD card. With the SD card you can partition it into a boot partition (FAT) and a filesystem partition (EXT3) so that your filesystem exists cleanly on the SD card, once the partition is in place you could simply extract the nfs.tar.gz file into it. There are several articles (and even threads on this forum) out there on setting up SD cards for booting on OMAP3, you may start with for getting your initial format done if you have not already, and then extract your nfs.tar.gz file into the second partition.

I am not too familiar with the serial numbers being used these days, but I can say that unless you have a very old board you bought from some odd source (like eBay) you probably have a Micron board, only the early boards back during the beta period had Samsung NAND.

I am working with Linux (3.4.31+) embedded system booting from JFFS2 partition. I frequently encounter a problem of a file corruption when power loss occurs while other files are being removed. It happens during upgrade procedure of the platform. These are simplified steps of the upgrade:

The mentioned power loss occurs in 5. step. Note that the rootfs.squashfs is mounted as read only and is never altered during upgrade. Even though this file gets corrupted and after device is powered on you can see that the file's md5 checksum is different, size stays unchanged, image can be mounted but it is impossible to read some of the files from this image.

A while ago I did see corruptions to the file that is open and being written to. Waiting longer than fs commit time (5 seconds by default) solved the problem. That means in your step 1 after extracting all the files from tar.gz a sleep of 7 seconds will allow the fs to settle down and get flushed to the flash. If that works for you, let us know.

A partition small enough so that the gc collects too often or early could erase previous logs prematurely. That subsequently could cause rollback too shallow thus files could end up at a corrupted state. This is my reading of jffs2 algorithms, not verified with experts or in practice yet.

Maybe two sets of same files are required. Each set will be written to apart from the previous set by a time interval longer than the commit time, e.g. 7 seconds. After the power up, determine which set is still valid and use the valid set.

There has been very little information about jffs. Some of my views are just guess, and some of the guesses were supported by testing in limited conditions. Thus I cannot guarantee the views are right. When I sift through the kernel commits in jffs area, it's obvious that it is very hard to track which version has what bugs, and when those bugs were fixed. Maybe if you try a different version the problem will be different.

So things didn't go as planned (expected with any HWRE), I kept finding that there are a lot of issues with flashrom and the Bus Pirate (Open GitHub Issue). Despite getting the "Reading flash..." message in the terminal, the process just hanged. I didn't want to deal with the effort of configuring my Bus Pirate, so I opted to use my Shikra, a FT2232H/FT232H based hardware hacking tool (GitHub and usage instructions) (Flashrom FT2232_SPI page).

Reading with the Shikra, this process took approximately about 5 seconds. While exploring the binary with Ghidra, I also soldered on some wires for access to the UART. Conveniently I can use the Shikra also for UART!

So, at this point I have a firmware image, and now UART access... do I have root? No, not yet. At this point I played around with U-Boot and set the bootargs to get a root shell, this did not work and I booted into a "nobody" shell, and the passwd/shadow files cannot be read. I'm not exactly a linux/bash expert, and so at the time I thought it was strange that the passwd/shadow files pointed to a /etc path in a JFFS2 filesystem. This turned out to be a crucial detail when I used binwalk later...

The next method I chose to see if I could get the password, was to analyze the firmware image, and this is where binwalk came in handy big time! Of interest was that JFFS2 filesystem, I took a lucky guess and mounted the data from the first JFFS2 partition.

Of interest to me was the JFFS2 filesystem, because I noticed earlier that the passwd and shadow files pointed to a /etc path in a "JFFS2" partition. So after using binwalk to extract the contents of the flash dump, I followed this guide on mounting the JFFS2 filesystem. Some of the modprobe commands don't work, but I still managed to mount the file system anyway. From the mounted partition I then copied the passwd and shadow files and proceeded to use John The Ripper to crack this MD5-crypt hashed password.

3a8082e126