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.

Using grep to Unearth Old Windows User Names (7/30/08):

Identifying Deleted User Accounts in Windows

I was recently presented with three laptop computers suspected as stolen. My task was to identify the owners. I chose to use a Linux forensic boot disk (one that would not automatically mount the partitions) to conduct the examination to avoid disassembling the computers to access the hard disk drives.

It became apparent on the first computer that the original user account(s) were deleted. There was a major discrepancy between the single user account (in one of the suspect's names) and in the installation date of the Windows Vista OS.

After studying Internet Explorer index.dat files recently, I decided to target deleted index.dat content. IE index.dat files contain the usernames of the active user browsing the web with Internet Explorer, as well as some local file system activities. I used the following command from the Linux terminal to fish for old user account names:

$ tr '[:cntrl:]' '\n' < /dev/sda | grep -abE --colour=auto '(((:[0-9]{16,16}|Visited):[[:space:]])|Cookie:).+@'

The command, broken down, does the following:

1. tr '[:cntrl:]' '\n' - translates control characters to line feeds to keep the grep memory buffer from exhausting.
2. < /dev/sda - feeds the raw data from device sda (the laptop hard disk) into the translate command. The device may be substituted with any file, such as a raw disk image.
3. | grep -abE --colour=auto '(((:[0-9]{16,16}|Visited):[[:space:]])|Cookie:).+@' finds the Internet Explorer cookie and history index.dat data that contains user names. The The hits are in color to help them stand out and the results can be redirected to a text file by appending the command with "> grep.results.txt". Broken down further:

• grep -abE : a=treat binary as text; b=show byte offset; E=treat as extended regular expression
• --colour=auto : show regex matches in color
• '(((:[0-9]{16,16}|Visited):[[:space:]])|Cookie:).+@' : Match expressions ":<16>: @" or "Visited: @" or "Cookie:@" where is any name of one character or more.

Example of Command Output:

254468840::2007052620070527: user@:Host: cis.cuesta.edu
286125672:Cookie:user@www.ibm.com/rc
161464680:Visited: user@http://encarta.msn.com/proscribed.html

The rest of the story

I analyzed the hits and observed user names inconsistent with those in the Vista /USERS directory. Further examination of the new user names showed they existed previous to the current user account (as determined from the index.dat date code), and urls for the users MySpace page. The newly discovered user was contacted through his MySpace page and identified the computer as stolen in June, 2007.

This a simplified discussion of the full process, which included examining the file system to determine existing users using The Sleuthkit. The purpose of the article is to demonstrate how grep can be used from a boot CD or USB device to locate Windows artifacts that show deleted accounts that can be used to identify the account holders.

In this case. the hard disk drive being examined was never mounted. Grep searches can be directed against unallocated sectors through a similar process which I will discuss at a later time.

Linux Sleuthing is Born!

I'm moving my content from slo.sleuth.googlepages.com to this blog to make updating and searching for old content easier. Hopefully, I'll even post more often and get some good feedback from the community!