Binwalk does carving, it doesn't care if embeedded file maybe cut into pieces, and its the parts are not stored in the container file continuously. It just finds JFIF header and tries to guess the size, and saves data starting from the point it found the header at. You may try to carve using photorec, but most probably it won't help either.
as my previous answer was deleted (I'm guessing because it was not an answer per se) I've got more of an answer for you.
the firmware does nothing to stop you from using UART to interact with it except require a login.
root login is enabled for such an endeavor and you already have the password in the buildroot.config file.
from there you'll need to dig into ...
I was able to extract the file system just fine. I used Binwalk v2.1.2b and have sasquatch installed.
Extracted file system:
_squashfs.tmp.extracted/squashfs-root $ ls
bin boot config dev etc home lib media mnt opt proc root root.dev run sbin selinux srv sys tmp usr var
It is indeed for a MIPS device:
$ file bin/bash
bin/bash: ELF 32-...
Assuming nothing is cryptographically signed, that should be possible. You simply need to follow your steps in reverse. If you used binwalk's extract option, that made it too easy; you'll want to figure out how to unpack/pack the image manually (maybe the verbose option will provide more info on the steps taken). I realize this is a generic sounding answer, ...
If you run strings on your firmware file, you can typically get a lot of helpful information. In this case, since I don't know what your device is other than a Harman Kardon "something," I searched through the strings in a text editor until I found the line
User-Agent:Harman Kardon AVR151/AVR1510
Just to double-check the firmware does belong to ...
you can mount jffs2 file system directly
fo rmount jffs2 file system on linux
One method of mounting JFFS2 images uses the mtdram module to emulate an MTD device using system RAM. This works well for JFFS2 images that are less than approximately 32 MB but will not work for larger images since it requires allocating a large amount of system RAM. The basic ...
A few things:
Please include an entropy plot of the file using the -E flag; this will show if any portion of the file is indeed compressed or encrypted.
Please include a link to either the firmware download site or a direct download link, as well as a link to the UAV product page.
The presence of plaintext strings such as "description" and "image" in the ...
Looking at the entropy of a file's contents is a good way to understand whether some/all of it is compressed or encrypted. Any good compression or encryption will result in entropy in the region of 95% or higher.
For this firmware, binwalk -E shows large areas with entropy in the 70-85% range (probably code), with other much lower (likely data) and only ...
I read about similar issue with ZTE modem: ZTE encrypted backup config file
It was ZLIB-compressed and encrypted with AES in ECB mode with a 16-byte key. You can read this topic, maybe it can work for your modem too.
There can be several reasons for that:
Sometimes you want parts of it read/write which squashfs doesn't support. Other parts should always be read-only, so there squashfs would be a great fit.
Some vendors allow OEM-partitions that contain changes specific to that OEM, while that doesn't necessarily have to be a different filesystem it's often a filesystem ...
Binwalk has this feature but you need to enable it explicitly:
Scan target file(s) for common executable opcode signatures
A project which explicitly tries to determine an architecture of a given binary is cpu_rec from Airbus.
Please note that both solutions can only handle a small set of processors: binwalk has a short list of ...
Thanks for the pointers. At least the xz.txt answers one of my questions, which is why the XZ util won't work to decompress. Although I still don't think what binwalk extracts is the exact XZ file generated by kernel make process. More on that below.
The kernel is a UEFI enabled kernel, so I'm guessing the first PE image is the EFI stub.
The specific ...
I've found this project https://github.com/lorf/csr-spi-ftdi, along with info:
BlueCore 2 chips (such as BC212015) are not supported in BlueSuite 2.4 and above
what means they are intentionally try to enforce developers to use more high level tools .
Above github tool should help you identify exact chip without disassembling physical device. I've checked ...
Main part of fortigate firmware is a /bin/init executable, most of other files are just symbolic links to it. So, you can obtain this file (or any other file of interest) from device or VM using fnsysctl and exec backup commands, together with the configured tftp-server. In my case it looks like this:
#> fnsysctl cp /bin/init /var/log/root/mlog.0