Digital photo frame forensics
In Part 1 we discuss how to recover images that were stored within the internal flash storage of the photo frame. In Part 2 we show how to wipe the contents of the internal storage of a photo frame. In Part 3 we show the steps for creating a TrueCrypt volume on a photo frame.
NOTE: Proceed with the following at your own risk! Many of the commands below can result in your hard drive being overwritten if you select the wrong device. Likewise, it is possible that certain digital photo frames may react unexpectedly to some of the operations below, and you may end up "bricking" your digital photo frame as a result. As a precaution you should use dd to take a backup of the image of the digital photo frame's flash storage (instructions below) so that you can try to restore it to its original state in the event of problems. But don't proceed unless you can accept the consequences of "bricking" your photo frame!
We begin by powering the photo frame and connecting its USB port to our computer. A quick way to confirm what device Linux has associated with the internal storage of the photo frame is to use the dmesg command. In the example below we can see that the frame's storage is associated with device /dev/sdc:
user@linux:~$ dmesg <snip> [55233.397944] usb-storage: device found at 6 [55233.397946] usb-storage: waiting for device to settle before scanning [55238.396434] usb-storage: device scan complete [55238.397414] scsi 6:0:0:0: Direct-Access Kodak EasyShare EX-101 1 Di PQ: 0 ANSI: 2 [55238.398278] scsi 6:0:0:1: Direct-Access Kodak EasyShare EX-101 1 Di PQ: 0 ANSI: 2 [55238.399152] scsi 6:0:0:2: Direct-Access Kodak EasyShare EX-101 1 Di PQ: 0 ANSI: 2 [55238.400027] scsi 6:0:0:3: Direct-Access Kodak EasyShare EX-101 1 Di PQ: 0 ANSI: 2 [55238.401056] scsi 6:0:0:4: Direct-Access Kodak EasyShare EX-101 1 Di PQ: 0 ANSI: 2 [55238.401665] sd 6:0:0:0: Attached scsi generic sg3 type 0 [55238.401813] sd 6:0:0:1: Attached scsi generic sg4 type 0 [55238.401956] sd 6:0:0:2: Attached scsi generic sg5 type 0 [55238.402093] sd 6:0:0:3: Attached scsi generic sg6 type 0 [55238.402235] sd 6:0:0:4: Attached scsi generic sg7 type 0 [55238.418181] sd 6:0:0:3: [sdf] Attached SCSI removable disk [55238.422147] sd 6:0:0:0: [sdc] 206848 512-byte logical blocks: (105 MB/101 MiB) [55238.423647] sd 6:0:0:1: [sdd] Attached SCSI removable disk [55238.425269] sd 6:0:0:2: [sde] Attached SCSI removable disk [55238.426770] sd 6:0:0:4: [sdg] Attached SCSI removable disk [55238.427513] sd 6:0:0:0: [sdc] Write Protect is off [55238.427516] sd 6:0:0:0: [sdc] Mode Sense: 0f 00 00 00 [55238.427519] sd 6:0:0:0: [sdc] Assuming drive cache: write through
For kicks we can also use the lsusb command to confirm the USB ID of the photo frame:
user@linux:~$ lsusb <snip> Bus 002 Device 006: ID 040a:1003 Kodak Co.
Next we wish to examine the partition information and layout of the flash storage. This is done by issuing the mmls command against the device /dev/sdc. Normally it would be desirable to first create a forensic copy of the storage before proceeding further (dd if=/dev/sdc bs=4096 of=kodak.dd conv=notrunc,noerror,sync), however we will skip this step for simplicity and work directly on the device:
root@linux:~# mmls /dev/sdc DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000031 0000000032 Unallocated 02: 00:00 0000000032 0000206847 0000206816 DOS FAT16 (0x06)
The output above shows that the FAT16 partition begins at offset 32. This will be the offset that we will specify in the majority of the following commands by issuing the "-o 32" parameter. We now use fsstat to examine the file system information of this FAT partition:
root@linux:~# fsstat -o 32 /dev/sdc FILE SYSTEM INFORMATION -------------------------------------------- File System Type: FAT16 OEM Name: MSWIN4.1 Volume Label (Boot Sector): USBFDD-BOOT Volume Label (Root Directory): KODAK File System Type Label: FAT16 Sectors before file system: 63 File System Layout (in sectors) Total Range: 0 - 206753 * Reserved: 0 - 1 ** Boot Sector: 0 * FAT 0: 2 - 404 * FAT 1: 405 - 807 * Data Area: 808 - 206753 ** Root Directory: 808 - 839 ** Cluster Area: 840 - 206751 ** Non-clustered: 206752 - 206753 METADATA INFORMATION -------------------------------------------- Range: 2 - 3295142 Root Directory: 2 CONTENT INFORMATION -------------------------------------------- Sector Size: 512 Cluster Size: 2048 Total Cluster Range: 2 - 51479 FAT CONTENTS (in sectors) --------------------------------------------
The FAT CONTENTS above does not show anything being allocated in the FAT table. So we use fls -r to see whether there are any deleted files:
root@linux:~# fls -r -o 32 /dev/sdc r/r 3: KODAK (Volume Label Entry) v/v 3295139: $MBR v/v 3295140: $FAT1 v/v 3295141: $FAT2 d/d 3295142: $OrphanFiles
Nothing shows up. As an example if we were to copy one file (image001.jpg) to this file system and then delete it, it would normally look like this:
root@linux:~# fls -r -o 32 /dev/sdc r/r 3: KODAK (Volume Label Entry) r/r * 5: image001.jpg v/v 3295139: $MBR v/v 3295140: $FAT1 v/v 3295141: $FAT2 d/d 3295142: $OrphanFiles
Given that I'm confident that this digital photo frame did have JPEG images stored within its internal storage in the past, I anticipate that if there are any actual JPEG images remaining somewhere on the internal storage I will be able to find them by searching for the keywords JFIF and EXIF. So we use the strings command to quickly search through the device (note that this would be faster if I were to perform this step against a forensic copy of the flash storage that has been copied to my hard drive):
root@linux:~# dd if=/dev/sdc bs=4096 | strings -tx | grep -i -e JFIF -e EXIF 10ba06 Exif 237a06 Exif 237c88 JFIF 29da06 Exif 2d7a06 Exif 311205 @Exif 311488 JFIF 38ea06 Exif 38ec88 JFIF 405206 Exif 43f206 Exif 517206 Exif 5e2a06 Exif 6aba06 Exif <snip> 3b5fa04 8EExif 3c0e204 8EExif 3ca3204 8EExif 3d36205 Exif 3dc9a04 8EExif 3e58206 Exif 3ef0a04 8EExif 3f96a04 8EExif 402fa04 8EExif 40d1204 8EExif 4167206 Exif 4203206 Exif 25856+0 records in 25856+0 records out
When I did this the total number of strings found was 111, so now I'm reasonably confident that there are JPEG images stored somewhere within the flash storage even though the FAT isn't showing anything.
So how do we carve out these files? We'll use Foremost. The "-o output" parameter tells Foremost to save the results to a directory called output, and the "-t all" tells Foremost to extract all file types that it recognizes (version 1.5.6 recognizes jpg, gif, png, bmp, avi, exe, mpg, wav, riff, wmv, mov, pdf, ole, doc, zip, rar, htm, and cpp). I'm asking Foremost to recover every file type just in case interesting files have been stored on this photo frame:
root@linux:~# foremost -o output -t all -i /dev/sdc Processing: /dev/sdc |**|
Let's now change to the output/jpg directory and use wc to see how many files there are:
root@linux:~# cd output/jpg root@linux:~/output/jpg# ls *.jpg | wc -l 107
107 is close to the output result of 111 above suggesting that we are on the right track. Let's now run the file command against all extracted files to quickly confirm the file types:
root@linux:~/output/jpg# file * 00002141.jpg: JPEG image data, EXIF standard 00004541.jpg: JPEG image data, EXIF standard, comment: "AppleMark" 00005357.jpg: JPEG image data, EXIF standard 2.2 00005821.jpg: JPEG image data, EXIF standard 2.2 00006281.jpg: JPEG image data, EXIF standard, comment: "AppleMark" 00007285.jpg: JPEG image data, EXIF standard, comment: "AppleMark" 00008233.jpg: JPEG image data, EXIF standard 2.2 00008697.jpg: JPEG image data, EXIF standard 2.2 00010425.jpg: JPEG image data, EXIF standard 2.2 00012053.jpg: JPEG image data, EXIF standard 2.2 00013661.jpg: JPEG image data, EXIF standard 2.2 00015313.jpg: JPEG image data, EXIF standard 2.2 00017301.jpg: JPEG image data, EXIF standard 2.2 00019177.jpg: JPEG image data, EXIF standard 2.2 00020909.jpg: JPEG image data, EXIF standard 2.2 00022729.jpg: JPEG image data, EXIF standard 2.2 00024657.jpg: JPEG image data, EXIF standard 2.2 00026405.jpg: JPEG image data, EXIF standard 2.2 00027705.jpg: JPEG image data, EXIF standard 2.2 00028837.jpg: JPEG image data, JFIF standard 1.01 00030577.jpg: JPEG image data, JFIF standard 1.01 00032049.jpg: JPEG image data, EXIF standard 2.2 00033309.jpg: JPEG image data, EXIF standard 2.2 00034545.jpg: JPEG image data, EXIF standard 2.2 <snip>
Indeed, by examining these files with an image viewer I can confirm that we've successfully recovered 107 JPEG images from the digital photo frame's internal storage even though they weren't showing up in the FAT.
Next step is to wipe the content of the internal flash storage to try to prevent recovery of these files.
You can either wipe the flash storage so that it can be immediately re-used, or you can wipe it so that the partitions need to be re-created and the file system formatted before the digital photo frame can be reused. The former is quicker but only appropriate if there is nothing sensitive in the file names and the photo frame is staying in your possession. The latter requires more steps but is recommended if you are planning on selling or disposing the digital photo frame.
NOTE: Be extremely careful with these commands. Accidentally selecting the wrong device (ex: /dev/sdb instead of /dev/sdc) can result in inadvertently wiping your computer's hard drive!
There are a number of tools that can do this but for this article we'll stick with dd. In order to wipe the flash storage so that it can be re-used without having to be re-formated, we simply mount the storage, delete any present files, and create a large file filled with junk data. Given that the internal storage is not very large (about 105 MB) I do not have to worry about my file reaching the maximum file size for the file system type before filling the entire partition with random data:
root@linux:/media/KODAK# dd if=/dev/zero bs=4096 of=data dd: writing `data': No space left on device 25798+0 records in 25797+0 records out
After creating the file, make sure to unmount the volume to force and confirm that the contents of the file are written to storage, then mount the volume again and delete the file "data".
The alternative sanitization method is to wipe the entire flash storage which will require having to reformat it before it can be reused:
root@linux:~# dd if=/dev/urandom bs=4096 of=/dev/sdc dd: writing `/dev/sdc': No space left on device 25857+0 records in 25856+0 records out
Note: If you would rather fill it with a specific hexadecimal value instead of /dev/zero or /dev/urandom, one trick is to pipe the output of the dd command into tr, and pipe the results of that back into dd. Below is how you would fill the flash storage with hex value FF (octal value 377):
root@linux:~# dd if=/dev/zero bs=4096 | tr '\000' '\377' | dd of=/dev/sdc
See results below:
root@linux:~# xxd /dev/sdc 0000000: ffff ffff ffff ffff ffff ffff ffff ffff ................ 0000010: ffff ffff ffff ffff ffff ffff ffff ffff ................ 0000020: ffff ffff ffff ffff ffff ffff ffff ffff ................ 0000030: ffff ffff ffff ffff ffff ffff ffff ffff ................ 0000040: ffff ffff ffff ffff ffff ffff ffff ffff ................ <snip> 01f6590: ffff ffff ffff ffff ffff ffff ffff ffff ................ 01f65a0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 01f65b0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 01f65c0: ffff ffff ffff ffff ffff ffff ffff ffff ................
In this part we show how you can use the internal storage of a digital photo frame as an encrypted volume. The native flash storage that comes with most digital photo frames is usually too small for most people's needs. Often it only has 128, 256, or 512 MB of storage which fills up quickly when storing photos taken by a 5 to 10 megapixel camera. So we'll show how you could use your digital photo frame's native flash storage as an encrypted volume, perhaps as a secondary backup for your most critical documents.
Note that in our case the the Kodak digital photo frame that we used did not seem to like it when the TrueCrypt volume spanned the entire flash storage (/dev/sdc) instead of only the FAT16 partition (/dev/sdc1). Whenever we tried to create the encrypted volume using the entire flash storage, upon powering on the photo frame the LCD screen would indicate that it needed to format the memory, and our system was unable to detect the USB device until this had completed.
The instructions for creating the encrypted volume are straightforward to anybody who has done so on a USB drive as they are pretty much identical. The instruction are as follows:
1) With the photo frame connected to your computer, launch TrueCrypt. Select Volume | Create New Volume
2) Select Create a volume within a partition/drive
3) Select Standard TrueCrypt volume
4) For Volume Location, select the proper device for your frame's FAT partition (/dev/sdc1 in our case)
5) Specify your encryption options, password, and file system
6) Click Format, acknowledge the message confirming all data on the device will be wiped, and click Yes
For the last step above it may take a few minutes before receive an acknowledgement message from TrueCrypt stating that the volume has been successfully created.
If all went well, you now have a Digital Photo Frame in which the internal memory is an encrypted volume. In order to use it, connect the frame to your computer, in TrueCrypt click on Select Device, select your photo frame's flash storage, then select Mount and enter your encryption password.
That's it for this article. Originally there was going to be a fourth part that discussed how to store an encryption key in a random area or in the file slack of the digital photo frame's flash storage, however it didn't meet the cut because it was felt that it was of limited value in practice (you would need to use dd every time to extract the key while also ensuring that your command history didn't betray this location, as well as having to securely wipe the extracted key after every use, among other reasons). However those who wish to pursue this can most likely piece the steps together by reading our articles that discuss how to use dd as a hex editor along with Part II of Examination of overwritten files with The Sleuth Kit.