partx is another useful linux command that can be used to automatically identify and create loop devices of partitions that it detects from a disk image file.
Agreed. There are dozens of tools in Linux and BSD to examine these things. The first one I tend to do is
strings file | less, to see if suspicious strings do pop up; both in images and executables. (Actually, no, the
very first one is always
file file to see if the file fingerprint is recognized by the standard
magic database, but that should be obvious.)
Note that the
mount command can create (and then automatically delete) the loopback device, when using the
-o loop option like I did. For details, see
man 8 mount, under
Loop-device support heading, near the end of the man page.
For those who are not aware,
loop devices are provided by the kernel in Linux and BSDs, which allow an user (with sufficient privileges) to synthesize a block device from an ordinary file. The block device will support the same operations as all mass storage devices –– all block devices! ––, so one can easily mount a filesystem, or even a whole partition table and some/all of its filesystems.
The only trick is that if you want to create a new filesystem image, you should use e.g.
dd if=/dev/zero of=file bs=blocksize count=blockcount to ensure storage is allocated for each byte of the image. Most Linux and BSD filesystems support
sparse files, where sections of the file may not exist, and simply read all zeroes; this way, a gigabyte-size file with just one nonzero byte at the end (or anywhere else) is usually just one allocation block long. The
dd command uses the
zero character device to fill the
file with binary zeroes.
Like I said,
mount can do the loopback device setup and teardown automatically, or you can use the
losetup command, or even do it yourself (see
man 4 loop). Other than the offset (if not at the beginning of the file) and possibly size (if not the complete file), no other details need to be specified, so the usage is very straightforward. While I like to mount such files (images) read-only via
-o ro, it is perfectly okay to mount them read-write, so that any changes will be reflected in the original file; but do remember to properly
unmount the file/image, as the kernel may cache changes and only flush them to the underlying file at unmount time. (The unmount command is, unsurprisingly,
umount, and you can supply it with either the device, or the directory on top of which the media is mounted.)
For the SD card Dave dumped, it really looks to me like a bog-standard Android system image.
One that has not been optimized, and is, uh, quite "vanilla", indicating that with some systems integration work, the boot-up time could be shortened significantly, for example. I wonder how receptive Rigol would be towards such suggestions?
(It really depends on whether they used some external team to cobble something together for them, or whether they set up their own team that is still getting up to speed on how to optimize Android for appliance use. I'm really hoping for the latter, because that means future updates could be
really nice for users, also showing how to leverage their chosen hacker-friendly stance for actually creating a better end product. Time will tell.)
Home
Help
Search
Login
Register
