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\\. In Vista C:\$Recycle.Bin\\ 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.
XP: C:\Recycler
1
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.
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
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
Richard’s 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.
2
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.
3
SidToName: http://www.joeware.net/freetools/tools/sidtoname/index.htm
4
Sid2user: http://evgenii.rudnyi.ru/soft/sid/
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 author’s 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.
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 + . 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
5
Keith Jones: keith.jones@foundstone.com
6
http://www.e-fense.com/helix/Docs/Recycler_Bin_Record_Reconstruction.pdf
7
http://www.foundstone.com/us/resources/proddesc/rifiuti.htm
8
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.
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:
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 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 user’s 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#.
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 . 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 computer’s 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.
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
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.
10
This information came from: http://support.citrix.com/article/CTX109645 . This was pulled on September 26,
2007.
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.”
11
This guide was downloaded on 9/4/2007 from: