Recycle Bin, an icon on the Windows desktop that stores the temporarily deleted files and can retrieve files that might have been deleted accidentally.Microsoft’s Recycle Bin is a special folder that stores files deleted via Windows Explorer. By default, the files deleted from removable media, floppy disks, network drives are deleted permanently. Even the files residing on hard drives when deleted via the Command Prompt or holding the Shift Key at the time of deletion are permanently deleted, without being stored in the Recycle Bin. When I say permanently deleted, a forensic examiner might still recover the permanently deleted file using data-carving tools as long as the memory location of the file has not been overwritten or reused for another file. From the forensic point of view, Recycle Bin is a very evidential as it may contain plethora of evidence.
When the user views the Recycle Bin, the files are displayed with their original file named and when these deleted files are restored from the Recycle Bin, these are returned to their original directory with same filename as earlier. A separate section in this article has been written on the Restore feature. For now, let’s continue with the architecture of Recycle Bin.
Recycle Bin Architecture
The actual location of the Recycle Bin depends on the version of the Operating System and the underlying File-System. On Windows 98 and prior, typically the FAT (File Allocation Table) file system, the Recycle Bin is stored in ‘C:\Recycled’ and on Windows XP/NT/2000 with the NTFS file system (New Technology File System), it is located in ‘C:\Recycler’. The later version of Windows viz. Windows Vista\7\8\8.1, the Recycle Bin is in C:\$Recycle.Bin folder. These folders are normally hidden from the end-user. A recycle bin folder i.e., either a Recycler or $Recycle.Bin is placed on each drive, here drive refers to a logical partition and is assigned a drive letter.
Fig.1.1 (RECYCLER in Win XP) Fig.1.2 ($Recycle.Bin in Win 7)
$Recycle.Bin versus $RECYCLE.BIN
Per my observations, the name of the $Recycle.Bin folder on the initial/system partition i.e., C:\ is displayed as $Recycle.Bin (with upper-case and lower-case characters). However, in the other partitions it is displayed as $RECYCLE.BIN (all capital letters)
Fig 2.1 ($Recycle.Bin in System Partition) Fig 2.2 ($RECYCLE.BIN in other partitions)
Prior to Windows Vista, a file in the Recycle Bin is stored in its physical location and renamed as D<originating drive letter of the file><#>.<original file extension>. For Instance if a file ‘Readme.txt’ has been deleted from drive C:\ then it could be renamed as DC1.txt. A hidden file called INFO2 stores the file’s original path and original name in binary format.
In Windows Vista and later, when a file is deleted with the NTFS several things occur. The $MFT entry is updated with a new record number for the parent, that means the parent now becomes the Recycle Bin instead of its original location. Then the file is given a new name with a six random characters and the original file extension. The original file deleted is renamed as $R< alpha-numeric >.<original file extension> and a paired administrative file is saved as with the same six random characters used earlier along with original file extension $I<alpha-numeric>.<original file extension>. For example, if a file ‘Readme.txt’ is deleted it could become $RETRFL3.rtf and the paired administrative would be $IETRFL3.rtf
Each of these sub-folders will be referring to as a Recycle Bin, and they will be distinguished from each other based on the user they belong to This folders naming convention is based on the Security Identifier (SID) of the user and it remains the same for Windows XP, Vista and 7. It is often important to be able to match a SID with a specific user; SID is an alpha-numeric string that is used by Windows to uniquely identify an object – like a user or a group. The SID does not exist until the user logs-on for the first time, even though the user profile is created.
Files that are deleted by other users on the machine are not placed under the same Recycle Bin. Each user has a private Recycle Bin, thereby preventing mingling of deleted files or folders. This is because when a user deletes a file, the file appears in one’s own SID folder. A user will have a private bin on each logical partition; this means if I have two users and 5 partitions, each of the partition will have two subfolders indicating two different SIDs. In a way there would 10 Recycle Bins, 5 recycle bins for each of the two users.
Let’s analyze S-1-5-21-1004336348-682003330-725345543-500
- “S” means the string is a Security Identifier.
- “1” refers to the Revision Level.
- “5” is the Identifier Authority.
- The remaining part of the string, from “21- 100433-…45543” is the Domain or Local Computer Identifier.
- The “500” at the end is known as the Relative ID, 500 means the user is a system administrator. Any group or user that is not created by default will have a Relative ID of 1000 or greater.
Decoding Recycle Bin
The $I file
The $I files contain provide valuable information even though the paired $R file is overwritten. The $I files records the following metadata about original file:
- Name of file deleted
- Size of file deleted
- Full path the deleted file
- And data the file was sent to Recycle Bin
For testing, I’ve deleted a text file ‘4n6Xplorer_Delete.txt’ of size 26 bytes.
For the above deleted file, a $IR4HB6A.txt and $RR4HB6A.txt file are created accordingly.
The $I file stores the following information when decoded
1. The first 8 bytes, bytes 0-7, is the $I header, always 01 followed by seven sets of 00.
2. The second 8 bytes, bytes 8-15, is size of the file in bytes stored in hex. Because of the Big Indian/Little Indian conflict it needs to be flipped i.e., 00 00 00 00 00 00 00 1A. When this hex value is converted into decimal it is 26 bytes. Little Endian format means the lower-ordered byte of the number is stored in the memory at the lowest address. Or, in other words, the little end is read first. However, when one reads English, one reads the larger order first, what is known as Big Endian.
3. The third octet of 8 bytes, bytes 16-23, stores the date/time the file was deleted, in standard Windows date/time format. Represented as an offset from Midnight, January 1, 1601, expressed in 100 nano seconds. Since this is a number in Little Endian format, convert it in Big Endian format. To convert this number to a more usable size, one multiplies the number by 100 (to convert it from 100 nano-seconds to nano-seconds) and then divides it by 1,000,000,000 to convert it from nano-seconds to seconds. To calculate the exact time and date at which the file was deleted, one just needs to add the result of the calculation, to January 1, 1601.
Thankfully, the date/time of the file deleted can be interpreted by simply bookmarking the 8 byte date in Encase or by the Hex Value Interpreter in FTK.
4. The final set of information after the header, the file size, and the date is the full path and file name of the original file, before it was deleted. This is from file offset 24 and runs for the length of the path and file name.
The $R file
The $R file is a copy of the deleted file.
The $I30 file
The $I30 file is a Windows NTFS Index Attribute that can assist in identifying deleted files, including those that have been wiped or overwritten. Thus even if the original file no longer exists, we may still be able to identify its name, file size, and original timestamps. Evidence may still be found in Index Attributes even if wiping or anti-forensics software has been employed.
It can provide informatio on full filename, parent directory, file size, creation time, last modification time, MFT change time, access time. You can either use INDX parser software or EnCase EnPack to parse these $I30 files.
When a folder that contains a file is sent to the Recycle Bin, each item i.e., the folder and the file is treated as a separate deletion. Individual $I and $R are created for the folder and for the file that was in the deleted folder. When a file is restored, the corresponding $I and $R are erased from the Recycle Bin folder and the $R and $I are used to recreate a new copy of the original file and place it where it was prior to deletion. If the restored file is deleted again, a new $I and $R are generated, and these files have names that are different than the previous $I and $R.
If a file that is deleted was originally in a folder that no longer exists, Windows will each re-create the folder(s) that would be necessary to hold the file. If a folder has to be re-created, an entirely new folder is created and the original deleted folder will not be removed from the Recycle Bin.
When a file is sent to a Recycle Bin, it has a “deleted” time-stamp and a “created” time-stamp value, which are recorded in the $I-file. When this file gets restored, it loses the “deleted” timestamp, but gains a “modified” and “accessed” time-stamp. When a folder is sent to the Recycle Bin, it too has the “deleted” and “created” time-stamp, but when it is restored, it only retains the “created” time-stamp, and never gains the “modified” or “accessed” time-stamp, unlike what happens with a file.
There will be “desktop.ini” file in a Recycle Bin which is a system file and provide information to Windows Explorer about how to display the contents of the folder.
Tools for Recycle Bin Forensics
- Rifiuti – A Recycle Bin Forensic Analysis Tool for INFO2 by Intel Security (McAfee)
- Rifuiti 2 – A rewrite of Rifiuti that supports upto Windows 10
- Windows 7 Recycle Bin EnScript by Bruce W. Pixley
- INDXParse – A $I30 file parser by Willi Ballenthin
- FILETIME Extractor – A MFT FILE and INDX record parsel by Kazamiya
- WISP – Windows parser that targets NTFS index type attributes by TZWorks
In the next post, I'll give an insight on differences between WIndows 8.1 & Windows 10 Recycle Bin.