I purchased the current generation Kindle with the 6" screen. This model provides the user the ability to plug the device into a computer via a USB port to interact with the device. Amazon accomplishes this ability by creating a 1.5GB portion of the device that is visible and accessible to the user as if it were a standard USB storage device.
From the research that I have conducted so far, it appears that you can treat the Kindle as you would any other USB storage device for imaging purposes. The best way to do it is to use the USB cable that Amazon provides for connecting the Kindle to a computer. You can then write block a Kindle like you would any USB device. For my research, I used a Tableau T8 USB Forensic Bridge and was able to make the image using EnCase without any problems.
I haven't spent much time on the analysis portion of this research. However, I can report that a Kindle USB Drive shows up as an mkdosfs\FAT32 situation. This makes sense given that the Kindle runs some sort of Linux OS that we can't see via this USB capture process.
There are some interesting artifacts of the low hanging fruit variety. For example, "userannotlog" file located in the system folder. It lists the last book that I read, what my position was in the book and it also includes clear text time stamp information that correlates with when I know I was reading the book in question. Very cool.
The "documents" folder, as you might expect, contains the actual content that I have on my Kindle. I don't have much on it right now, but each book has an .azw file which is the actual content of the book in a proprietary format and a .mdp file that...well, I don't know what it does at this point.
There is a "search indexes" folder in the system\search indexes folder path that, one assumes, keeps track of searching done on the device. I bought a wine book that I did a search for the word "Pinotage" (Sigh. Yes, add "wine geek" to my list of vices...) and I used that as a keyword for a search...and came up with nothing eventful. There were about 20 hits on the word, but all of them in the context of other words in that alphabetical range so nothing that would show that I searched for that word.
You'll find a lot of indexed words in the system\search indexes\Index.db What I'm seeing already is that there are three bytes before each word that are clearly meaningful. For example, the word "pinewood" is preceded by 0x740008. So what we have is the word "pinetorch" and then 0x740008 and then the word "Pinewood". I don't know what the 0x74 means or if it's associated with the word "pinetorch" or "pinewood", but the 0x08 is the length of the pinewood entry. It's probable that this length indicator actually uses two bytes which would make 0x0008 the bytes that indicate length. I'm seeing this behavior consistently in this index file where a word is preceded by byte(s) whose hex value correlates with the length of the word that comes after the byte(s). Interestingly, I'll see a block of words pretty close together and then one word will end with 0x7A instead of 0x74 and then there won't be anymore words until a new block starts again about 900 or so bytes later. Towards the end of this file, there is a listing of the books on the Kindle and the paths to their associated files.
There is also a reader preferences file in the system\com.amazon.ebook.booklet.reader\reader.pref location. It has a clear text time stamp that appears to correlate with the last time I used the Kindle. It also declares what preferences I'm using for a dictionary, the type of justification I'm using and the last book I read.
There's a white paper in here for someone somewhere.
