Quote:
Originally Posted by Titano
I think Ixtab means a firmware image (the entire nand memory [if the kindle uses nand]).
- - - -
Then plug in your kindle and copy the file's named mmcblk0p1.bin and mmcblk0p2.bin.
|
The
device names in Linux are very regular.
mmc -- is, well, an MMC device. In the Kindles, an eMMC device (e == embedded) but the drivers don't care if the device plugs in or gets soldered in.
It does not matter how the storage is implemented, the device has a built-in "high level" controller.
Although in the case of the Kindles, the eMMC part does implement the storage in NAND behind the controller.
(The tech. data sheet is indexed in the "Tools Prefix" index.)
mtd -- Memory Technology Device. This is the driver that is used for "lower level" flash devices (NAND, NOR of various kinds).
In Linux (a Unix work-alike), true to its heritage, "all devices are files" or at least that was the Unix design goal, that all devices share the semantics of files.
(Plan-9, the successor to Unix, does a better job reaching that goal.)
In legacy *nix (and Linux) all "device files" (specifically: device nodes) appear in the file system in the /dev directory.
So just the pathname: /dev/mmcblk0p1 (first block of MMC memory, first partition) is tells you that this is a device not a file and that it has a "high level" controller in front of its storage.
The controller provides a: read/write/seek/etc interface, the lower level mtd devices provides a: read/erase/re-program interface.
The fact that you can use programs that do "file operations" on it is just "*nix at work".
In the Kindle case - the backing storage of the eMMC controller is NAND and that NAND (an mtd type device) has an erase block size of 4,096 bytes.
So if you provide the eMMC controller with 4K blocks to write, it can implement that as one 4K byte one read/erase/re-program cycle.
Using the default 512 byte block size, the eMMC controller has to use 8 read/merge/erase/re-program cycles to get the same job done.
The partitions of an eMMC device, like those of a (spinning) hard disk drive need not describe the entire storage area of the device.
In the case of the Kindles, they do not, there is storage area "outside" of that described by the partition table.
The /mnt/us
is a file system, ultimately stored on the /dev/mmcblk0p4 device. I write "ultimately" because there are a couple of VFS layers involved before the bits and bytes actual hit the silicon.
Translation: There is a lot of useful information in a *nix /dev/name.
Now, to continue with the topic at hand, getting a forensics's image file ....
We know there are four partitions;
We know the partitions 3 and 4 (mmcblk0p3 and mmcblk0p4) are not of any interest;
We know there is storage area outside of the partition table described areas;
We know that either partition 1 or partition 2 (or both) will be mounted (in-use) during "normal" operation;
We know that we can not get a complete (in the sense of being correct) image of the backing store of a file system while the file system is "in-use";
A procedure that "will work" -
Boot the system that uses partition 1 as its file system ("main"), copy partition 2; then:
Boot the system that uses partition 2 as its file system ("diags"), copy partition 1; and:
somewhere along the way (from either system):
Read the partition table of mmcblk0 (the "raw" device) and copy the storage area from 0 ... the block prior to the first block described in partition 1.
A much better procedure -
Use one of the "service and maintenance" tools that boot the Kindle into a state where it is using a RAM RESIDENT file system;
Read the partition table;
Copy from 0 .. the block prior to the start of partition 3.
Then, off-kindle, sort out the various parts of the copied image.
Since we want a quality copy of this 5.1.1 release, the second procedure is the desired one.
And GM can best recommend which of the various "service and maintenance" tools to use for this job.