Abstract: With the advent of Vista, Microsoft changed the structure of the Recycle Bin making it more difficult

for investigators to determine what files were discarded. Traditionally, investigators were able to use rifiuti to parse the INFO/INFO2 file found in previous versions of the Recycle Bin. This document attempts to detail the changes in the Recycle Bin and to provide a fast method for extracting the necessary data from the Recycle Bin during a media analysis.

Forensic Analysis of the Vista Recycle Bin

Introduction:
Microsoft has changed the underlying structure of the Vista Recycle Bin. No longer does the Recycle Bin rely on a single INFO2 file as a database for the Recycle Bin. Instead an index/deleted file pair now resides in the Recycle Bin. When performing media analysis, an investigator would now need to extract data from every index file that he could locate to ascertain what was deleted and when. This paper discusses the structure of the Vista Recycle Bin and compares it to the XP Recycler.

Recycle Bin Layout

XP stored deleted files under C:\Recycler\<User SID>\. In Vista C:\ $Recycle.Bin\<User SID>\ holds the pertinent files. Each Security Identifier (SID)1 corresponds to a specific user or system account. NOTE: Neither XP nor Vista creates a Recycle Bin folder for a user until the user deletes a file. Therefore a single user system will likely only have two folders: one for the administrator account and one for the user. When looking at the SIDs there is a short hand for determining to which account the directory belongs.

http://support.microsoft.com/kb/243330 for more info on common SIDs. The information between S-1-5-21 and the final numbers xxxx has some relation to the domain.

XP: C:\Recycler

Two points should be noted about the above illustration.2 The short SID (circled in red) is the Recycle Bin for the System user. This should never be seen! There is little (absolutely no?) reason for a user to ever use this account and probably indicates malicious behavior. For the standard SIDs, notice that the entire SID is identical except for the last block of numbers. The -50x accounts are the built-in Windows accounts; specifically in this case, the -500 is the administrator account (in XP and Vista). The -100x accounts are the user accounts.

Vista: C:\$Recycle.Bin

Microsoft has a good article on this here in KB314828. The domain information is a randomly selected number based on the installation and domain. This enables the system to control permissions.

Notice the similarities in Vista. The -1000 account is the main user account; the -1001 is a second user (limited), the -500 is the administrator and the -501 is the guest user. An investigator can use Joe Richards tool 3 which works on NT, 2000, Server 2003, XP and Vista to determine the username associated with the SID. Another tool is sid2user.4 Within the SID directory the landscape changes significantly. XP has an austere look compared to the busy vista presented in the Vista recycling bin. Regardless of which system one is investigating, they both treat files and directories in a similar manner. When a file is deleted, it is moved to the Recycle Bin and several operations are performed onto the filename (this will be discussed in detail in the next section). When a directory is discarded, the directory name has the same operations performed on it that a single file has. But, if one navigates into the deleted directory, one finds that none of the files and directories within is changed. The Recycle Bin only performs changes to the parent folder.

Deleted File Storage

Inside the XP Recycler, each deleted file receives a new name. The file extension remains unchanged, but the name has a transformation following this scheme: DC + sequential number. A file named new_bmp.bmp might appear in the Recycler as DC3.bmp. Delete an additional executable and it would be named DC4.exe. According to Lance Mueller of http://www.forensickb.com/ , a reason exists for the DC nomenclature. He wrote that the D stands for Deleted and that the second letter (in this case a C) stands for the drive from which the file was deleted. He also commented that the indexing was reset upon emptying the Recycle Bin. The authors experience is that the reset takes some time to occur. It would appear that XP has a background method that resets the index value at some point in time after the Recycle Bin has been emptied and before it is refilled. XP enters the file information (deletion date, size, and filename/path) into a flat file called INFO2. Keith Jones, 5 author of rifiuti has written a paper6 on the structure of the XP Recycler and his rifiuti tool7 parses this INFO2 file. To understand the previous versions of the Recycler, one should read Jones work. This paper only repeats enough information to explain the differences between the previous structures and the current structure in Vista.

3 4 5 6 7

SidToName: http://www.joeware.net/freetools/tools/sidtoname/index.htm Sid2user: http://evgenii.rudnyi.ru/soft/sid/ Keith Jones: keith.jones@foundstone.com http://www.e-fense.com/helix/Docs/Recycler_Bin_Record_Reconstruction.pdf http://www.foundstone.com/us/resources/proddesc/rifiuti.htm

XP Recycler; Note the INFO2 file.

Inside the Vista Recycle.Bin, each deleted file receives a new name while maintaining the extension. The naming is different from XP though. Vista changes the name using this scheme: $R + <5 random alphanumeric characters>. A file named new_bmp.bmp could be changed to $R3DE46.bmp. The biggest difference is not in the rewriting of the file name, but is in the database (or lack thereof). Vista shuns an INFO2 file.8 Instead, there is an index file for each recycled file. The pairing is easy enough to understand. From the earlier example, when new_bmp.bmp is deleted, it receives a name change to $R3DE46.bmp and then receives an index file: $I3DE46.bmp. Notice, the only difference in naming is the $I versus the $R.

Note the pairing of the files.

The index file $I for each pairing has a set structure. In many ways, this is similar (read: almost identical) to the INFO2 database in previous Windows incarnations. Here is one index file viewed in a hex editor:

The author cannot find a definitive reason for the move away from the INFO2 file. The best assumption is that the procedure for updating and maintaining the INFO2 file required too much work. When all of the files are emptied from the Recycler, XP may reset the INFO2 DB which includes a reset of the numbers. If DC10 is deleted from files DC4-DC20, the INFO2 DB may simply erase that portion of the DB and add any new entries to the end. The only time the DB would be cleaned up and defragmented would be when the Recycler was emptied. By implementing file pairs, Vista precludes the need for database maintenance. The author examined one users recycle bin and discovered that the DC numbers began around 290 and continued for another 160 or so files and had an INFO2 file about two megabytes in size. This system had not reset the numbers to zero and was not attempting to use the old numbers. One would assume that this user had not emptied the recycle bin and therefore the INFO2 DB had not had the chance to reset the DC#.

Hex editor view of an index file.

There are several things of interest about the index file. First, the file is always the same size: 544 bytes. Second, the file always begins with 0x01 in byte 0. There does not seem to be any explicable reason for the initial byte of 0x01. Whether the index refers to a directory, link or file, the first byte is always the same. The first byte (0x00) is followed by seven empty bytes. Bytes nine through twelve (0x08-0x0B) provide the deleted file size. In the above example, that would be a hex value of AD8.9 The file size represented here is: 2776 bytes. As an aside, there is sufficient padding (bytes thirteen to sixteen) to allow for larger files, but one would not reasonably expect to ever see those bytes filled for that purpose. Beginning with the seventeenth byte and continuing for eight bytes (0x10-0x17) dwells the Windows NT timestamp. After converting this number to decimal, it can be computed on a Windows machine using the following command: c:\w32tm /ntte <time/date number>. That will output the file in a readable time format. Using the preceding command, the above time stamp translates to: 148548 18:49:58.5780000 9/18/2007 2:49:58 PM. The first number, in 24 hour time, is Greenwich Mean Time. The second is set to the local computers time zone.

Converting the time stamp to human readable format with w32tm.

When investigators perform these calculations from a non-Microsoft based computer, a few more steps are needed as the number needs to be converted to UNIX time. The number must be divided by 10,000,000 and the resulting answer must have 11,644,473,600 subtracted.10 ((128346149985780000/10000000)-11644473600) = 1190141399.
9

Literally, the hex is stored: 0xD8 0x0A 0x00 0x00. With little-endian, each pair is read from right to left: 0x00 0x00 0x0A 0xD8. The number is concatenated: 00000AD8. The leading zeros are dropped: AD8. That is then converted to decimal: 2776.

This answer can then be interpreted by any utility that can output UNIX time in a readable format. A free online conversion tool is available at http://www.onlineconversion.com/unix_time.htm . Finally, byte twenty-five (0x18) through the end of the file (EOF) contains the Unicode text for the original pathname and the filename. Microsoft includes plenty of padding in this file for the filename and directory. The last modified, access, changed (MAC) times for the original file would still be stored in the Master File Table (MFT). This would be the same as with previous versions of Windows.

Other various points

Vista does not seem to consistently clean out the index files after the recycle bin has been emptied. Occasionally index files are left behind and can provide an investigator with more information about earlier activity on the system. Whether these indices get removed at a later date during a cleanup operation or whether they live an orphaned life forever is not yet clear. Then again, XP does not seem to clean up the Recycler properly which leads one to believe that they may live till they receive more direct intervention. In Vista, if one navigates to the $Recycle.Bin directory from a GUI (Explorer), he will not see the file pairs. Vista displays the file with its original name (as XP does). Right-clicking on the file will show the file creation date and the deletion time. The only way to see the file pairs is to navigate to the appropriate directory via the command prompt. A user doing that will only have access to their own SID directory unless they started the command prompt using the run as option. Vista tries very diligently to protect the $Recycle.Bin directory. The directory is set as Hidden and System. The SID directories have the same settings on them. C:\ $Recycle.Bin\dir /a is the easiest manner to view all of the files in the directory. For anyone desiring to explore the recycle bin in Vista, it was easiest to copy the recycle bin to a different directory using: C:\xcopy /H C:\$Recycle.Bin C:\target_directory. Vista does not ever search the $Recycle.Bin. Vista Search has been prohibited from searching and/or recording any system files and directories. While Search can be made to examine hidden directories, it cannot be made to index system folders. In fact on page four of the Admin Guide for Windows Desktop Search (WDS) 3.111 states that desktop search will not store information about documents or e-mail once they have been deleted.
10

This information came from: http://support.citrix.com/article/CTX109645 . This was pulled on September 26, 2007. 11 This guide was downloaded on 9/4/2007 from: