Digital photo frame forensics

August 8, 2011

This article experiments with a Kodak EasyShare digital photo frame using Ubuntu and The Sleuth Kit.

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!


Part 1: Recovering photos from digital photo frame internal flash storage

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.



Part 2: Wiping the digital photo frame's flash storage

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  ................



Part 3: Creating a TrueCrypt volume on a Digital Photo Frame

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.