Identifying Owners of Stolen iPods

iTunes is your friend

I have gone from years of computer forensics without ever encountering Apple Products in any meaningful way to seeming only dealing with Apple laptops and iPods. I've been asked to attempt to identify the previous owners of suspected stolen devices. Today I'll discuss the iPod.
iPods are obviously small, portable devices that are easily stolen. I don't own one myself, so I don't know much about their internal functioning. I do know from experience that depending on the generation of the device, the file system can by fat32 or hfs+.

Determining the current username

One of the first things I discovered in trying to identify the current owner is that the iPod can be plugged into a Windows or Mac computer with iTunes installed, and iTunes will reveal the user name. Turning on the device and navigating the menu system will do the same. Neither effort is forensically sound, however, and changes to the stored data can/will occur.

In an Ubuntu Linux system (properly configured to not automount), the user name is displayed in the Disk Mounter applet or in Nautilus as "User's iPod" where User is the volume name of the data partition on the iPod. You can see this with the SleuthKit's mmls command using something like:

# mmls /dev/sdf

The problem with this approach is:

1. This is the current username. And it's just a username. If it's something like: Chuck E. Cheese, well you don't have much of a clue as to who the person is.
2. If the iPod is stolen and the owner data has been changed by theif, then you don't have the victim's username, but instead the suspect's.

Determining the victim's real name/email address

A little "googling" led me to understand that iTunes purchased music contains the purchaser's email address embedded in the song to help Apple track music pirates. A little hexeditor fun helped me determine that there is quite a bit of information embedded in the .m4p songs from iTunes, including email address of the purchaser AND the first and last name. The name's source looks to be the account information from registering with iTunes (which requires credit card payment), but I have not confirmed this.
My approach to determining the victim's real name is to search the unallocated portions of the partition for the tag "name" followed immediately by an alphanumeric character (alphanumeric in the event that I'm incorrect in the assumption that the music purchaser's name coming from the iTunes credit card-verified account).
Using the Sleuthkit's blkls command to extract unallocated blocks, we pipe them through grep to search for the name tag:
# blkls /dev/sdf2 | grep -aE 'name[0-9a-zA-Z]+'
This could be similarly accomplished with:
# blkls /dev/sdf2 | grep -aE 'name[[:alnum:]]+'
The breakdown of the command is as follows:

1. blkls /dev/sdf2 - blkls sends unallocated blocks to standard input (the terminal window). Rather than choose the raw device /dev/sdf2 and designate an offset, I have chosen to address the partition directly for simplicity.
2. grep -aE - grep searches the data piped to the terminal. The -a flag treats the data as binary, display matches in the terminal rather than just reporting match occurred. The -E treats the following quoted expression as a regular expression rather than matching it literally.
3. 'name[0-9a-zA-Z]+' or 'name[[:alnum:]]+' - both expressions mean: search for the ascii string "name" followed immediately by at least one number or letter.

The grep search could be run against the allocated data as well, to compare the results to the unallocated data as you assess the likelihood the unallocated matches represent information about a previous owner.
This methodology represents a "down and dirty" approach to determining ownership. It does not provide a well documented location evidence can be found to prove theft for court purposes. Consider it a triage approach to determining ownership to propell a case forward. Further documentation would be needed to produce useful forensic information, such as documenting byte offset, carving the files from which the hits were made, etc., but this exceeds the scope of this article.