Processing Vista $RECYCLE.BIN

The MS Windows recycle bin differs in Vista from XP. In XP, an deleted file is moved to the "\Recycler\$SID\ folder where "$SID" is the security identifier of the user deleting the file. The file is renamed, in the format "D" An "info2" file is created containing the file's original name, file deleted time, and original file size. In Linux, the command line tool rifuiti can be used to parse the info2 file. More information about the XP recycle bin can be found here.

Vista has a different schema, however. Deleted files are moved to the "\$RECYCLE.BIN\$SID\" folder, but this time no info2 file is created. Instead, a pair of files is created: the file itself is renamed randomly beginning with "$R" and an information file containing the 16-bit filename with the same name as the data file only beginning instead with "$I". Both files take on the extension of the original file. Deleted folders are subjected to the same deletion scheme, but the files and subdirectories within the deleted folders retain their original names and paths within the directory and are not otherwise represented in the recycle bin. The original file size and date of deletion are also contained in hex within the file. More information about the Vista recycle bin can be found here.

In Linux, one can quickly examine all the filenames of deleted files found in the Vista recycle bin. In the command line, simply change to the "/$RECYLE.BIN/$SID/" directory and issue this simple command:

# strings -el -f \$I*

The -el flag tells the command to look for 16-bit encoding and "-f" to print the filename of each processed file. The output resembles the following:

# strings -el -f \$I*
$I3XJZSP.docx: C:\Users\957630\Documents\1234567.docx
$I42NQXL.lnk: C:\Users\Public\Desktop\HP Total Care Advisor.lnk
$I4ULAZJ.url: C:\Users\957630\Desktop\Videos.url
$I96F8EZ.txt: C:\Users\957630\Documents\dm123.txt
$IA7VIFO.lnk: C:\Users\957630\Desktop\Mini400.lnk
...

File size and deletion date of files of interest can be determined from a hex view of the file.

0000000: 0100 0000 0000 0000 da26 0000 0000 0000 .........&......
0000010: d02a 0401 4c5c c901 4300 3a00 5c00 5500 .*..L\..C.:.\.U.
0000020: 7300 6500 7200 7300 5c00 3900 3500 3700 s.e.r.s.\.9.5.7.
0000030: 3600 3300 3000 5c00 4400 6f00 6300 7500 6.3.0.\.D.o.c.u.
0000040: 6d00 6500 6e00 7400 7300 5c00 3100 3200 m.e.n.t.s.\.1.2.
0000050: 3300 3400 3500 3600 3700 2e00 6400 6f00 3.4.5.6.7...d.o.
0000060: 6300 7800 0000 0000 0000 0000 0000 0000 c.x.............
0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................

The first 8-bits of the file is the file header, the second is the file size, and the third is the deletion date. Thus, for this file, the original file size was 0xda26 or 55846 bytes:

# echo $((0xda26))
55846

And, the file deletion date was 0xd02a04014c5cc901 or "Fri Dec 12 03:23:06 PST 2008." This determination is a little more difficult and would benefit from a script, but for now, I'll show how its done manually.

Windows Time is recorded in Little endian format, thus we start with 0x01c95c4c01042ad0 which is 128735545861090000 nanoseconds since January 1, 1601. We devide by 10,000,000 (to convert from nanoseconds to seconds), and then subtract 11644473600 (the number of seconds between Windows Time and Unix Time, which is the number of seconds since January 1, 1970). Finally we convert to standard notation with the "date" command.

# echo $((0x01c95c4c01042ad0))
128735545861090000

# echo $((128735545861090000/10000000))
12873554586

# echo $((12873554586-11644473600))
1229080986

# date -d @1229080986
Fri Dec 12 03:23:06 PST 2008

In one command, this looks like:

# date -d @$((((0x01c95c4c01042ad0)/10000000)-11644473600))
Fri Dec 12 03:23:06 PST 2008

I'll contemplate writing a script to automate the whole process--filename, file size, deletion date--in the future. But for now, this will work.

linuxsleuthing code project

Computers, iPods, Thumbdrives, oh My!

I've been busy with a major case during which many smaller cases have walked through my door. I began longing for a way for criminal investigators to be able to conduct preview examinations of digital storage devices without having to drop the devices off at the computer lab.

Many of the questions I receive are relatively simple to answer:

• "Who owns this computer/iPod?"
  
• "Does this computer have any illegal images/videos/files?"
  
• "Are there any emails/chats between X and Y stored on this device?"

While I understand a preview examination of a digital storage device is not the equivalent of full forensic examination, the plethora of storage devices and the dwindling number of public sector forensic computer examiners begs for an intermediate solution. And, while forensically sound boot-discs exist, e.g., CAINE or the FBI's ImageScan, they do not lend themselves to criminal investigators with little or no computer forensics training (CAINE) and/or they only do one thing well (ImageScan).

My idea is to modify a disc like CAINE to include scripts accessible through a right-click menu that make basic digital storage device examination simpler. Virtually anyone who uses a computer understands the basics of navigating a file system with a file browser, and Nautilus is the file browser of choice in CAINE which utilizes the Gnome desktop. Nautilus has a built-in option for right-click scripts, and you'll find five already deployed in CAINE. The CAINE scripts have limitations and appear to have been obtained from g-scripts. When using them in a filtered file list (e.g., searching for documents in Nautilus), the scripts don't always work, nor are the scripts from a root Nautilus window.

My Solution

I created (and continue to create) a series of Nautilus scripts with which to remaster CAINE or add to an installed Linux distro. The problem has been that I do this across five different computer platforms, tweaking things as I go, to the point I'm not sure on which computer any particular script resides. Plus, no one else has access to them for use/testing/improvement, at least until I remaster CAINE and release. Therefore I have created a the LinuxSleuthing Google Code Project. I'll be populating the site with the scripts I create and encourage any feedback in the form of requests, bugs, suggestions, or improvement to the code.

The HTCIA Central California Chapter will be conducting training in September in the use of CAINE with many of these scripts, with primary focus on finding and previewing images, basic keyword searching, and iPod ownership identification, so the immediate focus of the scripts posted to the code project will be on these topics.

The scripts will follow the unix principle of "do one thing and do it well." They are not designed to run blind, finding all occurrences of index.dat, for example, and parsing them for histories. It will be up to the user to find the files and apply the parsing script. While this might sound labor intensive, it allows the user to surgically strike at desired data as time allows rather than wait for whole disk searches. That said, this concept may morph as real world trials expose flaws or beg enhancements.

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!